DFlash2 - драфтер для спекулятивного декодирования, и llama.cpp v0.8.0 стала первым релизом с его поддержкой для Qwen3.8-Flash-Next. Практический отчёт одного пользователя на Apple Silicon M5 Max показывает: после подбора параметров DFlash2 обгоняет MTP на 17% по геометрическому среднему (87,9 против 75,1 tok/s), на списках прирост 39%, на коде 18%, на контексте 6K 19%, а на свободной прозе минус 3%, что автор относит к шуму.
Короткий ответ на главный вопрос: переходить стоит, если вы генерируете код, списки, JSON и другой структурированный вывод на коротких и средних промптах. На прозе и на длинном контексте около 25K выигрыша нет. Все цифры ниже взяты из одного отчёта на одной конфигурации, а не из официального бенчмарка, и это ограничение важнее самих процентов.
Что такое DFlash2 и зачем он нужен Qwen3.8-Flash-Next
DFlash2 не заменяет целевую модель. Это отдельная небольшая модель-драфтер, которую подключают к Qwen3.8-Flash-Next, чтобы ускорить выдачу токенов. MTP решает ту же задачу другим способом: прогнозирует несколько токенов внутри самой модели. Цель у обоих вариантов одна - меньше проходов по большой модели на каждый выданный токен.
Поддержка DFlash2 для Flash-Next появилась в llama.cpp v0.8.0. Автор отчёта квантовал собственные GGUF драфтера и прогнал их на M5 Max, сравнив с MTP-головой, которая была в работе до этого (отчёт на r/LocalLLaMA).
Speculative decoding в llama.cpp: как драфтер ускоряет генерацию
Схема простая. Драфтер смотрит на уже сгенерированный текст и предлагает несколько следующих токенов. Целевая модель проверяет всю цепочку за один проход и принимает ту часть, которая совпадает с её распределением. Принятые токены уходят в вывод, первое расхождение отбрасывается, и цикл повторяется.
Выигрыш берётся из асимметрии: генерация на Apple Silicon упирается в пропускную способность памяти, поэтому проверка пяти токенов стоит почти столько же, сколько проверка одного. Угадал драфтер - получили несколько токенов по цене одного прохода. Не угадал - заплатили за холостую проверку.
Поведение драфтера задают два параметра. n-max ограничивает длину цепочки: слишком большое значение заставляет драфтер тратить compute на хвосты, которые целевая модель всё равно отклонит, слишком маленькое обрезает выигрыш. p-min задаёт порог вероятности, ниже которого предложение не рассматривается. Насколько неочевидна связь длины черновика и итоговой скорости, видно на другом железе и другой модели: в разборе MTP для Ling-3.0-Flash на DGX Spark режим n=1 оказался быстрее n=2 и n=3 на обычном тексте.
Acceptance rate: главная метрика, но не единственная
Acceptance rate - доля токенов, предложенных драфтером, которые целевая модель приняла. Метрика показывает, насколько хорошо драфтер подстроился под распределение целевой модели.
Соблазн считать её главным показателем ломается о цифры из отчёта. На коде MTP выдал 80,5 tok/s при acceptance 94%, а DFlash2 - 95,1 tok/s при 84%. Точность ниже, скорость выше на 18%.
Итоговая скорость складывается из стоимости одного шага драфтера, средней длины принятой цепочки, числа отклонений и накладных расходов на верификацию. Драфтер с более низким acceptance может предлагать более длинные цепочки и делать это дешевле. Поэтому acceptance читают вместе с tok/s, а не вместо них.
Результаты перехода с MTP на DFlash2: +17% в среднем и +39% на списках
Замеры на M5 Max после свипа параметров дали такую картину:
| Промпт | MTP, tok/s (acceptance) | DFlash2, tok/s (acceptance) | Разница |
|---|---|---|---|
| Код | 80,5 (94%) | 95,1 (84%) | +18% |
| Списки | 91,4 (98%) | 127 (98%) | +39% |
| Контекст 6K | 80,2 (97%) | 95,3 (90%) | +19% |
| Проза | 53,8 (78%) | 51,9 (64%) | -3% |
| Геометрическое среднее | 75,1 | 87,9 | +17% |
Автор отчёта называет DFlash2 заметным улучшением скорости декодирования для всех типов промптов, кроме прозы, где регрессия мала и лежит в пределах шума (сводная таблица замеров).
Почему списки дают максимальный прирост
Списки, таблицы и JSON структурно предсказуемы: после маркера следующий токен часто определяется форматом, а не смыслом. Acceptance здесь одинаковый - 98% у обоих драфтеров, но DFlash2 успевает проверить более длинные цепочки: в оптимальных настройках у него n-max = 5 против n-max = 3 у MTP. Одинаковая точность при большей длине черновика даёт 91,4 → 127 tok/s, то есть +39%.
На практике это те задачи, где вывод жёстко ограничен форматом: маркированные списки, таблицы сравнения, ответы по схеме, кодогенерация в готовый шаблон.
Код: прирост есть, но acceptance ниже
Код дал 80,5 tok/s у MTP против 95,1 tok/s у DFlash2, прирост 18%, при падении acceptance с 94% до 84%. В коде больше развилок, где следующий токен не предопределён формой, поэтому драфтер чаще промахивается. Это тот самый случай, когда метрика точности и метрика скорости расходятся, и ориентироваться нужно на вторую.
Один промпт с кодом не гарантирует таких же 18% на всём репозитории. Прогоните несколько своих файлов: в плотном коде с редкими именами переменных и нестандартными API acceptance обычно ниже, чем на учебных примерах.
Как воспроизвести замеры: параметры, методика и подводные камни
Методика отчёта: сначала обширный свип параметров отдельно для MTP и отдельно для DFlash2, затем финальные прогоны с лучшими значениями. Найденные оптимумы на Apple Silicon M5 Max: для MTP n-max = 3 и p-min = 0,75, для DFlash2 n-max = 5 и p-min = 0,75.
Эти значения привязаны к конкретному железу и набору промптов. Похожая история с цифрами на других Mac: заявленные 45 tok/s на M4 Max и 25 tok/s на M2 Ultra для Qwen3.8-Flash-Next-oQ4e-mtp на Apple Silicon пока нельзя считать подтверждённым бенчмарком, и это хороший пример того, почему чужой tok/s плохо переносится на свой сетап.
Свип n-max и p-min: зачем он нужен и как его делать
n-max растёт до тех пор, пока прирост от более длинных цепочек перекрывает стоимость их проверки. p-min отсекает маловероятные предложения: слишком высокий порог оставляет драфтеру только очевидные токены и снижает выигрыш, слишком низкий добавляет мусор в верификацию.
Практическая процедура:
- зафиксировать набор промптов (код, список, проза, длинный контекст) и не менять их между прогонами;
- менять один параметр за раз, начиная с n-max при фиксированном p-min;
- на каждом значении делать несколько прогонов и смотреть на разброс, а не на единственный замер;
- писать в таблицу и tok/s, и acceptance: одно без другого плохо объясняет результат.
Сетку значений, по которой шёл свип в отчёте, автор не приводит. Отправная точка - найденные им оптимумы, от них двигайтесь по одному шагу в обе стороны и останавливайтесь там, где tok/s перестаёт расти.
Память и квантование драфт-головы: 350 МБ против 2,2 ГБ, но VRAM не экономится
Драфт-голова DFlash2 в Q4_0 занимает около 350 МБ. У Q4_0 ggml MTP-головы, которая была в работе до перехода, - 2,2 ГБ. Разница в шесть раз по файлу, и на этом экономия заканчивается.
На VRAM она не переносится: compute-буфер, нужный DFlash2, примерно компенсирует разницу (детали по памяти драфтеров). Рассчитывать, что переход освободит память под более длинный контекст или более крупную целевую модель, не стоит. Выигрыш здесь в скорости декодирования.
Квантование драфт-головы выбирают по остаточному принципу. Сравнение Q4_0 и Q8_0 у DFlash2 не показало измеримой разницы ни по скорости, ни по acceptance, поэтому автор отчёта советует Q4_0 ради экономии места. Логика та же, что при выборе кванта основной модели: драфтер ошибается мягко, его задача - угадать направление, а не выдать финальный текст. Как квантование влияет на скорость и качество самой Qwen3.8-27B MTP на M5 Max, разобрано отдельно.
Длинный контекст (25K): где DFlash2 перестаёт выигрывать
На контексте 6K DFlash2 дал 95,3 tok/s против 80,2 у MTP при acceptance 90% и 97% соответственно, это +19%. На 25K картина меняется: DFlash2 примерно сравнивается с MTP, а MTP держится почти ровно, тогда как у DFlash2 заметен спад относительно коротких контекстов.
С ростом контекста растёт стоимость верификации и падает предсказуемость продолжения. Драфтер, который хорошо работал на 6K, на 25K чаще промахивается, а его накладные расходы остаются. MTP в этой точке ведёт себя стабильнее.
Практический вывод: для чатов, генерации кода и структурированного вывода на коротких и средних промптах DFlash2 интересен. Для работы с длинными документами, где основные запросы идут на 25K и больше, выигрыша ждать не стоит. Промежуточных точек между 6K и 25K в отчёте нет, поэтому где именно преимущество исчезает, по этим данным не определить.
Изображения работают: vision в DFlash2 для Flash-Next
Отдельное отличие от DFlash2 для версии 27B: в конфигурации для Flash-Next изображения не ломаются. Драфтер учитывает vision, тестовые промпты с картинками прошли и дали связные ответы с хорошим acceptance. У DFlash2 для 27B картинки не работают.
Формулировка осторожная: это единичная проверка одного пользователя на нескольких промптах, а не систематический бенчмарк мультимодальности. Ни числа промптов, ни метрик качества в отчёте нет. Если в работе есть скриншоты, схемы или страницы PDF, проверьте свой сценарий отдельно: связный ответ на тестовой картинке не доказывает, что драфтер не испортит сложный визуальный запрос.
Ограничения выводов: один пользователь, одна конфигурация
Все цифры выше - из одного отчёта, снятого на Apple Silicon M5 Max в llama.cpp v0.8.0, на своём наборе промптов. Автор прямо оговаривает, что у других пользователей настройки, скорее всего, будут другими.
- Геометрическое среднее по нескольким промптам - не репрезентативная выборка. Оно удобно как сводка, но не как прогноз для вашей нагрузки.
- Падение на прозе (-3%) автор относит к шуму. Значит, знак эффекта надёжно не установлен: на другом наборе прозаических промптов разница может оказаться нулевой или положительной.
- Оптимумы n-max и p-min найдены на этом железе и этих промптах. Переносить их на NVIDIA, другую модель или другую сборку llama.cpp без проверки нельзя.
- Отсутствие разницы между Q4_0 и Q8_0 - результат замеров автора, а не гарантия для любой нагрузки.
- Работа с изображениями подтверждена тестовыми промптами, а не набором задач с известными ответами.
- Результаты привязаны к версии llama.cpp: в следующих релизах поведение драфтера может измениться.
Отчёт не стоит игнорировать. Один аккуратный замер с указанием модели, версии, параметров и acceptance полезнее сводки без методики. Строить на нём категоричные рекомендации для всего парка железа нельзя.
Стоит ли переходить: практический чек-лист
Сценарии:
- Генерация кода, списков, таблиц, JSON - переход вероятно оправдан, ориентир +18% и +39% в отчёте.
- Свободная проза, письма, тексты - выигрыша нет, возможен небольшой минус.
- Длинный контекст 25K и больше - паритет с MTP, смысл переходить теряется.
- Мультимодальные промпты - работает, но проверять на своих картинках.
- Ограниченная память - облегчения по VRAM не будет.
Шаги:
- Обновиться до llama.cpp v0.8.0 или более новой версии с поддержкой DFlash2.
- Взять драфт-голову DFlash2 в Q4_0: разницы с Q8_0 в отчёте не нашлось, а места Q4_0 занимает меньше.
- Подобрать n-max и p-min свипом на своих промптах, отталкиваясь от значений из отчёта (3 и 0,75 для MTP, 5 и 0,75 для DFlash2).
- Замерить tok/s и acceptance на одинаковых промптах в одинаковых условиях для MTP и DFlash2.
- Сравнить на своих задачах не только скорость, но и качество: ускорение декодирования не компенсирует испорченный ответ.
Если вы ещё выбираете, на чём гонять Qwen 3.8 локально, полезен разбор трёх квантов Qwen 3.8 на 16 ГБ VRAM на задачах AtCoder: там видно, как размер кванта и режим thinking effort меняют результат.
DFlash2 в llama.cpp v0.8.0 по данным одного отчёта даёт заметный прирост на структурированных промптах у пользователей Apple Silicon. На прозе и длинном контексте выигрыша нет. Решение принимается после собственного замера, а не по чужому геометрическому среднему.