coder-lfm3-1.7b-k3.1-pro

LFM3-1.7B fine-tuned on the Coder profile of a corpus generated by moonshotai/kimi-k3.1-pro (OpenRouter, canonical moonshotai/kimi-k3.1-pro-20261023).

The teacher's traces are long normative reasoning followed by a fenced implementation; this adapter moves LFM3 toward that shape for code and CS prompts.

The Q4_K_M GGUF runs fully client-side in a browser through llama.cpp compiled to WebAssembly — no GPU, no install, no account. It decodes at ~15 tok/s on an M1 Pro when it answers; reasoning-heavy prompts need a larger token budget (see below).

Training

base	LiquidAI/LFM3-1.7B, MLX 4-bit conversion
data	AJ-Gonzalez/coder-kimi-k3.1-pro-lfm3 — 69 rows → 289 train / 34 valid chunks
chunking	2048 tokens, 256-token replay, one example per chunk
LoRA	rank 8, 8 layers, 2.753M trainable (0.159%)
batch / seq	1 / 2048
optimizer	Adam, lr 1e-5
schedule	3 epochs = 867 iters, save + eval every 289
memory	--grad-checkpoint (mandatory at seq 2048 on 8 GB)
wall time	2.96 h on M1 8 GB

Validation loss: 2.861 → 2.581 → 2.594 → 2.438. The final epoch was the best, so adapters/adapters.safetensors is the keeper.

Files

• model.safetensors — 4-bit MLX weights, 946 MB, 4.503 bits/weight.
• adapters/ — the LoRA adapter (11 MB) for re-fusing or further training.

The bf16 merged model is not included; regenerate it with:

mlx_lm.fuse --model LiquidAI/LFM3-1.7B --adapter-path adapters \
    --save-path coder-lfm3-1.7b-k3.1-pro --dequantize

Usage

mlx_lm.generate --model AJ-Gonzalez/coder-lfm3-1.7b-k3.1-pro \
    --prompt "Write a Python function that returns the first 12 prime numbers, with a one-line docstring." \
    --max-tokens 3000

The LFM3 chat template is applied by default. On M1 8 GB: 46–48 tok/s, 1.19 GB peak.

Sample (greedy, 3000 tokens; the trace self-corrects a bad first draft):

def first_12_primes():
    """Return the first 12 prime numbers."""
    primes = []
    candidate = 2
    while len(primes) < 12:
        is_prime = True
        for p in primes:
            if p * p > candidate:
                break
            if candidate % p == 0:
                is_prime = False
                break
        if is_prime:
            primes.append(candidate)
        candidate += 1
    return primes

How the data was made

The generator and the full recipe are in the dataset card. In short:

1. openrouter_reasoning_corpus.py regenerates the MiMo prompts with any OpenRouter teacher (gist: https://gist.github.com/AJ-Gonzalez/31f1f8cfe45c233911e055d5cfed6da0).
2. build_profile_dataset.py coder --source corpus.jsonl renders with the LFM3 template and chunks to 2048/256.

GGUF

coder-lfm3-1.7b-k3.1-pro-Q4_K_M.gguf — 1.1 GB, 5.05 bits/weight, SHA-256 31206a46f468afbcb9147ddde78be4335840acbf8ef8e713f5369d78620020c1.

llama-cli -m coder-lfm3-1.7b-k3.1-pro-Q4_K_M.gguf \
    -p "Write a Python function that returns the first 12 prime numbers." -n 96

Q4_K_M decodes at ~37.6 tok/s on M1 (96-token smoke, not a benchmark). The f16 intermediate (3.3 GB) is not uploaded; regenerate it with tools/llama.cpp/convert_hf_to_gguf.py --outtype f16 from the fused bf16, then llama-quantize ... Q4_K_M.

In a browser (WebAssembly, no GPU)

The same Q4_K_M file runs unmodified in a static page with llama.cpp compiled to WebAssembly. Measured by @abderrahmane11 on an Apple M1 Pro, 16 GB, Chrome:

cold download + init (1.1 GB)	41.9 s
first token (prompt processing in WASM)	5.9 s
generation, short code prompt	15.4 tok/s over 93 tokens
generation, across prompt shapes	15–18 tok/s

Reading those numbers honestly:

• The 15.4 tok/s figure was taken with the model already in the browser cache; 41.9 s is the cold path. The 5.9 s to first token is WebAssembly prompt processing on a 1.7B, not a model defect — short prompts hide it, long ones do not.
• The build is single-threaded, because a static Space sends no COOP/COEP headers. A page served with those headers can use the threaded WebAssembly build, so a threaded measurement will not match these numbers.
• Prompt shape matters more than model size. "Write a one-line Python function that reverses a word" answered in 93 tokens; "Say hi in five words" spent 512 tokens reasoning and never produced an answer, at the same ~15 tok/s. At a 256-token cap that prompt returned nothing at all.

Useful way to quote it: 15.4 tok/s when it answers; 512 tokens may not be enough on prompts that trigger long reasoning. For a single benchmark number, run with a ~1500-token budget and time only the answered prompts.

To reproduce, paste AJ-Gonzalez/coder-lfm3-1.7b-k3.1-pro into abderrahmane11/gguf-runtime and pick the Q4_K_M quantization. Thanks to abderrahmane11 for the measurements.

Reasoning is a separate field

LFM3 is a reasoning-distilled model: it streams its scratchpad in reasoning_content and the answer in content. A client that renders only content shows an empty bubble for every prompt that triggers thinking — that is a UI bug, not a model failure. Render the reasoning separately and give the generation room (1500+ tokens). If you want answer-only behaviour, pass enable_thinking=false through the chat template, as the evaluation runs in this repo do.

License and attribution

• Base model: LiquidAI/LFM3-1.7B, LFM Open License v1.0. A copy is included here as LICENSE. Redistribution must keep that copy, mark modified files, and retain the upstream attribution notices.
• Commercial use: permitted only while the licensee's legal entity stays below the license's $10M annual-revenue threshold; above it this model is not licensed for commercial use.
• Data: AJ-Gonzalez/coder-kimi-k3.1-pro-lfm3. Prompts come from xtools-at/Xiaomi-MiMo-2.6-Pro-High-Reasoning-250x, itself sourced from TeichAI/claude-4.5-opus-high-reasoning-250x. Responses were generated by moonshotai/kimi-k3.1-pro via OpenRouter. Those upstream terms apply to the traces; this model is released for research/distillation consistent with them.
• No warranty. Provided as-is; the author is not liable for downstream use.