В on-policy RL одна и та же политика должна генерировать траектории и затем оценивать их при обучении. На практике rollout и trainer часто считают ее немного по-разному. IsoExec, представленный в блоге vLLM, пытается убрать это расхождение на уровне исполнения, а не компенсировать его постфактум в алгоритме.
Для команды, которая обучает агентов, вывод неприятный, но полезный: нестабильность может жить не в reward, данных или гиперпараметрах, а в стыке двух инфраструктурных стеков. Масштабирование кластера такую ошибку не лечит. Оно лишь делает эксперимент дороже.
Одна политика, два результата
RL-системы обычно разделяют работу между inference-движком и training-стеком. Первый генерирует rollout, второй повторно вычисляет logprob выбранных токенов и обновляет модель. В SkyRL это могут быть vLLM и Megatron.
Хотя параметры модели совпадают, среды исполнения отличаются: определения модели, ядра, формы батчей, режимы prefill и decode, а также схемы распределения вычислений могут быть разными. Поскольку операции с плавающей точкой неассоциативны, другой порядок редукций способен изменить вероятности токенов. Математически политика та же. На уровне битов уже не совсем.
Это не косметическая погрешность. Как пересказывает блог vLLM, исследование ByteDance VeXact показало, что mismatch сам по себе может дестабилизировать REINFORCE и GRPO, искажать вклад advantage-weighted loss еще до реакции KL-оценки и усложнять калибровку корректировок через importance sampling или rejection. Fireworks сообщала о запуске GLM-5.2 с train-inference KL около 0,013: clipping отбрасывал примерно 45% токенов, а reward обрушился примерно на двадцатом шаге. При побитовом выравнивании токены не отсекались, и запуск оставался стабильным.
Иными словами, два execution-стека могут создать проблему, которую затем приходится героически исправлять на уровне RL-алгоритма. Инфраструктурный ритуал получается дорогой: сначала внести численное расхождение, потом бороться с его последствиями.
Что именно объединяет IsoExec
IsoExec состоит из двух частей. Первая, execution contract, фиксирует все решения, способные повлиять на округление: реализацию ядра, dtype накопления и границ, порядок редукций, параметры разбиения вроде split-K и split-KV. Контракт описывается независимо от фреймворка и должен одинаково исполняться в rollout-движке и trainer.
Вторая часть, unified model, использует ядра, проверенные на побитовую согласованность между training, prefill и decode. Модель при этом сохраняет возможности vLLM, включая scheduler, управление KV cache и CUDA graph capture, и соединяется с training-стеком Megatron.
Операторы разбиваются на регионы, каждый из которых может объединять несколько операций в одном ядре. Для каждой пары «регион и сценарий исполнения» система выбирает конкретную реализацию и закрепленные константы. Перед регистрацией реализации регион проверяется на побитовую точность между сценариями.
Гарантии здесь не безусловные. Claims задают границы, внутри которых согласованность доказана. Например, topology claim перечисляет размеры параллелизма, для которых дерево редукции проверено как инвариантное. Если реальная конфигурация не входит в список, адаптер отклонит установку ядра. Совпадение контрактов между trainer и rollout проверяется через SHA-256-идентификаторы.
Это важное ограничение продукта и одновременно его сильная сторона. IsoExec не обещает магическую детерминированность на любой конфигурации. Он требует явно описать, где именно гарантия действует, и отказывается молча считать непроверенную топологию эквивалентной.
За согласованность придется заплатить
В тесте авторов синхронное DAPO-обучение Qwen3.5-35B-A3B работало на одном узле с восемью H100. За 50 шагов IsoExec дал 25% накладных расходов относительно текущего baseline SkyRL. Это пока не бесплатная замена раздельным execution-стекам.
Но сравнивать эти 25% стоит не только со скоростью baseline. Альтернатива включает стоимость нестабильных траекторий, ложных гипотез о reward и алгоритме, а также запусков, результаты которых меняются после перестройки батчей или параллелизма. Для небольшого эксперимента unified execution может оказаться избыточным. Перед масштабным посттренингом цена диагностики уже выглядит разумнее.
Практический шаг для RL-команды сейчас прост: отдельно измерить rollout-versus-training logprob difference на одной и той же версии модели, затем проверить, меняется ли он при других батчах и схемах tensor, expert или sequence parallelism. Если расхождение растет вместе с инфраструктурой, расширять кластер рано.
Главный маркер для IsoExec дальше не новый benchmark, а расширение списка проверенных конфигураций без роста накладных расходов. Если единый контракт начнет покрывать больше топологий и execution-режимов при overhead заметно ниже опубликованных 25%, trainer-inference mismatch превратится из загадочной болезни RL в обычную инженерную проверку перед запуском.