Open-Weight Coding Models in October 2026: The VRAM, Bandwidth and Cost Math for Self-Hosting

Three open-weight coding models landed within eighteen days of October 2026: Mistral Large 4 on 6 October (Mistral announcement), Meta’s Muse Spark Open on 15 October (Meta dev docs), and Moonshot’s Kimi K3.1 Pro on 23 October (Kimi blog). The arithmetic that decides whether you can serve them is three-layered: total parameters set the hardware footprint, active parameters set the per-token compute bill, and the context window sets the KV-cache budget that no announcement mentions. “Open weight” is a licence statement, not a capacity plan — a 1.05T-parameter checkpoint at BF16 needs 2.10 TB of VRAM before a single token is generated. This analysis is built from vendor documentation and pricing pages fetched on 2026-11-04; no model was served and no GPU was rented. What follows is a decision procedure, not a roundup.

The stack at a glance

The three models differ by an order of magnitude in total parameters and by an order of magnitude in published pricing philosophy, which is why their self-hosting economics diverge so sharply. Mistral publishes API prices and a 52B active count; Meta publishes checkpoint sizes and VRAM guidance but no API price for the open model; Moonshot publishes benchmarks and a context window but not the active-parameter count that the bandwidth math requires.

None of these licences is OSI-approved open source. All three are custom terms: Mistral’s Ecosystem Open Weight License v26.10, Meta’s Muse Model License with an Acceptable Use Policy, and Moonshot’s weights are governed by a stated release policy rather than a licence text at this writing.

Layer 1 — Footprint: total parameters set the hardware floor

Total parameters multiplied by bytes per parameter — 2 bytes at BF16, 1 at FP8, 0.5 at INT4 — gives the weights-only VRAM floor, and it is the first number to check before reading any benchmark. Mistral Large 4 at 1.05T needs 2.10 TB at BF16, 1.05 TB at FP8, or 0.53 TB at INT4. Muse Spark Open at 816B needs 1.63 TB at BF16, 0.82 TB at FP8, or 0.41 TB at INT4. Kimi K3.1 Pro at 3T-class needs 6.00 TB at BF16, 3.00 TB at FP8, or 1.50 TB at INT4 — 1.5 TB of weights before any KV cache exists.

Meta states the architectural fact directly: “Serving still loads the full 816B weights into VRAM, which sets the hardware footprint” (Meta dev docs). Sparsity does not reduce the load; it only reduces the per-step compute, which is Layer 2. Meta’s own checkpoint figures corroborate the arithmetic and add a nuance: the BF16 checkpoint is about 1.65 TB of weights, servable on eight GPUs such as 8 x B300, while the NVFP4 checkpoint is about 537 GB and fits a single 4-GPU Blackwell node (Meta dev docs). The 537 GB sits above the naive 0.41 TB INT4 figure because most weights are 4-bit but some layers are kept in BF16 — quantization is never uniform in practice. Meta adds that for BF16 you should budget roughly 2 TB of VRAM once KV cache, activations, and runtime overhead are counted (Meta dev docs), a ~20% premium over weights alone that recurs across serving stacks.

Mistral’s footprint claims come with provenance: the model was trained from scratch on 3,800 NVIDIA Grace Blackwell GPUs in Mistral’s own European datacenters, and the public preview is served on that same infrastructure (Mistral announcement). Kimi’s 3T-class scale means the floor is the story: at 4-bit, 1.5 TB of weights already exceeds a single 8-GPU node’s HBM on most current parts before a token of context.

Layer 2 — Per-token compute: active parameters set the bandwidth bill

Decode speed is memory-bandwidth-bound: each generated token requires reading the active parameters from HBM once, so bytes moved per step equals active parameters times bytes per parameter, and the single-stream ceiling is bandwidth divided by those bytes. At FP8, Mistral Large 4’s 52B active parameters move 52 GB per step — about 6.5 ms on a ~8 TB/s-class GPU, a single-stream ceiling near 154 tok/s, or about 10.8 ms and ~92 tok/s on a ~4.8 TB/s part; at INT4 that halves to 26 GB per step, ~3.2 ms, and a ~308 tok/s ceiling. Muse Spark Open’s 42B active parameters move 42 GB per step at FP8 — ~5.2 ms and a ~190 tok/s ceiling on ~8 TB/s — or 21 GB per step at INT4, ~2.6 ms, ~381 tok/s ceiling.

The reason 52B and 42B — not 1.05T and 816B — determine single-stream speed is that a sparse MoE routes each token through only its active experts; the dormant experts stay in VRAM but are not read on that step. Kimi K3.1 Pro’s row is empty because Moonshot does not publish the active-parameter count (Kimi blog); without it, the per-token bandwidth math cannot be done from public data, and that absence is itself the finding for anyone planning to serve it. These are bandwidth ceilings, not measurements. Batching changes the picture fundamentally: one weight read serves every sequence in the batch, which is why continuous batching pushes aggregate throughput far above the single-stream ceiling — the ceiling constrains latency, not farm throughput.

Layer 3 — Memory planning: the KV-cache budget the announcements omit

The KV cache is the memory line item that every one of these announcements leaves out, and it scales with context length, not parameter count. In a clearly labelled hypothetical configuration — 61 layers, 8 KV heads, head_dim 128, FP16 — the cache costs 244 KB per token, which is 8.2 GB at 32K context, 50 GB at 200K, and 250 GB at 1M; with 4 KV heads it halves to 122 KB per token, or 125 GB at 1M. To be explicit: this is an illustrative configuration, not any vendor’s published architecture, and no vendor in this set publishes its KV-head configuration — so treat these as planning magnitudes, not specs.

The practical consequence is that you should budget KV from your real context distribution, not the maximum window. Moonshot’s own model card strategy note says Kimi K3.1 Pro adopts a Claude-style context-compaction strategy triggered at 200K tokens (Kimi blog) — an admission that the 1,048,576-token window is not where long-horizon agent traffic actually lives. If your agent turns mostly sit under 200K, a 50 GB-class KV budget per the hypothetical config, not 250 GB, is the number that sizes your node. Muse Spark’s multimodal inputs (text, image, audio, video in; text out — Meta dev docs) add another planning wrinkle: non-text tokens consume cache too, and their expansion factors are not published.

Open-weight model serving costs vs a dedicated node

Open-weight model serving costs are dominated by GPU-hours against aggregate throughput, and at moderate utilization the arithmetic favors the API. From Mistral’s published prices, a 10,000-in / 500-out agent turn costs about $0.008 and a 100,000-in / 2,000-out turn costs about $0.074 (docs); one thousand such calls cost about $8 and about $74 respectively. Against that, the break-even calculation, with every assumption stated: 8 GPUs at $2.50 per GPU-hour is $20/hour; at about 900 tok/s aggregate at 60% utilization, that is roughly $6.17 per million output tokens; 4 GPUs gives roughly $3.09 per million. Against Mistral’s published $2.10 per million output tokens, dedicated capacity is more expensive at moderate utilization — even the 4-GPU configuration at $3.09 loses on unit price.

The consequence for capacity planning: self-host for control, data residency, or refusal-free capability — not for the unit price, unless you can sustain high utilization around the clock. Mistral’s published benchmark claim makes the refusal-freedom argument concrete: the vendor says the model scores 82% on one Artificial Analysis Cyber Index task (highest of any model) and 93% of Cybench challenges, and that several closed models score near zero on the same task because they refuse to perform it (Mistral announcement). That is a vendor’s own claim, but it identifies a real category of workload — security and red-team tooling — where API refusals, not price, are the binding constraint. Moonshot approaches the same territory from the policy side: it states it will not release open weights that “extend the absolute frontier of cyber capability” and intends to raise open-weight cyber capability progressively (Kimi blog). That is a release-gating policy about which capabilities ship, not a licence term about what you may run.

What the announcements did not tell you

The gaps in these announcements are consistent, and they are exactly the numbers a serving plan needs. Kimi K3.1 Pro’s active-parameter count is not published in the available sources (Kimi blog), which makes its decode ceiling and its cost-per-token arithmetic impossible to compute independently; Moonshot’s pricing page is JavaScript-rendered, so the $2/$10 figures circulating are reported secondhand rather than captured from the primary table (Moonshot pricing). No vendor publishes KV-head counts, so KV budgets must be estimated from generic configurations. And every headline benchmark is a vendor claim: Mistral’s 82% Cyber Index and 93% Cybench figures (Mistral announcement) and Kimi’s Terminal-Bench 4.0 at 65.7% (versus GPT-6 Astra 58.2% and Claude Opus 5.5 66.4%) and Kimi Code Bench 3.0 Long-horizon at 61.2% versus K3’s 55.95% (Kimi blog) all come from the vendors themselves. Two further context points matter for planning rather than benchmarking: Kimi ships a “Highspeed” variant claiming 2–3x the speed of the base model (Kimi blog), and Muse Spark Open shares the same base model as the closed Muse Spark 1.3 (PyTorch blog) — meaning the open checkpoint is a release decision about an existing capability, not a new capability class.

The decision rule: what to self-host, in order

Self-hosting decisions should follow a fixed order because each step’s output feeds the next, and skipping to the price comparison is the most common failure. The procedure:

1. Size nodes from total parameters at target precision. Multiply total params by bytes per parameter: Mistral Large 4 is 2.10 TB BF16 / 1.05 TB FP8 / 0.53 TB INT4; Muse Spark Open is 1.63 / 0.82 / 0.41 TB (Meta’s actual checkpoints: ~1.65 TB BF16, 537 GB NVFP4); Kimi K3.1 Pro is 6.00 / 3.00 / 1.50 TB. Add ~20% overhead per Meta’s own 2 TB guidance for its 1.65 TB BF16 model.
2. Compute the bandwidth ceiling from active parameters. 52 GB/step for Mistral at FP8 (~154 tok/s single-stream on ~8 TB/s), 42 GB/step for Muse (~190 tok/s). For Kimi, this step cannot be completed from public data — treat its single-stream latency as unknown until weights and configs ship.
3. Budget KV from your real context distribution, not the max window. If traffic concentrates under 200K — as Moonshot’s own 200K compaction trigger implies — plan for the tens-of-GB class, not the 250 GB-at-1M class, and note the config is hypothetical until vendors publish KV-head counts.
4. Compare against published API price at sustained utilization. At ~60% utilization, dedicated 8-GPU capacity works out to roughly $6.17 per million output tokens and 4-GPU to roughly $3.09, versus Mistral’s published $2.10 — the API wins on unit price unless utilization is much higher.
5. Self-host only if the arithmetic clears, or if control, data residency, or refusal-free capability dominates. If step 4 fails but your workload is refusal-gated or residency-bound, self-hosting is still rational — but make that trade consciously, with the ~$4–6 per million premium priced in.

Limits of this analysis

This analysis is built from vendor documentation and pricing pages fetched on 2026-11-04; no model was served and no GPU was rented, so no throughput, latency, or quality number here is a measurement. The single-stream figures are arithmetic bandwidth ceilings, not benchmark results, and real serving stacks fall below them. The KV-cache configuration (61 layers, 8 KV heads, head_dim 128, FP16) is a labelled hypothetical; no vendor in this set publishes its KV-head architecture. Kimi K3.1 Pro’s full weights were scheduled for release by 2026-11-04 and were not confirmed available at this writing, and its active-parameter count and primary pricing are unpublished — the $2/$10 figures are reported secondhand. All benchmarks cited are vendor claims, not independent evaluations. Mistral’s weights were announced for “the end of the month” and their final availability was not independently verified. Prices and terms change; re-verify before committing budget.

FAQ

Can I self-host Mistral Large 4 on a single 8-GPU node?

At FP8, weights alone need 1.05 TB, which fits eight ~141 GB-class parts with room for a modest KV cache; BF16 at 2.10 TB does not fit with usable context. The single-stream ceiling is ~154 tok/s at FP8, so plan for batching to hit useful aggregate throughput. Note the licence is open weight, not OSI open source (docs).

Why does Muse Spark Open’s 537 GB checkpoint not match the naive 4-bit estimate?

The naive INT4 arithmetic gives 0.41 TB for 816B parameters, but Meta’s NVFP4 checkpoint is about 537 GB because most weights are 4-bit while some layers are kept in BF16 (Meta dev docs). Quantization is never uniform — sensitive layers stay high-precision. Always plan from the published checkpoint size, not the naive per-parameter estimate, and add KV cache and runtime overhead on top.

What is Kimi K3.1 Pro’s active-parameter count?

It is not published in the available sources (Kimi blog), and it should not be guessed. Without it, the decode bandwidth math — bytes moved per step, step time, single-stream ceiling — cannot be computed from public data. This is the single largest planning gap among the three models, and it means Kimi’s serving economics cannot be evaluated independently until the weights and configurations ship.

Is self-hosting cheaper than the Mistral API?

Not at moderate utilization. Eight GPUs at $2.50 per GPU-hour cost $20/hour; at about 900 tok/s aggregate and 60% utilization, that is roughly $6.17 per million output tokens, and 4 GPUs give roughly $3.09 — both above Mistral’s published $2.10 (docs). Self-hosting wins on unit price only at sustained high utilization, or when control, data residency, or refusal-free capability is the actual requirement.

Are the vendor benchmarks trustworthy for capacity planning?

Treat them as vendor claims, not independent results: Mistral’s 82% Cyber Index and 93% Cybench figures (Mistral announcement) and Kimi’s Terminal-Bench 4.0 65.7% and Code Bench 61.2% (Kimi blog) come from the vendors themselves. They are useful for relative positioning and for identifying workload categories, but they carry no information about VRAM footprint, bandwidth ceilings, or serving cost — the numbers that actually decide self-hosting.

The Bottom Line

October 2026’s three releases mark the point where open-weight coding models crossed the trillion-parameter line, and the serving math says most teams should read that as a pricing signal, not a hosting invitation. Mistral Large 4 is the only one of the three with complete public arithmetic — 52B active parameters, published prices, a 2.10 TB BF16 floor — and even it loses on unit price to its own API below high utilization ($6.17 vs $2.10 per million output tokens at 60% utilization on 8 GPUs). Muse Spark Open is the most hostable at the checkpoint level (537 GB NVFP4 on a 4-GPU node) but publishes no API price for the open model. Kimi K3.1 Pro is the largest and the least plannable: 1.50 TB at 4-bit, no active-parameter count, secondhand pricing. The rational posture is to run the five-step decision rule per workload: host only where refusal-freedom, residency, or control is the binding constraint, and buy tokens everywhere else.