ORL (On-Policy Residual Learning) - метод пост-обучения диффузионных языковых моделей, который заставляет модель финализировать больше токенов за один forward pass без потери качества. Вместе с собственным инференс-движком dlmrt авторы метода заявляют пиковые 2 788 токенов/с на одной RTX 5090 для LLaDA-2.1-mini в NVFP4 и 7 708 токенов/с на восьми B200 для DiffusionGemma 26B MoE.
Эти числа описывают одиночный запрос (batch size 1), а не суммарную пропускную способность при параллельных запросах. Все GPU-показатели - пиковые результаты на конкретных бенчмарках, а не средние по произвольным промптам. Ориентироваться на них как на гарантированную скорость вашего пайплайна нельзя: на других задачах и промптах цифры будут ниже.
Модели, код обучения, пайплайн оценки и инференс-движок открыты, а чекпоинт LLaDA-2.1-mini ORL NVFP4 авторы описывают как запускаемый локально на RTX 5090. Ниже - как устроен метод, откуда берётся ускорение, что с качеством и какие подводные камни есть у заявленных цифр.
Что такое ORL и зачем он нужен диффузионным LLM
Диффузионная языковая модель (dLLM) генерирует текст итеративно. Она стартует с зашумлённого блока токенов и на каждом шаге денойзинга уточняет сразу весь блок, пересматривая собственные предсказания. Чем больше шагов, тем выше качество и ниже скорость. Главный рычаг здесь - tokens per forward (TPF): сколько токенов модель финализирует за один прямой проход. Если за шаг закрывается 8 токенов вместо 2, итераций становится вчетверо меньше при том же результате.
ORL повышает именно TPF. Метод обучает residual-контекст: механизм, который переносит предсказания предыдущих шагов денойзинга в следующий шаг и помогает модели раньше фиксировать токены, в которых она уверена. ORL не заменяет архитектуру dLLM, а работает как надстройка над существующими моделями, поэтому его можно применить к уже готовому чекпоинту.
Почему residual learning в dLLM - это on-policy задача
residual-траектория зависит от текущего состояния модели: то, какие токены она зафиксировала на третьем шаге, определяет её вход на четвёртом. Офлайн-датасет, собранный более ранним чекпоинтом, к моменту обучения описывает уже не ту модель, которая учится, и расхождение накапливается. ORL обучается на residual-траекториях, которые модель порождает на лету, поэтому разрыв между обучением и инференсом не растёт. Авторы отдельно отмечают, что residual learning в DLM по своей природе on-policy, и строят обучение на траекториях, порождённых самой моделью, - препринт ORL на arXiv.
Точный residual-надзор требует держать в памяти и повторно обрабатывать множество состояний, зависящих от траектории. Чтобы это масштабировалось, ORL сочетает асинхронный захват и транспорт residual, специализированное block-diffusion attention и packed compute-balanced обучение.
Adjacent Entropy Contraction: как ORL снижает неопределённость
Вторая часть метода - цель Adjacent Entropy Contraction. Каждый шаг денойзинга должен снижать неопределённость относительно предыдущего шага. Loss при этом гейтируется: если модель уже уверена в предсказании, штраф не применяется, чтобы не давить на корректные токены и не ломать их. Механизм обостряет предсказания по мере того, как модель пересматривает собственные решения, - пост авторов в r/LocalLLaMA.
Практический смысл: модель быстрее сходится и финализирует больше токенов за меньшее число шагов, а это напрямую конвертируется в TPF и скорость генерации.
dlmrt: инференс-движок для диффузионного декодирования
Ускорение даёт не только обучение. dlmrt - собственный инференс-движок авторов, заточенный под низколатентное одиночное диффузионное декодирование: он захватывает весь цикл денойзинга в CUDA-граф и исполняет его на GPU, а также поддерживает NVFP4 на GPU Blackwell, включая потребительскую RTX 5090, - описание dlmrt от авторов. Для авторегрессионных моделей выбор движка тоже критичен, и логика там похожая: сравнение llama.cpp и vLLM для локального запуска MoE показывает, насколько сильно стек влияет на итоговую скорость.
CUDA-граф: как захват всего цикла денойзинга ускоряет генерацию
Обычно каждый шаг денойзинга - это отдельный запуск ядер, который инициируется с CPU, плюс синхронизация между шагами. При batch size 1 эти накладные расходы съедают заметную долю времени, ведь полезной работы на один запуск мало. dlmrt вместо этого записывает весь цикл как один CUDA-граф и выполняет его на GPU. CPU перестаёт быть узким местом, а сотни мелких запусков превращаются в один крупный.
NVFP4 на Blackwell: что это даёт на RTX 5090
NVFP4 - 4-битный формат с плавающей запятой. Он уменьшает объём весов и трафик памяти, а на Blackwell для него есть аппаратная поддержка. Все заявленные пиковые цифры получены именно в NVFP4, поэтому на GPU без поддержки этого формата ускорение будет меньше. Как это выглядит на потребительской карте в реальных замерах, разбирается в материале про NVFP4, MTP и честное сравнение локального запуска на RTX 5090.
Сколько это в цифрах: пиковые 2 788 токенов/с на RTX 5090
Ключевые числа из материалов авторов: 2 788 токенов/с на одной RTX 5090 (LLaDA-2.1-mini + ORL в NVFP4), 5 046 токенов/с на одной B200 и 7 708 токенов/с на восьми B200 (DiffusionGemma 26B MoE + ORL в NVFP4). Отдельно приводится сравнение на одной H100: QwenDLM-4B + ORL обгоняет спекулятивное декодирование по speed-quality кривой и работает в 1,74 раза быстрее DFlash при совпадающей точности - данные препринта.
| Конфигурация | GPU | Токенов/с (batch size 1) |
|---|---|---|
| LLaDA-2.1-mini + ORL, NVFP4 | 1× RTX 5090 | 2 788 |
| ORL-модель, NVFP4 | 1× B200 | 5 046 |
| DiffusionGemma 26B MoE + ORL, NVFP4 | 8× B200 | 7 708 |
| QwenDLM-4B + ORL | 1× H100 | 1 298 |
| DFlash (speculative decoding, vLLM) | 1× H100 | 746 |
| EAGLE3 (speculative decoding, vLLM) | 1× H100 | 405 |
Держите в голове, что все строки таблицы - это одиночный запрос. Это не агрегированная пропускная способность при параллельных запросах и не средняя скорость на произвольных промптах.
Почему batch size 1 - это важно
Одиночный запрос - типичный сценарий локального использования: чат с одной сессией, code assistant, работа в IDE. При малом batch полезной работы на каждый запуск ядра мало, поэтому накладные расходы на запуск и синхронизацию становятся критичными, а оптимизации вроде захвата цикла в CUDA-граф дают максимальный эффект. При больших batch картина меняется: вычисления становятся плотнее, задержки запуска размываются, и выигрыш от таких трюков обычно скромнее. Если вы планируете обслуживать много одновременных пользователей, замеры для batch size 1 напрямую не переносятся на ваш сценарий.
Сравнение с speculative decoding: DFlash и EAGLE3
В том же сравнении на одной H100 заявлены конкретные цифры: QwenDLM-4B + ORL выдаёт 1 298 токенов/с, DFlash - 746 токенов/с, EAGLE3 - 405 токенов/с при ослабленной верификации и сопоставимой измеренной точности. То есть ORL быстрее DFlash примерно в 1,74 раза, а EAGLE3 отстаёт ещё сильнее.
Важная деталь методологии: сравнение end-to-end системное. ORL работает на движке dlmrt, а спекулятивные декодеры - на vLLM. То есть сравниваются разные инференс-стеки, а не только алгоритмы ускорения в одинаковых условиях. Плюс спекулятивное декодирование требует draft-модели и шага верификации, тогда как ORL - это пост-обучение, и на инференсе дополнительных моделей не появляется.
Качество не страдает: HumanEval и другие бенчмарки
Ускорение не покупается деградацией качества, по крайней мере на тех бенчмарках, которые приводят авторы. На QwenDLM-4B, диффузионной модели, конвертированной из Qwen3-4B, ORL поднимает HumanEval pass@1 с 82,9% до 89,6%. На той же модели tokens per forward растёт до 6,2×, а end-to-end пропускная способность вместе с dlmrt - примерно в 6,9 раза при сопоставимом или лучшем качестве.
На LLaDA-2.1-mini авторы указывают 4,2M self-generated токенов и 36 H100 GPU-часов пост-обучения. Это примерно в 10 раз меньше данных, чем у предыдущих LLaDA-рецептов, и даёт до 1,5× выше TPF и до 3× выше пропускную способность при сопоставимом качестве - детали в препринте. На DiffusionGemma 26B MoE прирост скромнее: TPF повышается в 1,1-1,2 раза. Логично: чем выше параллелизм модели изначально, тем меньше остаётся запаса для ускорения.
Всё это результаты на конкретных бенчмарках. HumanEval проверяет генерацию кода, и переносить прирост pass@1 на другие задачи без проверки не стоит.
Можно ли запустить локально на RTX 5090
Чекпоинт LLaDA-2.1-mini ORL в NVFP4 авторы описывают как запускаемый локально на одной RTX 5090. Модели, код обучения, пайплайн оценки и инференс-движок открыты: код можно изучить, чекпоинт - скачать и прогнать самому.
Что понадобится: GPU Blackwell (для NVFP4), движок dlmrt и поддержка формата в вашем стеке. Пошаговых инструкций и деталей конфигурации (версии драйверов, требований к VRAM) в опубликованных материалах нет, поэтому первый шаг - поднять dlmrt и убедиться, что NVFP4-инференс вообще стартует на вашей карте. Дальше имеет смысл прогнать бенчмарк на своих промптах, а не полагаться на числа из анонса.
Локальный запуск на одной карте - отдельная история с кучей нюансов про квантование и размер модели, и она уже подробно разбиралась на живом опыте: почему владелец RTX 5090 отказался от модели 27B в пользу Flash Next.
Ограничения и что стоит учитывать
- Все заявленные числа относятся к одиночному декодированию (batch size 1), а не к агрегированной пропускной способности при параллельных запросах.
- GPU-показатели - пиковые результаты на конкретных бенчмарках, а не средние по произвольным промптам.
- Сравнение с DFlash и EAGLE3 end-to-end системное: ORL идёт на dlmrt, спекулятивные декодеры - на vLLM. Сравниваются разные стеки.
- Конкретные 1 298, 746 и 405 токенов/с получены при ослабленной верификации и сопоставимой измеренной точности; в источнике упоминается и строгая верификация, но числа приведены для ослабленной.
- Показатель 2 788 токенов/с получен с NVFP4 и зависит от поддержки формата на Blackwell. На старых GPU ускорение будет другим.
- 7 708 токенов/с для DiffusionGemma 26B MoE требуют восьми B200. Это серверная конфигурация, а не домашняя машина.
- ORL - это пост-обучение, а не бесплатная надстройка: для LLaDA-2.1-mini указаны 36 H100-часов и 4,2M self-generated токенов.
- Улучшения TPF и пропускной способности указаны как «до» (up to) соответствующих значений, то есть это верхняя граница, а не гарантия на любых промптах.
- Методология бенчмарков, конфигурация промптов и полные условия замеров в опубликованных материалах не раскрыты.
- DiffusionGemma выигрывает всего 1,1-1,2× по TPF: у изначально высокопараллельных моделей запас для ускорения небольшой.
- Диффузионные языковые модели пока распространены меньше авторегрессионных, и экосистема инструментов вокруг них моложе.
Кому и зачем это нужно
Разработчикам и исследователям: ORL - открытый метод пост-обучения с опубликованным кодом, обучением и пайплайном оценки. Если вы работаете с dLLM, это готовый рецепт поднять TPF на своём чекпоинте и сравнить результат с baseline на своих данных.
Владельцам RTX 5090: есть открытый NVFP4-чекпоинт, который авторы описывают как запускаемый локально. Проверить его на своих промптах реалистично, но помните, что 2 788 токенов/с - это пик на конкретном бенчмарке, а не ваша средняя скорость.
Тем, кто строит продакшн: связка ORL + dlmrt интересна в первую очередь для низколатентных сценариев с одиночными запросами, где важна скорость первого ответа. Для массового параллельного обслуживания замеры при batch size 1 ничего не обещают, там нужен отдельный тест.
Если вы пока выбираете стек и модель под свои задачи, полезно держать в голове общий контекст: обзор свежих open-weights релизов 2026 года помогает понять, где сегодня проходит граница между авторегрессионными и диффузионными подходами. Конкретный практический шаг: развернуть dlmrt, скачать чекпоинт LLaDA-2.1-mini ORL NVFP4 и прогнать на своих промптах замеры TPF и end-to-end скорости. Только после этого решайте, стоит ли переносить подход в рабочий пайплайн.