Neutrino-0.6B (certified speculative-decoding draft for Neutrino-8B)

This model exists for one purpose: it is the certified speculative-decoding DRAFT for Neutrino-8B. Paired with the 8B it delivers certified-exact speculative decoding (27,648 spec tokens compared on the ship brain, zero mismatches; 41,472 across the whole lane, zero mismatches anywhere). It is not an assistant: no chat tuning, no instruction following, no tool use, and its standalone knowledge is deliberately not a claim. If you want a small model to talk to, use Neutrino-0.6B-Chat.

A 596M-parameter base language model whose every transformer linear is stored in a proprietary ternary-family weight format eight times smaller than fp16, in a single 327,719,836-byte container (237,703,560 bytes on the wire), decoding at 225-236 tok/s on the CPU cores of a 16 GB Apple M5 with the same runtime binaries that execute Neutrino-8B. That last property is what makes it a draft model rather than a separate deployment: the verifier and the draft are the same format, read by the same code, in one process.

This is the small end of the Neutrino family, shipped as the 8B's speed companion. The honest capability numbers are in the battery below; read them before using it for anything but its intended lane (drafting, edge/embedded token generation, and as a reference artifact for ternary-family QAT at tiny scale).

• Container: neutrino-0.6b_v4.bin - TRTC v4, arch-3, 28 layers, hidden 1024, vocab 151936. 327,719,836 bytes, sha256 91c0b26d105710e755ef1ec1b5607c00da5d5cbd048fd5584135fb6fc1e19399 (working name in receipts: neutrino-0p6b_v4_base.bin; the same bytes appear as neutrino_v4.bin in the speculative-decoding lane).
• Coded transport: neutrino-0.6b_v4.tv4z - 237,703,560 bytes, lossless, byte-exact round-trip receipt banked; sha256 132d9ab758b0b1a5b9b6638e55647462dbdb4ec8345720cc98c3d4cf669e780c.
• Inside: 196 packed ternary linears + one int8 embedding lane (tied: the input embedding and lm_head share one table; container walk cross-checked in results_model_anatomy/ANATOMY.json, and the GGUF conversion records tied_output_omitted: true). Nothing in the decode path is fp16/fp32 weights.
• Base: Qwen/Qwen3-0.6B (Apache-2.0), ternary QAT by Fermion Research. Tokenizer shipped in this repo; vocabulary identical to the 8B's, identity receipt banked, which is a precondition for drafting.

Architecture

Geometry as read from the shipped container's header (bit-checked during the GGUF conversion, gguf/receipts/convert_0p6b.json; parameter split and byte budget from the provenance-gated walk, results_model_anatomy/ANATOMY.json):

field	value
Parameters	596,049,920 (440,401,920 ternary projection + 155,582,464 int8 embedding + 65,536 fp32 norm)
Decoder layers	28
Hidden width	1,024
Feed-forward width	3,072, gated (SwiGLU)
Attention	grouped-query 2:1 - 16 query heads, 8 KV heads, head_dim 128
Rotary embedding	full head width (rotary_dims 128), theta 1,000,000
Normalization	RMSNorm, eps 1e-6, plus per-head Q/K RMSNorm in attention
Context length	40,960 tokens (max_pos)
Vocabulary	151,936
Embeddings	tied - one int8 table serves embed-in and lm_head (eok=1)
KV cache	114,688 B/token fp16 (112 KiB): 0.47 GB @ 4k, 3.76 GB @ 32k
Coded lane	196 ternary linears (7 per layer x 28); 113 fp32 norm tensors stay full precision

Byte budget of the 327,719,836-byte container, by tensor class:

lane	bytes	share
ternary weight lane (q/k/v/o/gate/up/down x 28 layers = 196 linears)	165,150,720	50.39%
token embeddings, int8 (one tied table)	155,582,464	47.47%
per-row metadata (dims, scales, row sums)	5,508,960	1.68%
embedding row scales	1,215,488	0.37%
norm vectors, fp32 (113 tensors)	262,144	0.08%
container header	60	-

Every layer costs exactly 5,898,240 weight-lane bytes (40.0% attention / 60.0% MLP; the 8B's split is 21.7% / 78.3%). State occupancy across the 440,401,920 ternary weights: 62.263% zero / 18.873% plus / 18.864% minus (per-layer arrays in ANATOMY.json).

The scale story in one row. The tied embedding table is 26.1% of the parameters but 47.5% of the container's bytes, because the format only touches the transformer linears and the int8 vocabulary is left alone. On the 8B the same lane is 32.1% of the file. At this size the vocabulary, not the network, is the largest single object you download.

Formats and artifacts

artifact	bytes	sha256
neutrino-0.6b_v4.bin (TRTC v4 container, the file every runtime executes)	327,719,836	91c0b26d105710e755ef1ec1b5607c00da5d5cbd048fd5584135fb6fc1e19399
neutrino-0.6b_v4.tv4z (lossless coded transport, 72.5% of raw)	237,703,560	132d9ab758b0b1a5b9b6638e55647462dbdb4ec8345720cc98c3d4cf669e780c
gguf/neutrino-0.6b-base-fv5.gguf (llama.cpp-fork pack, 310/310 tensors bit-checked vs the container)	343,140,320	dd9354c4b3cd2b34195b0270540e4fa5db3811e42b6e4bdbd57958e0027e9272
gguf/fv5.patch (the llama.cpp patch that builds the fork)	-	81bf7be5eef18eb98ab4823596374c8dd6615151cf5615425973cb65942c0f73

Container md5 for cross-checking older receipts: 86565bf6183e8031943aac9fd9771385.

Quickstart

Five surfaces read those artifacts. All five execute the same container.

1. pip engine (the one-command door; pulls the container and the platform-matching native runtime):

pip install fermion-research
fermion generate --model fermionresearch/Neutrino-0.6B \
    --raw --max-new 64 "2, 3, 5, 7, 11,"  # base model: --raw skips the chat template; the prompt is positional

The first run downloads the ~0.3 GB container with no progress display in fermion 0.1.5; from 0.1.6 the download shows a progress bar. Later runs load from the local cache.

2. Reference torch path (bit-packed weights at rest, registers as a native transformers model). Download the repo first — the loader resolves the container relative to a local path only, so passing the hub id straight to from_pretrained raises FileNotFoundError:

hf download fermionresearch/Neutrino-0.6B --local-dir Neutrino-0.6B \
    --exclude "gguf/*" --exclude "*.tv4z"   # skip the packs other runtimes use

import fermion  # registers the trtc_v4 model type
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("Neutrino-0.6B")   # the downloaded directory
tokenizer = AutoTokenizer.from_pretrained("Neutrino-0.6B")
ids = tokenizer("2, 3, 5, 7, 11,", return_tensors="pt").input_ids
print(tokenizer.decode(model.generate(ids, max_new_tokens=64)[0]))

This is a BASE model: prompt it as a completion engine. Greedy decoding produces repetitive text on open-ended prompts (typical for 0.6B base models); use sampling for anything user-facing.

import fermion must come first: it registers the trtc_v4 model type. Without it Transformers raises model type 'trtc_v4' ... not recognize this architecture and advises upgrading Transformers or installing it from source. Both are dead ends — the type is registered at import time by the fermion-research package, and trust_remote_code=True will not help because this repo carries no auto_map. Add the import.

3. Native binary (the fast path; this repo ships the fermion-run-* binaries under bin/ — they execute TRTC v4 arch-3 containers generically, so the same binaries also run the 8B with no rebuild). From the downloaded repo directory:

(cd bin && shasum -a 256 -c fermion-run-macos-arm64.sha256)   # sidecar holds a bare filename
chmod +x bin/fermion-run-macos-arm64                          # hf download writes 0644
xattr -d com.apple.quarantine bin/fermion-run-macos-arm64 2>/dev/null || true  # macOS only
./bin/fermion-run-macos-arm64 neutrino-0.6b_v4.bin "1,791,1283" 128 9   # ids, n_new, threads

On Linux use bin/fermion-run-linux-x64 and skip the xattr line.

4. GGUF pack + our llama.cpp fork (also the draft-model file for llama.cpp's native speculative decoding against the 8B pack). The fork is public at fermionresearch/llama.cpp, branch fermion-fv5 (= upstream ggml-org/llama.cpp @ d67c0b41 + the FV5 patch; gguf/fv5.patch in this repo is the same change as a mailbox patch):

hf download fermionresearch/Neutrino-0.6B gguf/neutrino-0.6b-base-fv5.gguf --local-dir .
git clone https://github.com/fermionresearch/llama.cpp && cd llama.cpp
git checkout fermion-fv5
cmake -B build -DCMAKE_BUILD_TYPE=Release -DLLAMA_CURL=OFF -DGGML_METAL=OFF  # no FV5 Metal kernel yet: CPU path
cmake --build build -j --target llama-completion
./build/bin/llama-completion -m ../gguf/neutrino-0.6b-base-fv5.gguf \
    -p "2, 3, 5, 7, 11," -n 128 --temp 0 -no-cnv

5. MLX pack (Apple-silicon runtime with custom Metal kernels). Run it from the mlx/ folder of the downloaded repo — the fermion_mlx package and its tokenizer files ship there, and requirements.txt installs mlx itself:

cd Neutrino-0.6B/mlx        # the directory downloaded in step 2
pip install -r requirements.txt
python -m fermion_mlx --model ../neutrino-0.6b_v4.bin --mode gen \
    --tokenizer . --prompt "2, 3, 5, 7, 11,"

Recommended settings, by use case

use case	settings	why
draft model for Neutrino-8B	inherit the verifier — set nothing	The draft's sampler cannot change what is emitted. Under greedy the verifier's own argmax decides acceptance; under HF-assisted sampling the correction re-weights by p_i/q_i. Tuning the draft is a throughput knob, never a quality knob.
benchmark / completion reproduction	greedy, no penalty, no top-k — this repo's shipped generation_config.json	Everything in the Evaluation section was measured this way, so a bare model.generate(), an lm-eval run and fermion generate all reproduce each other.
user-facing chat	use Neutrino-0.6B-Chat instead	This SKU has no chat post-training; every graded conversational number in the family belongs to the -Chat container.

generation_config.json here is do_sample: false, no temperature, no top_k, no top_p, no repetition_penalty — deliberately empty of sampler opinion, so nothing silently overrides a harness. Top-k is not exposed on any runtime we ship; note that llama.cpp and ollama default to top-k 40, which is why the Modelfile in gguf/ pins it to 0.

Speed

Surface	Machine	Rate	Memory / protocol
native fermion-run, CPU only	Apple M5	225-236 tok/s	9 threads, 128-token greedy, mmap; per-prompt 232.89 / 224.52 / 233.56, demo median 225.37 (receipts/m5_demo_rereceipt_p3.json)
MLX 0.31.2 + Metal	Apple M5, 16 GB	201.16 tok/s	median of 5 (197.19-202.03), peak 0.526 GiB, 512-token greedy, 9-token prompt (mlx/receipts/bench_0p6b_m5.json)
GGUF pack via fermion-fv5	CPU, 16 threads	55.38 tok/s tg128 (+/-0.30)	pp512 132.18, build e07b3ec (gguf/receipts/bench_0p6b.json)
C-served draft walker inside the 8B's process	H100	1,177 tok/s	0.85 ms/token standalone, arch-3 trit_ops_8b.cu, graph == eager on a 24-token identity (results_dspec_8b/RESULTS.md section 2)

Evaluation battery (this exact container, 91c0b26d...)

Measured on the shipped checkpoint (P3 decay step-16500) with frozen, receipted meters. Stack pins: lm-eval 0.4.8, datasets 3.6.0, transformers 4.53.2, grade_probe b279c53e; generative rows evalscope 1.4.2; BFCL wheel bfcl-eval 2025.10.27.1. Canonical roll-up: receipts/ship_checkpoint_numbers.json.

A 596M model at this storage depth reads LOW on knowledge-adjacent meters. That is expected, disclosed, and the reason this SKU's story is size, speed, and drafting rather than capability.

Knowledge and likelihood

Meter	Score	Protocol
ARC-easy	53.45	lm-eval suite leg, 0-shot
Winogrande	53.43	same
PIQA	62.79	same
BoolQ	50.52	same
HellaSwag	31.64	same
ARC-challenge	24.06	same
OpenBookQA	19.60	same
Suite / commonsense average (7 tasks)	42.21	mean of the seven rows above, 0-shot
MMLU full-57	26.66	likelihood, 14,042 items, banked grade16500 (near chance; the sub-7B knowledge-conversion floor is a banked house finding)
MMLU subset-14 (frozen gate probe)	27.50	kprobe, mmlu_subset 0.25, seed 0, 14 named subtasks
SciQ	80.40	0-shot acc, lm-eval 0.4.8 (chance 25.0)
COPA	63.00	0-shot acc, lm-eval 0.4.8, n=100 (chance 50.0)
MNLI, house meter	35.45	e4_mnli_bitnet_parity, label-token likelihood, validation_matched, full 9,815 (chance 33.3)
MNLI, lm-eval stock	34.18	0-shot acc, lm-eval 0.4.8. Not comparable to the house-meter row above: the two formulations differ, and both readings sit within 2 pp of the 3-class floor
LAMBADA (openai)	25.79	0-shot acc, lm-eval 0.4.8. Long-range last-word prediction is the capability that thins first at this scale, and it is the mechanical explanation for the GSM8K and termination cells below

fp32 reference constants for context, not re-run here: MMLU 46.9, suite 53.5 (results_smallmodel_0p6b/p3_eval/base/kprobe.json -> fp32_baselines).

Generation, perplexity, behaviour

Meter	Score	Protocol
C4 perplexity	46.25	500,000 tokens, C4-val, fp32-bake meter, wall 1,329.9 s
GSM8K flexible-extract	1.67	lm-eval gsm8k, 0-shot generative, first-N fixed subset limit=300, batch 8
GSM8K strict-match	0.00	same run
GSM8K stated-format (house grader)	1.67	second greedy pass, max_gen_toks=1024, n=300
Termination rate	0.23	fraction of generations ending on EOS/stop within budget, GSM8K stated pass, cap 1024, n=300
IFEval prompt-strict	14.88	house IFEval leg, evalscope 1.4.2 (base model, no instruction tuning)
BFCL v3 macro-13	15.38	bfcl-eval 2025.10.27.1; degenerate never-calls profile (irrelevance 100.0 + live_irrelevance 100.0, all 10 calling subsets 0.0). Do NOT use this model for function calling.
genfmt QA (house)	match 0.62 / well-formed 0.80	50-row house QA probe, genfmt_max_new: 32

Against its full-precision reference at the identical parameter count (596,049,920 on both sides), every cell graded by us on one harness on one day at zero shots: 81.6% of the reference's ability across the seven common tasks, at 15.8% of the bytes (238 MB against 1,503 MB), and 78.0% averaged across all eleven tasks measured. Best-retaining axes: Winogrande 91.5%, PIQA 90.4%. Rig, pins, revision gates, and the disclosed deviations (A10G rather than A100, per-row batch size) are in results_smallclass_headtohead/RESULTS.md; raw receipts in that lane's raw/. This supersedes the earlier single-task ARC-easy read, which was one cell against a differently-sourced reference number.

The SciQ, COPA, LAMBADA, and stock-MNLI cells were measured on this container on 2026-07-27 (A100-80GB, lm-eval 0.4.8, fp32-baked TritLinear path, same pins and bake as the suite above; run receipt eval_smallclass/extra_suite.json, grade_probe.py sha b279c53e..., state sha gate PASS against f2915792...). Read them as absolute capability evidence and as a same-family comparison against our own 8B on the identical tasks (95.90 / 84.00 / 56.65 / 54.57). They are not competitive claims: a same-harness sub-1B cohort grid run on 2026-07-27 (results_smallclass_headtohead/RESULTS.md, 7 rival checkpoints x 11 tasks, 77 cells) measures this model at or near the bottom of its cohort on most of those tasks. That grid is the calibrated read; use it rather than inferring a ranking from the absolute cells above.

Not measured at this scale: MMLU-Redux (an 8B-line generative meter), wikitext perplexity (the house perplexity meter is C4-val only), and IFEval's loose/instruction variants (only prompt-strict was promoted from the raw report).

Correctness gates

• MLX refgate vs neutrino_ref.npz: teacher-forced rel err max 1.74e-06, argmax 9/9, greedy 24/24, 0 flips; cachegate 0/256 (mlx/receipts/refgate_0p6b.json, cachegate_0p6b.json).
• GGUF convert bit-compare: 310/310 CONVERT_PASS (gguf/receipts/convert_0p6b.json).
• C-runtime bit gate: 221/384 raw positions as measured, diagnosed as exactly 2 flat-margin argmax flips then greedy cascade (top-2 margins 0.02-0.20 logits); kernel output is deterministic across runs and threads (receipts/m5_bitgate_analysis.json).
• Export: double-export byte-determinism PASS, tv4z byte round-trip PASS, fp32 HF expansion self-check PASS (rc=0) (receipts/receipt_base.json).

Reproducing the battery

The model registers as a native transformers model (import fermion), so the public harnesses run directly.

# first: hf download fermionresearch/Neutrino-0.6B --local-dir Neutrino-0.6B  (Quickstart 2)
# lm-eval 0.4.12 needs accelerate for HFLM: pip install lm-eval accelerate
import fermion, lm_eval
from lm_eval.models.huggingface import HFLM
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("Neutrino-0.6B")   # the downloaded directory
tok = AutoTokenizer.from_pretrained("Neutrino-0.6B")
model.config.tie_word_embeddings = False  # tied inside the packed container; skip HF's re-tie
lm = HFLM(pretrained=model, tokenizer=tok)
lm_eval.simple_evaluate(model=lm, num_fewshot=0, tasks=[
    "arc_easy", "arc_challenge", "boolq", "hellaswag",
    "openbookqa", "piqa", "winogrande"])          # the suite-average row
lm_eval.simple_evaluate(model=lm, tasks=["mmlu"], num_fewshot=5)
lm_eval.simple_evaluate(model=lm, tasks=["gsm8k"], num_fewshot=0, limit=300)

IFEval and BFCL used the same frozen house meters as the 8B card, against a vLLM OpenAI-compatible endpoint:

pip install evalscope==1.4.2 bfcl-eval==2025.10.27.1
evalscope eval --model Neutrino-0.6B --api-url http://127.0.0.1:8000/v1 \
    --datasets ifeval bfcl_v3

Speed is re-measured with the shipped binary and the MLX pack:

./bin/fermion-run-macos-arm64 neutrino-0.6b_v4.bin "1,791,1283" 128 9   # from the repo dir (Quickstart 3)
python -m fermion_mlx --model ../neutrino-0.6b_v4.bin --mode bench \
    --tokenizer . --gen-tokens 512 --runs 5                             # from mlx/ (Quickstart 5)

Per-cell venue, version, and date receipts are in the eval-receipts repo.

As the 8B's draft (the reason this SKU exists)

A 0.6B draft proposes k tokens; the 8B verifies all k in one batched forward pass and keeps the accepted prefix plus one token of its own. A proposal is accepted only when it equals the 8B's own argmax, so the output stream is the plain greedy stream: speed changes, the text does not.

The exactness certificate

Suite	Arms	Tokens compared	Result
Ship-brain cert (8B 016c6f36...5fa0)	dynamic draft length, draft = Neutrino-0.6B + confidence head	27,648	0 mismatches (re-run 2026-07-27 against the cons3-B25 ship brain; the ifc-s50 cert 39787a2e...a3be is retired)
spec8b_dyn cert (W-baseline verifier)	dynamic + k in {2..6} x 9 prompts x 512	27,648	PASS, all IDENTICAL
Story leg: this base container as the draft, no distillation, no confidence head	k in {3,4,5} x 9 x 512	13,824	PASS, all IDENTICAL
forced-reject floors (both drafts)	k=1 dynamic / k in {3,5} fixed	256 each	output EXACT
Lane total	-	41,472	zero mismatches anywhere

Venue: Modal H100, 2026-07-26. Receipt: Neutrino-8B/receipts/dspec_cert_ifc_s50.json; lane log results_dspec_8b/logs/cert_bench_wbase_20260725.log.

Speedup by prompt class (ship brain, H100, 3-round median, baseline 395.9 tok/s)

Class	Speedup	tok/s	Acceptance behaviour
counting	x1.93	762.6	100% of drafted tokens accepted (k=6 probe: all 6 survive every verify pass, 74 passes per 512 tokens, ~7 tokens emitted per 8B forward)
facts	x1.55	613.0	96.5% survive (5.8 of 6 per pass)
prose	x1.34	531.9	free-form narrative
chat explanation	x1.13	446.6	the controller often disables drafting and pays a small resync cost
code	x1.07	426.1	hardest class for the draft

Acceptance decays with draft length everywhere except facts (97-99% flat), which is why the controller rides long drafts on facts and explanation (histogram mass at k=7), drops to 1-2-token drafts on code and counting, and turns itself off on chat explanation. The full acceptance-vs-k curves and per-class controller mechanics are in results_model_anatomy/ANATOMY.json -> speculative_decode.mechanics_probe_w_baseline.

Out of the box, without distillation

This shipped base container was never trained for drafting and carries no confidence head, and it still certifies: 13,824 tokens, all identical, run as a fixed-k draft. Bench medians on H100: k=4 facts 610.8 (x1.61), k=5 facts 648.9 (x1.71), k=5 explanation/mmlu x1.54, prose k=4-5 x1.29-1.40. Fixed-k has no disable machinery, so its floor classes drop below 1.0 (x0.46 at k=3, x0.34 at k=5); the dynamic controller with the distilled draft floors at x0.75. The distillation then buys +10 to +25 percentage points of acceptance (prose 93.6 against ~70-77, code 85 against ~50) plus the confidence head and dynamic-k layer.

On Apple silicon

The pair runs in one process on a 16 GB M5 under a 6 GiB MLX cap (peak 4.3 GiB; the draft alone peaks at 0.526 GiB). Exactness holds: the gate returns 6/6 prompts token-identical with and without --spec (results_mlx_packs/receipts/specgate_8b_0p6b.json). Throughput on Apple is class-dependent: facts 22.00 -> 25.71 tok/s (x1.168) at 0.7442 acceptance, while chat (x0.837) and prose (x0.680) regress because the batched verify is compute-bound at ~2.8x a single step, so break-even needs about 2.9 accepted tokens per round and the base draft's acceptance on those classes is 0.30-0.44 (results_mlx_packs/RESULTS.md, Deliverable 1). A code class was never measured on MLX. Use --spec on Apple for factual workloads; an FV5 sgemm path is the wired follow-up.

Draft-model artifact pins

• neutrino_v4.bin (this shipping base container, as built in the speculative-decoding lane): sha 91c0b26d...19399, 327,719,836 B
• draft_v4.bin (the distilled dspec draft, a different artifact, not published here): sha aa725821..., 327,719,836 B
• dspec draft QAT state archive/labarchive/dspec/draft_r1/final_state.pt, sha 6fc64752..., 2,385,930,847 B; confidence head conf_head.pt, sha 610d90d0..., 39,477 B
• wbase_v4.bin (the 8B verifier used in the W-baseline arms): sha 5af0c75b..., 3,875,404,812 B

The behaviour stage we ran and did not ship

A combined behaviour stage (the 8B recipe at quarter-to-full dose) was measured on this checkpoint before ship and did not clear its preregistered guard bands: instruction following moved +8.6 at quarter-dose, but general-capability guards failed at every dose. The first tiny-scale behaviour-stage receipts are banked in the eval-receipts repo. The shipped checkpoint is therefore the unmodified P3-decay base: no undisclosed behaviour training.

Weights: get them and verify them

The container ships in this repository. Fetch it and check the digests — MANIFEST.json carries the same sha256, and fermion info verifies it for you automatically:

hf download fermionresearch/Neutrino-0.6B neutrino-0.6b_v4.bin --local-dir .
shasum -a 256 neutrino-0.6b_v4.bin   # must print 91c0b26d...19399
md5 neutrino-0.6b_v4.bin             # macOS — must print 86565bf6183e8031943aac9fd9771385
md5sum neutrino-0.6b_v4.bin          # Linux — same digest

Export provenance: exported on a Modal CPU container (cpu=8, 24 GiB) from the archived QAT state (sha256 f29157924805c04a54c07a1a588e1fa5d4045da7b40026580476e31454becd4e, 2,385,891,475 bytes) with the banked exporter (export_trit_c_model.py sha 78bd8b8b..., pinned command and flags recorded in the export receipt; quantizer parameters are not published). Gates: double-export byte-determinism PASS, tv4z byte round-trip PASS, HF expansion self-check PASS. Full receipt: receipts/receipt_base.json; greedy-cache trajectory receipts/hf_greedy_cache_86565bf6.json.

Limitations

• BASE model: no chat template behavior, no instruction-following guarantees, no tool use (see the battery above).
• Knowledge-adjacent meters are at or near floor by construction (596M in a ternary-family format; the sub-7B knowledge-conversion floor is a banked house finding). Do not quote the MMLU or GSM8K cells as competitive benchmarks.
• BFCL v3 measures a degenerate never-calls profile. This model has no function-calling capability and none is claimed.
• Greedy decode parity vs the fp reference implementation is 382/384 positions on the banked gate prompts: the int8-activation runtime and the fp expansion disagree at 2 near-tie argmax positions (top-2 margins 0.02-0.20 logits; full analysis in receipts/m5_bitgate_analysis.json). Runtime output is deterministic.
• On Apple silicon, speculative decoding against the 8B is a win on factual prompts and a regression on chat and prose (see the section above). The H100 path is a win on all five measured classes.
• The GGUF pack loads only through our llama.cpp fork until upstreaming lands; stock llama.cpp, ollama, and LM Studio binaries do not know its tensor types.
• Knowledge cutoff and multilingual behavior inherit from the base model plus the disclosed feed diet (see eval-receipts).

Model lineage and methodology

Lineage in one line: base model (see frontmatter) -> ternary QAT on the streamed small-model diet corpus (scout-3 lineage, 15K steps) -> 1.5K KD-anchored decay (P2, step-16500 shipped) -> exported with the banked exporter, gates in the export receipt above. The QAT recipe, the diet disclosure, the tiny-scale behaviour-stage receipts, and every graded cell (venue, version, date) live in the eval-receipts repo; the format and engine write-ups are at fermionresearch.com/research/.

License and attribution

Weights: Apache-2.0. Derivative of Qwen/Qwen3-0.6B (Apache-2.0, Alibaba Cloud), see LICENSE. Training data: the small-model diet corpus (streamed realization) disclosed in the eval-receipts repo.

bin/ binaries: shipped in this repo under bin/ with sha256 sidecars — the same generic TRTC v4 runtimes bundled with Neutrino-8B (same EULA: free to use with these weights, no redistribution, no reverse engineering).

Contact: contact@fermionresearch.com