Qwen 3.6 27B и 35B MTP по сравнению со стандартными моделями на GPU с 16 ГБ видеопамяти
MTP и стандартное декодирование на RTX 4080 — реальные бенчмарки
Я протестировал производительность спекулятивного декодирования (Multi-Token Prediction, MTP) в моделях Qwen 3.6 27B и 35B на видеокарте RTX 4080 с 16 ГБ видеопамяти (VRAM).
Для более широкого обзора скоростей генерации токенов и компромиссов, связанных с использованием VRAM, для большего числа моделей на том же оборудовании, см. Бенчмарки LLM для видеокарт с 16 ГБ VRAM с использованием llama.cpp.
Что такое MTP (Multi-Token Prediction)
Multi-Token Prediction — это форма спекулятивного декодирования, встроенная непосредственно в определенные чекпоинты моделей. Вместо предсказания одного токена за прямой проход, модель использует дополнительные «MTP-головы», которые предлагают несколько будущих токенов за один шаг, а затем проверяют их параллельно. Если предположения принимаются, эффективная пропускная способность возрастает без изменения качества вывода.
Семейство Qwen 3.6 поставляется как с стандартными файлами GGUF, так и с вариантами, поддерживающими MTP. В llama.cpp MTP активируется с помощью:
--spec-type draft-mtp --spec-draft-n-max 3
Параметр --spec-draft-n-max является ключевым рычагом настройки. Он задает количество спекулятивных токенов, которые предлагает MTP-голова на каждом шаге. Более высокие значения дают потенциальное увеличение скорости, но требуют дополнительной VRAM для буферов черновиков, что является реальной проблемой для видеокарт с 16 ГБ памяти.
Что и как я тестировал
Я проверил, как две модели Qwen 3.6 ведут себя с включенным MTP по сравнению со стандартным декодированием на GPU с 16 ГБ VRAM (RTX 4080).
Чтобы уместить веса модели и KV-кэш в VRAM, я использовал сильно квантованные варианты:
Qwen3.6-27B-UD-IQ3_XXSиQwen3.6-27B-UD-IQ3_XXS-MTPQwen3.6-35B-A3B-UD-IQ3_SиQwen3.6-35B-A3B-UD-IQ3_S-MTP
Для каждого запуска отслеживаются два бюджета контекста:
- Avg Ctx — размер контекста, при котором llama.cpp занимает ~14,8 ГБ VRAM, оставляя другим приложениям (Xorg, GNOME Shell, Cursor) комфортный буфер в ~500 МБ.
- Max Ctx — максимальный контекст, который смогла выделить llama.cpp, учитывая, что те же десктопные приложения уже занимают ~500 МБ VRAM.
Ключевой причиной сохранения среднего контекста на практическом уровне является то, что Hermes Agent — который я использую как основного AI-ассистента, подключенного к llama.cpp на этой машине, — требует контекста не менее 64 K по умолчанию и отклоняет модели с меньшим окном при запуске. Модели ниже этого порога не могут поддерживать достаточный объем рабочей памяти для многошаговых рабочих процессов с вызовом инструментов. Для llama.cpp это означает передачу параметра --ctx-size 65536 или большего. Любая конфигурация MTP, которая значительно сжимает средний usable контекст ниже 64 K, поэтому не подходит для ежедневных рабочих нагрузок Hermes, именно поэтому числа Avg Ctx в таблицах ниже являются наиболее релевантными для принятия решений.
Были протестированы оба уровня квантования KV-кэша: q8 (более высокое качество, больше VRAM) и q5 (меньше VRAM, длиннее контекст). Имейте в виду, что переход от q8 к q5 KV-кэша может привести к заметному падению качества — в моих тестах деградация была достаточно значительной, чтобы сделать q5 непригодным для моих рабочих нагрузок. Скорость и числа контекста для q5 включены для полноты картины, но вам следует протестировать качество ответов на своих собственных задачах перед переходом на него.
Qwen 3.6 27B MTP против Стандартного
KV Cache q8
| MTP max 1 | MTP max 2 | MTP max 3 | MTP max 4 | Стандарт (IQ3_XXS) | |
|---|---|---|---|---|---|
| Скорость промпта | 148 t/s | 151 t/s | 148 t/s | 147 t/s | 200 t/s |
| Скорость генерации | 65 t/s | 75 t/s | 73 t/s | 75 t/s | 45 t/s |
| Avg Ctx | 40 K | 40 K | 40 K | 30 K | 80 K |
| Max Ctx | 60 K | 60 K | 60 K | 50 K | 100 K |
При использовании KV-кэша q8, MTP с --spec-draft-n-max 2 обеспечивает ~67 % более быструю генерацию (75 против 45 t/s) ценой сокращения среднего окна контекста вдвое — с 80 K до 40 K. Скорость обработки промпта падает с 200 до ~150 t/s, потому что MTP требует передачи данных с устройства на хост во время фазы префиллинга.
KV Cache q5
| MTP max 1 | MTP max 2 | MTP max 3 | MTP max 4 | Стандарт (IQ3_XXS) | |
|---|---|---|---|---|---|
| Скорость промпта | 145 t/s | 144 t/s | 141 t/s | 139 t/s | 191 t/s |
| Скорость генерации | 57 t/s | 62 t/s | 67 t/s | 66 t/s | 41 t/s |
| Avg Ctx | 70 K | 60 K | 60 K | 50 K | 130 K |
| Max Ctx | 100 K | 100 K | 90 K | 80 K | 160 K |
Переход на KV-кэш q5 восстанавливает значимый контекст: --spec-draft-n-max 1 дает 70 K среднего контекста при 57 t/s — это ускорение генерации на 39 % по сравнению со стандартным декодированием, при этом окно контекста остается полезного размера. При --spec-draft-n-max 3 контекст падает до 60 K, но генерация достигает 67 t/s (+63 %).
Выводы по Qwen 3.6 27B
MTP действительно полезен для плотной модели 27B. Идеальная точка для 16 ГБ VRAM:
- KV q8 +
--spec-draft-n-max 2— максимальная скорость (75 t/s), контекст снижается до 40–60 K - KV q5 +
--spec-draft-n-max 1— лучший баланс скорость-контекст (57 t/s, 70 K средний контекст)
Qwen 3.6 35B MTP против Стандартного
Модель 35B имеет архитектуру Mixture-of-Experts (MoE) (35B-A3B означает 35B общих параметров, ~3B активных на токен). MoE-модели обычно выигрывают от MTP больше, потому что разреженная маршрутизация делает MTP-голову вычислительно менее затратной по сравнению с полным прямым проходом.
KV Cache q8
| MTP max 1 | MTP max 2 | MTP max 3 | MTP max 4 | Стандарт (IQ3_S) | |
|---|---|---|---|---|---|
| Скорость промпта | 277 t/s | 277 t/s | 265 t/s | 275 t/s | 368 t/s |
| Скорость генерации | 186 t/s | 189 t/s | 180 t/s | 171 t/s | 146 t/s |
| Avg Ctx | 15 K | 10 K | — | — | 80 K |
| Max Ctx | 80 K | 70 K | 60 K | 50 K | 150 K |
Архитектура MoE обеспечивает впечатляющую сырую скорость генерации с MTP (+27 % при max 1, +29 % при max 2 против стандартных 146 t/s). Но практическая проблема заключается в среднем контексте. При использовании KV-кэша q8 даже --spec-draft-n-max 1 дает всего 15 K среднего контекста — этого едва хватает для modest задач. Более глубокие черновики вообще не имеют жизнеспособного среднего контекста на видеокарте с 16 ГБ.
Это центральный вопрос стоимости VRAM для MTP на потребительском оборудовании: дополнительные буферы черновиков напрямую съедают оставшийся бюджет VRAM, и модель 35B-A3B с KV-кэшем q8 оставляет очень мало запаса.
KV Cache q5
| MTP max 1 | MTP max 2 | MTP max 3 | MTP max 4 | Стандарт (IQ3_S) | |
|---|---|---|---|---|---|
| Скорость промпта | 264 t/s | 266 t/s | 270 t/s | 264 t/s | 343 t/s |
| Скорость генерации | 151 t/s | 147 t/s | 137 t/s | 131 t/s | 122 t/s |
| Avg Ctx | 10 K | — | — | — | 120 K |
| Max Ctx | 120 K | 110 K | 110 K | 80 K | 200 K |
KV-кэш q5 лишь незначительно улучшает ситуацию со средним контекстом. --spec-draft-n-max 1 дает 10 K среднего контекста при 151 t/s. Стандартное декодирование при q5 дает 122 t/s при 120 K среднего контекста.
Выводы по Qwen 3.6 35B
На GPU с 16 ГБ модель 35B MoE с MTP сталкивается с жестким ограничением: средний usable контекст коллапсирует до 10–15 K токенов, что делает ее непригодной для реальных рабочих нагрузок. Стандартное декодирование при 122–146 t/s с контекстом 80–120 K значительно полезнее.
Если у вас 24 ГБ+ VRAM, комбинация 35B + MTP становится гораздо более привлекательной — проблема с окном контекста исчезает, и вы сохраняете преимущество в скорости.
Выбор правильного значения --spec-draft-n-max
Вопрос о том, сколько спекулятивных токенов предлагать на каждом шаге (--spec-draft-n-max), не имеет единственно правильного ответа — это зависит как от архитектуры модели, так и от доступной VRAM:
- Для 27B dense на 16 ГБ:
--spec-draft-n-max 2с KV q8 — самый быстрый,--spec-draft-n-max 1с KV q5 — наиболее дружелюбный к контексту. - Для 35B MoE на 16 ГБ:
--spec-draft-n-max 1— единственный вариант, который сохраняет какой-либо usable контекст, и то лишь незначительно. - Более высокие значения (
3,4) увеличивают давление на VRAM без пропорционального прироста скорости — при max 4 вы тратите примерно ту же дополнительную VRAM, что и при max 2, но скорость генерации не успевает за этим.
Как включить MTP в llama.cpp
Убедитесь, что вы используете GGUF с поддержкой MTP (в имени файла содержится MTP). Если вы новичок в флагах llama.cpp, в статье Быстрый старт llama.cpp с CLI и Сервером описаны все основы. Затем запустите llama-server или llama-cli со следующими параметрами:
llama-server \
--model Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf \
--ctx-size 40000 \
-ngl 99 --flash-attn on \
--cache-type-k q8_0 --cache-type-v q8_0 \
--spec-type draft-mtp \
--spec-draft-n-max 2
Для KV-кэша q5 замените q8_0 на q5_1 или q5_0 и увеличьте --ctx-size:
llama-server \
--model Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf \
--ctx-size 80000 \
-ngl 99 --flash-attn on \
--cache-type-k q5_1 --cache-type-v q5_1 \
--spec-type draft-mtp \
--spec-draft-n-max 1
MTP активируется автоматически, как только llama.cpp обнаруживает MTP-головы в файле GGUF и установлен флаг --spec-type draft-mtp.
Таким образом, стандартный Qwen3.6-27B-UD-IQ3_XXS.gguf не будет работать в режиме MTP, вам понадобится Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf.
Однако Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf может работать как в режиме спекулятивного декодирования, так и в авторегрессионном.
Заключение
На GPU с 16 ГБ (RTX 4080) с этими квантами MTP в llama.cpp — явная победа для Qwen 3.6 27B и чистый негатив для Qwen 3.6 35B в практическом использовании:
Qwen 3.6 27B (IQ3_XXS) — MTP стоит того:
- KV q8 + MTP max 2 → ~67 % более быстрая генерация, контекст 40–60 K (против 80–100 K без MTP)
- KV q5 + MTP max 1 → ~39 % более быстрая генерация, контекст 70–100 K (против 130–160 K без MTP)
- Хороший баланс скорости и эффективности VRAM при
--spec-draft-n-max 2
Qwen 3.6 35B (IQ3_S) — MTP непрактичен при 16 ГБ:
- Скорость генерации выше на 27–29 %, но средний контекст коллапсирует до 10–15 K при q8, 10 K при q5
- Стандартное декодирование при 122–146 t/s с контекстом 80–120 K полезнее для реальных задач
- Ситуация существенно улучшается при 24 ГБ+ VRAM
На бумаге KV-кэш q5 — очевидный ответ для максимизации окна контекста при сохранении прироста скорости MTP, но на практике падение качества при переходе от q8 к q5 может быть значительным. Протестируйте q5 на своих задачах перед внедрением; для моих рабочих нагрузок деградация была неприемлемой, и q8 с более строгим бюджетом контекста остается лучшим компромиссом.
Для более широкой картины вариантов хостинга LLM и компромиссов инфраструктуры см. статью Хостинг LLM в 2026 году и Производительность LLM в 2026 году. Если вы настраиваете параметры сэмплирования Qwen 3.6 вместе с MTP, полезным дополнением будет Справочник по параметрам инференса Agentic LLM для Qwen 3.6 и Gemma 4.
