Инференс LLM в продакшене: 4 точки отказа и скрипты для их диагностики

Материал VK Cloud фиксирует разрыв между «поставил модель и прогнал пару запросов» и «сервис неделю живёт под реальной нагрузкой». Погоржельский описывает четыре точки отказа: фрагментацию KV-кэша (промежуточной памяти, где модель хранит контекст разговора), OOM на длинных контекстах, блокировку очереди внутри батча и расхождение метрик p50 и p99 (время отклика для «средних» и «самых медленных» запросов). Скрипты для воспроизведения собраны в отдельном репозитории, числа сняты со стенда VK Cloud.

Что понадобится

• GPU-сервер с картой A100 40 Гб или аналогичной (можно арендовать в VK Cloud или другом облаке)
• Установленный vLLM или TensorRT-LLM
• Модель для тестирования (в примерах используется Llama 2 13B)
• Python 3.10+ с библиотеками csv, time
• Репозиторий-харнес со скриптами из статьи VK Cloud
• Около 2 часов на воспроизведение основных сценариев

Память важнее вычислений: почему инференс LLM деградирует?

Продакшен-инференс упирается в память GPU сильнее, чем в вычислительные ядра. Причина в двух этапах работы модели.

Префилл (обработка промпта) нагружает вычислительные ядра. Декодирование (когда модель выдаёт токены по одному) постоянно читает и пишет память, и упирается именно в её пропускную способность.

По мере роста контекста основной поток обращений к памяти смещается с весов модели на KV-кэш. По данным интеграторов, которые приводит Погоржельский, KV-кэш в продакшене часто начинает превышать по объёму сами веса модели.

Конкретные цифры из статьи VK Cloud. Модель на 13 млрд параметров на A100 40 Гб занимает примерно 26 Гб под веса. Остаётся около 14 Гб на KV-кэш. При расходе порядка 1 Мб на токен (токен, минимальная единица текста для модели, примерно часть слова) это примерно 14 тысяч токенов на всю карту:

• При длине последовательности 512 токенов в батч помещается около 28 запросов
• При длине 2048 токенов помещается только 7 запросов

Для моделей на 70 млрд параметров масштаб проблемы ещё больше. У старых архитектур с multi-head attention KV-кэш для контекста 8K доходит до примерно 20 Гб на запрос, по данным introl.com. Но у моделей с grouped-query attention (Llama 3) 8 KV-голов вместо 64, и расход памяти падает примерно в 8 раз: около 2,6 Гб на запрос при 8K и около 10 Гб при 32K, по данным Symphony.

Пошаговая инструкция: как найти и устранить деградацию

1. Проверьте фрагментацию KV-кэша

Классическая реализация резервирует непрерывный кусок памяти под максимальную длину последовательности заранее. Запрос генерирует 100 токенов, а max_len выставлен в 2048, значит, около 1948 слотов простаивают. По замерам авторов vLLM на реальных нагрузках, существовавшие на тот момент системы теряли 60-80% памяти KV-кэша на фрагментацию и избыточное резервирование, по данным blog.vllm.ai.

2. Включите PagedAttention

PagedAttention выделяет память не одним куском, а блоками по требованию, по аналогии с виртуальной памятью в операционной системе. Логические позиции токенов сопоставляются физическим блокам через block table (таблицу соответствий). По данным SOSP 2023, потери на фрагментацию падают до менее 4%, а пропускная способность растёт в 2-4 раза при том же уровне задержки по сравнению с FasterTransformer и Orca. Против HuggingFace Transformers прирост доходит до 24-кратного, по данным blog.vllm.ai.

3. Отслеживайте занятость пула блоков во времени

PagedAttention смещает проблему, но не устраняет полностью. При постоянных аллокациях, вытеснениях и повторном использовании блоков фактическая доступная ёмкость под новые запросы начинает колебаться. В TensorRT-LLM KV-кэш организован иерархически: блок как единица аллокации, пул (primary на GPU, secondary с выгрузкой на CPU), менеджер состояний блоков.

Скрипт из репозитория-харнеса снимает занятость KV-кэша во времени:

# kv_usage_probe.py
from vllm import LLM
import time, csv

llm = LLM(
    model="meta-llama/Llama-2-13b-hf",
    gpu_memory_utilization=0.9
)

with open("kv_usage.csv", "w", newline="") as f:
    w = csv.writer(f)
    w.writerow(["ts", "gpu_cache_usage", "free_blocks"])
    for _ in range(3600):  # час наблюдения под нагрузкой
        m = llm.llm_engine.stat_logger.stats
        # далее запись gpu_cache_usage_sys, free_blocks

4. Настройте алерты на расхождение p50 и p99

Если p99 latency (время отклика для 1% самых медленных запросов) начинает расходиться с p50 (медианным временем), это сигнал приближающейся деградации. Погоржельский указывает: инференс LLM редко выходит из строя сразу; как правило, его работа постепенно ухудшается, оставаясь незаметной до достижения критического состояния.

5. Запустите скрипты на своём железе

Числа из статьи сняты со стенда VK Cloud. Чтобы получить актуальные пороги для ваших алертов, запустите скрипты из репозитория-харнеса на своей конфигурации. Универсальных чисел здесь нет: разница между архитектурами моделей может составлять порядок.

Что делать с этим прямо сейчас, по ролям

Инженеру, который разворачивает LLM в продакшене. Возьмите скрипт kv_usage_probe.py из харнеса VK Cloud и запустите на своём стенде под реальной или имитированной нагрузкой на час. Посмотрите, как ведёт себя занятость KV-кэша. Настройте алерт на расхождение p50 и p99.

Автору Дзена или маркетологу, который пользуется ИИ-сервисами. Если ваш чат-бот или генератор текста начинает «тупить» к вечеру или после нескольких дней работы, это может быть не «модель устала», а именно деградация инференса. Понимание механизма помогает грамотно сформулировать запрос к поставщику.

Предпринимателю в РФ. VK Cloud предоставляет GPU-инфраструктуру на территории России. Если вы строите LLM-сервис и выбираете между облачными провайдерами, скрипты из статьи позволяют объективно сравнить, как инференс LLM ведёт себя на разных платформах под нагрузкой, до того как вы заплатите за месяц аренды.

Материал Погоржельского фиксирует неочевидную вещь: инференс LLM ломается не громко, а тихо, по миллисекунде за час, по блоку памяти за запрос. Кто не мониторит, тот узнаёт последним, обычно от пользователя, который написал в поддержку «ваш бот опять завис».