Card: report call/abstain in the headline, fix the MoVA restack figure (15.1 GB, not 7.55), one decimal throughout, pin the serve image

README.md

@@ -29,12 +29,13 @@ thumbnail: https://huggingface.co/primitive-ai/K2-Horizon-MoVA-36B-A4B-mixed-NVF
   <img src="https://img.shields.io/badge/vs%20BF16-1.7×%20smaller-F98424?style=flat-square" alt="1.7x smaller than BF16">
   <img src="https://img.shields.io/badge/vs%20official%20FP8-8%25%20smaller-F98424?style=flat-square" alt="8 percent smaller than the official FP8">
   <img src="https://img.shields.io/badge/knowledge-level%20with%20BF16%20%26%20FP8-3DD13D?style=flat-square" alt="knowledge level with BF16 and FP8">
-  <img src="https://img.shields.io/badge/tool%20calling-1.4%20below%20FP8-lightgrey?style=flat-square" alt="tool calling 1.4 below the official FP8">
+  <img src="https://img.shields.io/badge/call%20accuracy-1.4%20below%20FP8-lightgrey?style=flat-square" alt="call accuracy 1.4 below the official FP8">
+  <img src="https://img.shields.io/badge/vs%20our%20NVFP4-%2B1.7%20call%20accuracy-F98424?style=flat-square" alt="plus 1.7 call accuracy versus our pure NVFP4 build">
   <img src="https://img.shields.io/badge/requires-Blackwell-lightgrey?style=flat-square" alt="requires Blackwell">
   <a href="https://primitive.com"><img src="https://img.shields.io/badge/web-primitive.com-lightgrey?style=flat-square" alt="primitive.com"></a>
 </p>
 
-<h3 align="center">8% smaller than the official FP8, level on knowledge, 1.4 behind on tool calling.</h3>
+<h3 align="center">8% smaller than the official FP8, level on knowledge, 1.4 behind on call accuracy.</h3>
 
 <p align="center">
 Mixed-precision quantization of <a href="https://huggingface.co/IFM/K2-Horizon-MoVA-36B-A4B">IFM/K2-Horizon-MoVA-36B-A4B</a> to
@@ -42,11 +43,11 @@ Mixed-precision quantization of <a href="https://huggingface.co/IFM/K2-Horizon-M
 15 of the 45 sparse layers carry NVFP4 experts; the other 30 carry FP8 with block scales.
 </p>
 
-> **This is the more accurate of our two builds, and it needs Blackwell.** There is also a
+> **This is the better of our two builds on call accuracy, and it needs Blackwell.** There is also a
 > [pure NVFP4 build](https://huggingface.co/primitive-ai/K2-Horizon-MoVA-36B-A4B-NVFP4) at
 > 36.74 GB that is 7.74 GB smaller, 1.21× faster at concurrency 32, and **the only one of the two
-> that runs on Ampere**. Take this one if tool calling matters most; take that one for
-> pre-Blackwell hardware, the smallest footprint, or throughput under load.
+> that runs on Ampere**. Take this one if tool calling matters most; take that one for pre-Blackwell
+> hardware, the smallest footprint, or throughput under load.
 
 ---
 
@@ -54,21 +55,19 @@ Mixed-precision quantization of <a href="https://huggingface.co/IFM/K2-Horizon-M
 
 * 🗜️ **8% smaller than IFM's own FP8, 1.7× smaller than BF16.** 44.48 GB against 48.36 GB and
   74.89 GB.
-* 🎯 **Knowledge is level with both references.** 87.31 against the official FP8's 86.84 and BF16's
-  85.94 over 1,170 items. It is the highest number in the table and it is still a tie — read the
-  four builds as one group on this axis.
-* 🎯 **The better of our two builds on tool calls.** 73.47 on call accuracy against the pure NVFP4
-  build's 71.77, for 7.74 GB more — the one axis that separates the two (t = +2.42). Against the
-  official FP8 the pooled gap is 1.44 and neither half of the suite separates on its own.
-* 🧠 **The lever was the weight-scale scheme, not the bit width.** Moving two thirds of the expert
-  layers from group-wise 4-bit to FP8 with `[128,128]` block scales is worth about a point of tool
-  calling; every build we measured between 36.74 GB and 48.39 GB otherwise lands in the same band.
+* 🎯 **Knowledge is level with both references.** 87.3 against the official FP8's 86.8 and BF16's
+  85.9 over 1,170 items. It is the highest number in that column and it is still a tie.
+* 🧭 **The better of our two builds on tool calls.** 73.5 on call accuracy against the pure NVFP4
+  build's 71.8, for 7.74 GB more — the one axis that separates the two (t = +2.4). Against the
+  official FP8 the gap is 1.4 and neither half of the suite separates on its own.
+* 🧠 **Block scales, not bit width, are what moved tool calling here.** Two thirds of the expert
+  layers carry FP8 with `[128,128]` block scales rather than group-wise 4-bit.
 * 🖥️ **One card, no tensor parallelism.** Both official recipes use TP=2; this fits TP=1 with
   231,488 tokens of KV at 32K context.
 * ⚠️ **Blackwell.** Two thirds of the expert layers carry FP8 block scales and sm_80 has no FP8
-  tensor cores, so we neither built nor tested this one for Ampere. The pure NVFP4 build is
-  verified there.
-* 🔧 **`compressed-tensors`, no custom kernels.** Stock vLLM off the nightly image, no patches.
+  tensor cores, so we neither built nor tested this one for Ampere. The pure NVFP4 build is verified
+  there.
+* 🔧 **Serves on stock vLLM `main`, no patches and no custom kernels.** Plain `compressed-tensors`.
 
 ---
 
@@ -79,17 +78,22 @@ K2-Horizon support merged into vLLM `main` on 3 September 2026
 0.28.0 predates it. Use a `main`/nightly build:
 
 ```bash
+hf download primitive-ai/K2-Horizon-MoVA-36B-A4B-mixed-NVFP4-FP8 \
+  --local-dir ./K2-Horizon-MoVA-36B-A4B-mixed-NVFP4-FP8
+
 docker run --gpus all --ipc=host -p 8000:8000 -v $PWD:/models \
-  vllm/vllm-openai:nightly \
+  vllm/vllm-openai:nightly-8a728663c1c3eeace834a95f5654fa653cc1998c \
   --model /models/K2-Horizon-MoVA-36B-A4B-mixed-NVFP4-FP8 \
   --trust-remote-code --max-model-len 32768 \
   --gpu-memory-utilization 0.92 \
   --reasoning-parser k2_horizon
 ```
 
-Verified on the pinned nightly `8a728663c1c3` (vllm `0.28.1rc1.dev388`), one RTX PRO 6000
-Blackwell: 43.02 GiB resident for weights, 42.39 GiB left for KV — **231,488 tokens at 32K context,
-7.06× concurrency** — and engine init in 198 s.
+That image tag is the nightly every number on this page was measured on (vllm
+`0.28.1rc1.dev388`). On one RTX PRO 6000 Blackwell it leaves 43.02 GiB resident for weights and
+42.39 GiB for KV — **231,488 tokens at 32K context, 7.06× concurrency**. Expect a slow first boot:
+engine init takes 198 s, of which 90 s is `torch.compile`, because the FP8 block-scale path compiles
+more kernels than a pure NVFP4 one (97 s and 3 s respectively for our other build).
 
 **Reasoning effort is a server-level choice on this architecture, not a per-request one.** The
 template emits a different tag pair per effort and `K2HorizonReasoningParser` picks one pair once
@@ -121,10 +125,10 @@ the runs counted in the `runs k/a` column.
 
 | build | size | knowledge | call | abstain | tool calling | runs k/a | finished | out/answer |
 |---|---|---|---|---|---|---|---|---|
-| [IFM BF16](https://huggingface.co/IFM/K2-Horizon-MoVA-36B-A4B) | 74.89 GB | 85.94 ±0.66 | 74.58 ±1.30 | 60.83 ±2.89 | 71.83 ±1.04 | 2/3 | 95.8% | 1206 |
-| [IFM FP8](https://huggingface.co/IFM/K2-Horizon-MoVA-36B-A4B-FP8) | 48.36 GB | 86.84 ±0.48 | 74.90 ±1.50 | 60.42 ±2.92 | 72.00 ±0.77 | 2/6 | 96.1% | 1176 |
-| **this repo** | **44.48 GB** | 87.31 ±1.03 | 73.47 ±1.71 | 58.89 ±3.09 | 70.56 ±1.40 | 2/9 | 96.3% | 1118 |
-| [our pure NVFP4](https://huggingface.co/primitive-ai/K2-Horizon-MoVA-36B-A4B-NVFP4) | 36.74 GB | 86.54 ±0.54 | 71.77 ±1.00 | 60.42 ±3.68 | 69.50 ±1.38 | 2/6 | 95.6% | 1234 |
+| [IFM BF16](https://huggingface.co/IFM/K2-Horizon-MoVA-36B-A4B) | 74.89 GB | 85.9 ±0.7 | 74.6 ±1.3 | 60.8 ±2.9 | 71.8 ±1.0 | 2/3 | 95.8% | 1206 |
+| [IFM FP8](https://huggingface.co/IFM/K2-Horizon-MoVA-36B-A4B-FP8) | 48.36 GB | 86.8 ±0.5 | 74.9 ±1.5 | 60.4 ±2.9 | 72.0 ±0.8 | 2/6 | 96.1% | 1176 |
+| **this repo** | **44.48 GB** | 87.3 ±1.0 | 73.5 ±1.7 | 58.9 ±3.1 | 70.6 ±1.4 | 2/9 | 96.3% | 1118 |
+| [our pure NVFP4](https://huggingface.co/primitive-ai/K2-Horizon-MoVA-36B-A4B-NVFP4) | 36.74 GB | 86.5 ±0.5 | 71.8 ±1.0 | 60.4 ±3.7 | 69.5 ±1.4 | 2/6 | 95.6% | 1234 |
 
 `call` is accuracy on the 160 tool-calling items that require a call; `abstain` is the 40 whose
 correct action is to call **nothing**; `tool calling` is the two pooled as 200. We report the halves
@@ -132,22 +136,19 @@ separately because pooling hides which one moved. `runs k/a` is the number of kn
 runs behind each row. `finished` is the share of the 1,170 knowledge items that answered inside the
 token budget; `out/answer` is mean output tokens.
 
-**Knowledge is one group.** This build's 87.31 is the highest number in the column and it does not
-separate from anything: against the official FP8 it is t = +0.59, at n=2 on both sides. The four
-means span 1.4 points, which is inside a single checkpoint's own repeat spread. Don't rank on this
+**Knowledge is one group.** This build's 87.3 is the highest number in the column and it does not
+separate from anything: against the official FP8 it is t = +0.6, at n=2 per side. Don't rank on this
 column.
 
-**Tool calling: 1.44 below the official FP8, and here is the honest version of that.** The pooled
-200-item number separates (t = −2.56 over nine runs here and six there). Neither half separates on
-its own: `call` is 1.42 low at t = −1.70, `abstain` is 1.53 low at t = −0.97. So the loss is small,
-real in aggregate, and spread across both halves of the suite rather than concentrated in one. That
-is a different result from our pure NVFP4 build, where the loss is 3.12 on `call` alone (t = −4.24)
-and abstention is untouched.
+**Tool calling: where the 1.4 sits.** The pooled 200-item number separates from the official FP8
+(t = −2.6 over nine runs here and six there), but neither half does on its own: `call` is 1.4 low at
+t = −1.7 and `abstain` is 1.5 low at t = −1.0. So the loss is small, real in aggregate, and spread
+across both halves of the suite rather than concentrated in one. Our pure NVFP4 build behaves
+differently — there the loss is 3.1 on `call` alone (t = −4.2) and abstention is untouched.
 
-**It is not a formatting failure.** Unparsed replies run at 14 per 1,800 here (0.78%) against 13
-per 1,200 for the official FP8 (1.08%) and 6 per 600 for BF16 (1.00%) — ours is the cleanest of the
-three. Thinking fired on 99–100% of items in every row. The model produces well-formed calls; the
-residual is argument accuracy.
+It is not a formatting failure. Unparsed replies run at 14 per 1,800 here (0.78%) against 13 per
+1,200 for the official FP8 (1.08%) and 6 per 600 for BF16 (1.00%) — cleaner than either IFM build,
+and our pure NVFP4 build is cleaner still at 0.75%. Thinking fired on 99–100% of items in every row.
 
 <details>
 <summary>Per-benchmark detail, both suites</summary>
@@ -175,7 +176,7 @@ Pooled over every run behind the row, so a cell rests on `runs × items`. `when2
 40 abstention items; the other four tool-calling benchmarks supply the 160 call items.
 
 **Where the tool-calling difference sits.** xlam/APIGen is 40.2 here against the official FP8's
-44.8 — 4.6 points on 45 items, and the largest single-benchmark gap on the page. The pure NVFP4
+44.8, 4.6 points on 45 items and this build's largest gap against that reference. The pure NVFP4
 build gives up 7.0 points on the same benchmark, so this build recovers about a third of that loss.
 xlam items carry the longest argument lists in the suite.
 
@@ -183,20 +184,19 @@ xlam items carry the longest argument lists in the suite.
 
 > **The noise floor, and why the run counts are in the table.** Every build compared here has at
 > least six agentic runs, the one exception being the BF16 reference at three. It needs to be six.
-> The official FP8's tool-calling figure read 72.67 ±0.29 after three runs and 72.00 ±0.77 after
-> six; this build's read 70.33 ±1.61 after three and 70.56 ±1.40 after nine. On the 1,170-item
-> knowledge suite, repeat runs of a single checkpoint span up to 1.9 points, so **treat any
-> knowledge gap under about 1.2 points as unresolved** — every gap in that column is smaller than
-> that. We publish ties as ties.
-
-**Two footnotes on the table.** The BF16 row was served at 20,480 context against the quants'
-32,768, because 74.89 GB of weights leaves only 81,664 tokens of KV on a 96 GB card; the generation
-budget was the same 16,384 tokens for every row. And `out/answer` is a mean over a long tail —
-median output is 204 tokens here against a mean of 1,118, a ratio near 5.5×. That ratio is usually
-the signature of a model that reaches its answer and cannot stop, so it is worth saying plainly
-that it is not: the official FP8 shows 1,176 against a median of 211 on the same items, the same
-ratio, and the same ~4% of items hitting the budget. It is how K2-Horizon reasons — short answers
-most of the time, occasional long chains — and quantization did not cause it.
+> The official FP8's tool-calling figure read 72.7 ±0.3 after three runs and 72.0 ±0.8 after six;
+> this build's read 70.3 ±1.6 after three and 70.6 ±1.4 after nine. On the 1,170-item knowledge
+> suite, repeat runs of a single checkpoint span up to 1.9 points, so **treat a knowledge gap of a
+> point or so as unresolved.** The widest gap in that column is 1.4, between this build and BF16,
+> and even that is only t = +1.6. We publish ties as ties.
+
+Two footnotes on the table. The BF16 row was served at 20,480 context against the quants' 32,768,
+because 74.89 GB of weights leaves only 81,664 tokens of KV on a 96 GB card; the generation budget
+was the same 16,384 tokens for every row. And `out/answer` is a mean over a long tail: median output
+is 204 tokens against a mean of 1,118, a ratio of 5.5×. That shape usually means a model that
+reaches its answer and cannot stop. Here it does not — the official FP8 shows 1,176 against a
+median of 211 on the same items, a ratio of 5.6×, with the same ~4% of items hitting the budget.
+It is how K2-Horizon reasons, and quantization did not cause it.
 
 ---
 
@@ -205,7 +205,8 @@ most of the time, occasional long chains — and quantization did not cause it.
 Cache-free, 8,192 tokens in and 512 out, one RTX PRO 6000 Blackwell, same nightly and same serve
 flags as the accuracy rows. Prefix caching is disabled and every measurement runs on its own seed,
 so no row is reading a cache the previous one filled. These come from one sitting and drift a few
-percent between sittings, so read them as a bracket rather than to the decimal.
+percent between sittings, so read them as a bracket. BF16 is absent because at 74.89 GB it only
+serves 20,480 context on this card, which would not be the same measurement.
 
 | build | tok/s @ conc 1 | TPOT @ conc 1 | tok/s @ conc 32 | TPOT @ conc 32 | median TTFT @ conc 32 |
 |---|---|---|---|---|---|
@@ -213,17 +214,17 @@ percent between sittings, so read them as a bracket rather than to the decimal.
 | **this repo** | 29.99 | 32.56 ms | 248.4 | 89.5 ms | 3.59 s |
 | [our pure NVFP4](https://huggingface.co/primitive-ai/K2-Horizon-MoVA-36B-A4B-NVFP4) | **30.45** | **32.10 ms** | **301.5** | 93.1 ms | **1.54 s** |
 
-**Quantizing this model buys prefill, not decode.** Those three builds span 12 GB and land within
-0.7 tok/s of each other at concurrency 1, and their per-token decode cost at concurrency 32 is
-within 5% (89.2–93.1 ms). The aggregate difference is almost entirely time to first token. Prefill
-is compute-bound and lower-precision expert GEMMs are faster; decode is bandwidth-bound and cannot
-improve much, because vLLM restacks the 7.55 GB of BF16 MoVA value-experts on every forward pass
-whatever the routed experts are quantized to. That fixed cost dominates a single stream and is the
-reason single-stream latency is flat across the whole size range.
+**Quantizing this model buys throughput under load, not single-stream latency.** Those three builds
+span 11.6 GB and land within 0.71 tok/s of each other at concurrency 1. At concurrency 32 their
+per-token decode cost is nearly flat too — 89.2, 89.5 and 93.1 ms, a 4.4% spread — so the aggregate
+differences are not a decode-rate effect. They show up in prefill and in scheduling under load,
+where median time to first token falls from 4.46 s to 1.54 s across the range. Decode stays pinned
+because vLLM restacks the 15.1 GB of BF16 MoVA value-experts on every forward pass whatever the
+routed experts are quantized to, and that fixed cost dominates a single stream.
 
-This build sits between the two on every throughput column, which is what its size predicts. If
-throughput under load is the priority rather than call accuracy, the pure NVFP4 build is 1.21×
-this one at concurrency 32 and reaches first token in 1.54 s against 3.59 s.
+This build sits between the two on all five columns, which is what its size predicts. If throughput
+under load matters more than call accuracy, the pure NVFP4 build is 1.21× this one at concurrency 32
+and reaches first token in 1.54 s against 3.59 s.
 
 ---
 
@@ -232,21 +233,20 @@ this one at concurrency 32 and reaches first token in 1.54 s against 3.59 s.
 | | **this repo** | [pure NVFP4](https://huggingface.co/primitive-ai/K2-Horizon-MoVA-36B-A4B-NVFP4) |
 |---|---|---|
 | size | 44.48 GB | **36.74 GB** |
-| knowledge | 87.31 ±1.03 | 86.54 ±0.54 |
-| call | **73.47 ±1.71** | 71.77 ±1.00 |
-| abstain | 58.89 ±3.09 | 60.42 ±3.68 |
-| tool calling, pooled | 70.56 ±1.40 | 69.50 ±1.38 |
+| knowledge | 87.3 ±1.0 | 86.5 ±0.5 |
+| call | **73.5 ±1.7** | 71.8 ±1.0 |
+| abstain | 58.9 ±3.1 | 60.4 ±3.7 |
+| tool calling, pooled | 70.6 ±1.4 | 69.5 ±1.4 |
 | tok/s @ conc 32 | 248.4 | **301.5** |
 | median TTFT @ conc 32 | 3.59 s | **1.54 s** |
 | Blackwell | yes | yes |
 | **Ampere (A100)** | **no** | **yes** |
 
-This build spends 7.74 GB, +21%, and call accuracy is the one axis that pays it back: +1.70 at
-t = +2.42. The pooled tool-calling lead of 1.06 does not separate (t = +1.45), nor does knowledge
-(t = +0.94). **If tool calling dominates
-your workload and you have 48 GB, IFM's own FP8 is still the most accurate option** — it leads this
-build by 1.44 pooled. What this build offers against it is 8% less memory at a gap that neither
-half of the suite resolves on its own.
+This build spends 7.74 GB, +21%, and call accuracy is the one axis that pays it back: +1.7 at
+t = +2.4. The pooled tool-calling lead of 1.1 does not separate (t = +1.5), nor does knowledge
+(t = +0.9). **If tool calling dominates your workload and you have 48 GB, IFM's own FP8 is still the
+most accurate option** — it leads this build by 1.4 on call accuracy. What this build offers against
+it is 8% less memory at a gap that neither half of the suite resolves on its own.
 
 **On Ampere.** We have not tested this build on an A100 and do not expect FP8 block scales to load
 on sm_80, which has no FP8 tensor cores. The pure NVFP4 build does run there through Marlin
@@ -262,7 +262,7 @@ different `temperature`, or whether the model was allowed to reason at all. So e
 table, on this card and on our other cards, comes from the one fixed protocol described above — the
 same 1,370 items, auto-scored, no LLM judge.
 
-| model | shape | size | overall | knowledge | call | abstain | finished | out |
+| model | shape | size | overall | knowledge | call | abstain | finished | out/answer |
 |---|---|---|---|---|---|---|---|---|
 | [Laguna-XS-2.1](https://huggingface.co/primitive-ai/Laguna-XS-2.1-mixed-NVFP4-MXFP8) | 31 B MoE | 19.3 GiB | 81.7 | 83.8 | 68.4 | 73.5 | 98.9% | 1097 |
 | [Nemotron-3.5-Lightning-30B-A3B](https://huggingface.co/primitive-ai/Nemotron-3.5-Lightning-30B-A3B-mixed-INT4-INT8) | 30 B MoE+Mamba | 19.2 GiB | 87.1 | 87.9 | 85.4 | 70.5 | 97.9% | 1429 |
@@ -270,17 +270,17 @@ same 1,370 items, auto-scored, no LLM judge.
 | [Muse-Glimmer-30B](https://huggingface.co/primitive-ai/Muse-Glimmer-30B-mixed-NVFP4) | 30 B MoE | 20.4 GiB | 86.6 | 88.8 | 78.6 | 54.5 | 99.7% | 800 |
 | [Qwen3.8-27B](https://huggingface.co/primitive-ai/Qwen3.8-27B-mixed-NVFP4-FP8) | 27 B dense | 20.7 GiB | 88.8 | 90.4 | 85.5 | 54.5 | 99.7% | 651 |
 | [Granite-4.2-30B](https://huggingface.co/primitive-ai/granite-4.2-30b-mixed-NVFP4-FP8) | 30 B dense | 18.1 GB | 85.5 | 86.2 | 85.8 | 60.8 | 98.5% | 1502 |
-| [K2-Horizon-MoVA-36B-A4B NVFP4](https://huggingface.co/primitive-ai/K2-Horizon-MoVA-36B-A4B-NVFP4) | 37 B MoE+MoVA, 4 B active | 36.74 GB | 84.1 | 86.5 | 71.8 | 60.4 | 95.6% | 1234 |
-| **K2-Horizon-MoVA-36B-A4B mixed** (this repo) | 37 B MoE+MoVA, 4 B active | **44.48 GB** | **84.9** | 87.3 | 73.5 | 58.9 | 96.3% | 1118 |
+| [K2-Horizon-MoVA-36B-A4B NVFP4](https://huggingface.co/primitive-ai/K2-Horizon-MoVA-36B-A4B-NVFP4) | 37 B MoE+MoVA, 4 B active | 36.7 GB | 84.1 | 86.5 | 71.8 | 60.4 | 95.6% | 1234 |
+| **K2-Horizon-MoVA-36B-A4B mixed** (this repo) | 37 B MoE+MoVA, 4 B active | **44.5 GB** | **84.9** | 87.3 | 73.5 | 58.9 | 96.3% | 1118 |
 | [Laguna-S-2.1](https://huggingface.co/primitive-ai/Laguna-S-2.1-mixed-NVFP4-MXFP8) | 110 B MoE | 64.0 GiB | 84.3 | 87.1 | 64.6 | 81.0 | 97.3% | 995 |
 | [Qwen3.8-Flash-Next](https://huggingface.co/primitive-ai/Qwen3.8-Flash-Next-mixed-NVFP4-FP8) | 180 B MoE, 6 B active | 183.7 GB | 90.3 | 92.2 | 84.8 | 56.7 | 99.5% | 686 |
 
 `overall` pools the two suites as 1,370 items, weighted 85.4% knowledge and 14.6% tool calling by
 item count. **Read it with `finished`**: `overall` scores an answer that overran the token budget as
 wrong, but it cannot tell you whether the model needed the room or failed to stop — `finished` and
-`out` separate those, and this model's 96.3% is among the lowest `finished` in the table because it
-reasons in long chains. A gap under **1.0** in `overall` is a tie. Sizes are as each card reports
-them, which mixes GB and GiB; the rest of this page is GB.
+`out/answer` separate those, and this model's 96.3% is among the lowest `finished` in the table
+because it reasons in long chains. A gap under **1.0** in `overall` is a tie. Sizes are as each card
+reports them, which mixes GB and GiB.
 
 ---
 
@@ -290,24 +290,26 @@ The model is 37.4 B parameters in five very unequal pieces:
 
 | | params | share |
 |---|---|---|
-| routed MoE experts, 45 layers × 100 × 3 × 2560×768 | 26.54 B | 70.9% |
+| routed MoE experts, 45 layers × 100 × 3 × 2560×768 | 26.54 B | 71.0% |
 | MoVA value-experts, 45 layers × 64 × 2560×1024 | 7.55 B | 20.2% |
 | attention `qk_proj` / `o_proj` / `gate_proj` | 1.61 B | 4.3% |
 | `embed_tokens` + `lm_head`, untied, vocab 250624 | 1.28 B | 3.4% |
 | shared experts + the three dense MLP layers | 0.41 B | 1.1% |
 
+Which of those pieces got which format:
+
 | tensors | count | format |
 |---|---|---|
 | routed experts on 30 of the 45 sparse layers | 9,000 | FP8 E4M3, block scales `[128,128]` |
 | routed experts on the other 15 sparse layers | 4,500 | NVFP4, group 16 |
 | MoVA `v_experts` and `v_router`; `qk_proj`/`o_proj`/`gate_proj`; `mlp.gate`; shared experts; dense layers 0–2; `lm_head`; embeddings; norms | 3,408 | BF16 |
 
-`compressed-tensors`, top-level format `mixed-precision`, two config groups. The NVFP4 group is
-W4A4 and carries observed activation scales plus a tensor-level `weight_global_scale`; the FP8 group
-is weight-only with block scales.
+`compressed-tensors`, top-level format `mixed-precision`, two config groups. The NVFP4 group is W4A4
+and carries observed activation scales plus a tensor-level `weight_global_scale`; the FP8 group is
+weight-only with block scales.
 
-**The second-largest block is off limits for a concrete reason, not caution.** vLLM's MoVA attention
-does this on every forward pass:
+**The second-largest block cannot be quantized at all.** vLLM's MoVA attention does this on every
+forward pass:
 
 ```python
 w1 = torch.stack([expert.weight for expert in self.v_experts], dim=0).contiguous()
@@ -318,17 +320,16 @@ It stacks the raw `.weight` of all 64 value-experts and hands `fused_mova_impl`
 quantized `Linear` carries `weight_packed` plus scales and no `weight`, so a quantized v_expert
 either fails at load or feeds packed bytes to a kernel that reads them as bfloat16. IFM's own FP8
 ignores all 2,880 of them for the same reason. That is 20% of the model pinned to BF16 in any build,
-which is why lower precision buys less here than the parameter count suggests — and, per the
-throughput section, why decode speed barely moves.
+which is why lower precision buys less here than the parameter count suggests: those 7.55 B
+parameters are 15.1 GB of BF16 that every forward pass moves regardless. Per the throughput section,
+that is why decode speed barely moves.
 
-Attention is left alone too: MoVA fuses `q` and `k` into a single `qk_proj`, so those two would have
-to share one scheme. And a layer's experts are quantized as a unit: vLLM's fused MoE requires one
-scheme across an expert's `gate`/`up`/`down`, so the mixture here is per layer, never per
-projection.
+Two engine constraints shape the rest. MoVA fuses `q` and `k` into a single `qk_proj`, so those two
+would have to share one scheme. And a layer's experts are quantized as a unit: vLLM's fused MoE
+requires one scheme across an expert's `gate`/`up`/`down`, so the mixture here is per layer, never
+per projection.
 
-We publish the formats and the measurements. How the allocation was chosen is ours; note that a
-servable `compressed-tensors` checkpoint must declare its targets in `config.json`, so which modules
-sit in which format is visible there by necessity.
+---
 
 ## Attribution
 
@@ -337,8 +338,9 @@ sit in which format is visible there by necessity.
 - Calibration: 496 conversations at seqlen 2048, used to observe activation scales.
 - The checkpoint carries IFM's `modeling_k2_horizon.py` and `configuration_k2_horizon.py`
   unchanged, so `--trust-remote-code` works for tooling that wants the reference implementation.
-- Audited before publication: every fused NVFP4 group shares one `weight_global_scale`, no
-  activation scale is zero or NaN, and `config.json` agrees with the tensors actually present.
+- Audited before publication: every fused NVFP4 group shares one `weight_global_scale`, every FP8
+  block-scale tensor has the shape its group declares, no activation scale is zero or NaN, and
+  `config.json` agrees with the tensors actually present.
 
 ---