Что произошло

Проект vLLM выпустил версию 0.27.0 10 августа 2026 года. Это крупное обновление сервера инференса: в нём 561 коммит от 242 участников, поддержка новых моделей, изменения в ядре, API, распределённом обслуживании и безопасности. Уже 11 августа вышла 0.27.1 — небольшой патч поверх основной версии с поддержкой квантованных DSpark Markov heads.

Для бизнеса важен не размер списка изменений, а один пункт в официальных примечаниях: переход на PyTorch 2.13.0, torchvision 0.28.0 и Triton 3.7.1 прямо назван несовместимым изменением окружения. Если локальный помощник, RAG или агент уже обслуживает сотрудников через vLLM, обновление следует рассматривать как миграцию платформы, а не как обычную замену Python-пакета.

Это не означает, что релиз нужно пропустить. В нём есть полезные улучшения производительности, управляемости и защиты. Но безопасная ценность появляется только после проверки на собственном оборудовании, моделях, квантизациях и рабочих запросах.

Что нового имеет практический смысл

vLLM 0.27.0 добавляет полный стек поддержки Kimi K3 и поддержку текстовых dense- и MoE-вариантов Qwen3.5, K-EXAONE 2.0, VaultGemma и jina-embeddings-v5-text-nano. Model Runner V2 расширен на эмбеддинги, классификацию и другие негenerative задачи. Это позволяет одной платформе обслуживать не только генерацию ответов, но и часть конвейера поиска или классификации.

Есть изменения, которые могут быть заметны пользователям сервиса:

  • новая инфраструктура прогрева JIT и Triton-ядер должна убрать задержки компиляции на первом запросе;
  • расширена работа с KV-кешем и его выгрузкой на другие уровни хранения;
  • добавлен упрощённый механизм отказоустойчивости для конфигураций data parallel плюс expert parallel с внешним балансировщиком;
  • Rust-фронтенд получил gRPC-интерфейс управления, проверку состояния, отмену запросов и обнаружение серверов и моделей;
  • `vllm-bench` встроен в CLI, что упрощает воспроизводимое измерение задержки и пропускной способности.

Однако эти возможности не включаются в экономический эффект автоматически. Поддержка новой модели ещё не означает, что она помещается в имеющиеся GPU, укладывается в SLA или корректно вызывает ваши инструменты на русском языке. В релизе также удалена поддержка некоторых моделей и аргументов, поэтому конфигурацию запуска нужно сравнить с разделом deprecations.

Почему нельзя обновлять поверх работающего контура

vLLM компилирует множество CUDA-ядер. Документация проекта предупреждает о бинарной несовместимости между версиями CUDA и PyTorch и рекомендует устанавливать vLLM в новое окружение. Для нестандартной CUDA или существующей установки PyTorch может понадобиться сборка из исходников.

Практически это означает четыре независимых риска.

Первый — окружение. Новый PyTorch, Triton, Transformers, FlashInfer, NCCL и другие зависимости могут изменить доступные колёса, ABI или поведение сборки. Образ, который запускается на тестовой машине, ещё должен совпасть с драйвером, архитектурой GPU и базовой ОС в производстве.

Второй — модель. Нужно проверить загрузку именно используемого чекпойнта, формат квантизации, токенизатор, контекст, structured outputs, reasoning parser и tool calling. Общая строка «модель поддерживается» не гарантирует совместимость всех режимов.

Третий — API. Даже если OpenAI-совместимые маршруты сохранились, клиент может зависеть от формы ошибки, порядка потоковых событий, счётчиков токенов, stop-последовательностей или JSON-схемы. Эти детали проверяются контрактными тестами.

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

Что изменилось в безопасности

В 0.27.0 разработчики заменили `diskcache`, чтобы исключить десериализацию через pickle, исправили гонку в проверке sparse-инвариантов, ограничили ресурсы для derender, очистили пути файлов в сообщениях об ошибках и добавили ограничения для списков prompt в completion API и времени компиляции регулярных выражений.

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

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

План миграции без остановки бизнеса

Безопасный маршрут состоит из двух параллельных окружений.

1. Зафиксируйте текущий production: образ, digest, версию vLLM, PyTorch, CUDA, драйвер, аргументы запуска, модель, ревизию весов и токенизатора.
2. Соберите новый образ отдельно. Не обновляйте пакет внутри работающего контейнера и не используйте плавающий тег `latest`.
3. Запустите на том же классе GPU и прогрейте модель до измерений.
4. Прогоните золотой набор: русские документы и вопросы, RAG-контекст, structured outputs, вызовы инструментов, длинные диалоги, отказы и токсичные входы.
5. Выполните контрактные тесты API и интеграций: таймауты, отмена, потоковая выдача, коды ошибок, повторные запросы и лимиты.
6. Снимите p50, p95 и p99 для TTFT и общей задержки, tokens per second, число ошибок, GPU-память, загрузку CPU, длину очереди и качество ответов.
7. Отдайте новой версии 5–10% реального трафика без права необратимых действий. Сравните метрики по одинаковым типам запросов.
8. Расширяйте долю только при прохождении заранее утверждённых порогов. Старый образ, конфигурация и веса должны оставаться готовыми для быстрого отката.

Для RAG дополнительно сравните полноту и точность найденных фрагментов. Если тот же сервер выдаёт эмбеддинги, изменение в pooling или модели может потребовать отдельной проверки индекса; нельзя считать генеративные тесты достаточными.

Какие пороги задать

Управленческое решение проще, если критерии утверждены до теста. Пример для внутреннего ассистента:

  • ноль критических расхождений в правах и маршрутизации инструментов;
  • не хуже текущей версии по точности ответов на золотом наборе;
  • p95 TTFT и общей задержки не ухудшаются более чем на 10%;
  • пиковая GPU-память оставляет согласованный резерв;
  • доля HTTP 5xx и аварийных перезапусков не растёт;
  • все сценарии structured output и tool calling проходят контрактные тесты;
  • откат отрабатывается за установленное время без потери запросов.

Порог в 10% здесь пример, а не рекомендация для каждого бизнеса. Для оператора колл-центра важнее стабильная хвостовая задержка, для ночной пакетной обработки — пропускная способность и цена, для агента с действиями — корректность схемы и прав.

Модельная экономика обновления

Предположим, локальный сервис обрабатывает 1,5 млн токенов в день, а инфраструктура стоит 180 000 рублей в месяц. После миграции измеренная пропускная способность позволяет обслуживать тот же трафик за 150 000 рублей, но подготовка, тестирование и наблюдение стоят 240 000 рублей разово.

Модельная экономия — 30 000 рублей в месяц, простой срок окупаемости работ — восемь месяцев. Если обновление не сокращает инфраструктуру, ожидание или трудозатраты, экономия может быть нулевой, даже если бенчмарк вырос. И наоборот, исправление риска удалённого отказа или утечки трудно оценить одним ROI, но оно может оправдывать плановую миграцию.

Все цифры примерные. Подставьте фактическую стоимость GPU, электричества и сопровождения, объём трафика, цену простоя и ожидаемый срок жизни контура. Не включайте в эффект ускорение, которое не изменяет число серверов или время работы сотрудников.

Что делать руководителю сейчас

Если vLLM не используется, новость не требует срочной закупки GPU: сначала определите процесс и модель нагрузки. Если используется в тесте, фиксируйте 0.27.1 в отдельном образе и сравнивайте с текущей версией. Если это уже production, создайте карточку контролируемой миграции с владельцем, золотым набором, порогами и проверенным откатом.

Главный вывод: vLLM 0.27 приносит заметные возможности и защитные исправления, но переход на PyTorch 2.13 меняет основание стека. Полезное обновление начинается не с команды установки, а с воспроизводимого стенда и решения, при каких показателях новая версия получит трафик.