IN THIS BREAKDOWN · 10 SECTIONS
You can read 20% of this breakdown.
The paper in one minute
When an LLM serves many requests at once, the KV cache grows with batch size times context length and can outweigh the model itself. It also has to be read from GPU memory for every generated token, so it limits speed as well as capacity. Storing it in fewer bits helps both. The problem is accuracy: with plain round-to-nearest quantization applied per token (the usual way, since tokens arrive one at a time), 4 bits works and 2 bits breaks. On Llama-2-13B, GSM8K falls from 22.67 to 4.55.
The authors looked at what the cache contains. Keys have a few fixed channels with very large values, consistent with earlier findings about activation outliers. Quantizing per token puts a huge channel in every group, so the scale is set by the outlier and the normal channels get crushed. Quantizing per channel (each group is 32 tokens of one channel) keeps each outlier's error in its own channel. Values have no such channels. They are used as a weighted sum over tokens with sparse attention weights, so what matters is that the few attended tokens are accurate; per token grouping keeps each token's error to itself.
Per-channel grouping needs 32 tokens before a group can be formed, and tokens arrive one at a time. KIVI keeps the newest tokens (up to R = 128) in full precision and quantizes them in blocks when the window fills. That window turns out to matter: without it, 2-bit keys per channel and values per token score 12.21 on GSM8K; with it (KIVI-2), 20.77.
KIVI needs no calibration data or fine-tuning. Across Llama-2, Falcon and Mistral, 2-bit KIVI stayed close to 16-bit on standard and long-context tasks (Falcon-7B, which already shares one KV head, needed 4 bits). On Llama-2-7B, peak memory fell 2.6x, batches grew up to 4x and throughput rose 2.35-3.47x on one A100.
Research notes: the problem, approach and results
lower peak memory on Llama-2-7B including weights, enabling up to 4x larger batches
GSM8K on Llama-2-13B: KIVI-2 against plain 2-bit per-token quantization of keys and values (16-bit: 22.67)
higher throughput on ShareGPT-like requests on one A100, from the larger batch
At large batch sizes and long contexts the KV cache, not the weights, fills GPU memory and dominates the bytes read per generated token. Quantizing it is the obvious fix, but plain per-token 2-bit quantization wrecks accuracy, and calibration-based methods don't fit a cache that grows one token at a time.
Study how keys and values are distributed. Keys have a few fixed channels with very large magnitudes, so quantize them per channel (groups of 32 tokens within a channel); values have no such pattern and are consumed as a weighted mix of a few tokens, so quantize them per token. Keep the newest up to 128 tokens in full precision so per-channel groups can form, and fuse dequantization into the attention matmul.
At 2 bits, Llama-2 and Mistral models stayed within about 2 points of 16-bit on CoQA, TruthfulQA and GSM8K and within about 1 point on LongBench averages. On Llama-2-7B, peak memory fell 2.6x, allowing up to 4x larger batches and 2.35-3.47x throughput.
Why it matters to an FDE
For long contexts or high concurrency, the KV cache is what runs out first. How many users fit on one GPU, and therefore cost per request, often comes down to bytes per KV value.
KV quantization is a capacity lever you can pull without retraining. KIVI is plug-in: no calibration set and no fine-tuning, so it can be tried against a customer's own eval in a day.
Ask how the cache is grouped, not just how many bits. Two 2-bit schemes differ by 16 GSM8K points on the same model. When evaluating a serving stack's "2-bit KV" option, the grouping and the recent-token window decide whether it works.
Averages hide the tasks that break. LongBench averages moved about a point, while passage retrieval on Mistral-7B-Instruct-v0.2 dropped 8.5 points and code completion on Llama-3-8B-Instruct dropped 6. If the customer's product is retrieval over long context or code, test that task directly, and consider 4 bits.
Understand the mechanism. Try it on a real problem.
Unlock this breakdown and 149 more papers.
Premium opens every paper in full, plus every answer, concept, course and guide on the site. One payment for six months of access.
6 months · One payment · No auto-renewal
- ◇1 architecture diagram
- </>1 runnable code experiment
- ▦2 results tables
- ?5 interview questions with answers
- 03Key takeaways
The four groupings compared, why the window matters, the knobs, and three misreadings
Free account - 04How it works
The quantizer, the grouped and residual parts, the decode-time update and the kernels
Premium - 05The numbers that matter
Error analysis, standard and long-context accuracy, ablations and efficiency
Premium - 06Try it yourself
Recheck the paper's tables, quantize toy keys and values both ways, and compute real compression
Premium - 07Where it breaks
Short requests, task-specific losses, MQA models, prefill cost and slips
Premium - 08Using it on a deployment
Sizing the gain for the customer's lengths, testing the fragile tasks, and choosing 2 or 4 bits
Premium - 09Interview angles
Five questions this paper prepares you for, with answer hints
Premium - 10Read next
Where to go from here on this site
Premium
