80 токенов/с + контекст 128K на 12 ГБ VRAM - Qwen3.6 + MTP

Пост пользователя janvitos на r/LocalLLaMA за май 2026 года описывает сетап для локальных LLM, выдающий >80 токенов/с в стандартном бенчмарке mtp-bench.py и стабильные 50 токенов/с при полностью заполненном контексте в 128K всего на 12 ГБ потребительской VRAM (RTX 4070 Super, AMD Ryzen 7 9700X, 48 ГБ DDR5-6000, CachyOS). Работать всё это заставляет комбинация нескольких вещей: модель Qwen3.6-35B-A3B в квантовании UD-Q4_K_XL от Unsloth, встроенные прямо в GGUF draft-головы MTP и сборка llama.cpp из исходников с PR #22673 (Multi-Token Prediction).

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

Важные флаги

llama-server \
  -m Qwen3.6-35B-A3B-MTP-UD-Q4_K_XL.gguf \
  -fitt 1536 \
  -c 131072 \
  -fa on \
  -ctk q8_0 -ctv q8_0 -ctkd q8_0 -ctvd q8_0 \
  -ctxcp 64 \
  --no-mmap --mlock \
  --spec-type mtp --spec-draft-n-max 2 \
  --chat-template-kwargs '{"preserve_thinking": true}' \
  --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0

Главная ручка здесь - -fitt 1536. Режим -fit (fit-target) появился в llama.cpp недавно и заменяет ручную настройку --n-cpu-moe: вы указываете, сколько VRAM нужно оставить свободной, а программа сама решает, что отправить на GPU, а что сбросить в RAM. Запаса в 1536 МБ как раз хватает, чтобы уместить draft-головы MTP и KV-кэш на 128K контекста без OOM. Если подключить монитор к встроенной графике и полностью отдать dGPU под инференс, доступны все 12 ГБ карты 4070. О семействе режимов -fit и их связи с -ngl, -cmoe и -ncmoe см. moe-cpu-offload.

--spec-type mtp вместе с --spec-draft-n-max 2 задают конфигурацию speculative decoding. janvitos выяснил, что -n-max 3 работает чуть быстрее, но процент принятых токенов (acceptance rate) падает, и овчинка выделки не стоит: с MTP нужно максимизировать и скорость, и процент принятия. О четырёх режимах speculative decoding в llama.cpp (draft model, MTP, EAGLE3, ngram-mod) см. speculative-decoding.

Результаты бенчмарков

Результаты mtp-bench.py (по девяти типам задач):

Картина полностью соответствует устройству MTP: структурированный вывод с высокой локальной предсказуемостью (код, перевод) даёт максимальный процент принятия и наибольшее ускорение. У художественного текста процент принятия самый низкий (0.694) и пропускная способность минимальная (69.2 т/с) - draft-головы ошибаются чаще, и больше токенов приходится откатывать назад.

На длинном контексте генерация проседает до ~50 т/с. Всё ещё вполне пригодно к работе. janvitos несколько дней гонял этот сетап через OpenCode, анализируя кодовые базы проектов целиком (заполняя контекст примерно до 75K), и никаких проблем не возникло.

Комментарий про turboquant + MTP

Самый интересный комментарий оставил Still-Notice8155, запустивший ту же линейку моделей на GTX 1070 8GB - восьмилетнем чипе поколения Pascal - и получивший следующие цифры:

• Контекст 0K: 48 т/с
• Контекст 80K: 23 т/с (плато DeltaNet)
• Контекст 125K: 13.6 т/с

В этой конфигурации MTP объединён с квантованием KV-кэша через turboquant при флагах --cache-type-k turbo4 --cache-type-v turbo3, --n-cpu-moe 32, ctx-checkpoints 8 на модели Qwen3.6-35B-A3B-MTP-UD-Q2_K_XL (двухбитный динамический квант). Расход памяти на KV-кэш падает до ~590 МБ на 131K против ~720 МБ на q4_0: turboquant использует подход rotate-then-quantize, который при том же объёме байт выигрывает у целочисленного квантования KV. VRAM на 131K: занято 7.5 ГБ, свободно 633 МБ. Карта 1070 умещает 128K контекста на 8 ГБ.

Ускорение по сравнению с запуском без MTP на длинном контексте впечатляет: ~3 т/с -> 13.6 т/с на 125K контекста (в 4.5 раза). MTP экономит примерно фиксированное время на токен независимо от длины контекста, тогда как стоимость attention растёт линейно, поэтому по мере заполнения контекста разрыв увеличивается. Архитектурное объяснение см. в speculative-decoding.

В более позднем посте тот же пользователь с 32 ГБ RAM и квантом IQ4_XS при тех же настройках MTP+turboquant получил на 1070 скорость 32.1 т/с на коротком контексте и 18.1 т/с на 131K. Тест позиционного поиска CodeNeedle: 9-14 / 16 PASS, точность по строкам 84-88%. Общий процент принятия MTP draft: 87-94%.

Подтверждение тройной блокировки режима размышлений

Комментатор cognitium сообщает, что модель "тратит половину контекста на бесконечные монологи о том, какая она хорошая и как строго следует правилам, а потом просто их нарушает". Ответ janvitos: используйте --chat-template-kwargs '{"enable_thinking": false}' (под Windows синтаксис немного другой). Это независимое подтверждение проблемы thinking-mode-rule-erosion - даже автор поста с рабочей конфигурацией изначально не заметил, что модель думает во вред задаче, а решение в точности совпадает с рецептом из трёх флагов от Вячеслава.

Споры вокруг -no-mmap

В длинной ветке комментариев обсуждается --no-mmap. Итоговый консенсус: --no-mmap в паре с --mlock загружает модель в анонимную память RAM и блокирует её там от выгрузки, полностью исключая дисковый ввод-вывод во время инференса ценой более долгого запуска. Пользователь sh4rk1z провёл замеры на RTX 2070 Super: ускорение декодирования на 1.5%, ускорение обработки промпта на 5.2%, экономия 28 МБ VRAM и снижение стандартного отклонения между прогонами в 10-20 раз. Именно снижение дисперсии здесь ключевое: без -no-mmap страницы из mmap могут вытесняться при нехватке памяти, вызывая периодические скачки задержки, которые легко спутать с падением качества.

Связи

• speculative-decoding - MTP, EAGLE3, ngram-mod, варианты с draft-моделью - семейство, практическим воплощением которого служит этот тред на Reddit
• moe-cpu-offload - режим -fit / -fitt, который впервые появляется в вики благодаря этому треду
• random-rotation-quantization - TurboQuant, к которому относится --cache-type turbo4
• local-llm-16gb-vram-tests - тесты Вячеслава с тем же семейством моделей на оборудовании того же класса
• habr-local-llm-quantization-deep-dive - базовый концептуальный разбор, объясняющий UD-Q4_K_XL, ncmoe и ik_llama
• thinking-mode-rule-erosion - подтверждено независимо в ветке с cognitium
• OpenCode - инструмент, через который janvitos работает с этим сетапом
• llama.cpp - собрана из PR #22673 для включения MTP