KVQuant nuq3-1% on LLaMA-7B: 4.8x KV compression, under 0.1 WikiText-2 perplexity, A6000 decode kernel faster than fp16
Fields
kv-efficiency/kvquant-nuq3-llama7b-a6000Notes
Closes the sub-4-bit KV-quantization gap that is not KIVI and not TurboQuant. KVQuant nuq3-1% (per-channel keys, pre-RoPE, non-uniform, 1% per-vector sparse outliers) is a 3-bit scheme with a published quality cost: under 0.1 WikiText-2 perplexity versus fp16 across LLaMA, Llama-2, Llama-3, and Mistral; 4-bit under 0.02; 2-bit under 0.5; with stated memory savings of 4.8x, 3.7x, and 6.9x. Passkey on LLaMA-2-7B-32K stays at 1.0 from 4K through 32K for nuq3-1% (0.98 at 2K) against fp16 at 1.0, while the paper's own KIVI-2 comparison falls to 0.70 at 32K. LongBench average is 31.21 versus 31.96 fp16 (a 0.75 point drop) and 30.04 for KIVI-2. HARDWARE: the only timed number is on an RTX A6000, a 48 GB workstation card. At sequence length 16K the nuq4-1% key matvec is 126.3 us versus 219.4 us fp16 (1.74x) and the value matvec is 124.5 versus 203.7 us (1.64x), including packing. That speedup is the kernel, not a request tok/s, so measured_tps_at_ctx stays null. WHY IT MATTERS ON A SMALL CARD: fp16 KV for LLaMA-7B is 524,288 B/token, so 32K is 16 GiB of cache before weights. At 3.33 bits that is 109,118 B/token, 3.33 GiB at 32K, which is the difference between the cache fitting beside the weights on a 24 GB card and not. LLaMA-7B is not a models/ record; the geometry is the standard 32-layer MHA one, and Table 8's 64 GB-at-128K figure is consistent with it within rounding. engine_id is niche-h2ogpt only because KVQuant ships as a research kernel rather than a serving engine this catalog tracks; a dangling engine id would fail validation. Do not read a tok/s out of the kernel microseconds.