В llama.cpp предложили поддержку MTP — Qwen3.6 27B быстрее в 2,4 раза

Разработчик am17an открыл PR #22673 в llama.cpp с поддержкой MTP-голов: дополнительные слои модели предсказывают следующие три токена, а основной forward-pass проверяет их одним проходом. На Qwen3.6 27B при 8-битной квантизации режим даёт стабильные 16–22 токенов в секунду против 7 на baseline — ускорение в 2,4 раза.

MTP (Multi Token Prediction) — техника, предложенная исследователями Meta в апреле 2024: рядом с основной языковой моделью обучаются дополнительные головы, предсказывающие следующие 1–3 токена напрямую. Широкое применение в production-LLM пришло с DeepSeek-V3, а Qwen3.6 поддерживает архитектуру из коробки. До PR #22673 при экспорте в GGUF эти головы терялись. Теперь они подтягиваются как отдельная под-модель внутри того же файла и работают как драфтер для спекулятивного декодинга.

Что такое Multi Token Prediction

Стандартный авторегрессионный декодинг генерирует токены последовательно: сгенерировал — пересчитал контекст — сгенерировал следующий. Это упирается в латентность памяти: каждый токен требует одного полного прохода через модель, и с ростом её размера падает скорость генерации.

Спекулятивный декодинг ускоряет процесс через идею «угадай и проверь»: маленькая черновая модель быстро генерирует несколько токенов вперёд, а большая основная модель проверяет их одним пакетным проходом. Принятые токены остаются, отвергнутые перегенерируются. Если черновик угадал — экономия в разы.

MTP идёт дальше: вместо двух разных моделей (большая + черновая) одна и та же модель обучается предсказывать сразу несколько следующих токенов через дополнительные параллельные головы. Концепция вышла из статьи Meta «Better & Faster Large Language Models via Multi-token Prediction» (Gloeckle и соавторы, апрель 2024), массовое применение в production-LLM пришло с DeepSeek-V3. Главное преимущество — не нужно держать в памяти отдельную draft-модель.

Бенчмарки am17an на Qwen3.6 27B

Автор PR прогнал девять синтетических задач — генерация Python-кода, C++-кода, объяснение концепций, суммаризация, факто-QA, перевод, креативные тексты, пошаговая математика и длинный код-ревью. Замеры с одной моделью и одним GPU (см. gist с бенчмарком):

• Baseline без спекулятивного декодинга: 7,0–7,7 ток/с, агрегат 201 секунда на 1404 токена.
• MTP, n-max 3 (3 драфт-токена за шаг): 13,9–21,6 ток/с, accept rate 72,2%, 83,8 с — ускорение в 2,4 раза.
• MTP, n-max 2: 15,2–18,2 ток/с, accept rate 82,6%, 90,4 с — короче драфт, но выше доля принятых.
• Draft-модель Qwen3.5 0.8B, n-max 16: для сравнения с классическим speculative decoding — 12,7–47,7 ток/с, accept rate 67,7%, 81,4 с.

На фактической QA («ответь точно») draft-модель догоняет MTP по скорости — accept rate подскакивает до 99,4%, — но на креативных и аналитических задачах MTP стабильнее: меньше провалов на нестандартных формулировках.

Как запустить

После сборки llama.cpp из ветки PR запуск сервера с MTP выглядит так:

			./llama-server -m qwen3.6-q8_0-mtp.gguf -np 1 \
  --chat-template-kwargs '{"preserve_thinking": true}' \
  --spec-type mtp --spec-draft-n-max 3
		

Ключевой флаг — --spec-type mtp. --spec-draft-n-max 3 задаёт длину драфта; для большинства моделей оптимум — 2 или 3.

Готовый GGUF с MTP-головами для Qwen3.6 27B автор приложил к PR. Конвертация других MTP-моделей идёт через обновлённый convert_hf_to_gguf.py из той же ветки.

MTP против обычного спекулятивного декодинга

Классическая схема speculative decoding в llama.cpp требует двух GGUF-файлов: основной модели и небольшой черновой (например, Qwen3.5 0.8B как драфт для Qwen3.6 27B). Это удваивает требования к памяти и усложняет деплой — нужно следить, чтобы токенизаторы у обеих моделей совпадали. MTP убирает оба ограничения: дополнительные головы лежат в том же GGUF-файле, что и основная модель, токенизация заведомо одна. По бенчмаркам автора MTP-режим стабильнее по задержке, а draft-модель может выстрелить выше пика на специфичных задачах вроде QA, где её предсказания проще.

В обсуждении PR мейнтейнер ngxson отметил, что предыдущие попытки добавить MTP опирались на постоянное копирование данных между host и device — основной автор am17an обошёл это через отдельный hook для распространения скрытых признаков между ubatch-ами.

Свежий старт лучше моего WIP #18886 — другие попытки добавить MTP сильно полагались на копирование данных host ↔ device. Похоже, у тебя это решено?

Xuan Son Nguyen (ngxson)мейнтейнер llama.cpp

Чек-лист для тех, кто хочет попробовать

1. Склонировать репозиторий llama.cpp и переключиться на ветку PR #22673 (или дождаться мерджа в master).
2. Собрать с CUDA или Metal-бэкендом — режимы для CPU работают, но без значимого ускорения.
3. Скачать GGUF с MTP-головой: qwen3.6-q8_0-mtp.gguf, ссылка приложена в PR.
4. Запустить llama-server с флагами --spec-type mtp --spec-draft-n-max 3.
5. Сравнить токены в секунду с baseline (без флагов спекулятивного декодинга) — на Qwen3.6 ожидается рост в 2–2,5 раза.

Выводы

После мерджа PR локальный запуск Qwen3.6 27B приближается по задержке к облачным API: разница в ответе на коде и аналитике сокращается с десятков секунд до считанных. Для MoE-вариантов вроде Qwen3.6 35BA3B экономия видеопамяти от MTP особенно полезна — ту же скорость теперь можно получить на одной серверной карте, не запуская параллельно отдельную draft-модель.

Если пишете инструменты вокруг локальных LLM — обновитесь после мерджа PR в master. Тем, кто использует облачные модели только из-за скорости, имеет смысл проверить, не закрывает ли Qwen3.6 + MTP их сценарий. У нас уже выходил отдельный гайд по запуску LLM локально через Ollama — он пригодится, если вы только подбираете инструменты.

Источники: PR #22673 в llama.cpp, бенчмарки am17an.