Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Параллельно подготовленные следующие токены можно согласовать друг с другом, почти не возвращая последовательные вычисления. В препринте, который не проходил рецензирование и где все числа получены самими авторами, DCOCO обошёл сильнейший конкурирующий метод по пропускной способности вплоть до 18%. Для команд со своим контуром вывода LLM это открывает способ ускорить генерацию без замены целевой модели и без потери точности её распределения ответов.
Почему параллельному черновику не хватает контекста
Упреждающее декодирование (speculative decoding) разделяет генерацию между двумя моделями. Лёгкая модель готовит блок следующих токенов, а целевая проверяет их за один проход и принимает совпавший префикс. Если первый токен оказался неверным, всё после него в этом блоке уже не приносит пользы.
Последовательная черновая модель видит каждый уже выбранный токен, поэтому может связать соседние позиции. Но ей приходится строить продолжение шаг за шагом. DFlash сокращает эту задержку: диффузионная модель предсказывает весь блок параллельно, не зная, какой именно вариант будет выбран на предыдущей позиции.
Из-за этого правдоподобные по отдельности варианты могут образовать несогласованную фразу. Авторы приводят простой тип ошибки: модель рассматривает «New York» и «San Diego», но собирает из них «New Diego».
При этом нужный токен часто уже находится среди запасных вариантов. На Qwen3-8B в тех позициях, где первый вариант DFlash был неверным, правильный токен входил в список лучших кандидатов в 59% случаев. Значит, модели не обязательно генерировать черновик заново: достаточно лучше выбрать из того, что она уже рассчитала.
Как DCOCO возвращает связи внутри блока
DCOCO сохраняет несколько кандидатов для каждой позиции черновика. Затем небольшой обучаемый корректор оценивает совместимость каждого кандидата с вариантами на соседней позиции. Он использует скрытые состояния, идентификаторы токенов и оценки DFlash, поэтому второй проход черновой модели не нужен.
Все пары между соседними позициями корректор оценивает одной пакетной операцией. В этом состоит отличие от DSpark и Domino: те тоже добавляют потерянный контекст, но прогоняют обучаемый модуль по блоку последовательно. Такая цепочка лежит на критическом пути каждого цикла и сильнее мешает при одновременной обработке запросов.
После параллельной оценки DCOCO всё же делает короткий последовательный шаг, но без нейросетевых вычислений. Первый токен остаётся лучшим вариантом DFlash, затем алгоритм движется слева направо и выбирает наиболее подходящего преемника для уже принятого кандидата.
Такой порядок повторяет логику проверки: ранняя ошибка обесценивает поздние исправления. Авторы сравнили его с поиском пути, который максимизирует общую сумму оценок по всему блоку. Выбор слева направо дал более высокую пропускную способность на всех проверенных наборах, потому что не менял надёжный ранний токен ради привлекательного продолжения в конце.
Целевая модель по-прежнему проверяет результат и принимает только допустимый префикс. Поэтому DCOCO меняет скорость подготовки предложения, но не подменяет решение основной модели. Подход работает как при выборе самого вероятного токена, так и при случайной выборке из распределения.
Когда результат меняет планы по инфраструктуре
DCOCO проверяли с четырьмя целевыми моделями на десяти наборах задач по математике, программированию и генерации общего назначения. В испытания вошли Qwen3 разных размеров, Qwen3-Coder и Llama-3.1, режимы с расширенным рассуждением и без него, а также детерминированная и случайная генерация.
Максимальное ускорение относительно обычной генерации токен за токеном достигло 6,6 раза. При одновременной обработке запросов DCOCO опережал сильнейшего конкурента на 6–23%, тогда как последовательные корректоры под высокой нагрузкой уступали даже исходному DFlash. Это указывает, что выигрыш сохраняется не только в одиночном запросе, но и в серверном режиме.
Работа не требует менять целевую LLM, однако и не предлагает универсальную надстройку для любого API. Корректор использует внутренние состояния DFlash и обучается вместе с черновой моделью. Поэтому результат касается прежде всего команд, которые контролируют модели, обучение и сервер вывода, а не вызывают закрытую модель через внешний сервис.
Если в архитектурном плане уже есть параллельный черновик, DCOCO делает его более жизнеспособным под нагрузкой: качество кандидатов можно повышать без последовательного нейронного прохода. Если команда только выбирает способ ускорения, работа предлагает сравнивать методы не по длине принятого черновика отдельно, а по итоговой пропускной способности при ожидаемом числе одновременных запросов. Более точный черновик может проиграть, если его исправление слишком долго занимает вычислительный контур.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
