KV-Cache Offloading & Compression(Розвантаження та компресія KV-кешу)

1. Огляд концепції та системна проблема

З появою моделей із вікнами контексту на 1–2 мільйони токенів (Gemini 2.0, Claude 3.5/3.7) інженери зіткнулися з новою інфраструктурною кризою:

• Ваги моделі 70B займають статичні 38 ГБ VRAM.
• Але якщо 4 користувачі відкривають сесії з довгим кодовим контекстом по 200 000 токенів, розмір їхнього сумарного KV-кешу перевищує 60 Гігабайт!
• Коли один користувач робить паузу на 5 хвилин, щоб подумати, його гігабайтний кеш продовжує марно блокувати VRAM, не даючи іншим користувачам надіслати запит.

KV-Cache Offloading & Compression впроваджує динамічне дворівневе або трирівневе керування пам'яттю інференсу: гарячий кеш залишається в VRAM, теплий — у RAM сервера, а холодний — скидається на NVMe накопичувач.

2. Архітектурна таксономія та ментальна модель

┌─────────────────────────────────────────────────────────────┐
│                 KV-CACHE HIERARCHY & TIERS                  │
├─────────────────────────────────────────────────────────────┤
│ TIER 1: HOT VRAM (HBM3 on GPU)                              │
│ • Latency: < 100 ns | Bandwidth: 2–3 TB/s                   │
│ • Зберігає активні токени генерації поточного такту         │
├─────────────────────────────────────────────────────────────┤
│                          ▲                                  │
│                 Offload  │  Prefetch                        │
│                          ▼                                  │
├─────────────────────────────────────────────────────────────┤
│ TIER 2: WARM SYSTEM RAM (DDR5 on Host Server)               │
│ • Latency: ~100 µs  | Bandwidth: 100–300 GB/s               │
│ • Зберігає сесії користувачів, які чекають у черзі          │
├─────────────────────────────────────────────────────────────┤
│                          ▲                                  │
│                 Swap     │  Restore                         │
│                          ▼                                  │
├─────────────────────────────────────────────────────────────┤
│ TIER 3: COLD NVMe STORAGE (PCIe 5.0 SSD)                    │
│ • Latency: ~10 ms   | Bandwidth: 10–14 GB/s                 │
│ • Довготривале збереження гігантських сесій агентів         │
└─────────────────────────────────────────────────────────────┘

3. Практичні інженерні сценарії в продакшені

01. Збереження стану нічної сесії агента

Агент завершив довгу таску з аналізу 150 файлів. Його стан контексту (15 ГБ KV-кешу) скидається на швидкий NVMe диск через Litestream/vLLM offload. Коли інженер вранці ставить уточнююче запитання, кеш завантажується за 1 секунду без повторного платного префілу 150 файлів.

02. Впровадження FP8 KV-кешування у vLLM

Увімкнення апаратного стиснення кешу одним прапорцем:

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.90

Це дозволяє подвоїти кількість одночасних сесій без виділення додаткових відеокарт.

4. Підводні камені, типові помилки та безпека

• PCIe Bottleneck (Вузьке горло шини материнської плати): Якщо сервер має повільні лінії PCIe (наприклад, PCIe 3.0 або лінії x4 замість x16), час вивантаження та завантаження кешу може перевищити час повторної генерації.
• Шум квантування при наддовгому контексті: При стисненні кешу до 4 біт (INT4) у контекстах понад 100k токенів накопичується похибка, що призводить до втрати здатності моделі до точного цитування.

5. Стратегічний висновок для інженера 2026 року

Розвантаження та компресія KV-кешу перетворили гігантські контекстні вікна з дорогої екзотики на доступний інженерний інструмент. Розуміння ієрархії пам'яті дозволяє проектувати системи з мільйонним контекстом на помірних серверах.