vLLM 0.33.0: что проверить перед обновлением сервера с ИИ-моделью
При обновлении сервера опасна не только ошибка установки, но и изменение ответов под нагрузкой. vLLM 0.33.0 появился в официальном списке релизов 1 ноября. В журнале — новые образы, изменения запуска и ускорения для отдельных связок оборудования и моделей. Разбираем, что проверить на своей инфраструктуре.
Что меняется в поставке
Для AWS EFA появился образ vllm/vllm-openai:v0.33.0-efa с библиотеками EFA и сборкой Mooncake для переноса KV-кеша. Релизные образы получили короткий алиас vllm/vllm. Не меняйте работающий продакшен-файл без фиксации полного тега и digest: иначе трудно установить версию при сбое. Без EFA и переноса кеша новая ветка образа не нужна.
В релизе есть исправления стартовых гонок портов и наблюдения за фронтенд-процессами при запуске движка. Это важно для кластера, где контейнер иногда поднимался, но endpoint отвечал неустойчиво. Однако слово «исправлено» в changelog не доказывает, что оркестратор больше не нуждается в пробах готовности. Сохраните прежние health check до испытания новой версии. Для маленького сервера сначала оцените локальный маршрут, а не переносите настройки кластера без нужды.
Производительность: не переносите чужой процент
Авторы приводят улучшения декодирования для конкретных ускорителей, режимов параллелизма и моделей. Цифра из такого теста относится к названной комбинации, а не к любому GPU и любому запросу. Измерьте на своём потоке медиану и хвост задержки, время до первого токена, пропускную способность, память и долю ошибок. Используйте одну и ту же модель, длины входа и уровень одновременной нагрузки до и после обновления. Иначе выигрыш может объясняться не версией vLLM, а изменением очереди или формата данных.
Отдельно проверьте структурированный вывод и вызов инструментов. Клиент может получить корректный HTTP-ответ, но другое число повторов или иной формат аргументов функции. Составьте небольшой контрольный набор с ожидаемыми полями и ошибочными входами. Если приложение возвращает пользователю факты из файлов, добавьте вопросы без ответа, на которые система должна честно воздержаться.
План безопасного обновления
Зафиксируйте текущие версии vLLM, CUDA, драйвера, PyTorch, способ квантования и шаблон чата модели. Снимите показатели за сопоставимое окно нагрузки. Поднимите новую версию рядом с прежней на том же наборе запросов, проверьте запуск после перезагрузки и остановку процесса. Затем направьте малую долю запросов на новый сервер и наблюдайте не только среднюю задержку, но и ошибки длинных контекстов. Путь возврата должен быть проверен заранее: старый образ, конфигурация и совместимые файлы модели остаются доступными до приёмки.
Поддержка новых архитектур в рантайме не означает, что соответствующие модели были выпущены вместе с vLLM или что у вас есть право их использовать. Читайте отдельные карточки модели и лицензии. Для выбора модели под нагрузку пригодится разбор длинного контекста и поиска: увеличение окна и изменение движка не гарантируют сохранности фактов.
Нужно ли обновляться сразу? Только если нужное исправление или функция стоит риска миграции. Ускорится ли мой сервер на заявленный процент? Это можно установить лишь измерением на вашей конфигурации. Достаточно ли успешного старта контейнера? Нет, нужен тест ответов и отката. Вывод: обновление стоит принимать по измеримому результату, а не по длине списка изменений.