# vLLM KV cache и preemption: почему запросы пересчитываются

Что означает preemption в vLLM: давление на KV-кеш, повторные вычисления, задержка и проверка контекста с параллельностью.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/vllm-kv-cache-preemption/
Language: ru

Preemption в vLLM означает, что движок вынужден временно прервать обслуживание последовательности из-за ограничений ресурсов, например давления на KV-кеш. В зависимости от режима и версии часть работы может потребовать повторного вычисления. Сервер при этом способен продолжать отвечать без CUDA OOM, но задержка и полезная производительность меняются.

## Отличите вытеснение от аварии

OOM обычно прерывает конкретную операцию или процесс. Вытеснение относится к управлению активной работой и не обязательно является аварией. Однако регулярные сообщения preemption показывают, что выбранный профиль запросов нужно изучить внимательнее. Особенно если растёт время ожидания при умеренном потоке.

Сохраните частоту сообщений и параметры нагрузки. Единичный эпизод после резкого всплеска отличается от непрерывного режима. Важно сопоставлять события с количеством выполняемых последовательностей, длинами входов и выходов, а не делать вывод по одному предупреждению в журнале.

## Найдите источник давления на кеш

Память кеша зависит от архитектуры модели, точности хранения и числа активных токенов. Увеличение параллельности или длинные ответы постепенно занимают ресурс. При этом размер весов остаётся прежним: одна и та же карта проходит одиночный тест и испытывает давление на потоке.

[Официальная оптимизация vLLM](https://docs.vllm.ai/en/stable/configuration/optimization/) описывает preemption и варианты настройки. Контекст следует оценивать целиком, как показано в [руководстве max-model-len](/ru/journal/vllm-max-model-len/). Простое увеличение разрешённой длины без проверки нагрузки способно ухудшить рабочую границу.

## Проведите опыт с одним изменением

Практический сценарий: зафиксируйте модель и документы, затем сравните два уровня активной параллельности. Для каждого сохраните число вытеснений, завершённые запросы, задержку первого токена и полное время ответа. После этого отдельно попробуйте меньший резерв выхода или более короткие входы.

Если снижение параллельности убирает вытеснения, проверьте новую очередь ожидания. Пользовательская задержка может перенестись из вычислений в очередь, поэтому исчезновение предупреждения ещё не определяет лучший режим. Нужна оценка полного пути запроса от отправки до последнего токена.

## Сравните способы расширения ресурса

Увеличение бюджета памяти движка иногда даёт больше места кешу, но требует свободной VRAM и запаса для остальных буферов. Другой вариант — меньшая модель, поддерживаемое изменение точности, дополнительная реплика или распределение. У каждого способа есть собственные условия совместимости и влияние на качество.

Не выбирайте настройку по чужому проценту. Сначала покажите, какой именно ресурс исчерпан, и измерьте эффект. Описание доступных наблюдений сверяйте с [метриками vLLM](https://docs.vllm.ai/en/stable/usage/metrics/). Общая экономическая связь кеша и количества сессий разобрана в [отдельной статье](/ru/journal/kv-cache-economics/).

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

## Обсудите мощность на языке рабочего режима

Владельцу GPU полезно передавать не только число гигабайт, но и режим, где вытеснения редки либо допустимы по требованиям задачи. Для пакетной обработки некоторая дополнительная задержка может быть приемлема; для интерактивного ответа критерии будут другими.

Финансовому партнёру отчёт помогает сравнить увеличение памяти с добавлением реплик и ограничением контекста. В обсуждении пилота важно отдельно назвать устойчивость процесса и качество обслуживания: живой сервер ещё может выполнять слишком много повторной работы.