Токен как единица контекста
Языковая модель не работает с текстом как с последовательностью символов. Перед подачей в модель текст разбивается на токены — минимальные единицы, которые модель воспринимает и генерирует. Токенизация выполняется препроцессором, который входит в определение модели наряду с конфигурацией и самой архитектурой.
Контекстное окно — максимальное количество токенов, которое модель способна обработать за один проход. Оно ограничивает суммарную длину входа (промпт, системная инструкция, история диалога) и выхода (сгенерированный текст). Когда суммарное число токенов превышает размер контекстного окна, модель не может учесть «лишние» токены. Размер контекстного окна определяется конфигурацией конкретной модели.
KV cache: связь памяти и длины контекста
Механизм attention в трансформере оперирует парами «ключ–значение» (key и value), которые вычисляются для токенов входной последовательности. При инференсе эти данные сохраняются в буфер — KV cache, — чтобы не пересчитывать их на каждом шаге генерации. vLLM определяет свою ключевую оптимизацию как «эффективное управление памятью ключей и значений attention» (attention key and value memory).
Объём KV cache растёт вместе с длиной обработанной последовательности. Для запросов с длинным контекстом именно KV cache становится основным потребителем памяти GPU, поэтому управление этой памятью — центральная задача инференс-движков.
PagedAttention: страничное управление KV cache
vLLM решает проблему фрагментации памяти KV cache с помощью PagedAttention. Блоки key-value хранятся не в непрерывном массиве, а в отдельных страницах фиксированного размера — по аналогии с управлением виртуальной памятью в операционной системе.
Практические следствия такого подхода:
- Снижение фрагментации. При непрерывном выделении памяти под KV cache каждого запроса остаются неиспользуемые области, которые невозможно переиспользовать для других запросов. Страничная организация позволяет выделять и освобождать память гранулярно.
- Гибкое распределение. Запросы в батче могут иметь разную длину контекста. Страничная схема позволяет не резервировать память под максимальную длину заранее, а выделять её по мере необходимости.
- Переиспользование общих префиксов. Если несколько запросов содержат одинаковое начало, соответствующие страницы KV cache можно разделять между запросами, избегая дублирования данных в памяти.
Фазы инференса: prefill и decode
Инференс LLM включает фазу prefill — первичную обработку входного промпта — и фазу decode — пошаговую генерацию новых токенов. vLLM поддерживает disaggregated prefill, decode и encode, то есть разделение этих фаз для более гибкого управления вычислительными ресурсами.
Длинный промпт делает фазу prefill дорогостоящей, поскольку требуется обработать сразу большое количество токенов. Для решения этой проблемы vLLM применяет chunked prefill — разбиение обработки длинного входа на части. Это позволяет не блокировать обслуживание других запросов в батче, пока один запрос с длинным контекстом проходит prefill.
Prefix caching
Prefix caching — оптимизация, при которой KV cache для общего префикса нескольких запросов вычисляется один раз и переиспользуется. Типичный сценарий: системный промпт одинаков для всех запросов в сессии, или few-shot примеры повторяются от запроса к запросу. Вместо повторной обработки одинакового начала движок использует уже вычисленный KV cache и продолжает с того места, где запросы расходятся.
Это напрямую снижает объём вычислений при обслуживании запросов с длинным общим контекстом.
Continuous batching
Классический подход к инференсу — статический батч: собрать группу запросов, обработать все, вернуть результаты. Continuous batching позволяет добавлять новые запросы в батч и завершать старые динамически, не дожидаясь готовности всех запросов. В сочетании с chunked prefill это обеспечивает эффективное обслуживание запросов с разной длиной контекста одновременно.
Оптимизированные attention-ядра
Вычисление attention — наиболее ресурсоёмкая часть обработки контекста. vLLM поддерживает несколько специализированных ядер для ускорения этой операции: FlashAttention, FlashInfer, FlashMLA, TRTLLM-GEN и Triton. Выбор ядра зависит от аппаратной платформы и архитектуры модели.
Помимо attention-ядер, vLLM использует оптимизированные GEMM/MoE-ядра на базе CUTLASS, TRTLLM-GEN и CuTeDSL, а также автоматическую генерацию ядер и графовые трансформации через torch.compile.
Квантование
vLLM поддерживает квантование в форматах FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ/AWQ, GGUF, compressed-tensors, ModelOpt, TorchAO и других. Квантование снижает требования к памяти, что позволяет обслуживать запросы с более длинным контекстом на доступном оборудовании. Выбор формата квантования представляет собой компромисс между экономией памяти и точностью представления данных.
Speculative decoding
Speculative decoding — техника ускорения фазы генерации. vLLM поддерживает несколько вариантов: n-gram, suffix, EAGLE и DFlash. Техника не меняет размер контекстного окна, но снижает задержку генерации, что особенно заметно при длинных выходах.
Гибридные архитектуры
Помимо классических decoder-only моделей, vLLM поддерживает гибридные архитектуры, сочетающие attention с state-space моделями — например, Mamba и Qwen3.5. В таких архитектурах часть слоёв использует альтернативные механизмы обработки последовательностей, что влияет на характер роста потребления памяти с длиной контекста.
Масштабирование и параллелизм
Для обслуживания длинных контекстов на нескольких устройствах vLLM поддерживает несколько видов параллелизма: tensor, pipeline, data, expert и context parallelism. Context parallelism особенно релевантен для длинных последовательностей, поскольку позволяет распределить обработку контекста между устройствами.
vLLM работает на NVIDIA GPU, AMD GPU, x86/ARM/PowerPC CPU, а также поддерживает специализированные аппаратные плагины для Google TPU, Intel Gaudi, IBM Spyre, Huawei Ascend, Rebellions NPU, Apple Silicon, MetaX GPU и других платформ.
Поддерживаемые архитектуры моделей
vLLM поддерживает более 200 архитектур моделей, включая:
- Decoder-only LLM (Llama, Qwen, Gemma)
- Mixture-of-Expert LLM (Mixtral, DeepSeek-V3, Qwen-MoE)
- Гибридные attention и state-space модели (Mamba, Qwen3.5)
- Мультимодальные модели (LLaVA, Qwen-VL, Pixtral)
- Модели для эмбеддингов и retrieval (E5-Mistral, GTE, ColBERT)
- Модели для reward и классификации (Qwen-Math)
Практические ограничения длинного контекста
Даже если модель формально поддерживает большой контекст, на практике возникают ограничения:
- Память GPU. KV cache для длинных последовательностей может исчерпать доступную память. PagedAttention и квантование смягчают проблему, но не устраняют её полностью.
- Задержка prefill. Обработка длинного входа требует времени. Chunked prefill помогает не блокировать другие запросы, но общая задержка для длинного промпта остаётся высокой.
- Пропускная способность. При обслуживании множества запросов с длинным контекстом одновременно пропускная способность снижается, поскольку каждый запрос занимает больше памяти и вычислительных ресурсов.
- Качество генерации. Формальный размер контекстного окна не гарантирует, что модель одинаково эффективно использует информацию из всех частей промпта. Качество на длинных последовательностях зависит от архитектуры и обучения модели.
Что учитывать при развёртывании
При развёртывании модели с длинным контекстом через инференс-движок стоит обращать внимание на:
- Доступную память GPU и ожидаемый размер KV cache для целевой длины контекста.
- Поддержку PagedAttention или аналогичного механизма — без него фрагментация памяти быстро станет узким местом.
- Наличие prefix caching — критично, если запросы имеют общий префикс.
- Chunked prefill — необходим для обслуживания длинных запросов без блокировки коротких.
- Формат квантования — компромисс между экономией памяти и точностью.
- Выбор attention-ядра — зависит от GPU и архитектуры модели.
- Вид параллелизма — для длинных контекстов особенно релевантен context parallelism.
- Аппаратную платформу — набор оптимизированных ядер и поддерживаемых форматов квантования различается в зависимости от платформы.
