DeepSeek-V3.1-Terminus

This model uses multi-head latent attention. No V cache is allocated at all, and the K cache stores a 512-wide latent plus 64 rope dimensions — so reading num_key_value_heads from config.json and multiplying, as every calculator does, overstates the cache by well over an order of magnitude.

A parameters × bits ÷ 8 estimate puts Q4_K_M at roughly 358.60 GiB. The real file is 376.71 GiB, because a quantization is a mixture and some tensors are always kept at higher precision. The larger discrepancy is the cache: this model allocates no value cache at all, so any formula reading num_key_value_heads overstates it by more than an order of magnitude.

How much VRAM does DeepSeek-V3.1-Terminus need?

Q4_K_M is exactly 404,494,158,624 bytes (376.71 GiB) in weights. Add the KV cache, which depends on your context length, plus roughly half a gigabyte of runtime overhead.

How large is DeepSeek-V3.1-Terminus's KV cache?

2.14 GiB at 32K context with an f16 cache, computed per layer. Quantizing the cache to q8_0 roughly halves it, which is often the difference between a context length fitting and not.

Is DeepSeek-V3.1-Terminus a mixture-of-experts model?

Yes — 256 experts, 8 routed per token. Every expert must be resident, but only the routed ones are read per token, which is why its memory requirement and its speed behave very differently.

Which quantization of DeepSeek-V3.1-Terminus should I use?

Q4_K_M is the usual default. Pick the largest quantization that fits your card at the context you actually need — the table above gives exact sizes for every one published.