KV-Cache Offloading & Compression

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 на GPU)                              │
│ • Задержка: < 100 нс | Пропускная способность: 2–3 ТБ/с     │
│ • Хранит активные токены генерации текущего такта           │
├─────────────────────────────────────────────────────────────┤
│                          ▲                                  │
│                 Offload  │  Prefetch                        │
│                          ▼                                  │
├─────────────────────────────────────────────────────────────┤
│ TIER 2: WARM SYSTEM RAM (DDR5 на хост-сервере)             │
│ • Задержка: ~100 мкс  | Пропускная способность: 100–300 ГБ/с │
│ • Хранит сессии пользователей, ожидающих в очереди          │
├─────────────────────────────────────────────────────────────┤
│                          ▲                                  │
│                 Swap     │  Restore                         │
│                          ▼                                  │
├─────────────────────────────────────────────────────────────┤
│ TIER 3: COLD NVMe STORAGE (PCIe 5.0 SSD)                    │
│ • Задержка: ~10 мс   | Пропускная способность: 10–14 ГБ/с   │
│ • Долгосрочное хранение гигантских сессий агентов           │
└─────────────────────────────────────────────────────────────┘

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-кеша превратили гигантские контекстные окна из дорогой экзотики в доступный инженерный инструмент. Понимание иерархии памяти позволяет проектировать системы с миллионным контекстом на умеренных серверах.