Тестируем DFlash от Nvidia: почему вместо обещанных 15x мы получаем 2,3x и когда технология бесполезна

В начале года технологическое сообщество активно обсуждало DFlash — новый метод ускорения работы больших языковых моделей без модификации их основных весов. Заголовки технологических блогов и материалы Nvidia обещали впечатляющие показатели: до 15-кратного роста пропускной способности на архитектуре Blackwell. Цифра выглядит грандиозно и создает ощущение очередного технологического прорыва в сфере инференса нейросетей.

Я решил проверить эти заявления на практике и провести независимое тестирование. Для экспериментов я взял готовый драфтер DFlash для модели Gemma 4 26B из официального репозитория и развернул его на собственном тестовом стенде. Результаты оказались далеки от маркетинговых слайдов: вместо 15-кратного ускорения удалось зафиксировать максимум 2,3x, да и то исключительно в режиме одиночного запроса. Как только на сервер поступает 4 одновременных запроса, преимущество полностью нивелируется, а при 8 параллельных пользователях DFlash начнет проигрывать базовой модели без спекуляции.

В этом материале я детально разберу, откуда берутся громкие показатели в пресс-релизах вендора, почему мои графики кардинально отличаются от презентационных и в каких сценариях DFlash действительно имеет смысл использовать.

Как устроена технология DFlash и за счёт чего она ускоряет LLM

Обычная большая языковая модель генерирует текст строго последовательно (авторегрессивно): один полный проход по всем миллиардам параметров дает на выходе ровно один токен. При обработке запроса от одиночного пользователя такая схема крайне неэффективна. Чтобы выдать один токен, видеокарта вынуждена прокачивать через свою шину памяти весь массив весов, из-за чего процесс упирается исключительно в пропускную способность памяти (memory bandwidth limit). Арифметика и вычислительные блоки GPU в этот момент простаивают.

Для решения этой проблемы было придумано спекулятивное декодирование (speculative decoding). Суть метода заключается в том, что небольшая и быстрая «черновая» модель (драфтер) быстро сгенерирует цепочку из нескольких предположительных токенов. Затем целевая крупная модель за один-единственный проход проверяет весь предложенный блок. Если последовательность совпадает, она принимается целиком, а если где-то возникло расхождение — хвост отбрасывается. Математическое распределение вероятностей не нарушается, поэтому качество ответа остается неизменным, а скорость работы растет.

Главным узким местом классических архитектур спекулятивного декодирования (например, EAGLE-3) остается сам процесс создания черновика. Драфтер в них точно так же генерирует токены по одному. Если нам нужно сформировать черновик из 5 токенов, драфтер совершает 5 последовательных проходов. Разработчики DFlash предложили кардинально иное решение — использовать блочную диффузионную модель, которая формирует весь черновой блок параллельно за один шаг.

Чтобы драфтер чаще попадал в правильные токены, в DFlash применяется механизм KV injection: внутренние скрытые состояния и контекстные признаки целевой модели напрямую прокидываются в KV-проекции каждого слоя черновой модели. Это дает драфтеру возможность опираться на уже посчитанный глубокий контекст основной сети, а не строить догадки с нуля.

В моих тестах черновой модуль занимал около 451 МБ и работал в связке с MoE-моделью на 26 млрд параметров. На практике драфтер угадывал продолжение примерно в 25% случаев, а средняя длина успешно принятого блока составила 2,06 токена. То есть за один проход целевой модели удавалось получить в среднем два токена вместо одного. Это дает ощутимый прирост, но всё же очень далеко от заявленных 15 раз.

Откуда берутся заголовочные 15x в материалах Nvidia

Показатель 15x не выдуман из головы, но он получен в чрезвычайно специфических условиях. Стенд Nvidia состоял из 8 систем DGX B300, оптимизированного стека TensorRT-LLM и модели gpt-oss-120b. А главное — этот результат зафиксирован в самой левой точке кривой Парето, где целевая производительность составляла 500–600 токенов в секунду на одного пользователя.

Это режим экстремально низкой задержки и максимальной отзывчивости. При таких требованиях стандартный авторегрессивный инференс работает крайне неэффективно: размер батча минимален, вычислительные мощности карты практически полностью простаивают. DFlash в этой точке демонстрирует колоссальный отрыв от базовой линии именно потому, что базовый режим находится в максимально невыгодных условиях.

Если переместиться в более реалистичный режим работы с высокой плотностью запросов, преимущество DFlash быстро сокращается. В той же технической документации Nvidia приводит данные для сбалансированной нагрузки: усредненное ускорение составляет 2,3x для gpt-oss-120b и 2,8x для Llama 3.1 8B. При одиночном запросе на одной видеокарте показатели составляли 5,8x на математических задачах и 4,4x на генерации кода для Gemma-4 31B. Таким образом, сам разработчик показывает широкий разброс от 1,8x до 15x в зависимости от условий измерений.

Практические замеры: тестирование DFlash на собственном стенде

Я проверил реальную суммарную скорость генерации при постепенном увеличении количества одновременных пользователей. В качестве точек сравнения выступали базовая генерация на Gemma 4 26B без спекулятивного декодирования и аналогичная конфигурация с подключенным модулем DFlash.

Характеристики тестового оборудования и окружения:

• Видеокарта: Nvidia RTX 6000 PRO;
• Драйвер и CUDA: Driver 610.57.04, CUDA UMD 13.3;
• Контейнеризация: Docker 29.7.2;
• Инференс-движок: llama.cpp (сборка server-cuda 10711);
• Модель: gemma-4-26B-A4B-it-Q4_0 с квантованным KV-кешем q4_0;
• Параметры теста: 512 токенов на запрос, максимальная длина черновика --spec-draft-n-max 4.

Главный вывод из этой таблицы кроется в динамике графиков. Производительность базовой модели растет практически линейно: каждый новый параллельный поток добавляет к общей пропускной способности почти столько же токенов, сколько и первый (181 → 326 → 441 → 517). В то же время DFlash мгновенно упирается в потолок уже после первого запроса и далее колеблется в диапазоне 480–580 токенов в секунду.

Точка перелома наступает в районе 4 одновременных запросов. При 8 параллельных клиентах суммарный поток DFlash оказывается на 31% ниже, чем у обычной модели без ускорителей.

Важно подчеркнуть: проседает именно суммарная пропускная способность сервера (throughput), а не скорость выдачи отдельному пользователю. На 8 запросах задержка одного потока у DFlash оставалась на уровне базовой линии (98,8 против 97,5 ток/с на поток). Сервер начинает проигрывать из-за того, что GPU тратит драгоценное время на просчет черновых токенов, большая часть которых затем отбрасывается.

Почему высокая конкурентность убивает спекулятивное ускорение

Спекулятивное декодирование и традиционный батчинг (объединение запросов в пакеты) соревнуются за один и тот же аппаратный ресурс — простаивающие вычислительные ядра GPU. По этой причине они не усиливают друг друга, а вступают в прямую конкуренцию.

Спекуляция расходует резервы видеокарты на формирование предположительных токенов, часть из которых неизбежно уходит в мусор. Когда сервер обрабатывает один запрос, эти затраты бесплатны: ядра GPU всё равно бы простаивали в ожидании чтения весов из памяти. Потоковый батчинг расходует тот же самый потенциал на расчет реальных токенов других пользователей. При 8 параллельных запросах веса модели считываются из памяти один раз для всей группы, и за один проход рассчитывается 8 полезных токенов без ненужных отбросов.

Как только батч полностью загружает вычислительные блоки видеокарты, узкое место системы смещается из памяти в вычисления (compute-bound). В этот момент выброшенные черновые токены перестают быть «бесплатными» — они напрямую отнимают такты процессора у полезной работы. Это и приводит к появлению «полки» на графике и последующему падению общей производительности.

Данное поведение не является дефектом реализации DFlash, это фундаментальное ограничение технологии. Разработчики продакшен-систем знают об этом свойстве: современные фреймворки автоматически отключают спекулятивное декодирование при превышении порога параллельной нагрузки (обычно в районе 32 активных сессий).

На моем стенде падение произошло существенно раньше (уже на 4 запросах) из-за разницы в оборудовании и софте: одна потребительская/профессиональная карта вместо кластера из 8 ускорителей B300 и сервер llama.cpp вместо специализированного TensorRT-LLM. Это наглядно доказало, что коэффициенты из официальных презентаций нельзя слепо экстраполировать на собственную инфраструктуру.

Зависимость эффективности от типа задач: математика, код и проза

Эффективность DFlash сильно зависит от предметной области и структуры генерируемого текста. Я провел отдельную серию тестов на одиночном запросе с длительностью 1024 токена и максимальным размером черновика до 15 токенов, а также добавил для сравнения режим MTP (Multi-Token Prediction).

Результаты наглядно показывают: на математических расчетах прирост составил 1,62x, на коде — 1,34x, а на связном тексте (прозе) ускорение упало до 0,95x. То есть при работе со свободной речь DFlash начинает замедлять генерацию. Режим MTP показал себя еще хуже, продемонстрировав отставание от базы почти во всех сценариях.

Также эти замеры объясняют, почему при --spec-draft-n-max 15 средний результат составил всего 1,30x против 2,31x в предыдущем тесте. Оказывается, установка слишком длинного черновика снижает итоговую скорость: при n-max=4 тот же тест выбивал 330,6 ток/с. Чем длиннее запрашиваемый блок, тем больше вычислений теряется при первой же ошибке драфтера.

Логика процесса проста: черновая модель работает эффективно только при низкой энтропии текста. В коде и математике структура ответов строго регламентирована синтаксисом и шаблонами. В художественной прозе на каждом шаге существуют десятки логичных вариантов продолжения фраз. Черновик ошибается уже на 2–3 токене, весь сформированный блок отбрасывается, а видеокарта платит за его просчет впустую. Ситуацию с русским языком дополнительно усложняет токенизация: из-за дробления слов на мелкие субтокены длинная цепочка становится еще менее предсказуемой.

Вендорские бенчмарки (Math500, GSM8K, HumanEval) построены на максимально предсказуемых датасетах. Даже по собственным признаниям Nvidia, на творческих задачах их показатель ускорения снижается с 2,6x до 1,8x.

Влияние квантования KV-кеша на базовую скорость

Во время отладки параметров я выявил еще один фактор, влияющий на итоговую производительность инференса. Для экономии видеопамяти при длинном контексте в настройках изначально использую квантованный KV-кеш (--cache-type-k/v q4_0).

Переключение KV-кеша в несжатый формат f16 дало мгновенный прирост базовой скорости со 189 до 263,1 ток/с — это +39% к производительности без применения каких-либо черновых моделей и спекулятивных методов. На 8 параллельных запросах суммарный поток вырос с 784 до 917 токенов в секунду.

Разумеется, платой за такой прирост становится увеличение расхода памяти кеша в 4 раза. Однако этот эксперимент наглядно демонстрирует: прежде чем усложнять архитектуру внедрением спекулятивного декодирования, стоит убедиться, что базовая конфигурация инференса выжата на максимум. На квантованном кеше `q4_0` лучшая конфигурация DFlash показывала прирост 1,75x к базе, а на полновесном кеше `f16` тот же DFlash давал уже лишь 1,35x.

Итоговые результаты и практические рекомендации

DFlash представляет собой качественное инженерное решение для узкого спектра задач, а не универсальную «серебряную пулю» для любого сервера. Технология полностью оправдывает себя там, где приоритетом является минимальная задержка для одного активного пользователя:

• Локальный запуск моделей на персональных рабочих станциях;
• Автодополнение кода и плагины для IDE;
• Голосовые ассистенты и агенты, вызывающие внешние инструменты в режиме реального времени.

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

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

Главный практический вывод: производительность спекулятивных методов необходимо замерять лично на собственном стеке, конкретном оборудовании, используемом языке и реальном профиле нагрузки.

Опыт построения эффективного инференса

На практике при проектировании высоконагруженных сервисов ставка делается на полный контроль над стеком, а не на спекулятивные надстройки. Например, при оптимизации работы собственной модели Grom 1.5 мы задействовали комплексный подход: интеллектуальное распределение запросов балансировщиком по специализированным пулам, удержание частых префиксов в памяти GPU и точный подбор размера модели под целевые ускорители. Это позволило получить отклик до первого токена в пределах 500 мс и стабильную генерацию до 120 ток/с на поток без использования нестабильных спекулятивных драфтеров.

Запуск цифрового рубля в России

В качестве дополнения к новостной повестке в сфере технологий: Банк России установил официальные сроки полноценного запуска цифрового рубля. С 1 сентября 2026 года новая форма национальной валюты становится официально доступна для граждан и юридических лиц. Цифровой рубль выступает третьей формой денег наряду с привычными наличными и безналичными средствами, а его эмиссией и обслуживанием инфраструктуры занимается непосредственно ЦБ РФ.

Источник: habr.com