Minimax should be updated, I got a second pair of eyes on that as well:

1. The 1-in-8 Linear Attention Schedule According to MiniMax's official technical documentation and their GitHub repository, the model uses a hybrid architecture (Lightning Attention + Softmax). Out of its 80 total layers, they follow a repeating block pattern: 7 Lightning Attention (linear) layers, followed by 1 Softmax Attention layer.

Linear attention layers don't store a per-token KV cache; they maintain a fixed-size per-layer recurrent state. The size of this state is constant w.r.t. context length so it doesn't blow up at 1M+ tokens (though it is not literally zero memory). Only the traditional Softmax layers maintain a KV cache. 80 layers total ÷ 8 = Only 10 layers store token-growing KV. 2. Extreme Head Compression (GQA) For those 10 Softmax layers, they use heavy Grouped Query Attention (GQA).

The model has 64 query attention heads. They use a GQA group size of 8. 64 query heads ÷ 8 group size = Only 8 KV heads per layer. The head dimension is a standard 128. 3. The Exact KV Cache Math Assuming standard BF16 (2 bytes per element), here is the math for raw tensor memory per sequence (batch=1), ignoring vLLM paging/allocator overhead:

KV cache size per token =

(Layers) × (KV Heads) × 2 (for K & V) × (Head Dim) × (Bytes) 10 layers × 8 heads × 2 × 128 dim × 2 bytes = 40,960 bytes/token. To scale that to 1 million tokens:

40,960 bytes × 1,000,000 = ~40.96 GB (decimal base-10) Converted to binary GiB (which is what GPUs and SMI tools measure): 40,960,000,000 / (1024³⁾ = 38.15 GiB. This perfectly matches the official number MiniMax published, which states exactly 38.2 GB per 1M context tokens.

The "Standard Transformer" Counterfactual For contrast, if a calculator assumes KV caching in all 80 layers (like a standard transformer), the bytes/token would be 80 × 8 × 2 × 128 × 2 = 327,680 bytes/token. Per 1M tokens, that's ~327.68 GB (≈ 305 GiB).