llama.cpp q4_0 KV on Qwen3-8B: 3.6x smaller cache, +1% perplexity, half the decode
Fields
kv-efficiency/llamacpp-qwen3-8b-q4kv-32k-a100Notes
Third-party measurement, not a vendor claim. Closes the measured-footprint gap for 4-bit KV: the collections 4-bit rows are ExLlamaV2 Q4, Quanto int4 and TurboQuant, and each of them derives its byte rate from the dtype width. This one is the cache size llama.cpp actually allocated. QUALITY COST, measured on the same run: wikitext-2 perplexity at 32K is 8.41 for f16, 8.41 for q8_0 and 8.49 for q4_0, so q4_0 costs about 1 percent perplexity and q8_0 costs none. SPEED COST, which the dtype-width rows do not capture: at 64K depth f16 decodes at 81.6 tok/s, q8_0 at 44.7 (55 percent) and q4_0 at 41.2 (50 percent). The cache is 3.59x smaller but decode is twice as slow, because the dequantization is memory-latency bound at batch 1. A 4 October 2026 update on a later build holds the same shape: 56 and 53 percent of f16 at 64K. WHAT IT BUYS ON A SMALL CARD: the 32K cache drops from 4.38 GiB to 1.22 GiB, which is the difference between a 32K context fitting beside the 4.68 GiB of Q4 weights on a 8 GB card and not fitting. CAVEAT: the card is an A100 80GB PCIe. The cache sizes and the perplexity are properties of the format and transfer directly; the tok/s figures are for that GPU and that commit (69320fe, sm80) and a later build or a different card will move them. q5_1 and a mixed q8_0/q4_0 setting silently fell back to CPU prefill in the same run, so those are not recorded.