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.

Changelog — weights updated 2026-07-31: distilled draft (trained to agree with the 8B); prior cut available via revision pinning. The container at this repo's tip is now a draft specialist distilled from Neutrino-8B rollouts so its greedy predictions match the 8B as often as possible. Same file names, same paths — every existing draft pointer keeps working. The new agreement and speedup numbers are in As the 8B's draft; the prior cut (91c0b26d…) remains available by pinning any revision dated before 2026-07-31.

A 596M-parameter 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,696,073 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. Since 2026-07-31 the weights are additionally distilled for drafting: trained to agree with Neutrino-8B's next-token choices.

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 ba0e9258d866d5eb309352dd7c1b810c402eac289fb98e871c63b38a3bcd8168 (the 2026-07-31 distilled-draft weights; the prior cut's sha256 was 91c0b26d…19399, available via revision pinning).
  • Coded transport: neutrino-0.6b_v4.tv4z - 237,696,073 bytes, lossless, byte-exact round-trip receipt banked; regenerated with the 2026-07-31 weights, sha256 7ced43476235e6b7e2a0b5190a0fb3c59ae36f2f44f739574078b28dc50e6b8c.
  • Inside: 196 packed ternary linears + one int8 embedding lane (tied: the input embedding and lm_head share one table; container walk cross-checked in the internal anatomy audit, 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 container walk):

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 the internal anatomy audit).

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

All model artifacts carry the 2026-07-31 distilled-draft weights; the prior cuts remain available via revision pinning.

artifact bytes sha256
neutrino-0.6b_v4.bin (TRTC v4 container, the file every runtime executes — the MLX pack reads this same file) 327,719,836 ba0e9258d866d5eb309352dd7c1b810c402eac289fb98e871c63b38a3bcd8168
neutrino-0.6b_v4.tv4z (lossless coded transport, 72.5% of raw) 237,696,073 7ced43476235e6b7e2a0b5190a0fb3c59ae36f2f44f739574078b28dc50e6b8c
gguf/neutrino-0.6b-base-fv5.gguf (llama.cpp-fork pack, bit-checked vs the container at conversion) pinned in gguf/SHA256SUMS pinned in gguf/SHA256SUMS (regenerated 2026-07-31)
gguf/fv5.patch (the llama.cpp patch that builds the fork) - 81bf7be5eef18eb98ab4823596374c8dd6615151cf5615425973cb65942c0f73

Container md5 of the 2026-07-31 weights: 196acb1aa52cb817d92aac1ef800b5f1. Receipts dated before 2026-07-31 describe the prior cut (md5 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

Measured on the prior cut. The 2026-07-31 container has the identical geometry and byte layout (decode speed does not depend on the weight values), but these rows have not been re-run on the new weights.

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, graph == eager on a 24-token identity

Evaluation battery (measured on the PRIOR cut, 91c0b26d...)

These standalone capability numbers were measured on the prior cut (pre-2026-07-31 revisions) and refer to that cut until re-measured on the distilled weights. The 2026-07-31 weights are distilled-for-drafting: optimized to agree with Neutrino-8B's next-token choices, not for standalone capability. Standalone, the distilled container answers as a compressed echo of the 8B's next-token habits; do not read the table below as a description of it, and do not use either cut as an assistant.

Measured on the prior shipped checkpoint 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 (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.

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 receipted in the eval-receipts repo. 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 in the eval-receipts repo, grade_probe.py sha b279c53e..., state sha gate PASS). 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 (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. To reproduce the table above, download a pre-2026-07-31 revision (hf download --revision <commit>); the tip of this repo carries the distilled-draft weights, which these rows do not describe.

# 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 2026-07-31 distilled draft (the weights in this repo now)

The container now carries a draft specialist: distilled from Neutrino-8B rollouts so its greedy predictions match the 8B as often as possible.

Certified exact against exactly this 8B pairing (neutrino-8b_v4.bin, sha256 016c6f36…55fa0): 27,648 spec tokens replayed, 0 mismatches (H100, 2026-07-30; greedy draft+verify vs plain greedy, dynamic draft length). Speculation moves the clock, never the text. The certification and acceptance receipts ship in the Neutrino-8B repo (receipts/draft/cert_20260730.log, receipts/draft/acceptance_20260730.log).

prompt class agreement with the 8B (teacher-forced, held-out) end-to-end speedup
counting 100% ×1.80
facts ~87% ×1.23
prose ~75% ×1.12
chat / explanation ~75% ×1.07
code ~78% ×1.06
forced-reject floor ×0.75 (output exact)

Speedups are H100, 3-round median, dynamic draft length, 2026-07-30. That agreement is up from 44–82% for the base-0.6B function these weights replace as the recommended pairing (same held-out probe, 2026-07-30). One disclosed sub-bar cell: a technical-explanation slice measured 61.9% agreement against its 65% bar (end-to-end ×0.91 there).

The distilled weights are not a chat model. Standalone, they answer as a compressed echo of the 8B's next-token habits; for conversation use Neutrino-0.6B-Chat or the 8B. Speculative decoding is a throughput feature with a correctness certificate; the speedup is prompt-dependent — the rows above are the honest spread, not a single headline number.

Certification history (prior cut)

The certifications below were measured on the prior cut and remain valid facts about it; the 2026-07-31 certificate above is the one that covers the weights in this repo now.

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 shipping 8B container)
dynamic-k cert (earlier internal 8B 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. The certification receipt ships in the Neutrino-8B repo (receipts/).

Speedup by prompt class (2026-07-27 run, prior draft cut — superseded by the table above)

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.

Out of the box, without distillation (the prior cut)

The prior 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 (prior-cut gate, mlx/receipts/specgate_8b_0p6b.json in the Neutrino-8B repo). Throughput with the distilled draft (M5, 6 GiB cap, MLX 0.32.0, 2026-07-30): facts ×1.014 at 0.8705 acceptance, chat ×0.81 (0.5551) and prose ×0.704 (0.4425) still regress — the MLX path is verify-kernel-bound today (batched verify costs ~2.8× a single step), so higher acceptance alone does not flip chat/prose there; the in-flight Metal kernel work is the fix. Receipt ships in the Neutrino-8B repo (receipts/). Use --spec on Apple for factual workloads.

Draft-model artifact pins

  • neutrino-0.6b_v4.bin (the 2026-07-31 distilled draft, the weights in this repo now): sha256 ba0e9258...8168, 327,719,836 B
  • prior cut (the base container the history above describes): sha 91c0b26d...19399, 327,719,836 B, via revision pinning
  • the dynamic-draft-length confidence head used on the H100 research path is a separate artifact, not published here (a throughput knob, never a quality knob)

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 ba0e9258...8168
md5 neutrino-0.6b_v4.bin             # macOS — must print 196acb1aa52cb817d92aac1ef800b5f1
md5sum neutrino-0.6b_v4.bin          # Linux — same digest
# prior cut (revision-pinned downloads): sha256 91c0b26d...19399,
# md5 86565bf6183e8031943aac9fd9771385

Export provenance, 2026-07-31 weights: distilled from Neutrino-8B rollout data (knowledge distillation on the drafting objective), baked and exported with the banked exporter. Gates: baked-vs-QAT teacher-forced argmax parity 0.9956 (all flips near-tie class), double-export byte-determinism PASS, tv4z byte round-trip PASS.

Export provenance, prior cut: exported on a Modal CPU container (cpu=8, 24 GiB) from the archived QAT state 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

  • Distilled-for-drafting: the 2026-07-31 weights are trained to agree with Neutrino-8B, not to be capable standalone. No chat template behavior, no instruction-following guarantees, no tool use. The standalone battery above describes the PRIOR cut until re-measured.
  • 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 (prior cut) 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 (prior cut) 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 (MLX), speculative decoding against the 8B is a win on factual prompts and still a regression on chat and prose with the distilled draft (verify-kernel-bound; 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 -> (2026-07-31) knowledge distillation for drafting on Neutrino-8B rollout data -> exported with the banked exporter, gates in the export provenance above. The QAT recipe, the diet disclosure, 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

Downloads last month
2,012
GGUF
Model size
0.6B params
Architecture
qwen3
Hardware compatibility
Log In to add your hardware

We're not able to determine the quantization variants.

Inference Providers NEW
This model isn't deployed by any Inference Provider. 🙋 Ask for provider support

Model tree for FermionResearch/Neutrino-0.6B

Finetuned
Qwen/Qwen3-0.6B
Quantized
(378)
this model