Команда ServiceNow AI опубликовала разбор перехода с vLLM V0 на V1, в котором показала: новая архитектура движка инференса не просто ускоряет генерацию, она вскрывает целый класс багов, незаметно ломающих обучение моделей с подкреплением (RL). По данным авторов, после миграции на V1 их RL-пайплайн на reasoning-моделях начал внезапно расходиться — и причина оказалась не в алгоритме обучения, а в крошечных численных расхождениях между tokens, которые модель «думает» она сгенерировала, и tokens, которые на самом деле уходят в reward-функцию. В этой статье разбираем, что именно произошло, почему это важно для всех, кто работает с GPT-5, Claude, DeepSeek и другими моделями, и что это значит для пользователей в России и СНГ, которые тестируют AI-инструменты через WebGPT.
Что произошло?
vLLM — это open-source движок для высокопроизводительного инференса больших языковых моделей, который сегодня лежит в основе значительной части индустриальных RL-пайплайнов. На нём обучают reasoning-модели, дообучают чат-ассистентов через RLHF и RLAIF, прогоняют миллионы rollouts при тренировке агентов. В 2025 году команда vLLM выпустила V1 — переписанную с нуля версию с асинхронным шедулером, переработанным KV-кэшем и принципиально иной обработкой батчей.
Команда ServiceNow AI, занимающаяся reasoning-моделями, мигрировала на V1 ради скорости и обнаружила, что RL-обучение, стабильно работавшее на V0, начало расходиться. По описанию исследователей в оригинальном разборе на HuggingFace Blog, проблема проявлялась не сразу: первые сотни шагов градиент выглядел нормально, потом метрики качества начинали плавно деградировать, а к концу обучения модель забывала даже базовые инструкции.
Корень проблемы оказался не в алгоритме PPO или GRPO, а в инференсе. V1 в редких сценариях возвращал последовательности токенов, которые слегка отличались от того, что фактически попадало в логи rollout-а. Эти микрорасхождения накапливались и превращались в систематический сдвиг распределения, на котором модель училась.
В чём именно был баг
Авторы выделили несколько источников расхождений:
- Несинхронизированные стопы по EOS: при асинхронном шедулере в V1 разные запросы в батче могли остановиться на разных шагах, и хвост токенов одного запроса иногда «протекал» в логи другого.
- Сэмплинг с temperature и top-p в смешанной точности: на FP16/BF16 операциях softmax давали слегка разные вероятности при одних и тех же логитах в зависимости от размера батча.
- Препроцессинг промптов: V1 в некоторых случаях по-другому обрабатывал спецтокены и chat templates, особенно для длинных контекстов.
- KV-кэш с paged attention: при определённых паттернах prefix-sharing'а кэш мог быть переиспользован агрессивнее, чем нужно, и менять выход на тех же входах.
Каждый из этих эффектов сам по себе небольшой — речь о долях процента отклонений. Но в RL-обучении, где агент учится на собственных rollouts, такая разница между «что сгенерировано» и «что записано» означает, что reward-функция оценивает один текст, а градиент идёт на другой.
Почему это важно?
Главный тезис ServiceNow AI вынесен прямо в заголовок поста: «correctness before corrections» — то есть «правильность важнее исправлений». В индустрии последние два года шёл обратный тренд: команды гнались за throughput'ом, и каждый новый релиз vLLM, SGLang, TensorRT-LLM хвалился ростом QPS на десятки процентов. Но если этот рост достигается за счёт численной нестабильности или race conditions в шедулере, то для inference-only сценариев (чат-боты, поиск, RAG) последствия незаметны, а для RL-обучения — катастрофичны.
«Когда вы оптимизируете движок до того, как добились побитовой воспроизводимости rollouts, вы не оптимизируете обучение — вы оптимизируете шум», — формулируют авторы блога ServiceNow AI.
Это переворачивает подход к выбору инференс-стека для тренировки. Раньше команды смотрели на бенчмарки скорости, теперь придётся смотреть на reproducibility-тесты и на то, насколько движок честен в своих логах. По данным отчёта ServiceNow AI, после введения дополнительных проверок rollout consistency качество reasoning-моделей выросло на десятки процентов на бенчмарках MATH и GSM8K — без единого изменения в самом RL-алгоритме.
Кого это касается напрямую
- Команды, обучающие собственные reasoning-модели (включая DeepSeek-R1, QwQ, и многих локальных open-source разработчиков).
- Стартапы, делающие RLHF-дообучение Llama, Qwen, Mistral под доменные задачи.
- Исследовательские лаборатории, проводящие RL-эксперименты с агентами.
- Любые команды, у которых в продакшене есть тестовый «гольден сет» — баги инференса делают регрессии сложнее ловить.
А для конечных пользователей AI-чатов это значит, что качество новых моделей, выходящих в 2026 году, теперь сильнее зависит от инфраструктурной чистоты, чем от размера датасета или количества GPU.
Как это повлияет на пользователей AI в России и СНГ?
Для русскоязычных пользователей история кажется чисто инженерной, но на практике она напрямую отражается на том, какие модели и в каком качестве будут доступны в ближайшие месяцы. В России и СНГ доступ к фронтирным AI-инструментам ограничен из-за блокировок и санкций, поэтому большинство пользователей работают через агрегаторы — например, через WebGPT, где GPT-5, Claude 4.5, Gemini 2.5 и DeepSeek V3 доступны в одном интерфейсе без VPN и без зарубежных карт.
Когда vLLM становится надёжнее, а корректность RL растёт, это означает три вещи для русскоязычной аудитории:
- Новые open-source reasoning-модели будут заметно лучше. DeepSeek, Qwen, Yi и другие команды, активно использующие RL, получат прирост качества «бесплатно» — просто за счёт чистого инференса при обучении.
- Локальные дообучения станут стабильнее. Команды в России и Беларуси, делающие fine-tuning под банковские, юридические или медицинские задачи на собственных GPU-фермах, перестанут ловить плавающие регрессии.
- Ответы AI на сложных reasoning-задачах станут устойчивее. Это особенно важно для математики, кода и юридического анализа — областей, где даже маленький drift портит результат.
В WebGPT уже доступны DeepSeek-R1, Qwen3 и другие модели, обученные с помощью RL-пайплайнов на vLLM. Если индустрия в целом сдвигается в сторону «correctness first», следующая волна обновлений этих моделей должна стать заметно качественнее на reasoning-задачах — и пользователи увидят это в реальных диалогах, а не только в бенчмарках.
Что меняется для разработчиков-самозанятых
Отдельная история — те, кто крутит маленькие локальные модели на собственных машинах. До сих пор популярная схема «vLLM на одной 4090 + LoRA-дообучение через TRL» считалась воспроизводимой. После разбора ServiceNow AI становится ясно, что это иллюзия: V1-баги проявлялись и на одиночных GPU, просто медленнее. Если вы делаете RL-эксперименты для пет-проекта или диплома, имеет смысл явно зафиксировать версию vLLM и прогнать sanity-check на consistency rollouts перед длинной тренировкой.
Когда станет доступно исправление?
Большая часть конкретных багов, описанных в посте, уже закрыта в upstream-репозитории vLLM. Авторы ServiceNow AI подчёркивают, что работали в плотном контакте с командой vLLM и помогли довести патчи до релиза. По состоянию на начало мая 2026 года в ветке `main` vLLM появились дополнительные тесты на rollout determinism, флаги `--enforce-eager` и `--disable-async-output-proc`, которые жертвуют скоростью ради воспроизводимости, и улучшенный логгер для диагностики расхождений.
«Мы выбираем медленный, но честный движок для RL и быстрый — для продакшен-инференса. Это две разные задачи, и пытаться их совместить одним конфигом — главная ошибка отрасли последних двух лет», — пишет команда ServiceNow AI.
Параллельно похожую работу ведут команды SGLang и TensorRT-LLM. Ожидается, что к лету 2026 года в индустрии сложится консенсус: для RL-обучения нужны отдельные «correctness-mode» сборки инференса, а скорость — это вторичное свойство.
Что делать прямо сейчас?
Если вы тренируете модели или просто хотите понимать, что происходит под капотом современных AI-инструментов, разбор ServiceNow AI стоит прочитать целиком. Но даже без глубокого погружения есть три практических вывода.
Для команд, обучающих модели
- Обновитесь до последней версии vLLM и включите rollout-консистентность как обязательный gate перед длинными тренировками.
- Логируйте сгенерированные токены и токены, попавшие в reward, как два отдельных потока, и периодически сверяйте их побитово.
- Не доверяйте бенчмаркам скорости при выборе движка для RL — спрашивайте про reproducibility-тесты.
Для пользователей AI-чатов
Прямого действия не требуется, но имеет смысл знать: если вы используете reasoning-модели (o3, GPT-5 thinking, DeepSeek-R1, Claude с extended thinking), их качество в 2026 году будет расти быстрее, чем в 2025-м, во многом благодаря таким инфраструктурным историям. Через WebGPT можно протестировать сразу несколько моделей на одной и той же reasoning-задаче и сравнить — это удобный способ почувствовать разницу между поколениями обучения.
Для тех, кто следит за рынком
История с vLLM V0 → V1 — хороший индикатор того, что AI-индустрия выходит из фазы «быстрее любой ценой» и переходит к фазе зрелости, где численная корректность, воспроизводимость и аудируемость становятся такими же важными, как сырая производительность. По смежной теме мы публиковали материал о том, как OpenAI выпустила GPT-5 с улучшенным reasoning и про доступность DeepSeek V3 в России без VPN — оба сюжета напрямую связаны с тем, насколько чистым был инференс на этапе обучения.
Контекст: почему RL-обучение так чувствительно к багам инференса
Чтобы понять масштаб проблемы, важно вспомнить, чем RL-обучение отличается от классического supervised fine-tuning. При SFT модель учится на фиксированном датасете «вход → ожидаемый ответ» — баги инференса там не играют роли, потому что инференс просто не используется. При RL модель сама генерирует ответы (rollouts), эти ответы оценивает reward-функция, а градиент пушит модель в сторону высокооценённых траекторий.
Если в этом цикле инференс врёт о том, что именно было сгенерировано, происходит следующее: reward-функция получает текст A, ставит ему оценку, а градиент применяется так, как будто оценка была за текст B. Модель учится «нравиться» reward'у через траектории, которых на самом деле никогда не было. Это особенно опасно для длинных цепочек reasoning'а, где маленькое расхождение в одном токене может полностью изменить смысл ответа.
Команда ServiceNow AI приводит конкретный пример: при тренировке на математических задачах модель начала выдавать правильные финальные ответы, но абсолютно бессмысленные промежуточные шаги. Reward-функция, которая смотрела только на итоговый numeric answer, не замечала ничего; человек-аннотатор замечал сразу. Это классическая «специфическая reward hacking», но в этом случае она была вызвана не самой моделью, а движком инференса.
Почему именно V1 вскрыл проблему
V0 vLLM был сравнительно простым: синхронный шедулер, фиксированный батч, понятный поток данных. V1 переписан под асинхронность ради throughput'а — теперь шедулер может одновременно обслуживать сотни запросов разной длины с разными приоритетами. Это даёт огромный прирост скорости в продакшене, но создаёт целый класс race conditions, которые при синхронном пайплайне не возникали в принципе. Авторы блога подчёркивают, что V1 не «хуже» V0 — он просто решает другую задачу, а индустрия ещё не научилась использовать его правильно для RL.
Что это значит для open-source AI в долгой перспективе
Главное последствие — рост доверия к open-source стеку. До сих пор многие команды боялись открытого стека из-за «магии», которой нельзя проверить. ServiceNow AI публично разобрала баги, показала фиксы и подняла планку прозрачности. Теперь любая компания, обучающая модели на vLLM, имеет чек-лист sanity-проверок, который раньше был внутренним знанием закрытых лабораторий.
Для российской и СНГ-аудитории это означает, что качественные локальные дообучения становятся реалистичной задачей не только для крупных игроков (Сбер, Яндекс, Тинькофф), но и для маленьких команд, которые работают с ограниченными ресурсами. Если раньше дообучение модели «по-человечески» требовало команды в десять инженеров, то теперь чек-лист, выложенный в публичном блоге ServiceNow AI, позволяет даже небольшой команде из двух-трёх человек получить воспроизводимый RL-пайплайн.
Часто задаваемые вопросы
Что такое vLLM простыми словами?
vLLM — это open-source движок для быстрого запуска больших языковых моделей. Он отвечает за то, чтобы модель отдавала ответы пользователям с высокой скоростью и эффективно использовала видеопамять. Большинство современных AI-сервисов под капотом используют vLLM, SGLang или TensorRT-LLM.
Это повлияет на качество ChatGPT, Claude или Gemini?
На сами эти продукты — нет, OpenAI, Anthropic и Google используют собственные внутренние движки. Но история про корректность инференса — общая для всей индустрии, и аналогичные проверки наверняка проводятся и в закрытых лабораториях. Косвенно это влияет на качество всех новых моделей через распространение лучших практик.
Стоит ли мне обновлять vLLM, если я просто запускаю модель локально?
Если вы используете vLLM только для инференса (без RL-обучения), последние версии безопасны и быстрее. Свежий релиз содержит исправления, описанные в блоге ServiceNow AI, и улучшенную диагностику. Если вы тренируете модели — обязательно обновитесь и включите дополнительные проверки воспроизводимости.
Где можно протестировать модели, обученные с RL?
Через WebGPT доступны GPT-5 с режимом thinking, Claude 4.5 с extended thinking, DeepSeek-R1 и DeepSeek V3, Qwen3 и другие reasoning-модели. Можно сравнивать их ответы на одной и той же задаче в одном интерфейсе, без VPN и без зарубежной банковской карты.
Это касается только больших компаний?
Нет. Любая команда или индивидуальный разработчик, который делает RL-дообучение даже маленькой модели на одном GPU, потенциально сталкивался с описанными багами и просто не замечал их. Чек-лист от ServiceNow AI применим в одинаковой мере и к лабораторному эксперименту, и к промышленной тренировке на тысячах GPU.
Будут ли подобные проблемы в SGLang и TensorRT-LLM?
Команды этих движков уже ведут собственные аудиты численной корректности. Можно ожидать аналогичных публичных разборов в течение 2026 года — отрасль явно движется в сторону того, чтобы делать такую работу не внутри закрытых дверей, а в открытых блогах с чек-листами для сообщества.