Neutrino-1 8B · Fermion Research

A dense decoder-only transformer. Grouped-query attention holds the KV cache at a quarter of the query width, 144 KiB per token at fp16, so a 4k-token session costs 0.60 GB of cache beside the 3.88 GB of weights.

Base modelApache-2.0, Alibaba Cloud

Qwen3-8B

Parameters6.95B coded projection weights, 1.24B int8 embedding, 0.3M norm

8,190,735,360

Decoder layers

36

Hidden width

4,096

Feed-forward widthgated (SwiGLU), three linears per layer

12,288

Attentiongrouped-query 4:1, head width 128

32 query heads, 8 key-value heads

KV cachefp16; 0.60 GB at 4k context, 4.83 GB at 32k

144 KiB per token

Position encodingapplied across the full 128-wide head

rotary, base 1,000,000

Normalizationplus per-head query/key RMSNorm inside attention

RMSNorm, eps 1e-6

Context length

40,960 tokens

Vocabulary

151,936

Embeddingsinput embedding and output head are separate tensors

untied

Where the bytes live

Only the transformer linears carry the coded format. The two embedding tensors stay int8 because their rows are read one token at a time, not multiplied against the full activation stream, and the normalization weights are too small to be worth coding. A third of the file is vocabulary.

252 transformer linearsthe coded ternary-family lane, 67.2% of the file: query, key, value, and output projections plus the gate, up, and down feed-forward linears, 7 per layer, 72,351,744 bytes per layer

2,605 MB

Token embeddings32.1% of the file: two untied int8 tensors of 151,936 × 4,096, input embedding and output head, one scale per row

1,245 MB

Per-row metadata0.6%: row dimensions, scales, and row sums

25 MB

Normalization weights145 tensors, kept float32: four per layer plus the final norm

1.2 MB

Container header

60 bytes

Inside the coded lane

Across the 6.95B coded weights, 62.63% sit at zero and the remainder splits 18.68% plus to 18.69% minus: sign-balanced to a hundredth of a point with no constraint asking for it. The balance is not uniform in depth. The gate and down feed-forward projections spike to 70 to 72% zeros in layers 1 through 3 while all four attention projections hold within about one point of 62% at every depth: the early feed-forward blocks shed weights the network does not need, and attention keeps a constant code density from layer 0 to layer 35.

gateupdownquery, key, value, output

One container, three doors. The download is a coded transport of the container, not a compressed copy of an fp16 model: it expands bit-exactly to the file every runtime executes, and that one file is what runs on a datacenter GPU and on a laptop alike.

Downloadcoded transport, 2,559,822,594 bytes; expansion is bit-exact

2.56 GB

On diskone container, 3,875,404,812 bytes

3.88 GB

Distribution surfaces

The release battery runs on the shipped container with thinking disabled, so every grade below is the artifact you download and not a research checkpoint. Protocol rides every row: shot count, grading mode, and item count.

MMLU5-shot, all 57 subjects, 14,042 items

72.1

MMLU-Reduxgenerative, re-annotated subset, thinking off

67.8

IFEval, prompt-strictgenerative, thinking off

77.2

IFEval, instruction-strictsame run, per-instruction grading

80.2

IFEval, prompt-loosesame run, loose extraction

76.3

BFCL v3macro over 13 subsets, thinking off

68.9

GSM8K, flexible extraction0-shot generative, greedy, 256-token cap

53.4

GSM8K, stated formatsame run, answer accepted only in the requested form

51.73

Single-stream decode, the rate that governs one prompt and one reply. Same artifact on every row; the surface changes, the weights do not.

H100 80 GB, drafted0.6B draft + 8B verify, output identical to plain decode; fastest prompt class

763 tok/s

H100 80 GBplain single-stream greedy

396 tok/s

NVIDIA L4, CUDA forkGGUF pack, full offload, 4.68 GiB VRAM at 4k context; fits 8 GB cards

30.7 tok/s

Apple M5, 16 GB (MLX), draftedfactual prompts, 0.6B drafting in the same process under a 6 GiB cap

25.7 tok/s

Apple M5 MacBook (optimized)single-stream decode on the shipping artifact

33.7 tok/s

Apple M5 (CPU only)shipped native binary, 9 threads

24.9 tok/s

Neutrino-1 0.6B drafts a run of tokens, the 8B scores the whole run in one forward pass, and the agreeing prefix is kept. A draft token is accepted only when it equals the 8B’s own argmax, so the output stream is the plain greedy stream: on the shipping configuration, 27,648 consecutive tokens matched with zero divergences.

The speedup is draft-acceptance physics, so it is stated per prompt class over the 396 tok/s plain rate. On counting prompts the 8B accepts the full six-token draft on every pass, about seven tokens emitted per 8B forward; on factual prompts acceptance holds at 96.5%. A dynamic controller sizes each draft to the class it is decoding, which is why every class clears the plain rate.

Counting and lists763 tok/s

×1.93

Factual short answers613 tok/s

×1.55

Prose continuation532 tok/s

×1.34

Conversational explanation447 tok/s

×1.13

Code426 tok/s

×1.07

What the pairing costs

Both containers are the same format and run on the same binaries, so the draft loads into the verifier’s own process with no second deployment and no conversion step. Its 328 MB sit beside the 8B’s 3.88 GB, and 4k tokens of shared context cost exactly one gibibyte of cache across the pair.

Weights resident3.88 GB verifier plus 328 MB draft, one process

4.20 GB

Draft surchargethe extra weight bytes the pairing costs

8.46%

Shared cache144 KiB on the 8B, 112 KiB on the draft; 1 GiB at 4k context

256 KiB per token

Certified rundraft plus verify against plain greedy, zero divergences

27,648 tokens

Drafting on a laptop

The pairing is not a datacenter feature. On a 16 GB Apple M5 both models load into one MLX process under a 6 GiB cap and peak at 4.3 GiB together, with the draft accounting for 0.53 GiB of it. The exactness gate returns 6 of 6 prompts token-identical with drafting on and off, and on factual prompts the drafted rate is 25.71 tok/s against 22.00 plain at an acceptance of 0.744.