Introducing the Neutrino-1 models

1. Three models, one format

An 8B-class model in fp16 is 16 GB of weights, and producing a single token moves nearly all of them through the processor. Neutrino-1 8B holds 8,190,735,360 parameters in a proprietary ternary-family weight format at one eighth the bytes of fp16, which puts the whole model in a 2.56 GB download and 3.88 GB on disk. Three models ship today in that format. Neutrino-1 8B is the capable one. Neutrino-1 0.6B is 596,049,920 parameters in 328 MB that decode at 225 tokens per second on a laptop, and it is the certified draft model that makes the 8B decode faster than the 8B can decode alone. Neutrino-1 0.6B-Chat is that small model finished for conversation.

The three share a tokenizer, a container layout, and an engine. One artifact per model, one loader, one set of kernels: the file that runs on an H100 is byte-identical to the file that runs on a MacBook, and the drafted path exists because two of the three containers can sit in the same process without a second runtime.

2. Architecture

Neutrino-1 8B is a 36-layer decoder-only transformer with a residual stream 4,096 wide. Attention is grouped-query: 32 query heads share 8 key-value heads at 128 dimensions per head, a 4:1 grouping that divides the decode-time cache by four, with rotary position embeddings over the full head dimension and RMS normalization applied per head to queries and keys before they reach the cache. Each layer carries a gated feed-forward block that expands 4,096 to 12,288 and projects back. The vocabulary is 151,936 tokens with separate input and output embedding tables, and the position range extends to 40,960 tokens.

Neutrino-1 0.6B is the same design at a quarter of the width. It runs 28 layers over a 1,024-wide stream, 16 query heads over the same 8 key-value heads for a 2:1 grouping, the same 128-dimension heads, and a feed-forward block of 3,072. It carries the identical 151,936-token vocabulary, and at that width a separate output table would cost more than the layers it serves, so the small model ties its input and output embeddings into one 156 MB table. Sharing the tokenizer with the 8B is what makes the two composable: drafted tokens need no remapping between models.

3. The container

The format decides what those parameters physically are. All 252 transformer projection matrices of the 8B, seven per layer across attention and the feed-forward block, live in the ternary lane: each stored weight is a three-way choice among minus, zero, and plus, and each output row carries scale metadata that sets the magnitude of the choice. The format extends the ternary family with proprietary structure, and the extensions are unpublished; the measurable consequence is that 6.95 billion projection weights occupy 2.60 GB of the container. Zero is a stored state, not a rounding outcome: 62.6 percent of all ternary weights are exactly zero, 18.7 percent positive, 18.7 percent negative. The signs land balanced to within two hundredths of a percentage point across 6.95 billion weights, with nothing in training enforcing that symmetry.

Occupancy is not uniform with depth. The attention projections hold a flat code density across all 36 layers, inside a band of about one percentage point. The feed-forward blocks of layers 1 through 3 spike instead: the down projection reaches 72.5 percent zeros at layer 2 and the gate 70.5 percent at layer 3, roughly ten points above the model-wide baseline. The earliest feed-forward blocks silence most of their connections; attention never does.

Two thirds of the file is that ternary weight lane. Nearly a third is vocabulary: the two untied embedding tables stay outside the ternary lane as int8 rows with per-row scales, 622 MB each. That choice costs 1.24 GB and buys precision on the only tensors where a single row carries a token’s whole identity. Normalization vectors stay at full precision, 1.2 MB in total. Nothing in the container is fp16, and every one of the 36 layers costs exactly 72,351,744 bytes, 21.7 percent attention and 78.3 percent feed-forward.

The download is smaller than the artifact because the two lanes code differently. The ternary lane compresses losslessly to roughly 55 percent of its raw bytes, and the layers that silence hardest code tightest: layers 1 through 3 reach 0.516 where a typical layer sits near 0.550. The int8 embeddings hold at 88 percent. The shipped transport lands at 2.56 GB and expands to the byte-identical container.

4. Training

Neutrino-1 8B was trained natively in its shipping format. There is no full-precision product model that was rounded afterward: the ternary representation is the medium the weights learned in, and the training methods that hold this quality at this depth are the lab’s unpublished work. The findings below are the part that travels.

Post-training ran as staged, single-axis behavioral campaigns: instruction following, tool calling, termination discipline, each stage graded against the full battery of every axis already installed. The staging exists because of a phenomenon we measured early and now design around: training pressure on one behavioral axis does not degrade the model uniformly. It degrades specific other axes, and which ones is an empirical property of each training diet, not of the model. One tool-calling stage in this lineage moved its tool-use score by twenty points while strict instruction following bled nine points on the same checkpoints and termination behavior improved. A mathematics-heavy diet collapsed tool calling instead. The damage chooses axes, so every stage has to watch all of them.

Protection is equally axis-specific. Folding an installed axis’s own training signal into a stage’s batches held that axis through the stage, and held only that axis: the nine-point instruction-following bleed fell to under half a point once the axis was represented, the tool-calling gain survived, and no axis absent from the mix was ever protected by accident. Dose behaves the same way. Tool-calling gains completed within roughly twenty-five optimization steps in every densely measured campaign, instruction following needed about fifty, and knowledge-heavy stages peaked mid-course and decayed past the peak. A dose plan copied from one axis to another is a category error.

Two more findings shaped the release. When a reward-driven stage plateaued, the cause was never a model ceiling: the model had exhausted its training material, corrective pressure faded, and further steps bought nothing that harder material did not. And a checkpoint that passes on the evaluation rig can still behave differently on a shipping runtime, so each stage’s winner is graded on the runtimes it ships on before it ships. Stages were accepted only when every installed axis held above preset floors. Several failed their floors and shipped nothing. The model that ships is the sequence of stages that held.

5. Evaluation

MMLU 72.1, five-shot, all 57 subjects, the full 14,042-question set. MMLU-Redux, the re-annotated subset, 67.8, run generatively with thinking off. IFEval 77.2 prompt-strict; the same run reads 80.2 instruction-strict and 76.3 prompt-loose. BFCL v3 68.9, macro-averaged over its thirteen categories.

GSM8K is scored twice, under both extraction rules the field uses, and the pair is more informative than either number. Flexible extraction takes the last number the model produced and reads 53.4. The stated rule accepts an answer only where the prompt asked for it, and reads 51.73: the arithmetic and the obedience are measured separately, and the gap between them is under two points. Both runs are zero-shot with no chain of thought, against the eight-shot chain-of-thought setting most published mathematics figures use.

The table below carries every model in the byte class on one measurement stack, with the same prompt format, shot count, extraction rule and generation cap on every side. Two cells are worth naming in advance. Requiring the answer in the stated form costs an instruction-tuned 16-bit rival almost everything it scored under the flexible rule, which is a formatting failure and not an arithmetic one.

Read down the byte row and the knowledge row together and the trade the class is built on comes apart. Every 16-bit artifact in the table buys its score with fifteen to sixteen gigabytes, and the two after-the-fact two-bit cuts buy their bytes with the score. Training in the shipping format is what breaks the trade, and the break is large enough to see as a shape rather than read as a number.

6. Tool use

The BFCL macro average is one number over thirteen separately scored suites, so the thirteen are published individually. Function composition against held signatures is the strongest block, 70.0 to 85.0 across simple, multiple, parallel, and parallel-multiple calls, and relevance detection sits alongside it at 77.1 to 80.0: the model declines to call a function nearly as reliably as it calls the right one. The live suites draw their schemas from real-world APIs collected in the wild, where argument names and nesting are nobody’s house style.

7. Memory and decode

Decode is a bandwidth problem before it is a compute problem. Producing one token requires streaming essentially the whole model through the processor once: the 2.60 GB ternary lane, then the 622 MB output embedding to score the vocabulary. The ceiling on single-stream tokens per second is memory bandwidth divided by those bytes. Kernels decide how close a machine runs to its ceiling; only byte count moves the ceiling itself.

The clearest evidence is a pair of measurements on one laptop. A base-M5 MacBook decodes the optimized shipping artifact at 33.7tokens per second; the separately measured CPU-only path reaches 24.9 with the GPU idle. Both paths stream the same packed weights through one memory system, so the format’s job is to make each token cost fewer bytes. On an H100 80 GB the same artifact runs 396 tokens per second on the plain path.

The engine is separable from our weights, which makes the Apple number checkable against someone else’s model. Loading the public BitNet b1.58-2B4T ternary weights into our container and decoding them on a 16 GB Apple M5 reaches 102.4 tokens per second, against 89.0 from the reference bitnet.cpp build on the same machine in the same session, batteries and thermals shared. No published number for a ternary model on Apple silicon is higher than 102.4.

Weights are the flat cost; context is the growing one. With the 4:1 grouped-query cache, one token of context costs 147,456 bytes at 16-bit precision across the 36 layers, so 4,096 tokens of history hold 604 MB and the full 40,960-token range 6.0 GB against the constant 3.88 GB of weights. Ungrouped 32-head attention would multiply the cache by four and push the full-context total past 28 GB. Grouping is why the whole object, model plus maximal cache, stays under 10 GB.

8. Drafted decode

Drafted decode is a system of two models in one format. Neutrino-1 0.6B proposes a short run of tokens. The 8B scores the entire run in a single batched forward pass, one pass for up to seven positions instead of one pass per token. The engine keeps the longest prefix on which the two models agree exactly, takes the next token from the 8B’s own distribution, and repeats. Under greedy decoding this procedure cannot emit a token the 8B would not have produced alone, and the implementation is checked the same way: drafted path against plain path, token by token, 27,648 consecutive tokens with zero divergences.

Delivered speed follows acceptance, and acceptance follows the text. On an H100 80 GB the drafted path reaches 763 tokens per second on counting-style output against 396.7 plain, 500 on facts, 437 on code, 422 on prose, and 402 on chat. The spread is not tuning: on counting the 8B accepted every one of six drafted tokens on every verify pass, which emits about seven tokens per forward pass of the 8B.

The pairing also runs on a laptop. Both models load into one process on a 16 GB Apple M5 under a hard 6 GiB cap, peak at 4.3 GiB resident, and deliver 25.71 tokens per second on factual prompts against 22.00 undrafted in the same session, accepting 74 percent of drafted tokens. Six prompts came back token-identical with drafting on and off, which is the property that matters: on Apple silicon drafting changes the speed and never the text.

Draft length is chosen per step rather than fixed, because the same draft model behaves differently on different text. Factual completions accept 96 to 99 percent of drafted tokens at every draft length tested, so the controller rides seven-token drafts there and the histogram piles up at the maximum. Elsewhere acceptance decays with length, and the controller reads recent acceptance and shortens the draft to one or two tokens, spending draft work only where it survives verification.

9. The small models

Neutrino-1 0.6B does two jobs. The first is drafting, and it is certified in that role rather than asserted: standing alone on an H100 80 GB it walks at 1,177 tokens per second, and paired with the 8B it produced 27,648 consecutive tokens with zero divergences from plain decode, carrying the 8B to 762.6 tokens per second on counting-class prompts with every one of six drafted tokens accepted on every verify pass. No published model of this size ships a bit-exact acceptance certificate for its drafted path.

The container is 596,049,920 parameters, 328 MB on disk and a 238 MB download, and it decodes at 225 tokens per second through the native binary on a 16 GB Apple M5, 201.2 through MLX inside 0.526 GiB of memory. It carries the 8B’s tokenizer, which is what makes the pairing composable: drafted tokens need no remapping between models. The vocabulary is the largest single object in the file at 47.5 percent of its bytes against 32.1 percent on the 8B, which is why the embeddings are tied. At this width the tokenizer is the model’s main expense.

The reference point for a format is the base model it was built from, at full precision, same parameter count, same harness. That reference is Qwen3-0.6B: 1.50 GB of bf16 weights, reading 60.82 on ARC-easy at zero-shot. The Neutrino container reads 53.45 from 238 MB, and it does that inside 0.526 GiB of process memory, just over a third of what the bf16 weights alone occupy.

Neutrino-1 0.6B-Chat is the same container finished for conversation, and the finishing is measurably small. The chat tune moved state occupancy by less than a tenth of a percentage point on every projection and left the tied embedding table byte-identical. Alignment at this scale is a rearrangement of ternary states inside the projections, not a rewrite of the model.

The chat model is graded on conversation and on the surfaces it ships on. Sentence fragments of the kind a person actually types get an answer instead of a request for clarification, factual prompts get the fact, absurd requests get a refusal rather than an agreement, and no reply carries chat-template scaffolding into the output. Stop discipline is measured on the compiled binary and on the MLX pack, because that is where a serve-time defect reaches a user, and the same container returns the same grades on both.

10. Deployment surfaces

The reference surface is the pip package: engine, loader, and chat front end in one wheel. The same repository carries prebuilt static binaries for macOS arm64 and Linux x86-64 that decode the container at native CPU speed with no Python in the path. Weights and engine version together; there is no build of one that does not match the other.

$ pip install fermion-research
$ fermion chat

For the llama.cpp ecosystem the release carries a GGUF pack and a public fork that adds the format as two tensor types. The CUDA build offloads all 36 layers: on an NVIDIA L4 the pack decodes at 30.7 tokens per second in 4.68 GiB of peak VRAM at 4,096 context, inside an 8 GB card. The CPU build is token-identical under greedy decoding against the container’s own full-precision expansion. An MLX pack serves Apple GPUs. Every pack is checked token for token against the shipping container before publication.

11. Availability

All three models are available now. Neutrino-1 8B ships as a single public repository holding the weights and the engine together, a 2.56 GB download. All three models ship as open weights under the Apache License 2.0, which permits commercial use, modification, fine-tuning, and redistribution. No waitlist, no gated preview.

Two research posts accompany this one: one on what survives when a model leaves floating point, and one on the engine.