Ускорение GLM-5.2 в llama.cpp: поддержка спекулятивного декодирования NextN/MTP

Что такое NextN/MTP и как он ускоряет GLM-5.2

В репозиторий llama.cpp добавлена поддержка спекулятивного декодирования NextN/MTP (Multi-Token Prediction) для архитектуры GLM_DSA, на которой построена модель GLM-5.2. Метод генерирует несколько токенов за один проход, сокращая количество итераций и ускоряя инференс без потери качества. Первые тесты показывают прирост скорости до 2x на задачах генерации кода и суммаризации.

Это прямое продолжение тренда на оптимизацию локального инференса. Ранее мы разбирали, как n-gram драфтеры ускоряют Qwen 3.6 27B в 6 раз и как DFlash и MTP показывают себя на vLLM и SGLang. Теперь очередь GLM-5.2 - модели, которая уже привлекала внимание ценой инференса в 30 раз ниже Opus 4.8.

Спекулятивное декодирование: от идеи к Multi-Token Prediction

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

Классический подход использовал отдельную draft-модель - облегчённую версию основной, которая быстро генерировала черновые токены. Основная модель проверяла их пачкой. Это давало ускорение, но требовало загрузки двух моделей в память. Multi-Token Prediction решает проблему иначе: одна модель обучается предсказывать несколько следующих токенов одновременно через дополнительные выходные головы. Никакой второй модели, никакого расхода лишней памяти на draft-сеть.

NextN/MTP - реализация этого подхода, интегрированная в llama.cpp. Модель GLM-5.2 с архитектурой GLM_DSA использует множественные предсказывающие головы, которые генерируют N следующих токенов за один forward-проход. llama.cpp проверяет их корректность и принимает те, что совпадают с результатом обычного декодирования. Чем выше точность предсказаний, тем больше токенов принимается за шаг и тем выше итоговое ускорение.

NextN/MTP в llama.cpp: особенности реализации для GLM-5.2

Архитектура GLM_DSA (Dense-Sparse Attention) в GLM-5.2 изначально проектировалась с учётом возможности Multi-Token Prediction. Модель содержит дополнительные линейные слои - MTP-головы, которые предсказывают токены на несколько позиций вперёд. При обычном декодировании эти головы не используются и не влияют на результат. При включении спекулятивного режима llama.cpp активирует их и начинает генерировать пачки токенов.

Важный технический нюанс: в последних сборках llama.cpp тензоры MTP/NextN загружаются автоматически при наличии их в GGUF-файле, даже если флаг --spec-type draft-mtp не указан явно. Это увеличивает потребление VRAM примерно на объём одного MoE-слоя. На системах с ограниченной памятью этот момент критичен - модель может просто не поместиться в GPU, если вы не планировали использовать спекулятивное декодирование. Подробнее об этом мы писали в отдельном материале про изменение поведения llama.cpp.

Интеграция в llama.cpp выполнена через стандартный механизм speculative decoding. Ключевые параметры: --spec-type draft-mtp для включения MTP-режима и --spec-draft-length N для указания количества предсказываемых токенов. По умолчанию N=4, но можно выставить значения от 1 до 8. Чем больше токенов предсказывается за шаг, тем выше потенциальное ускорение, но и выше вероятность отбрасывания неверных токенов.

Бенчмарки: реальный прирост производительности

Цифры - главное, ради чего вы читаете этот разбор. Мы протестировали GLM-5.2 с NextN/MTP на трёх конфигурациях: потребительская RTX 4090 (24 ГБ), серверная RTX 6000 Ada (48 ГБ) и CPU-only режим на AMD Ryzen 9 7950X. Модель - GLM-5.2 в квантизации Q4_K_M. llama.cpp - сборка b4567 от 28 июля 2026.

Методика тестирования и конфигурации

Все замеры проводились с batch size = 1, что соответствует типичному сценарию локального использования. Промпты взяты из трёх категорий: генерация кода (Python, 500 токенов на вход), суммаризация технического текста (2000 токенов на вход), многоходовой диалог (5 реплик, суммарно 1500 токенов контекста). Каждый тест прогонялся 5 раз, результаты усреднены. Измерялась скорость генерации в токенах в секунду после стадии prefill.

Параметры запуска с MTP: --spec-type draft-mtp --spec-draft-length 4. Базовый режим - стандартное авторегрессионное декодирование без спекуляции. Температура - 0.0 для воспроизводимости.

Результаты: ускорение на разных сценариях

Сценарий	RTX 4090 (базовый)	RTX 4090 (MTP)	Ускорение	RTX 6000 Ada (MTP)	Ускорение	CPU (MTP)	Ускорение
Генерация кода	48.2 tok/s	82.1 tok/s	1.70x	95.4 tok/s	1.98x	12.3 tok/s	1.45x
Суммаризация	45.7 tok/s	74.3 tok/s	1.63x	88.1 tok/s	1.93x	11.8 tok/s	1.40x
Многоходовой диалог	46.9 tok/s	79.8 tok/s	1.70x	91.2 tok/s	1.94x	12.1 tok/s	1.43x

На RTX 4090 прирост стабильно держится в диапазоне 1.6–1.7x. Серверная RTX 6000 Ada с большей пропускной способностью памяти выжимает до 1.98x - почти двукратное ускорение. CPU-режим скромнее, 1.4–1.45x, но это объяснимо: узкое место на процессоре - вычислительная скорость, а не пропускная способность памяти, поэтому эффект от спекуляции ниже.

Интересная деталь: на длинных контекстах (8000+ токенов) ускорение немного снижается - до 1.5x на RTX 4090. Причина в том, что prefill-стадия занимает больше времени, а MTP ускоряет только фазу генерации. Для задач с короткими промптами и длинной генерацией (например, написание кода с нуля) выигрыш максимален.

Практическое руководство: запуск GLM-5.2 с NextN/MTP в llama.cpp

Переходим к тому, что можно применить немедленно. Для запуска GLM-5.2 со спекулятивным декодированием в llama.cpp нужна сборка не ниже b4560 и GGUF-файл модели с поддержкой MTP-тензоров. Если вы уже запускали GLM-5.2 на llama.cpp ранее, модель, скорее всего, готова - MTP-головы были включены в GGUF с первых релизов.

Необходимые флаги и параметры

Минимальная команда для включения MTP:

./llama-cli -m glm-5.2-q4_k_m.gguf -p "Напиши функцию сортировки на Python" --spec-type draft-mtp --spec-draft-length 4

Разбор ключевых аргументов:

• --spec-type draft-mtp - включает режим Multi-Token Prediction. Без этого флага модель работает в стандартном авторегрессионном режиме.
• --spec-draft-length N - количество токенов, предсказываемых за шаг. Диапазон: 1–8. Значение 4 - оптимальный баланс между ускорением и точностью для GLM-5.2. При N=8 ускорение на RTX 4090 падает до 1.4x из-за частого отбрасывания неверных токенов.
• --spec-accept-length N - максимальное количество принимаемых токенов за шаг. По умолчанию равно spec-draft-length. Уменьшение этого параметра может помочь на нестабильных задачах.

Для серверного режима (llama-server) конфигурация аналогична:

./llama-server -m glm-5.2-q4_k_m.gguf --spec-type draft-mtp --spec-draft-length 4 --host 0.0.0.0 --port 8080

Примеры запуска для разных задач

Генерация кода (Python, полная функция):

./llama-cli -m glm-5.2-q4_k_m.gguf \
  -p "Реализуй алгоритм быстрой сортировки на Python с подробными комментариями:" \
  --spec-type draft-mtp --spec-draft-length 4 \
  -n 512 --temp 0.0

Вывод с MTP: 82.1 tok/s. Без MTP: 48.2 tok/s. Генерация 512 токенов занимает 6.2 секунды вместо 10.6.

Суммаризация длинного текста:

./llama-cli -m glm-5.2-q4_k_m.gguf \
  -f technical_report.txt \
  -p "Сделай краткую выжимку этого отчёта на русском, 5 ключевых пунктов:" \
  --spec-type draft-mtp --spec-draft-length 4 \
  -n 256 --temp 0.2

На prefill 2000 токенов уходит 0.8 секунды, генерация 256 токенов - 3.5 секунды с MTP против 5.6 без.

Интерактивный чат:

./llama-cli -m glm-5.2-q4_k_m.gguf \
  --spec-type draft-mtp --spec-draft-length 4 \
  --chat-template chatml \
  -cnv --interactive-first

В чат-режиме MTP даёт стабильные 1.7x на RTX 4090. Задержка между репликами сокращается с 2.1 до 1.2 секунды при генерации ответа в 100 токенов.

Ограничения и подводные камни

MTP не бесплатен. Три момента, которые нужно учесть перед внедрением.

Потребление памяти. Как упоминалось выше, llama.cpp теперь автоматически загружает MTP-тензоры при их наличии в GGUF. Для GLM-5.2 в квантизации Q4_K_M это дополнительные 1.2–1.8 ГБ VRAM. На RTX 4090 с 24 ГБ это некритично, но на GPU с 12–16 ГБ может стать проблемой при использовании длинных контекстов. Если память в дефиците, проверьте, не загружаются ли MTP-тензоры впустую при выключенном спекулятивном декодировании.

Совместимость с квантованием. MTP-головы чувствительны к агрессивному квантованию. На Q2_K и ниже точность предсказаний падает настолько, что ускорение становится минимальным - 1.1–1.2x. Оптимальный минимум для MTP - Q4_K_M. Q5_K_M и Q6_K дают ещё более стабильные предсказания, но разница в ускорении с Q4_K_M не превышает 5%.

Стабильность на разных ОС. На Linux (Ubuntu 24.04, драйвер 560) и Windows 11 (драйвер 555) MTP работает стабильно. На macOS с Metal-бэкендом наблюдаются редкие падения точности предсказаний на длинных последовательностях - проблема известна разработчикам llama.cpp и связана с особенностями реализации attention на Apple Silicon. Временное решение: уменьшить --spec-draft-length до 2–3 на Mac.

Когда MTP нецелесообразен. Если ваша задача - обработка одного короткого промпта с минимальной генерацией (например, классификация текста или извлечение сущностей), выигрыш от MTP близок к нулю. Prefill-стадия доминирует над генерацией, а MTP ускоряет только вторую. Также MTP не даёт преимуществ при batch size > 1 - в этом режиме вычисления уже эффективно утилизируют GPU, и спекулятивное декодирование не добавляет пропускной способности.

Сравнение с альтернативными методами ускорения

NextN/MTP - не единственный способ ускорить инференс GLM-5.2. Выбор метода зависит от доступного оборудования, требований к памяти и характера задач.

DFlash - альтернативная техника спекулятивного декодирования, которая на некоторых моделях показывает до 4.6x ускорения. Проблема в том, что DFlash требует патчей для конкретных архитектур и на GLM-5.2 пока не портирован. Если вы работаете с Qwen 3.6, DFlash даёт максимальные цифры, но для GLM-5.2 MTP - единственный готовый к использованию вариант.

EAGLE3 - метод, использующий отдельную draft-модель для предсказания токенов. Плюс: не требует специальной подготовки основной модели. Минус: дополнительный расход памяти на draft-сеть и нестабильная поддержка в llama.cpp. На GLM-5.2 EAGLE3 не тестировался, а на Qwen 3.6 показывал 1.9x с проблемами загрузки на vLLM.

N-gram драфтеры - метод, копирующий паттерны из контекста. Не требует дополнительной памяти и отлично работает на задачах редактирования кода, где модель часто повторяет собственные паттерны. На одноходовых промптах эффект минимален. Для GLM-5.2 n-gram подход не тестировался систематически, но на Qwen 3.6 27B комбинация DFlash + n-gram давала до 6x в сценариях итеративного кодирования.

Прямой вывод: что выбрать. Если вы работаете с GLM-5.2 локально на llama.cpp, MTP - единственный готовый метод с двукратным ускорением на GPU и полуторакратным на CPU. Альтернативы либо не портированы (DFlash), либо нестабильны (EAGLE3), либо дают эффект только в узких сценариях (n-gram). Для бюджетных кластеров на AMD MI50, где GLM-5.2 уже показывает 12–14 tok/s через RPC, MTP может поднять скорость до 18–20 tok/s без дополнительных затрат на оборудование.

Сравнительная таблица методов для GLM-5.2:

Метод	Ускорение	Доп. память	Статус для GLM-5.2
NextN/MTP	1.6–2.0x	1.2–1.8 ГБ	Готов к использованию
DFlash	до 4.6x (на других моделях)	минимальная	Не портирован
EAGLE3	~1.9x (на других моделях)	от 2 ГБ на draft-модель	Не тестировался
N-gram драфтер	1.1–1.3x (на других моделях)	0	Не тестировался

Если вы ещё не пробовали GLM-5.2 в деле, начните с обзора модели и её возможностей в кодинге, а затем возвращайтесь к этой инструкции за ускорением. Для тех, кто следит за оптимизациями llama.cpp в целом, свежий разбор SSD-матриц и FWHT-ядра даст полную картину доступных инструментов.

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