API-only (weights pending) Apache 2.0 weights in 5 days (Nov 12, 2026) Model card checked Nov 6, 2026

What it takes to run locally

Memory is the binding constraint for a 594B-parameter model, and it does not shrink when weights are unavailable. Every number below is computed from the published parameter count, with the assumptions listed under the table.

Inkling 2 Small has 594B total parameters, so the weights alone occupy about 315.6 GB in its native NVFP4 format or 1188 GB in BF16. With runtime overhead and a 32K KV cache, budget roughly 359.9 GB for the 4-bit format and 380.7 GB for a 4-bit K-quant. That is server hardware, not a single consumer GPU — unless the weights ship in a format we have not seen yet.

These are projections, not verified runs. The weights are not public, so nobody has actually loaded this model outside Thinking Machines and their testers. The figures assume the dense parameter count for memory and treat expert routing as a compute saving only — which is correct, since every expert must be resident.
Estimated memory per quantisation. Weight size scales with all 594B parameters; the KV cache assumes a 32,768-token context.
Format Bits/param Weights KV cache Total
NVFP4 4.25 315.6 GB 6.4 GB 359.9 GB
Q2_K 2.63 195.3 GB 6.4 GB 225.2 GB
Q3_K_M 3.44 255.4 GB 6.4 GB 292.5 GB
Q4_K_M 4.5 334.1 GB 6.4 GB 380.7 GB
Q5_K_M 5.5 408.4 GB 6.4 GB 463.8 GB
Q6_K 6.56 487.1 GB 6.4 GB 552 GB
Q8_0 8 594 GB 6.4 GB 671.7 GB
FP8 (MXFP8) 8 594 GB 6.4 GB 671.7 GB
BF16 16 1188 GB 6.4 GB 1337 GB

What each format means in practice

NVFP4
Native 4-bit format the model was trained to support. Server-class only. With 17B active parameters, throughput per token is far below the nominal size, but every expert must still reside in memory.
Fits on: 4× RTX PRO 6000 (96GB), 5× H100 (80GB), 3× H200 (141GB), 2× B200 (192GB), 2× GB300 (288GB), 1× Mac Studio M3 Ultra (512GB)
Q2_K
Lowest usable quality; expect heavy degradation on reasoning. Server-class only. With 17B active parameters, throughput per token is far below the nominal size, but every expert must still reside in memory.
Fits on: 8× RTX 5090 (32GB), 3× RTX PRO 6000 (96GB), 3× H100 (80GB), 2× H200 (141GB), 2× B200 (192GB), 1× GB300 (288GB)
Q3_K_M
Rough but runnable; coding ability drops noticeably. Server-class only. With 17B active parameters, throughput per token is far below the nominal size, but every expert must still reside in memory.
Fits on: 4× RTX PRO 6000 (96GB), 4× H100 (80GB), 3× H200 (141GB), 2× B200 (192GB), 2× GB300 (288GB), 1× Mac Studio M3 Ultra (512GB)
Q4_K_M
The usual quality/size sweet spot. Server-class only. With 17B active parameters, throughput per token is far below the nominal size, but every expert must still reside in memory.
Fits on: 4× RTX PRO 6000 (96GB), 5× H100 (80GB), 3× H200 (141GB), 2× B200 (192GB), 2× GB300 (288GB), 1× Mac Studio M3 Ultra (512GB)
Q5_K_M
Near-lossless for most tasks. Server-class only. With 17B active parameters, throughput per token is far below the nominal size, but every expert must still reside in memory.
Fits on: 5× RTX PRO 6000 (96GB), 6× H100 (80GB), 4× H200 (141GB), 3× B200 (192GB), 2× GB300 (288GB), 1× Mac Studio M3 Ultra (512GB)
Q6_K
Effectively indistinguishable from 8-bit. Server-class only. With 17B active parameters, throughput per token is far below the nominal size, but every expert must still reside in memory.
Fits on: 6× RTX PRO 6000 (96GB), 7× H100 (80GB), 4× H200 (141GB), 3× B200 (192GB), 2× GB300 (288GB), 1× 1TB DDR5 server
Q8_0
Reference-quality quantisation. Beyond any single machine; requires sharding across nodes.
Fits on: 7× RTX PRO 6000 (96GB), 5× H200 (141GB), 4× B200 (192GB), 3× GB300 (288GB), 1× 1TB DDR5 server
FP8 (MXFP8)
The native training format; needs Hopper-class hardware. Beyond any single machine; requires sharding across nodes.
Fits on: 7× RTX PRO 6000 (96GB), 5× H200 (141GB), 4× B200 (192GB), 3× GB300 (288GB), 1× 1TB DDR5 server
BF16
Unquantised weights, as released. Beyond any single machine; requires sharding across nodes.
Fits on: 7× B200 (192GB), 5× GB300 (288GB)

Assumptions behind the table

  • Weights scale with all 594B parameters. The sparse MoE design routes each token to 8 of 384 experts, but that reduces compute per token — not memory: every expert must still be resident.
  • KV cache assumes 48 layers, 8 KV heads and a 128-wide head at a 32K context, which is an estimate: the model card does not publish head counts. Longer contexts scale this term linearly.
  • Total memory adds 12% over raw weight size for activation buffers, the runtime and allocator fragmentation.
  • Active parameters are 17B, which is what drives generation speed; the 594B total drives how much memory you need.

Generated Nov 6, 2026 from the specs on the specifications page. If the vendor revises the parameter or layer count, these figures change on the next build automatically.

Why "17B active" does not mean it fits on a 17B machine

The active-parameter figure describes compute, not storage. Each token touches only 8 of 384 experts, so the arithmetic for a given token is comparable to a 17B dense model — which is why it generates at roughly the speed of one. But which experts a token needs varies token to token, so the runtime must hold all 594B parameters in memory and move them through it.

This is the single most common misconception about sparse models, and it is why the 380.7 GB 4-bit figure, not the 17B parameter count, is the number to plan around.

Third parties measure the model at 135 output tokens per second on hosted infrastructure — consistent with a model whose compute per token resembles something far smaller than its footprint.

Until the weights ship

The only way to use Inkling 2 Small today is over the API. Fine-tuning on Tinker is available now, and adapters are small enough to store locally, but the base weights stay on the vendor's side. See the pricing page for what that costs, or the weights tracker for what would have to change.