LLM serving: KV-cache и батчинг

Зачем LLM serving выделяют в отдельную тему

С обычной моделью часто все выглядит просто: собрали batch, сделали forward pass, вернули ответ. С LLM так думать опасно. Запрос сначала надо целиком прочитать, потом ответ рождается по одному токену, а параллельно сервис держит очередь, стримит текст пользователю, освобождает память после отмененных запросов и следит, чтобы дорогая GPU не простаивала.

Эта страница опирается не на “примерно помню”, а на несколько слоев источников: курс Stanford CS336 для общей картины inference systems, tutorial Hugging Face Transformers: Continuous Batching для механики prefill/decode, paper PagedAttention/vLLM для памяти KV-cache, SGLang docs для runtime/routing/cache reuse, BentoML LLM metrics для метрик и production-кейсы NVIDIA/Perplexity and NAVER для привязки к реальности.

Один запрос: prefill и decode

LLM не печатает весь ответ за один проход. Сначала идет prefill: модель прогоняет prompt целиком и сохраняет промежуточную память attention. Потом начинается decode: модель берет уже накопленный контекст, предсказывает следующий токен, добавляет его в контекст и повторяет цикл. Поэтому длинный prompt и длинный ответ ломают систему по-разному.

KV-cache: ускорение, которое само становится проблемой

KV-cache хранит ключи и значения attention для уже обработанных токенов. Без него на каждом новом токене пришлось бы заново пересчитывать прошлый контекст. С ним decode становится сильно дешевле. Но цена понятная: чем больше активных запросов и чем длиннее контекст, тем больше памяти видеокарты уходит на cache.

Грубая интуиция такая: память cache растет вместе с числом слоев, числом активных токенов, размерностью attention and bytes per value. Это не формула для точного sizing без учета реализации, но хороший способ понять, почему long context serving внезапно становится задачей про HBM, fragmentation and memory bandwidth, а не только про FLOPs.

PagedAttention и prefix cache

Главная идея PagedAttention из vLLM: не хранить KV-cache как один большой непрерывный кусок на каждую sequence. Запросы разной длины приходят и заканчиваются в разное время, поэтому naive allocation быстро дает пустоты и fragmentation. PagedAttention режет cache на blocks/pages и управляет ими похожим образом на virtual memory: так проще переиспользовать HBM и держать больше активных запросов.

Prefix cache - соседняя, но не та же идея. Если у многих запросов одинаковое начало, например system prompt или общий RAG-template, его можно не считать заново. В vLLM это описано в Automatic Prefix Caching docs. В SGLang похожая линия развивается через RadixAttention and hierarchical cache: она особенно интересна, когда приложение делает цепочку связанных вызовов, а не один одиночный prompt.

Батчинг и scheduler

У классического static batch есть неприятный эффект: короткие запросы могут ждать длинные. В генерации это особенно больно, потому что один ответ может закончиться за 20 токенов, а другой будет стримиться минуту. Continuous batching решает это через scheduler: между decode steps он добавляет новые запросы, убирает завершенные и пытается держать GPU занятой.

Важно: scheduler не “бесплатно ускоряет все”. Если слишком агрессивно гнаться за throughput, можно ухудшить TTFT для новых пользователей или p99 для коротких запросов. Более продвинутые papers вроде Orca and Sarathi-Serve полезны именно этим: они показывают, что serving - это trade-off между prefill, decode, latency and throughput.

Как выбирать serving engine

vLLM, SGLang, TensorRT-LLM, Triton and TGI не стоит учить как рейтинг “кто быстрее”. Нормальный выбор начинается с вопросов: какие длины prompt/answer, нужен ли streaming, есть ли повторяющиеся префиксы, нужен ли JSON по схеме, есть ли RAG/tools/agents, сколько моделей или адаптеров надо обслуживать, какие SLO по p95/p99 and cost.

Production-кейсы: что из них вынести

• Perplexity + NVIDIA - пример search-scale serving, где важны routing, multi-model stack, throughput and cost per query. Это не универсальный benchmark, а история про конкретный workload.
• NAVER Place + TensorRT-LLM - хороший кейс для разговора про TTFT/TPOT: vertical SLM-service, где пользовательская задержка важнее абстрактного tokens/sec.
• LoRAX/Predibase - полезный vendor case про обслуживание сотен fine-tuned adapters and continuous multi-adapter batching. Это материал от вендора, поэтому берем инженерные идеи, но не используем его как независимое доказательство качества или скорости.

Как читать материалы по порядку

Что спрашивают на собеседовании

• Почему LLM inference делят на prefill and decode?
• Почему KV-cache одновременно ускоряет генерацию и создает memory bottleneck?
• Что делает PagedAttention и почему это не просто “ускорение attention”?
• Как continuous batching может улучшить throughput, но ухудшить p99 или TTFT?
• Когда выбирать vLLM, когда смотреть SGLang, а когда TensorRT-LLM/Triton?
• Какие метрики ты покажешь перед rollout новой serving config?