KV‑кеш в трансформерах растёт квадратично и ограничивает инференс
Кеш ключ‑значений (KV) ускоряет генерацию токенов, но его размер растёт O(n²), делая пропускную способность памяти главным узким местом.
Авторегрессионные трансформеры стали практичными для инференса благодаря KV‑кешу – механизму, который сохраняет пары ключ‑значение для уже обработанных токенов. Без кеша каждый новый токен требовал бы пересчёта всех попарных произведений между векторами запросов (Q) и ключей (K), что делало генерацию невозможной в реальном времени.
KV‑кеш меняет баланс: вместо дополнительных вычислений мы тратим память. При последовательной генерации длина кеша растёт линейно, а объём хранимых пар – квадратично (O(n²)), где n – длина контекста. Это приводит к экспоненциальному росту потребления видеопамяти и, как следствие, к узкому месту – пропускной способности памяти. На современных GPU и ускорителях именно скорость чтения/записи в память ограничивает время генерации очередного токена.
Практически это проявляется в том, что при длине контекста более 4‑8 К токенов скорость инференса резко падает, даже если вычислительные ядра работают на полную мощность. Авторы статьи на Habr AI приводят измерения: при 2 К токенов среднее время генерации – 12 мс, а при 8 К – уже 45 мс. При этом нагрузка на GPU‑память достигает 90 % её пропускной способности.
Решения, обсуждаемые в статье, включают: (1) ограничение длины контекста, (2) использование «sliding‑window» кеша с удалением старых пар, (3) оптимизацию формата хранения (FP16/INT8) и (4) разработку новых архитектур, где KV‑кеш хранится в более быстрых уровнях памяти (HBM2e, HBM3). Пока что индустрия пока не имеет единого стандарта, но понимание квадратичного роста кеша уже заставляет разработчиков пересматривать стратегии масштабирования моделей.
Для разработчиков это значит, что просто увеличить контекст‑длину уже не вариант – нужно планировать кеш‑стратегию и учитывать пропускную способность памяти. Студенты курсов по LLM должны изучать техники sliding‑window и низкоуровневую оптимизацию памяти, иначе их проекты будут «залипать» на длинных запросах.


