Почему production LLM-инференс деградирует: KV-cache, OOM и хвост p99

Демо и production — это разные миры. Поставьте языковую модель, прогоните пару запросов — всё быстро, TTFT радует. Но через неделю под реальной нагрузкой начинаются сюрпризы: p99-латентность растёт, память утекает, а запрос, который вчера проходил без проблем, сегодня выдаёт OOM. Инженеры VK Cloud описали этот механизм деградации в техническом разборе.

Суть события

KV-cache — ключевой механизм оптимизации: при обработке новых токенов модель переиспользует вычисления для уже виденных частей текста. Это ускоряет генерацию, но с ростом длины сессий cache раздувается. Если система не следит за его размером, происходит утечка памяти и потолок достигается быстрее, чем ожидалось. Демо с парой запросов этого не показывает — проблема накапливается.

P99 — не просто медленный ответ. Разрыв между p50 и p99 в языковом инференсе структурный. В реальных системах p50 может быть 800 мс, а p99 — 28 секунд. Разница в 35 раз. Причина — в природе генерации: длина ответа варьируется в 2–4 раза, а стоимость короткого и длинного запроса отличается на порядки. Смешайте это с общей очередью и общей памятью — и хвост начинает жить своей жизнью.

Ускоренный рост p99 inter-token latency сигнализирует о деградации хвоста и наличии тяжёлых запросов. Увеличение глубины очереди и счётчика preemption говорит о перегрузке планировщика. Preemption означает, что короткие срочные запросы вытесняют длинные из очереди, создавая каскад задержек.

Детали

Paged Attention и Continuous Batching повысили эффективность инференса, но не устранили деградацию полностью. Проблема сместилась из резких отказов по памяти в постепенное ухудшение характеристик. Рост длины хвоста означает накопление длинных генераций, которые приводят к head-of-line blocking — короткие запросы ждут в очереди, пока дообслуживаются длинные. Это как если бы в супермаркете кассир обслуживал одного покупателя с тележкой на 200 позиций, а остальные стояли и ждали.

В итоге система работает нормально для медианы запросов, но медленные клиенты получают 28-секундный ответ на вопрос, на который хотели получить ответ за полсекунды. И никто не замечает проблему, пока кто-то не пожалуется. На практике точечные оптимизации работы с памятью и корректный мониторинг хвостовых метрик оказываются более устойчивыми мерами, чем простое наращивание ресурсов. Увеличение GPU не решает проблему утечки cache — нужно правильно настроить eviction policy и следить за ростом.

Контекст

Для B2B-клиентов это означает: при выборе инференс-провайдера важна не только цена демо-теста, но и прозрачная статистика по хвостовой латентности на реальной нагрузке. Инвесторы обращают внимание на компании с публичной p99-статистикой — это становится конкурентным преимуществом при привлечении B2B-контрактов. Рынок оптимизации инференс-инфраструктуры растёт вместе со спросом на AI-сервисы.

Компании, которые смогут предложить прозрачный мониторинг и оптимизацию tail latency, получат преимущество на корпоративном рынке. Для стартапов в области AI Infrastructure это окно возможностей — рынок ещё не насыщен решениями, которые действительно мониторят p99 в production.

О практических способах оптимизации работы с языковыми моделями читайте в материале про расширение контекстного окна LLM.

Что дальше

Главный вывод: компании, которые собирают только p50 и игнорируют p99, рискуют не замечать деградацию до момента, пока пользователь не получит 28-секундный ответ на простой вопрос. Мониторинг хвостовой латентности должен стать стандартной практикой для всех, кто разворачивает LLM в production.

О том, как устроены языковые модели изнутри, читайте в материале про LLM.