Why 8× smaller can load slower: mixed-precision KV caches inside the kernel8× 작은데 왜 더 느리게 읽히는가: kernel 안의 mixed-precision KV cache

§1The itch: 8× smaller should mean 8× faster — it often doesn’t문제의식: 8× 작아지면 8× 빨라져야 하는데 — 자주 그렇지 않다

When a language model generates text, most of what the GPU does at each step is not arithmetic — it is re-reading a growing record of everything generated so far (the KV cache). That re-reading is the speed limit, so the obvious fix is to make the record smaller: store each number in 4 or 2 bits instead of 16. The storage claim is a single bar chart, and it looks unbeatable: 언어 모델이 텍스트를 생성할 때 GPU가 매 step 하는 일의 대부분은 연산이 아니다 — 지금까지 생성한 모든 것의 기록(KV cache)을 다시 읽는 것이다. 그 재독이 속도의 상한이므로, 자연스러운 해법은 기록을 줄이는 것이다: 숫자 하나를 16 bit 대신 4 bit나 2 bit로 저장한다. 저장의 주장은 막대 그래프 하나이고, 이길 수 없어 보인다:

And yet the published record contains this result: on the same A100 GPU, a straightforwardly-written 4-bit KV kernel ran 1.1–1.2× slower than the 8-bit one it was supposed to beat (QServe) — half the bytes, more time. Meanwhile another paper’s 4-bit KV kernels beat full-precision fp16 outright, 1.2–1.7× (KVQuant). Same silicon, same idea, opposite outcomes. Something between “fewer bytes” and “less time” is not free — and this page is about naming that something precisely. 그런데 공개된 기록에는 이런 결과가 있다: 같은 A100에서, 평범하게 작성한 4-bit KV kernel이 이겨야 할 8-bit보다 1.1–1.2× 느렸다 (QServe) — byte는 절반인데 시간은 더 걸렸다. 한편 다른 논문의 4-bit KV kernel은 full-precision fp16을 1.2–1.7×로 완파했다 (KVQuant). 같은 실리콘, 같은 아이디어, 정반대의 결과. “byte가 준다”와 “시간이 준다” 사이의 무언가가 공짜가 아니라는 뜻이고, 이 페이지는 그 무언가를 정확히 이름 붙이는 페이지다.

What does the GPU actually have to do to use a byte it just saved?GPU는 방금 아낀 byte를 쓰기 위해 실제로 무엇을 해야 하는가?

§2Foundations: the four facts everything else stands on기초: 이후의 전부가 딛고 서는 네 가지 사실

1 · Decode is a re-read, and it is memory-bound. Generating one token multiplies one query against every stored K and V row — a matrix-vector product where each loaded element is used in roughly one multiply-accumulate, no matter the batch size (QServe calls this out explicitly). One operation per element loaded means the math units finish long before the memory system does: the kernel’s time is bytes ÷ bandwidth. This is exactly why shrinking bytes should work — and it is the regime all of §3–§7 lives in. 1 · decode는 재독이고, memory-bound다. token 하나를 생성하려면 query 하나를 저장된 모든 K·V row와 곱한다 — batch 크기와 무관하게 load된 element 하나가 대략 multiply-accumulate 한 번에 쓰이는 matrix-vector 곱이다 (QServe가 명시적으로 짚는 사실). element당 연산 1개라는 것은 연산 유닛이 memory system보다 훨씬 먼저 끝난다는 뜻이다: kernel의 시간은 bytes ÷ bandwidth다. byte를 줄이는 것이 통해야 하는 이유가 정확히 이것이고, §3–§7 전체가 이 regime 안의 이야기다.

2 · The machine executes 32 threads in lockstep. A GPU streaming multiprocessor (SM) issues instructions to warps — groups of 32 threads that all run the same instruction at once. Bytes reach those threads through a hierarchy: HBM (the big, slow-per-request DRAM) → L2 cache → shared memory (a small scratchpad per SM) → registers, where instructions actually operate. Two kinds of execution units sit at the end: tensor cores, which do dense matrix math at enormous rates, and ordinary CUDA cores, which do everything else — shifts, masks, type conversions — about 50× slower per op (QServe’s A100 comparison). 2 · 하드웨어는 thread 32개를 발맞춰 실행한다. GPU의 streaming multiprocessor(SM)는 warp — 같은 instruction을 동시에 실행하는 thread 32개 묶음 — 단위로 instruction을 발행한다. byte는 계층을 지나 thread에 도달한다: HBM(크지만 요청당 느린 DRAM) → L2 cache → shared memory(SM마다 있는 작은 scratchpad) → register, 여기서 instruction이 실제로 값을 만진다. 끝에는 두 종류의 연산 유닛이 있다: dense 행렬 연산을 엄청난 속도로 처리하는 tensor core, 그리고 나머지 전부 — shift, mask, type 변환 — 를 맡는 평범한 CUDA core. 후자는 op당 약 50× 느리다 (QServe의 A100 비교).

3 · A quantized cache stores codes, not numbers. Quantization maps each group of values (say 128 of them) onto small integer codes plus two recovery constants — a scale s and zero-point z. To use a code q the kernel must compute x̂ = (q − z) · s. So every low-bit read implies extra work that fp16 never did: extracting packed codes from a 32-bit word (unpack) and applying the recovery arithmetic (dequant) — all of it on the slow CUDA cores, because tensor cores only consume cleanly-typed, cleanly-laid-out operands. 3 · quantized cache는 숫자가 아니라 code를 저장한다. quantization은 값들의 그룹(예: 128개)을 작은 정수 code와 복원 상수 두 개 — scale s, zero-point z — 로 사상한다. code q를 쓰려면 kernel이 x̂ = (q − z) · s를 계산해야 한다. 즉 모든 low-bit 읽기에는 fp16이 하지 않던 추가 작업이 붙는다: 32-bit word에서 packed code를 꺼내는 unpack, 복원 산술을 적용하는 dequant — 전부 느린 CUDA core 몫이다. tensor core는 type과 layout이 깔끔한 피연산자만 먹기 때문이다.

4 · So there is a budget. While the memory system delivers bytes, the CUDA cores can execute only so many instructions “for free” under that shadow. Divide CUDA-core throughput by DRAM bandwidth and you get a number: on an A100-80GB, ≈ 9.8 ALU ops per byte moved (QServe; ≈ 12.5 on the 40 GB part — estimate). Stay under it and dequant hides entirely under DRAM time; cross it and the kernel stops waiting on memory and starts waiting on its own unpack instructions. 4 · 그래서 예산이 있다. memory system이 byte를 나르는 동안 CUDA core가 그 그늘 아래에서 “공짜로” 실행할 수 있는 instruction 수에는 한계가 있다. CUDA-core throughput을 DRAM bandwidth로 나누면 숫자가 나온다: A100-80GB에서 이동 byte당 ≈ 9.8 ALU ops (QServe; 40 GB 모델은 ≈ 12.5 — 추정). 이 밑에 있으면 dequant는 DRAM 시간 밑에 완전히 숨고, 넘는 순간 kernel은 memory가 아니라 자기 unpack instruction을 기다리기 시작한다.

Where exactly, along a byte’s journey, does that extra work get inserted?그 추가 작업은 byte의 여정 어디에 정확히 끼어드는가?

§3The promise vs the path약속 vs 경로

We now have the budget (§2). What §1’s bar chart hid is a pipeline: every saved byte still has to travel the full memory hierarchy — and then through two stages fp16 never needed. 이제 예산(§2)이 손에 있다. §1의 막대가 숨긴 것은 파이프라인이다: 아낀 byte도 여전히 memory hierarchy 전체를 지나야 하고 — 그 다음 fp16에는 없던 두 stage를 지나야 한다.

The performance story, stage by stage: every byte traverses HBM → L2 → shared memory → registers, and then an unpack + dequant instruction sequence, before any math happens. Hover each stage. 성능의 이야기를 stage별로: 모든 byte는 HBM → L2 → shared memory → register를 지나고 그 다음 unpack + dequant instruction 시퀀스를 지나야 비로소 연산이 시작된다. 각 stage에 hover해 보라.

How many instructions do those two stages actually cost? Follow one warp and count.그 두 stage는 실제로 instruction 몇 개짜리인가? warp 하나를 따라가며 세어 보자.

§4Inside one warp: load → unpack → dequant → mathwarp 하나의 내부: load → unpack → dequant → 연산

§3 named the added stages; it did not price them. This section walks one warp through one transaction of packed KV, instruction by instruction, and hands you the bill in step 6. §3은 추가된 stage의 이름만 붙였지 가격은 매기지 않았다. 이 섹션은 warp 하나가 packed KV transaction 하나를 끌고 가는 과정을 instruction 단위로 따라가고, step 6에서 청구서를 건넨다.

One warp, one transaction of packed uniform low-bit KV, followed to the FMA. The instruction counts are estimates anchored to QServe’s published 5 ops/element (naive) and ~2 ops/element (optimized); the verdict meter in step 6 is the punchline. warp 하나가 packed uniform low-bit KV transaction 하나를 FMA까지 끌고 가는 과정. instruction 수는 QServe가 제시한 element당 5 ops (naive)와 ~2 ops (최적화)에 앵커한 추정치이고, step 6의 verdict meter가 punchline이다.

Step 4 quietly fetched a scale and zero-point from somewhere. How many bytes does that second stream really add?step 4가 어디선가 scale과 zero-point를 조용히 가져왔다. 그 두 번째 stream은 실제로 몇 byte를 더하는가?

§5The second stream: what “2-bit” actually stores두 번째 stream: “2-bit”가 실제로 저장하는 것

The walkthrough priced the instructions. But §2’s fact 3 said a quantized cache stores codes plus recovery constants — and those constants are traffic too, uncounted so far. walkthrough는 instruction의 가격을 매겼다. 그런데 §2의 사실 3은 quantized cache가 code에 더해 복원 상수를 저장한다고 했다 — 그 상수들도 트래픽이고, 아직 세지 않았다.

Every group carries an FP16 scale (and usually a zero-point) — a second memory stream with its own bytes, its own loads, its own addresses. Head dim 128, 4 B of FP16 scale+zero per group; hover each bar for the arithmetic. 모든 그룹은 FP16 scale(과 대개 zero-point)을 달고 다닌다 — 자기 byte, 자기 load, 자기 주소를 가진 두 번째 memory stream이다. head dim 128, 그룹당 FP16 scale+zero 4 B; 각 막대에 hover하면 산술이 보인다.

Uniform low-bit adds a second stream and survives. What if the width itself varies token by token?uniform low-bit는 두 번째 stream을 달고도 살아남는다. 그런데 width 자체가 token마다 달라지면?

§6Deep water: where mixed widths break the machine’s assumptions깊은 물: 혼합 width가 하드웨어의 가정을 깨는 곳

This is the hardest section of the page — take it slowly. Everything so far assumed one width for every token; §2’s machine facts (lockstep warps, whole 32-byte sectors, affine addresses) were all quietly load-bearing. Mixed precision removes the uniformity they stand on, and four things break at once. 여기가 이 페이지에서 가장 어려운 섹션이다 — 천천히 가자. 지금까지는 모든 token이 같은 width라고 가정했고, §2의 하드웨어 사실들(lockstep warp, 통째로 소비되는 32-byte sector, affine 주소)이 전부 조용히 하중을 받치고 있었다. mixed precision은 그들이 딛고 선 균일성을 치우고, 네 가지가 동시에 부러진다.

Take a generic example alphabet {0, 2, 4, 8, 16} bits — some tokens evicted, some low-bit, some full precision (how they’re assigned doesn’t matter here). Three GPU assumptions break at once: affine addressing, one-path-per-warp, and aligned vector loads. DiffKV states the systems version plainly: heterogeneous precision “introduces irregular memory usage patterns … posing significant scalability challenges.” 일반적인 예시 alphabet {0, 2, 4, 8, 16} bits를 놓자 — 어떤 token은 evict, 어떤 것은 low-bit, 어떤 것은 full precision (여기서 부여 방식은 중요하지 않다). GPU의 세 가정이 동시에 깨진다: affine 주소, warp당 단일 경로, aligned vector load. DiffKV는 시스템 관점을 그대로 적는다: 이종 precision은 “irregular memory usage pattern을 도입해 … 심각한 scalability 문제를 일으킨다.”

Every one of these breakages appears in published systems — so how do shipped kernels put the uniformity back?이 붕괴들은 전부 공개된 시스템에 등장한다 — 그렇다면 실제로 배포된 kernel들은 균일성을 어떻게 되찾는가?

§7The published fix patterns공개된 fix 패턴들

§6 ended in wreckage on purpose. The literature’s answer is not one trick but a repertoire — and every entry works the same way: restore, somewhere, the uniformity the hardware was promised. §6은 일부러 잔해로 끝냈다. 문헌의 답은 한 가지 트릭이 아니라 레퍼토리다 — 그리고 모든 항목이 같은 방식으로 작동한다: 하드웨어가 약속받았던 균일성을 어딘가에서 복원하는 것.

Each failure above has a published answer. Flip each card between the broken layout and the engineered one — every pattern is cited to the paper that documented it. 위의 각 failure에는 공개된 답이 있다. 카드를 깨진 layout과 엔지니어링된 layout 사이로 뒤집어 보라 — 모든 패턴은 그것을 기록한 논문을 인용한다.

With the full repertoire applied, does low-bit KV always win — or only in a regime?레퍼토리를 전부 적용하면 low-bit KV는 항상 이기는가 — 아니면 특정 regime에서만인가?

§8When does it actually win?그래서 언제 실제로 이기는가?

The fixes buy back the instructions; they do not repeal §2’s roofline. Whether byte savings convert to time still depends on which side of the budget the kernel sits — and on whether the kernel is memory-bound at all. fix들은 instruction을 되사 오지만 §2의 roofline을 폐지하진 못한다. byte 절약이 시간으로 환전되는지는 여전히 kernel이 예산의 어느 쪽에 앉아 있는지 — 그리고 애초에 memory-bound인지 — 에 달려 있다.

Two dials decide the regime: how many instructions each byte costs (bit-width × kernel quality), and whether the kernel is memory-bound at all (batch). Drag both. 두 개의 다이얼이 regime을 정한다: byte 하나가 몇 개의 instruction을 요구하는가 (bit-width × kernel 품질), 그리고 kernel이 애초에 memory-bound인가 (batch). 둘 다 움직여 보라.

The honest summary, regime by regime: at batch 1 with fused kernels the naive byte-counting story largely holds — KVQuant’s low-bit KV kernels beat fp16 outright. Naive per-element dequant loses even there (QServe: 4-bit KV 1.1–1.2× slower than 8-bit on A100). And as batch grows the baseline roofline rises to meet you: MARLIN’s fully-engineered kernel decays from ~3.9× to ~1.5× by batch 128 (end-to-end in vLLM: 2.8× at batch 16 → ~1.2× at 128). Every added op per byte moves that crossover earlier. regime별 정직한 요약: batch 1 + fused kernel에서는 byte 계산 그대로의 이야기가 대체로 성립한다 — KVQuant의 low-bit KV kernel은 fp16을 완전히 이긴다. naive element별 dequant는 거기서도 진다 (QServe: A100에서 4-bit KV가 8-bit보다 1.1–1.2× 느림). 그리고 batch가 커지면 baseline의 roofline이 올라와 마중 나온다: 완전히 엔지니어링된 MARLIN kernel도 batch 128에서는 ~3.9× → ~1.5×로 감쇠한다 (vLLM end-to-end: batch 16에서 2.8× → 128에서 ~1.2×). byte당 op가 하나 늘 때마다 그 crossover는 앞당겨진다.

If the mechanics are this well mapped, what is the field still fighting over?메커니즘이 이렇게까지 정리돼 있다면, 이 분야는 아직 무엇을 두고 싸우고 있는가?

§9Where this goes다음은 어디로 가는가

The mechanics above are settled science by systems standards; the open questions are about what to do with them. Three directions are visibly active in the literature. 위의 메커니즘은 시스템 기준으로는 정리된 과학이다; 열린 질문은 그것으로 무엇을 하느냐다. 문헌에서 눈에 띄게 활발한 방향이 셋 있다.

Below 4 bits with better codes. Uniform integer grids waste precision on well-behaved distributions, so newer quantizers spend math to earn bits — non-uniform LUTs (KVQuant), rotations that spread outliers before coding (TurboQuant, LiftQuant). Every new code re-opens this page’s question: what does its decode cost per byte, and on which pipe? Choosing the widths. This page took the assignment as given; deciding it — which tokens, heads, or layers deserve bits — is its own literature, from eviction scores (H2O) to head-level retrieval-vs-streaming splits (DuoAttention), and each policy’s output lands on §6’s systems bill. The budget itself moves. Every ops-per-byte number here is A100-specific; new accelerator generations shift the CUDA-core-to-bandwidth ratio and add native low-bit datapaths, so the crossover lines in §8 must be re-derived per part — the analysis pattern transfers, the constants do not. 더 좋은 code로 4 bit 아래로. uniform 정수 grid는 얌전한 분포에서 정밀도를 낭비하므로, 최신 quantizer들은 연산을 써서 bit를 번다 — non-uniform LUT (KVQuant), coding 전에 outlier를 퍼뜨리는 rotation (TurboQuant, LiftQuant). 새 code가 나올 때마다 이 페이지의 질문이 다시 열린다: 그 decode는 byte당 얼마이고, 어느 pipe에서 도는가? width를 정하는 문제. 이 페이지는 부여를 주어진 것으로 놓았지만, 그것을 정하는 일 — 어떤 token·head·layer가 bit를 받을 자격이 있는가 — 은 그 자체로 하나의 문헌이다. eviction score(H2O)부터 head 단위 retrieval-vs-streaming 분할(DuoAttention)까지 있고, 모든 정책의 출력은 §6의 시스템 청구서 위에 떨어진다. 예산 자체가 움직인다. 여기의 모든 ops-per-byte 숫자는 A100 전용이다; 새 가속기 세대는 CUDA-core 대 bandwidth 비율을 바꾸고 native low-bit datapath를 더하므로, §8의 crossover 선은 part마다 다시 유도해야 한다 — 분석 패턴은 이식되지만 상수는 아니다.

Going deeper더 깊이

Primary sources1차 자료

• KV-cache quantization, byte by byte — how the codes get made in the first placeKV-cache quantization, byte 단위로 — 애초에 code가 어떻게 만들어지는가
• Where the bytes live: the GPU memory hierarchy this page walks throughbyte는 어디에 사는가: 이 페이지가 지나가는 GPU memory hierarchy
• Paper review: KIVI논문 리뷰: KIVI
• Paper review: KVQuant논문 리뷰: KVQuant

Back to all study notes모든 study 노트로 돌아가기