В этом материале
Preemption может сохранять работоспособность ценой повторной работы; отсутствие OOM ещё не означает достаточную ёмкость.
Preemption в vLLM означает, что движок вынужден временно прервать обслуживание последовательности из-за ограничений ресурсов, например давления на KV-кеш. В зависимости от режима и версии часть работы может потребовать повторного вычисления. Сервер при этом способен продолжать отвечать без CUDA OOM, но задержка и полезная производительность меняются.
Отличите вытеснение от аварии
OOM обычно прерывает конкретную операцию или процесс. Вытеснение относится к управлению активной работой и не обязательно является аварией. Однако регулярные сообщения preemption показывают, что выбранный профиль запросов нужно изучить внимательнее. Особенно если растёт время ожидания при умеренном потоке.
Сохраните частоту сообщений и параметры нагрузки. Единичный эпизод после резкого всплеска отличается от непрерывного режима. Важно сопоставлять события с количеством выполняемых последовательностей, длинами входов и выходов, а не делать вывод по одному предупреждению в журнале.
Найдите источник давления на кеш
Память кеша зависит от архитектуры модели, точности хранения и числа активных токенов. Увеличение параллельности или длинные ответы постепенно занимают ресурс. При этом размер весов остаётся прежним: одна и та же карта проходит одиночный тест и испытывает давление на потоке.
Официальная оптимизация vLLM описывает preemption и варианты настройки. Контекст следует оценивать целиком, как показано в руководстве max-model-len. Простое увеличение разрешённой длины без проверки нагрузки способно ухудшить рабочую границу.
Проведите опыт с одним изменением
Практический сценарий: зафиксируйте модель и документы, затем сравните два уровня активной параллельности. Для каждого сохраните число вытеснений, завершённые запросы, задержку первого токена и полное время ответа. После этого отдельно попробуйте меньший резерв выхода или более короткие входы.
Если снижение параллельности убирает вытеснения, проверьте новую очередь ожидания. Пользовательская задержка может перенестись из вычислений в очередь, поэтому исчезновение предупреждения ещё не определяет лучший режим. Нужна оценка полного пути запроса от отправки до последнего токена.
Сравните способы расширения ресурса
Увеличение бюджета памяти движка иногда даёт больше места кешу, но требует свободной VRAM и запаса для остальных буферов. Другой вариант — меньшая модель, поддерживаемое изменение точности, дополнительная реплика или распределение. У каждого способа есть собственные условия совместимости и влияние на качество.
Не выбирайте настройку по чужому проценту. Сначала покажите, какой именно ресурс исчерпан, и измерьте эффект. Описание доступных наблюдений сверяйте с метриками vLLM. Общая экономическая связь кеша и количества сессий разобрана в отдельной статье.
Проверьте также фактические длины завершённых выходов. Большой запрошенный резерв и короткие реальные ответы создают другой профиль, чем постоянно достигаемые предельные ответы, даже при одинаковом числе обращений.
Обсудите мощность на языке рабочего режима
Владельцу GPU полезно передавать не только число гигабайт, но и режим, где вытеснения редки либо допустимы по требованиям задачи. Для пакетной обработки некоторая дополнительная задержка может быть приемлема; для интерактивного ответа критерии будут другими.
Финансовому партнёру отчёт помогает сравнить увеличение памяти с добавлением реплик и ограничением контекста. В обсуждении пилота важно отдельно назвать устойчивость процесса и качество обслуживания: живой сервер ещё может выполнять слишком много повторной работы.