Bakit Bottleneck ang KV Cache sa Serving
Kapag pinatakbo ang isang dense model na 70B class sa sequence length na 128K na may 256 parallel, ang KV cache lang ay nangangailangan ng HBM na 1TB class. Sa MoE (tulad ng Mixtral-8x22B o DeepSeek-V3), mababa ang computation dahil sparse ang kilos sa expert selection, pero ang KV cache ay fully materialized kaya ang kapasidad na presyon ay katumbas o mas mataas pa kaysa dense. Ang problemang ginugugol ng serving team ngayon noong 2026 ay "paano mag-compress ng KV para mapakain ang GPU compute," at malinaw na hindi sapat ang HBM lang. Itinatahi ng artikulong ito ang FP8 quantization, paging, CPU/NVMe offload, RadixAttention, at multi-tenant isolation sa isang design theory.
Quality Trade-offs ng FP8 KV Cache
Ang FP8 KV (karaniwan ay E5M2 o E4M3) ay nagpapababa ng HBM usage ng kalahati kumpara sa FP16. Sa 2025, nag-aalala tungkol sa degradasyon ng output quality, pero sa 2026, naging consensus sa maraming papel at internal bench na "kung pipiliin ang tamang quantization method, ang quality loss ay 0.5% o mas mababa."
Ang rekomendasyon ay ang sumusunod:
- E5M2 (5 exp, 2 mantissa): Mas malawak ang dynamic range. Malakas sa long context at multilingual workload. Ang precision loss ay bahagyang mas malaki kaysa E4M3, pero mas kaunti ang hallucination-type failures.
- E4M3 (4 exp, 3 mantissa): Mas maraming mantissa, mas mataas ang precision. Angkop para sa code generation at math reasoning. Ang mga activation na may outliers ay naci-clip.
- per-channel scale + per-token shift: Bilang activation-aware quantization, sinasalo ang mga outlier. Naimplementa na sa parehong SGLang 0.4 series at vLLM 0.7 series.
Sa quality bench ng KGA (MT-Bench, HumanEval, JMMLU, at 4 internal Japanese RAG benchmarks), ang pagbabago ng Llama-3.3-70B mula sa FP16 KV tungong FP8 E5M2 KV ay may degradasyon ng aggregate score na -0.3% lamang, at -0.6% para sa Qwen3-72B. Sa kabaligtaran, napalitan ang HBM usage ng kalahati, at mapapataas ang bilang ng concurrent session sa parehong GPU ng 1.8x. Para sa production deployment, ang pinakamainam na operasyon ay ang paggamit ng E5M2 bilang initial setting at pagsasaalang-alang ng E4M3 para sa mga code/math-specialized endpoint.
Memory Profile ng MoE
Madaling maling maunawaan ang MoE model dahil sa sparsity ng routing, pero ang KV cache ay fully materialized para sa lahat ng token. Sa DeepSeek-V3 series (671B total, 37B activated), habang ang expert parameters ay kumukupas ng karamihan ng HBM, sa long context operation ang KV ay lumalagpas at nagiging dominant.
May tatlong MoE-specific na KV design points. Una, ang mga model ng MLA (Multi-head Latent Attention) series ay may compressed representation ng KV mula sa training time, at ang KV capacity ay higit sa 70% na mas maliit kaysa sa dense model ng katumbas na parameters. Lubos nitong pinabababa ang serving cost ng DeepSeek-V3 at Qwen3-MoE series. Pangalawa, ang paghahalo ng expert placement per GPU (expert parallelism) at KV cache placement (tensor parallelism) ay nagdudulot ng pagkakaiba-iba ng load kung saan mauuna ang KV ng ilang GPU na mag-overflow. Mahalaga ang disenyo ng pagpapaghiwalay ng EP at TP at pagkakalat ng KV nang pantay sa lahat ng GPU. Pangatlo, dahil sa hot/cold patterns ng routing, may pagkiling sa mga expert na naa-activate, at kailangan ang pagdidisenyo ng prefetch sa pagpapalagay na madalas na ina-access ang KV ng mga partikular na expert.
Paging at CPU/NVMe Offload
Ang PagedAttention ay namamahala ng KV sa yunit ng pahina ng 16 token, at hindi kailangang mag-allocate ng contiguous HBM. Sa 2026, naging practical na ang configuration ng pagpapalawak ng "pages" na ito sa tatlong layer ng HBM, CPU memory, at NVMe.
CPU offload. I-retire ang KV ng idle session (naghihintay ang user, agent step na nag-iisip nang matagal) sa CPU memory. Ang PCIe transfer cost sa pag-resume ay nasa 40GB/s order, at kahit ang 128K sequence KV ng 70B model ay maaaring ibalik sa GPU sa loob ng ilang daan milliseconds. Gamitin ang isa sa vLLM swap, SGLang offload backend, o LMCache.
NVMe offload. I-drop ang mga session na mas mabababang dalas (idle ng ilang minuto hanggang ilang oras) sa NVMe. Ang Gen5 NVMe ay may effective throughput na 12GB/s, at ang 128K KV ay may resume cost na 2-3 segundo. Para sa resume pagkatapos ng matagal na idle, ang dalawang hakbang na resume ng "NVMe to CPU, CPU to GPU" ay asynchronously pinapaliko sa pipeline.
Tiering policy. Sa customer case ng KGA, ang heuristic na "KV na active sa nakalipas na 30 segundo = HBM, 30 segundo-10 minuto = CPU, 10 minuto pababa = NVMe" ay epektibo sa maraming sitwasyon. Gayunpaman, sa multi-tenant, kailangan ang bawat tenant na may sariling TTL.
Benchmark ng LMCache at SGLang RadixAttention
Benchmark na ginawa internally sa KGA sa Q1 2026. Ang workload ay RAG chat (system prompt 1.5K, retrieved context 8K, average user turn 200 tokens, average 6 multi-turns), model ay Qwen3-72B FP8, hardware ay H200 SXM 8 cards.
- vLLM prefix caching only: Aggregate throughput 2100 tok/s, TTFT p50 210ms, TTFT p99 720ms, prefill recomputation rate 38%.
- SGLang RadixAttention: Throughput 2650 tok/s, TTFT p50 140ms, TTFT p99 510ms, prefill recomputation rate 17%.
- vLLM + LMCache (local CPU+NVMe): Throughput 2450 tok/s, TTFT p50 160ms, TTFT p99 430ms, prefill recomputation rate 11%.
- vLLM + LMCache (distributed, shared NVMe): Throughput 2380 tok/s, TTFT p50 180ms, TTFT p99 480ms, prefill recomputation rate 6%. Sa distributed mode, hindi mapapantayan ang node-local HBM reuse, pero ang epekto ng pagbabahagi ng cache sa buong cluster ay nag-aapekto sa p99.
Ang konklusyon ay, para sa single node, SGLang RadixAttention; para sa multi-node shared cache, vLLM + LMCache ang dalawang nangungunang pagpipilian sa kasalukuyan. Ang TensorRT-LLM ay may katulad na functionality, pero ang dalawa sa itaas ay nangunguna pagdating sa flexibility ng configuration.
Isolation at Fairness sa Multi-Tenant
Kapag ginagawa ang multi-tenant serving sa SaaS, may apat na design constraint ang KV layer.
Leak risk. Kung nagbabahagi ng parehong system prompt, walang problema, pero ang posibilidad ng "cache timing side channel" kung saan ang KV na may tenant-specific data ay maaaring ma-reference ng ibang tenant ay hindi zero. Para sa high-security domains tulad ng finance, healthcare, at government, ang praktikal na solusyon ay ang paghihiwalay ng GPU process o GPU group bawat tenant at pisikal na paghihiwalay ng KV.
Fairness. Sa naive LRU, ang tenant na nagpapadala ng maraming request ay monopolyize ang KV, at ang TTFT ng ibang tenant ay nagsasama. Sa KGA, nagmumungkahi kami ng hybrid policy na "mag-set ng KV quota bawat tenant, at ang bahagi na lumagpas sa quota ay LRU, pero sa normal operation ay hanggang 50% lang ang isang tenant."
SLA-based service quality. Nagiging pangkaraniwan na ang tier kung saan garantisado ang HBM resident slot para sa premium tenant, at ang CPU/NVMe offload ay inuuna para sa basic tenant. Ang parehong vLLM at SGLang ay may pluggable scheduler at maaaring mag-implement ng custom policy.
Visibility. Kapag nag-dashboard ng per-tenant KV hit rate, KV eviction rate, at KV quota usage gamit ang prometheus exporter, maaaring mag-ugnayan ang billing at capacity plan. Sa standard stack ng KGA, nivi-visualize ito gamit ang Grafana.
Sample Configuration: vLLM + LMCache + FP8 KV
```python from vllm import LLM from lmcache.integration.vllm import LMCacheConnector
llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8_e5m2", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, kv_transfer_config={ "kv_connector": "LMCacheConnector", "kv_role": "kv_both", "kv_buffer_size": 5e9, }, ) ```
Sa LMCache side, 256GB ang inilaan para sa CPU tier at 2TB para sa NVMe tier, at logical namespace ay ginawa bawat tenant para pamahalaan ang quota.
Buod
Ang KV cache ng 2026 ay hindi na panahon ng "magtaglay nang tapat ng kaya lang ng HBM." Pahalbawin ang kapasidad gamit ang FP8 KV, bawasan nang istruktura gamit ang MLA-type model, alisin ang fragmentation gamit ang PagedAttention, gawing epektibo ang prefix sharing gamit ang LMCache o RadixAttention, iimbak ang matagalang KV sa CPU/NVMe tier, at protektahan ang kalidad ng serbisyo gamit ang multi-tenant isolation at fairness policy. Kapag sabay na gumagana ang anim na layer na ito, maaari lamang na sabay na matupad ang effective throughput na ilang libong tok/s per node at SLO na p99 TTFT 500ms. Ang sinumang nagkontrol sa KV ang nagkokontrol sa LLM serving ng 2026.