Почему MTP может замедлять Gemma 4 12B QAT на Vulkan и как ROCm меняет результат

Короткий ответ: MTP ускоряет не любую генерацию

Если Gemma 4 12B QAT на Vulkan генерирует медленнее с включённым MTP, это ещё не указывает на проблему самой модели или квантования. MTP приносит пользу, когда число принятых прогнозных токенов компенсирует расходы на их подготовку, проверку, копирование буферов и синхронизацию.

В описываемом кейсе переход с Vulkan на ROCm дал заметный прирост скорости. Такой результат указывает на возможное узкое место в GPU-backend, inference-сервере или работе с памятью. Окончательный вывод требует контролируемого сравнения: одинаковые GPU, веса, prompt, длина контекста, batch size, параметры генерации, версии драйвера и runtime.

Независимых замеров именно для Gemma 4 12B QAT в связке Vulkan и ROCm с MTP в доступных материалах нет. Поэтому прирост после смены backend стоит воспринимать как наблюдение из исходного кейса, а причины объяснять проверяемыми гипотезами. Практический порядок такой: получить baseline без MTP, измерить MTP on/off, проверить логи и загрузку GPU, затем повторить тест на другом backend.

Зависимость результата от стека видна и в других локальных сценариях Gemma 4. Для одного из вариантов загрузки Gemma 4 12B требовался vLLM 0.26.0, а локальный запуск модели в целом чувствителен к доступной памяти и inference-движку. В описании архитектуры Gemma 4 12B фигурируют 48 dense layers без expert modules, словарь на 262 144 токена и окно контекста 256K. Эти характеристики увеличивают требования к поддержке операций и KV-cache.

Как MTP должен ускорять генерацию и где появляется overhead

MTP, Multi-Token Prediction, относится к семейству speculative decoding. Вместо последовательной генерации одного токена система пытается заранее подготовить несколько следующих токенов. Целевая модель затем проверяет прогноз и принимает его полностью или частично.

Упрощённо эффект можно описать так:

выигрыш = экономия на последовательных шагах - стоимость прогноза - стоимость проверки - копирования - синхронизация

Если прогнозы часто принимаются, за один цикл удаётся получить несколько токенов. Если они регулярно отклоняются, MTP добавляет работу и задержки. Поэтому сам факт включённого режима или высокая активность draft-этапа не доказывают ускорение.

Что именно сравнивается при MTP on/off

Сравнивать нужно несколько показателей. Один tokens/s не объясняет, где возникла потеря времени.

Например, MTP может поднять среднее число прогнозных токенов, но одновременно увеличить time to first token и стоимость каждого шага. В результате отдельные циклы выглядят продуктивнее, а итоговый ответ всё равно формируется дольше. В разборе бенчмарка MTP на Qwen3.6-27B хорошо виден общий принцип: результат меняется вместе с длиной контекста, числом запросов и типом нагрузки.

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

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

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

Длинный ответ создаёт больше возможностей для MTP, но универсального правила нет. Acceptance rate зависит от характера текста, sampling, длины контекста и конкретной реализации. Код, структурированный текст и естественный язык могут давать разный профиль принятия прогнозов.

Как QAT может менять профиль вычислений

QAT, quantization-aware training, связывает обучение модели с предполагаемым квантованным режимом работы. При инференсе скорость зависит от конкретного формата весов, поддерживаемых операций и kernels, которые доступны выбранному backend.

Квантованная модель не обязана показывать одинаковую скорость на Vulkan, ROCm и других стеках. Если backend не имеет эффективного пути для части операций, сервер может использовать менее быстрый kernel, разбивать вычисления на большее число запусков или переносить отдельные этапы на CPU.

Поэтому QAT нельзя оценивать отдельно от runtime. Файл модели задаёт данные для вычислений, а backend определяет, как именно эти вычисления выполняются на GPU.

Почему Vulkan может проигрывать ROCm на одной и той же задаче

Vulkan и ROCm используют разные пути исполнения, наборы GPU kernels, механизмы управления памятью и правила синхронизации. MTP усиливает разницу, потому что добавляет draft-этап, буферы прогнозов и зависимость между прогнозированием и проверкой.

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

Kernel support и стоимость запуска операций

Каждая операция MTP сама по себе может выглядеть недорогой, но большое число небольших запусков увеличивает суммарную задержку. Слабая поддержка квантованных вычислений, attention или KV-cache способна съесть выигрыш от принятых токенов.

Причины могут включать отсутствие fusion, менее эффективные kernels для отдельных форматов, дополнительные преобразования данных и частые kernel launches. Для диагностики полезно различать CUDA-подобные kernels, HIP-пути ROCm и Vulkan compute shaders, даже если inference-сервер скрывает детали в обычном логе.

Нельзя заранее утверждать, что именно одна из этих причин вызвала замедление Gemma 4 12B QAT на Vulkan. Подтверждение требует профиля операций, сообщений runtime и сравнения времени отдельных этапов.

Память, копирования и синхронизация между этапами

MTP связывает несколько этапов в одну цепочку. Draft-часть формирует прогноз, целевая модель его проверяет, после чего сервер обновляет состояние последовательности. Между этими этапами могут передаваться logits, токены, KV-данные и временные буферы.

Backend может по-разному обрабатывать очереди команд, барьеры, выделение памяти и копирование между буферами. При неудачной схеме GPU простаивает в ожидании предыдущей операции, хотя видеопамять занята.

Низкая вычислительная загрузка GPU при высокой задержке шага часто указывает на ожидание памяти, CPU или синхронизации. Рост latency между kernels и заметные паузы в профиле дают больше информации, чем один показатель VRAM.

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

ROCm мог дать прирост в конкретной конфигурации, но это не превращает его в универсально быстрый backend для любой модели и любой видеокарты. Сравнение может зависеть от GPU, драйвера, версии runtime, параметров сборки, серверного кода и поддержки конкретного формата квантования.

Если при переходе на ROCm одновременно менялись видеокарта, версия сервера или настройки памяти, результат нельзя приписать одному backend. Честная проверка требует сначала сравнить два стека на одном оборудовании, а затем отдельно исследовать влияние остальных компонентов.

Полезный ориентир для методики есть в разборе запуска крупной модели на одной RTX 5090: prefill, decode, warm-up, память и параметры сервера нужно разделять, иначе одна цифра скрывает источник разницы.

VRAM выросла, а генерация не ускорилась: как это объяснить

Занятая VRAM показывает объём размещённых данных. Она не показывает, насколько эффективно GPU обрабатывает kernels, какая пропускная способность памяти доступна в конкретный момент и сколько времени занимает синхронизация.

При MTP дополнительная память может уйти на KV-cache, прогнозные токены, временные буферы и резервирование. Эти расходы способны увеличить потребление VRAM без роста готовых токенов в секунду.

Контекст 256K и давление на KV-cache

Для Gemma 4 12B заявлено окно контекста 256K токенов. Это максимальная характеристика модели, а не обязательный объём для каждого запроса. Фактический расход памяти зависит от текущей длины prompt, числа последовательностей, batch size, формата KV-cache и настроек inference-сервера.

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

Большой context window полезен только при достаточном запасе памяти и корректной поддержке длинных последовательностей. Само наличие режима 256K не означает, что система будет одинаково быстрой на 4K, 32K и 256K токенах.

Занятая память против реальной загрузки GPU

При диагностике смотрите на VRAM вместе с GPU utilization, memory utilization или memory bandwidth, частотами, power draw и временем одного шага. Такая связка помогает отличить вычислительную нагрузку от ожидания.

• Высокая VRAM и высокая загрузка вычислительных блоков могут указывать на плотный вычислительный режим.
• Высокая VRAM и низкая GPU utilization чаще требуют проверки копирований, синхронизации, CPU fallback и работы очередей.
• Рост memory utilization при слабом приросте tokens/s может говорить о том, что узким местом стала пропускная способность памяти.
• Резкие паузы между операциями указывают на задержки запуска kernels или барьеры.

Сравнение KV-cache и unified memory в других локальных конфигурациях показывает ту же закономерность: дополнительная память иногда меняет вместимость, но не гарантирует ускорение. Практический разбор этой зависимости есть в материале о влиянии VRAM и KV-cache на скорость локальной LLM.

Когда начинается деградация из-за нехватки ресурсов

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

Для локальных вариантов Gemma 4 минимальный порог запуска начинается с 12 ГБ оперативной памяти, а конфигурации с 32 ГБ и больше дают больше запаса для модели и окружения. Этот ориентир относится к системной RAM и не заменяет расчёт VRAM под конкретные веса, KV-cache, batch и MTP.

Признаки нехватки ресурсов: постепенное падение скорости с ростом контекста, скачки использования RAM, активный обмен с диском, низкая загрузка GPU при высокой задержке и сообщения runtime о fallback или paging.

Какие параметры нужно зафиксировать перед сравнением

Сравнение MTP on/off и Vulkan/ROCm имеет смысл только при неизменной нагрузке. Если одновременно поменять prompt, batch и sampling, результат нельзя связать с одной настройкой.

MTP on/off: что нельзя менять одновременно

Сначала сравните два режима на одном backend. Затем повторите тот же тест после смены backend. Такой порядок отделяет влияние MTP от влияния стека.

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

Версия inference-сервера и совместимость

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

Для одного из сценариев загрузки Gemma 4 12B требовался vLLM 0.26.0. Это пример зависимости модели от серверного стека, но не доказательство того, что vLLM 0.26.0 быстрее Vulkan или ROCm. В отчёте нужно указывать фактическую версию сервера, runtime, драйвера и сборки backend.

Проверяйте сообщения о неподдерживаемых kernels, fallback на CPU, пропущенной инициализации MTP, ошибках KV-cache и изменении формата памяти. Предупреждение в логе иногда объясняет падение скорости лучше, чем мониторинг VRAM.

Минимальный набор измерений

Минимальный набор должен включать:

• время обработки prompt, prefill;
• generation tokens/s, decode;
• time to first token;
• полную задержку ответа;
• пиковое и среднее потребление VRAM;
• GPU utilization и memory utilization;
• частоты GPU и power draw;
• acceptance rate и среднее число принятых прогнозов;
• ошибки, предупреждения и сообщения о fallback.

Замеры prefill и decode лучше хранить раздельно. Модель может быстро обрабатывать большой prompt и медленно генерировать токены, либо показывать обратную картину. Смешивание этих фаз даёт среднее число, которое трудно использовать для диагностики.

Пошаговая диагностика падения tokens/s

Шаг 1. Зафиксировать базовый запуск без MTP

Запустите Gemma 4 12B QAT без MTP с заранее выбранными prompt, длиной контекста, лимитом ответа и sampling. Выполните warm-up, затем сделайте несколько одинаковых прогонов.

Запишите generation tokens/s, time to first token, prompt processing time, VRAM, загрузку GPU и сообщения runtime. Эта точка нужна для всех последующих сравнений. Без baseline любое ускорение или замедление остаётся впечатлением.

Шаг 2. Проверить, что MTP действительно выполняется

Наличие флага MTP в конфигурации не доказывает, что сервер использует ожидаемый путь. Проверьте лог загрузки MTP, создание связанных буферов, acceptance rate и сообщения о fallback.

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

Отдельно проверьте совместимость весов MTP с целевой Gemma 4 12B QAT. Неполная поддержка может приводить к корректной генерации с низкой скоростью.

Шаг 3. Сравнить короткий и длинный контекст

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

Если замедление появляется только при длинном контексте, проверяйте KV-cache, bandwidth и offload. Если оно заметно даже на коротком prompt, вероятнее выглядят расходы на MTP, kernel launches, синхронизацию или некорректный fallback.

Сравнивайте изменение эффекта внутри одинакового сценария. Абсолютные tokens/s для разных context length напрямую сопоставлять нельзя.

Шаг 4. Проверить backend и признаки ожидания

После серии Vulkan повторите тест на ROCm, сохранив все параметры и оборудование, если это возможно. Проверьте версии драйвера, inference-сервера, runtime и параметры сборки.

Сопоставьте GPU utilization, длительность kernels, паузы между операциями, копирования, VRAM и признаки CPU fallback. Если при сохранении остальных условий ROCm убирает падение скорости, вероятность проблемы в Vulkan-пути или его взаимодействии с сервером возрастает.

Переход на ROCm не заменяет профилирование. Он показывает, что другой стек выполняет задачу эффективнее, но не сообщает, какая именно операция создавала задержку в Vulkan.

Когда MTP включать, а когда лучше отключить

Признаки, что MTP приносит пользу

Оставляйте MTP включённым, если на типичных запросах одновременно выполняются несколько условий:

• acceptance rate остаётся высокой и стабильной;
• generation tokens/s растёт после прогрева;
• time to first token не ухудшается настолько, чтобы испортить интерактивную работу;
• потребление VRAM не приводит к offload и paging;
• в логах нет fallback и ошибок операций;
• результат сохраняется на разных длинах ответа и контекста.

Проверяйте эти признаки на реальных задачах пользователя. Один синтетический prompt не описывает работу с кодом, длинными документами и короткими вопросами.

Признаки, что MTP создаёт лишнюю нагрузку

MTP лучше временно отключить, если после прогрева generation tokens/s падает, acceptance rate низкая, VRAM растёт без прироста throughput, а между kernels появляются дополнительные паузы.

Поводом для отключения служит и ухудшение time to first token на коротких ответах. Если GPU загружен слабо, а CPU, RAM или memory bandwidth работают на пределе, дальнейшее увеличение числа прогнозов вряд ли исправит ситуацию.

При нестабильности, ошибках MTP или непредсказуемом fallback сначала используйте базовый режим. Он даёт понятную контрольную точку для проверки обновлений runtime.

Почему смена backend иногда важнее тонкой настройки модели

Настройка числа прогнозных токенов помогает только после того, как выбранный стек быстро выполняет базовые квантованные операции, attention, работу с KV-cache и проверку прогнозов. Слабая поддержка хотя бы одного этапа может перечеркнуть выигрыш MTP.

Практический порядок такой: сначала выберите backend с корректным и стабильным исполнением, затем подберите параметры MTP под характер запросов. Если Vulkan даёт замедление, используйте режим без MTP до проверки обновления runtime или другого backend. Если ROCm показывает прирост, повторите сравнение на нескольких контекстах и длинах ответа, а не на одном удачном запуске.

Вывод: скорость Gemma 4 12B определяется всей цепочкой исполнения

MTP ускоряет генерацию при положительном балансе между принятыми прогнозами и накладными расходами. На Vulkan этот баланс может оказаться отрицательным из-за kernels, копирований, синхронизации или особенностей inference-сервера. Переход на ROCm способен изменить результат, но причина требует проверки полного стека.

Рост VRAM не равен росту производительности. Память может расходоваться на KV-cache, контекст, MTP-буферы и резервирование, пока вычислительные блоки GPU простаивают.

Рабочий алгоритм: зафиксируйте Gemma 4 12B QAT и точные веса, сохраните backend, GPU, драйвер, версию сервера, prompt, context length, batch size, sampling, offload и KV-cache. После warm-up измерьте baseline без MTP, повторите тест с MTP, изучите acceptance rate и логи, затем проведите такую же серию на ROCm. Конкретные цифры и версии для исходного кейса нужно сверять с первичным отчётом, поскольку доступные материалы не подтверждают независимые сравнительные замеры именно Vulkan и ROCm.

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