MTP для Ling-3.0-Flash на DGX Spark: почему увеличение длины черновика не всегда ускоряет генерацию

По заявленному описанию эксперимента на одном DGX Spark с 128 ГБ памяти режим n=1 оказался быстрее n=2 и n=3 при генерации обычного текста. Для кода разница между тремя настройками оставалась небольшой. Сам по себе более длинный черновик MTP не гарантирует лучший throughput.

Причина связана с балансом между числом принятых токенов и стоимостью подготовки и проверки черновика. Если дополнительные кандидаты принимаются редко или требуют слишком много вычислений, рост acceptance length может не компенсировать накладные расходы.

Точные значения в tokens/s, acceptance length, доли принятых токенов, длины контекста и параметров программного стека в доступном описании отсутствуют. Поэтому ниже приведены подтвержденные качественные выводы, а незаполненные метрики прямо помечены как требующие проверки по первичному отчету.

Короткий ответ: почему n=1 может быть быстрее n=2 и n=3

Режим n=1 может выигрывать у более длинных вариантов, когда дополнительный шаг черновика дает слишком мало полезных принятых токенов. Основная модель в таком случае получает больше работы, а итоговый прирост числа токенов за один цикл остается небольшим.

Для обычного текста в описанной серии измерений зафиксирован именно такой порядок: n=1 быстрее n=2 и n=3. Для кода скорость всех трех режимов находилась примерно на одном уровне. Это вывод конкретного сравнения на одной системе, а не универсальное правило для любой модели, видеокарты или нагрузки.

Главный вывод эксперимента в одной таблице

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

Режим	CUDA Graphs	MTP	Обычный текст	Код	Acceptance length	Доля принятых токенов
Без MTP	Не указано	Выключен	Точное значение скорости не представлено	Точное значение скорости не представлено	Нет данных	Нет данных
n=1	Не указано	Включен, n=1	Быстрее n=2 и n=3 по заявленному описанию	Примерно тот же уровень, что у n=2 и n=3	Нет данных	Нет данных
n=2	Не указано	Включен, n=2	Медленнее n=1 по заявленному описанию	Примерно тот же уровень, что у n=1 и n=3	Нет данных	Нет данных
n=3	Не указано	Включен, n=3	Медленнее n=1 по заявленному описанию	Примерно тот же уровень, что у n=1 и n=2	Нет данных	Нет данных

Для каждой числовой метрики требуется первичная таблица измерений. Без нее нельзя честно указать, на сколько процентов один режим быстрее другого, какой вариант получил максимальный acceptance length и совпадает ли лидер по этой метрике с лидером по throughput.

Что этот результат не доказывает

• n=1 не становится лучшей настройкой для всех моделей и всех задач.
• Преимущество n=1 над n=2 и n=3 на прозе не доказывает, что MTP в целом замедляет генерацию.
• Близкая скорость на коде не означает одинаковое поведение для разных языков программирования, размеров файлов и длин контекста.
• Без полной матрицы запуска нельзя приписать весь результат MTP. На throughput могли повлиять CUDA Graphs, длина вывода, warm-up, способ замера и другие параметры.
• Из качественного порядка скоростей нельзя восстановить значения acceptance length и доли принятых токенов.

MTP для Ling-3.0-Flash на DGX Spark: что именно сравнивали

Эксперимент посвящен генерации Ling-3.0-Flash на одной системе DGX Spark с 128 ГБ памяти. Сравнение должно показать, как меняется скорость при включении MTP с разной длиной черновика, а раздельное включение CUDA Graphs и speculative decoding помогает не смешивать два разных источника ускорения.

Одна система с 128 ГБ памяти: почему это важно для интерпретации

Аппаратная платформа входит в условия теста. Память, пропускная способность, версия драйвера, поддержка конкретных CUDA-операций и поведение рантайма могут изменить баланс между основной моделью и MTP.

В этом случае известны только модель, DGX Spark и объем памяти 128 ГБ. Версии драйвера, CUDA, инференс-движка, параметры квантизации, частоты, энергопотребление и режимы распределения памяти в доступном описании не указаны. Добавлять такие характеристики в отчет нельзя.

Сравнение с другими локальными системами требует одинакового подхода к методике. В разборе практических результатов на DGX Spark отдельно объясняется, почему пиковая скорость не заменяет p50 и p95, а длина контекста и режим генерации меняют задержку.

Четыре режима: без MTP, n=1, n=2 и n=3

Базовая точка, режим без MTP, нужна для ответа на главный практический вопрос: дает ли speculative decoding реальное ускорение относительно обычного decode. Без этой строки можно сравнить три варианта MTP между собой, но нельзя точно оценить общий эффект механизма.

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

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

Какие условия замера нужно раскрыть

Для воспроизводимого сравнения нужны следующие поля:

• точная версия Ling-3.0-Flash и формат весов;
• версия инференс-движка, CUDA, драйвера и связанных библиотек;
• состояние CUDA Graphs в каждой строке сравнения;
• способ включения MTP и точное значение параметра n;
• длина входного контекста и целевая длина вывода;
• набор запросов для обычного текста и набор запросов для кода;
• число прогревочных запусков и число измеряемых повторов;
• включено ли время prefill в итоговую скорость;
• считается ли throughput по одному запросу или по серии запросов;
• среднее значение, медиана, p50, p95 и разброс результатов;
• определение acceptance length и доли принятых токенов.

Подход к фиксации prefill и decode подробно важен и для других локальных тестов. В методике сравнения локального запуска Qwen отдельно разводятся prefill, decode и параметры теста. Такой же принцип нужен для Ling-3.0-Flash.

Как MTP влияет на скорость генерации

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

Черновик и проверка основной моделью

При обычном decode модель получает уже сгенерированный контекст и последовательно выбирает следующий токен. MTP добавляет прогноз вперед. Черновик может предложить несколько продолжений, а основная модель проверяет их в рамках своего шага.

Ускорение появляется, когда число принятых токенов за цикл превышает стоимость подготовки черновика и дополнительной проверки. Формула в упрощенном виде выглядит так: итоговый throughput зависит от количества принятых токенов, времени подготовки кандидатов, времени проверки и накладных расходов самого рантайма.

Длина черновика задает потенциальный размер шага. Она не сообщает, сколько токенов реально попадет в итоговый ответ. При n=3 можно предложить три позиции и принять одну, две или три. Чем больше неиспользованных кандидатов, тем слабее связь между теоретической длиной черновика и фактическим ускорением.

Acceptance length и доля принятых токенов: это не одно и то же

Acceptance length показывает среднее число принятых токенов за один цикл или шаг, если именно так эту метрику определяет используемый рантайм. Это абсолютная величина.

Доля принятых токенов показывает отношение принятых токенов к числу предложенных. В упрощенном виде она рассчитывается как accepted / proposed. Это относительная величина.

Условный пример: если черновик предложил три токена, а основная модель приняла два, acceptance length для этого цикла равен двум, а доля принятия составляет два токена из трех. Пример объясняет разницу между метриками и не относится к измерениям Ling-3.0-Flash.

При разной длине черновика одна и та же доля принятия может давать разный acceptance length. Например, принятие двух токенов из двух и принятие трех токенов из трех дают максимальную долю, но второй вариант продвигает генерацию дальше за один цикл. Итоговая скорость все равно зависит от времени, которое потребовалось для получения этих токенов.

Сравнение DFlash, MTP, EAGLE3 и ngram на другой модели хорошо показывает, почему методику нельзя переносить механически между системами. В отдельном бенчмарке speculative decoding результаты различались в зависимости от метода, движка и типа задачи. Эти цифры не подтверждают поведение Ling-3.0-Flash, но показывают необходимость сравнивать несколько метрик.

Почему длинный черновик может не окупиться

Увеличение n добавляет потенциальные позиции для принятия. Одновременно растут затраты на подготовку и проверку черновика. Если дополнительные позиции часто отклоняются, пользователь получает больше вычислений без пропорционального увеличения числа итоговых токенов.

Для результата n=1 быстрее n=2 и n=3 возможны несколько объяснений:

• дополнительные позиции в старших режимах принимались недостаточно часто;
• проверка более длинного черновика создавала заметные накладные расходы;
• CUDA Graphs и другие настройки могли по-разному работать при разных формах вычислений;
• характер прозаических запросов не позволял длинному черновику стабильно предсказывать продолжение;
• замер мог учитывать не только decode, но и другие этапы работы.

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

CUDA Graphs и speculative decoding через MTP: как разделить эффект оптимизаций

CUDA Graphs и MTP решают разные задачи. CUDA Graphs сокращают накладные расходы запуска повторяющихся операций на GPU, а MTP меняет схему получения следующих токенов. Совместное включение может дать результат, который нельзя честно приписать одному механизму.

Что дает отдельное включение CUDA Graphs

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

Для decode это особенно чувствительно, потому что отдельный шаг генерации может быть небольшим, а накладные расходы запуска операций заметны относительно полезной работы. MTP меняет количество токенов и форму вычислительного шага, поэтому графы могут вести себя по-разному при n=1, n=2 и n=3.

В разборе CUDA capture на другой модели показано, почему результаты на prefill и decode нужно разделять. Этот материал дает технический контекст, но не заменяет замеры Ling-3.0-Flash на DGX Spark.

Почему MTP нужно сравнивать с одинаковой базой

Корректное сравнение меняет один фактор за раз или использует полную факторную матрицу. В минимальном варианте нужны такие строки:

• без MTP и без CUDA Graphs;
• без MTP, но с CUDA Graphs;
• MTP с n=1 при тех же настройках CUDA Graphs;
• MTP с n=2 при тех же настройках CUDA Graphs;
• MTP с n=3 при тех же настройках CUDA Graphs.

Если в эксперименте присутствуют только часть этих вариантов, выводы должны соответствовать фактической матрице. Например, сравнение n=1, n=2 и n=3 при включенных CUDA Graphs показывает порядок этих трех режимов, но не дает полного ответа о самостоятельном эффекте графов.

Как читать итоговую матрицу конфигураций

Конфигурация	CUDA Graphs	MTP	Что нужно сравнить	Статус по доступному описанию
Базовый режим	Нужно указать	Выключен	Скорость текста и кода	Числовых значений нет
CUDA Graphs без MTP	Включены	Выключен	Разница с базовым режимом	Отдельная строка не подтверждена
MTP n=1	Нужно указать	Включен	Throughput, acceptance length, доля принятия	Качественный лидер на обычном тексте
MTP n=2	Нужно указать	Включен	Те же метрики	Медленнее n=1 на обычном тексте
MTP n=3	Нужно указать	Включен	Те же метрики	Медленнее n=1 на обычном тексте

Полной факторной матрицы в доступных материалах нет. Поэтому нельзя утверждать, какая часть результата относится к CUDA Graphs, какая к MTP, а какая к их сочетанию.

Ling-3.0-Flash MTP: результаты для обычного текста

Обычный текст дает главный качественный результат эксперимента. Режим n=1 показал более высокую скорость генерации, чем n=2 и n=3. Это наблюдение нужно читать вместе с отсутствием числовых значений и подробностей о запросах.

Сравнение базового режима, n=1, n=2 и n=3

Режим	Throughput	Acceptance length	Доля принятых токенов	Что можно сказать
Без MTP	Не опубликован	Не применимо или не указано	Не указана	Нужен как базовая точка, но числовое сравнение отсутствует
n=1	Точное значение отсутствует	Не указано	Не указана	Быстрее n=2 и n=3 по заявленному описанию
n=2	Точное значение отсутствует	Не указано	Не указана	Медленнее n=1 по заявленному описанию
n=3	Точное значение отсутствует	Не указано	Не указана	Медленнее n=1 по заявленному описанию

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

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

Самая осторожная интерпретация звучит так: дополнительные позиции черновика в этой прозаической нагрузке не окупили свои вычислительные затраты. Такая формулировка согласуется с результатом, но не заменяет профилирование.

Чтобы подтвердить причину, нужно сопоставить для каждого n четыре величины:

• время подготовки черновика;
• время проверки основной моделью;
• среднее количество принятых токенов за цикл;
• итоговый throughput после учета всех накладных расходов.

Если acceptance length растет вместе с n, а throughput снижается, длинный черновик все равно может быть невыгодным. В таком случае скорость теряется на вычислениях, которые не превращаются в принятые токены.

Acceptance length против итогового throughput

В заявленном результате лидер по скорости на обычном тексте, n=1, определен качественно. Лидер по acceptance length не указан. Поэтому нельзя проверить, совпадают ли эти два лидера.

Это ограничение важно для интерпретации. Более высокий acceptance length может сопровождаться меньшим throughput, если каждый цикл с длинным черновиком занимает слишком много времени. Для выбора настройки нужна таблица, где обе метрики находятся рядом, а не одна усредненная оценка.

Практическое правило простое: acceptance length помогает понять работу speculative decoding, а throughput показывает пользовательский результат. При сервисе с жестким ограничением задержки нужно дополнительно смотреть p50 и p95, а при потоковой генерации учитывать скорость после прогрева.

Генерация кода: почему n=1, n=2 и n=3 дают близкую скорость

На кодовой нагрузке заявленная картина отличается от обычного текста. Скорость генерации для n=1, n=2 и n=3 оставалась примерно на одном уровне. Это означает, что увеличение длины черновика в выбранной серии не дало заметного преимущества, но и не создало такого разрыва, как на прозе.

Таблица результатов для кода

Режим	Throughput	Acceptance length	Доля принятых токенов	Условия запроса
Без MTP	Точное значение отсутствует	Не указано	Не указана	Тип и длина запроса не раскрыты
n=1	Примерно тот же уровень, что у n=2 и n=3	Не указано	Не указана	Подробности набора запросов отсутствуют
n=2	Примерно тот же уровень, что у n=1 и n=3	Не указано	Не указана	Подробности набора запросов отсутствуют
n=3	Примерно тот же уровень, что у n=1 и n=2	Не указано	Не указана	Подробности набора запросов отсутствуют

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

Что можно и чего нельзя заключить из близких результатов

Из серии измерений можно заключить, что на выбранных кодовых запросах разница между n=1, n=2 и n=3 была небольшой. Нельзя заключить, что MTP бесполезен для программного кода или что все языки программирования покажут одинаковый результат.

На поведение speculative decoding могут влиять структура кода, повторяемость шаблонов, наличие отступов, длина идентификаторов, комментарии и частота смены синтаксических конструкций. Это рабочие гипотезы для дополнительных тестов. Доступное описание эксперимента не содержит профилирования, которое позволило бы выбрать конкретную причину.

Почему нагрузку нужно делить на классы

Один средний показатель может скрыть противоположные результаты. На прозе n=1 оказался быстрее старших режимов, а на коде три значения остались близкими. Если объединить эти наборы запросов, итоговое среднее потеряет практический смысл.

Минимальный набор классов для локального бенчмарка:

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

Для каждого класса нужно сохранять одинаковые входы и сравнивать базовый режим с n=1, n=2 и n=3. Это позволит увидеть настройку, которая подходит конкретному рабочему процессу.

Как выбрать n для собственной нагрузки

Результат Ling-3.0-Flash на DGX Spark дает полезную стартовую точку, но не готовую универсальную настройку. Выбор n нужно привязывать к типу запросов и метрике, которая действительно важна для сервиса.

Когда начинать с n=1

Для обычного текста в конфигурации из описанного эксперимента разумно начать с n=1. Этот режим показал лучший качественный результат по скорости среди трех вариантов MTP.

Такая отправная точка не отменяет проверки базового режима без MTP. Если сравнение с baseline отсутствует, нельзя определить, дает ли n=1 абсолютное ускорение или только лучше работает среди трех вариантов speculative decoding.

Для кода сразу выбирать n=1 по результатам прозы не следует. Заявленная скорость трех режимов была близкой, поэтому выбор нужно делать по фактической задержке, стабильности и поведению на собственных запросах.

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

Acceptance length показывает, сколько токенов в среднем удалось принять за цикл. Пользователь видит другую величину: время до первого токена, скорость потока и общую длительность ответа.

Нужно одновременно сравнивать:

• throughput в tokens/s;
• время до первого токена;
• полную задержку ответа;
• p50 и p95 для серии запусков;
• acceptance length;
• долю принятых токенов;
• потребление памяти и стабильность работы.

Для интерактивного чата может быть важнее задержка первого токена. Для длинной генерации кода или документов обычно полезнее устойчивый decode throughput. Для сервиса с несколькими пользователями нужно отдельно проверить поведение при параллельных запросах.

Минимальная проверка перед внедрением

1. Зафиксируйте одну версию модели и один программный стек.
2. Оставьте неизменной аппаратную систему, параметры памяти и длину контекста.
3. Подготовьте отдельные наборы обычного текста и кода.
4. Выполните прогрев перед замером и зафиксируйте число прогревочных запусков.
5. Сравните базовый режим без MTP с n=1, n=2 и n=3.
6. Повторите каждый тест несколько раз и сохраните среднее, медиану и разброс.
7. Запишите throughput, задержку, acceptance length и долю принятых токенов.
8. Отдельно укажите, включены ли CUDA Graphs и входит ли prefill в итоговый показатель.

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

Ограничения измерений и что нужно подтвердить по первичному источнику

Описанный эксперимент полезен как наблюдение за конкретной конфигурацией: Ling-3.0-Flash, один DGX Spark и 128 ГБ памяти. Его нельзя использовать как доказательство того, что конкретное значение n всегда лучше остальных.

Одна DGX Spark не заменяет серию независимых тестов

Одна система исключает сравнение аппаратных платформ, но одновременно ограничивает переносимость вывода. Другая версия драйвера, другой рантайм, иная квантизация или другой объем доступной памяти могут изменить соотношение между стоимостью MTP и выигрышем от принятых токенов.

Даже на той же модели результат может измениться при другой длине входа, другом размере ответа и ином соотношении запросов. Параллельная обработка пользователей создаст еще одну нагрузку, которую одиночный stream не описывает.

Каких данных не хватает для полной проверки

Перед публикацией нужно подтвердить по первичному отчету:

• точные значения скорости для базового режима, n=1, n=2 и n=3;
• отдельные результаты для обычного текста и кода;
• acceptance length и долю принятых токенов для каждой строки;
• длину входного контекста и длину вывода;
• состав и количество запросов;
• число прогревочных и измеряемых запусков;
• версии модели, драйвера, CUDA и инференс-движка;
• точную схему включения CUDA Graphs;
• параметры MTP и определение значения n;
• правило расчета throughput и включение или исключение prefill.

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

Итог: измерять нужно собственную рабочую нагрузку

MTP может ускорить генерацию, но увеличение длины черновика не гарантирует максимальный результат. В заявленном эксперименте на обычном тексте предпочтительнее выглядел n=1, а на коде n=1, n=2 и n=3 показали близкую скорость.

Практический вывод: начните с n=1 для прозаических запросов, сравните его с базовым режимом и проверьте старшие значения на своих данных. В итоговой таблице обязательно держите рядом throughput, задержку, acceptance length и долю принятых токенов. Только такое сравнение покажет, окупается ли более длинный черновик именно в вашем сценарии.

Подписаться на канал