Neutrino-1 8B

Hacker News Top Models

Summary

Neutrino-1 8B is an 8.19B-parameter transformer with a proprietary ternary weight format, enabling it to fit on 8GB GPUs and serve multiple platforms from a single 3.88GB artifact with high decode speed.

No content available
Original Article
View Cached Full Text

Cached at: 07/28/26, 06:28 AM

# Neutrino-1 8B Source: [https://www.fermionresearch.com/models/neutrino-8b/](https://www.fermionresearch.com/models/neutrino-8b/) ![](https://www.fermionresearch.com/images/legacy/mark.svg)Available 2026\-07\-27 The flagship of the Neutrino family: 36 decoder layers behind a coded ternary\-family container that serves a datacenter GPU, a MacBook, and a desktop CPU from one artifact\. 2\.56 GBDownload, lossless1/8The bits of fp1672\.1MMLU763 tok/sSpec decode, H100 ![](https://www.fermionresearch.com/images/brand/newlogo.svg)Neutrino\-1 8B Neutrino\-1 8B is an 8\.19B\-parameter decoder\-only transformer that ships as one 3\.88 GB file\. Every one of its 252 transformer linears is stored in a proprietary ternary\-family weight format eight times smaller than fp16; the weights stay bit\-packed at rest and are decoded inside the matrix kernels, so nothing in the decode path is stored as fp16 or fp32 weight material\. Small weights change the serving economics\. Single\-stream decode is bound by how many bytes move per token, so a 3\.88 GB working set decodes at rates a 16 GB fp16 artifact cannot reach on the same memory system, and the whole model fits beside its KV cache on an 8 GB GPU or a 16 GB laptop\. The same container serves every platform below without conversion\. 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 CloudQwen3\-8BParameters6\.95B coded projection weights, 1\.24B int8 embedding, 0\.3M norm8,190,735,360Decoder layers36Hidden width4,096Feed\-forward widthgated \(SwiGLU\), three linears per layer12,288Attentiongrouped\-query 4:1, head width 12832 query heads, 8 key\-value headsKV cachefp16; 0\.60 GB at 4k context, 4\.83 GB at 32k144 KiB per tokenPosition encodingapplied across the full 128\-wide headrotary, base 1,000,000Normalizationplus per\-head query/key RMSNorm inside attentionRMSNorm, eps 1e\-6Context length40,960 tokensVocabulary151,936Embeddingsinput embedding and output head are separate tensorsuntiedGeometry as read from the shipped container's header\.### 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 layer2,605 MBToken embeddings32\.1% of the file: two untied int8 tensors of 151,936 × 4,096, input embedding and output head, one scale per row1,245 MBPer\-row metadata0\.6%: row dimensions, scales, and row sums25 MBNormalization weights145 tensors, kept float32: four per layer plus the final norm1\.2 MBContainer header60 bytesByte budget of the 3,875,404,812\-byte container, by tensor class\.### 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 60%65%70%08162435 60%65%70%08162435 Share of coded weights at zero, per projection, across all 36 layers\. 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\-exact2\.56 GBOn diskone container, 3,875,404,812 bytes3\.88 GB### Distribution surfaces #### pip engine 24\.9 tok/s on an Apple M5, CPU only, 9 threads The one\-command door: pip install fermion\-research downloads the container and the platform\-matching native binary\. CPU runtimes for macOS arm64 and Linux x86\-64, with a bit\-exact torch reference path underneath\. #### GGUF pack \+ CUDA fork 30\.7 tok/s on an NVIDIA L4, 4\.68 GiB at 4k context The llama\.cpp door: the container converted to GGUF with our weight types, loaded by our public llama\.cpp fork\. Runs llama\-completion and llama\-bench, with full CUDA offload\. #### MLX pack 33\.7 tok/s on a base M5 MacBook The Apple\-silicon door: Python\-native runtime with custom Metal kernels\. The container is memory\-mapped and the packed planes are decoded inside the GEMV kernels\. 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 items72\.1MMLU\-Reduxgenerative, re\-annotated subset, thinking off67\.8IFEval, prompt\-strictgenerative, thinking off77\.2IFEval, instruction\-strictsame run, per\-instruction grading80\.2IFEval, prompt\-loosesame run, loose extraction76\.3BFCL v3macro over 13 subsets, thinking off68\.9GSM8K, flexible extraction0\-shot generative, greedy, 256\-token cap53\.4GSM8K, stated formatsame run, answer accepted only in the requested form51\.73Measured on standard public harnesses, July 2026\. Methodology on the model card\. 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 class763 tok/sH100 80 GBplain single\-stream greedy396 tok/sNVIDIA L4, CUDA forkGGUF pack, full offload, 4\.68 GiB VRAM at 4k context; fits 8 GB cards30\.7 tok/sApple M5, 16 GB \(MLX\), draftedfactual prompts, 0\.6B drafting in the same process under a 6 GiB cap25\.7 tok/sApple M5 MacBook \(optimized\)single\-stream decode on the shipping artifact33\.7 tok/sApple M5 \(CPU only\)shipped native binary, 9 threads24\.9 tok/sSingle\-stream decode rates by platform and surface, July 2026\. 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\.93Factual short answers613 tok/s×1\.55Prose continuation532 tok/s×1\.34Conversational explanation447 tok/s×1\.13Code426 tok/s×1\.07H100, three\-round median per prompt class, over 396 tok/s plain decode\.### 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\. one process, one set of binariesNeutrino\-1 8B3\.88 GB, verifierNeutrino\-1 0\.6B328 MB, draftsix proposed tokensaccepted prefixemittedone process, one set of binariesNeutrino\-1 0\.6B, 328 MBNeutrino\-1 8B, 3\.88 GBsix proposed tokensaccepted prefixWeights resident3\.88 GB verifier plus 328 MB draft, one process4\.20 GBDraft surchargethe extra weight bytes the pairing costs8\.46%Shared cache144 KiB on the 8B, 112 KiB on the draft; 1 GiB at 4k context256 KiB per tokenCertified rundraft plus verify against plain greedy, zero divergences27,648 tokensThe drafted pair drawn to byte scale, with the residency each side costs\.### 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\. ### Two commands to a streaming chat\. ``` $ pip install fermion-research$ fermion chat ``` The first run pulls the container and the native binary for the host, then the prompt opens\. Later runs load from cache\. - A local OpenAI\-compatible server`fermion serve` Serves at http://127\.0\.0\.1:8000/v1\. Point any OpenAI client at that base URL; the key can be any string\. - Any of the three models`fermion chat \-\-model fermionresearch/Neutrino\-0\.6B\-Chat` \-\-model takes a repository id or a path on disk\. \-\-backend native pins the compiled runtime instead of the torch path\. - GGUF, through our llama\.cpp fork`llama\-completion \-m neutrino\-8b\-fv5\.gguf \-ngl 99` Build the fork, then run the pack from the model repository\. The CUDA build offloads all 36 layers\. - MLX, on Apple silicon`python \-m fermion\_mlx \-\-model neutrino\-8b\_v4\.bin \-\-mode chat \-\-tokenizer \.` Run from the mlx/ folder of the model repository, after installing its requirements file\. [Full engine documentation](https://www.fermionresearch.com/learn/) Neutrino\-1 8B ships as a single public repository holding the weights, the native binaries, the GGUF pack, and the MLX pack together, so there is never a version of one that does not match the others\. No waitlist, no gated preview\. Weights and engine in one repository\. Available 2026\-07\-27One public repositoryOpen weights, Apache 2\.0 ### License Open weights under the Apache License 2\.0\. Commercial use, modification, fine\-tuning, and redistribution are permitted, with no access request and no acceptance form\. The model is a derivative of Qwen3\-8B, itself Apache\-2\.0\. The pip package is Apache\-2\.0 too; the llama\.cpp fork is MIT, following upstream llama\.cpp\. ### Citation ``` @misc{fermionresearch2026neutrino, title = {Neutrino-1 8B}, author = {{Fermion Research}}, year = {2026}, url = {https://fermionresearch.com/models/neutrino-8b/} } ```

Similar Articles

Nemotron-3-Embed 1B/8B

Reddit r/LocalLLaMA

NVIDIA released Nemotron-3-Embed 1B and 8B models, state-of-the-art multilingual text embedding models for retrieval and semantic similarity, optimized for RAG systems.

prism-ml/bonsai-image-ternary-4B-gemlite-2bit

Hugging Face Models Trending

Prism ML releases Bonsai Image, a 1.21 GB text-to-image diffusion transformer using ternary weights (1.58-bit) for NVIDIA GPUs, offering 4.5s / 1024² on RTX 3080 and much smaller than FP16.

nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B-NVFP4

Hugging Face Models Trending

NVIDIA releases Nemotron-3-Ultra, a 550B-parameter open-weight model with a hybrid architecture combining Mamba-2, MoE, and attention, supporting up to 1M token context and configurable reasoning mode.

nvidia/Nemotron-Labs-Diffusion-14B

Hugging Face Models Trending

NVIDIA releases Nemotron-Labs-Diffusion, a family of tri-mode language models (3B, 8B, 14B) supporting AR, diffusion, and self-speculation decoding, achieving 2.7x-4x speed-ups over standard AR decoding.