ainews
MTP в llama.cpp: в 2 раза быстрее на обычных моделях, провал на MoE
В llama.cpp появилась нативная поддержка MTP (Multi Token Prediction) — технологии, где модель предсказывает несколько токенов за раз. На обычных dense-моделях (Qwen, DeepSeek, GLM) это даёт ускорение в 1.4-2.2 раза. На MoE-моделях прирост минимальный или его вообще нет — архитектура MoE уже оптимизирована по затратам на декодинг. Старые методы спекулятивной декодинга с отдельными draft-моделями показали себя ненадёжно.
Если вы запускаете LLM локально на llama.cpp, это даёт конкретный способ ускорить генерацию — но только если вы используете dense-модели с MTP-поддержкой. На MoE не тратьте время.
Что случилось
В llama.cpp добавили нативную поддержку MTP (Multi Token Prediction) через флаг --spec-type draft-mtp. Это позволяет моделям с встроенными MTP-головками (Qwen3.6, DeepSeek, GLM) генерировать несколько токенов за раз вместо одного — своего рода «предсказание наперёд».
Технически это стало возможно после апрельского мерджа speculative checkpointing (PR #19493), который починил работу спекулятивной декодинга на гибридных и рекуррентных архитектурах — старый механизм откатов там просто не работал.
Результаты на практике
Dense-модели (обычные): ускорение от 1.4x до 2.2x на моделях вроде Qwen3.6-27B. Реальный прирост, который ощущается.
MoE-модели: прирост минимальный или нулевой. Причина проста: MoE-архитектура уже экономит вычисления, активируя только часть параметров на каждом шаге. MTP там просто нечего оптимизировать. Та же картина с Gemma 4: dense-версия на 31B получила заметный буст, MoE-версия — копейки.
Что со старыми методами
Классическая спекулятивная декодинга (отдельная маленькая draft-модель, ngram-кэши) показала противоречивые результаты. Детальный бенчмарк Qwen3.6-35B-A3B на RTX 3090 не выявил ускорения от ngram-cache, ngram-mod или draft-моделей — некоторые конфиги даже замедляли генерацию.
Вывод: если нужна скорость, нативные MTP-головки — более надёжный рычаг, чем старые трюки с draft-моделями.
Итого
MTP работает, но избирательно. Dense-модели получили серьёзный буст. MoE остались практически на месте. Старые методы ускорения оказались ненадёжны.
Ключевые выводы
- Нативная MTP-декодинга в llama.cpp даёт 1.4-2.2x ускорение на dense-моделях, но почти бесполезна на MoE
- MoE-архитектура уже оптимизирована по затратам на декодинг — MTP там нечего экономить
- Старые методы спекулятивной декодинга (draft-модели, ngram-кэши) показали ненадёжные результаты, иногда даже замедляют работу
- Технически MTP стал возможен после фикса для гибридных/рекуррентных архитектур в апреле 2025
- Qwen3.6, DeepSeek и GLM поставляются с готовыми MTP-головками
Автор: Павел Заславский · Источник: reddit.com
Это один из тех случаев, когда технология работает ровно там, где обещала, но не везде. MTP — не магия, а конкретная оптимизация для dense-архитектур. И вот тут llama.cpp сделал хорошую работу: встроил поддержку, дал инструмент, и на Qwen/DeepSeek это реально ощущается.
Но MoE — это отдельная история. Эти модели уже выжимают максимум из каждого шага декодинга, активируя минимум параметров. MTP там банально нечего оптимизировать. И это нормально — не каждая фича должна быть универсальной. Важнее, что теперь понятно: если нужна скорость локально, берёте dense с MTP, а не пытаетесь колдовать с draft-моделями, которые в реальных тестах оказались лотереей.
Комментарии