Обещали космос, а дали... пока тишину
Когда Google в конце апреля 2026 года анонсировал Multi Token Prediction (MTP) для модели Gemma 4, сообщество локальных LLM дружно потирало руки. Ещё бы: спекулятивное декодирование, которое генерирует сразу несколько токенов за шаг, сулит ускорение в 2-3 раза без потери качества. Звучит как сказка. Но есть нюанс: MLX — главный инструмент для запуска моделей на Apple Silicon — эту фишку пока не поддерживает. И пользователи Mac остались у разбитого корыта.
Важно: все тесты проводились 7 мая 2026 года на Gemma 4 31B (квантование Q4_K_M). Результаты могут отличаться в зависимости от железа и конфигурации.
Что вообще такое Multi Token Prediction и с чем его едят?
В обычной авторегрессивной генерации модель предсказывает один токен за раз. MTP же заставляет нейронку думать на несколько шагов вперёд: она предсказывает блок из N токенов (обычно 4-8) параллельно, а затем верифицирует результат. Если блок проходит проверку — сразу записывается, если нет — откатывается на один токен и пробует снова. Это похоже на то, как опытный геймер нажимает комбинацию клавиш, а не тыкает по одной.
Google утверждает, что на их тестовых промптах Gemma 4 с MTP выдаёт до 2.7x ускорения по сравнению с обычным декодированием. Для локальных моделей — это потенциальный переворот. Представьте: диалог с ботом, который раньше заикался на каждом слове, вдруг начинает сыпать ответами как из пулемёта.
Но в теории это работает так, а на практике...
Первые впечатления: бегом по граблям
Мы решили проверить MTP на практике. Собрали стенд: Mac Studio M2 Ultra (192 ГБ), mlx-lm последней версии (0.22.1), модель Gemma 4 31B Q4_K_M. И тут нас ждал холодный душ.
Попытка запустить модель с флагом --multi-token-prediction 4 выдала ошибку: «Unsupported architecture for MTP». Разработчики mlx-lm в чате на GitHub ответили, что архитектура Gemma 4 (особенно её MoE-вариации) требует дополнительной адаптации для спекулятивного декодирования. Грубо говоря, модель просто не умеет «гадать» несколько токенов вперёд без специальной доработки.
Но это ещё не всё. Даже если бы MTP заработал, практический выигрыш оказался бы не таким радужным, как в рекламных слайдах Google. Почему?
Почему MLX тормозит с поддержкой
Во-первых, Gemma 4 — Mixture of Experts. MoE-модели имеют разреженные вычисления: каждый токен активирует только часть экспертов. Спекулятивное декодирование, которое генерирует N токенов параллельно, в MoE вызывает дисбаланс загрузки экспертов. Технически реализовать это стабильно — задача нетривиальная. В статье про Gemma 4 MoE мы уже писали, что рекордные 120 TPS на двух RTX 3090 были достигнуты без MTP. С ним цифры могли бы быть ещё выше, но инженерам пришлось бы переписывать ядро внимания.
Во-вторых, MLX — это не llama.cpp. У Apple Silicon своя архитектура: унифицированная память и GPU, который, хоть и мощный, но не NVIDIA. Правда о скорости MLX на Mac такова, что бенчмарки часто врут: реальная производительность в диалогах может быть в 2-3 раза ниже заявленной. MTP мог бы это исправить, но пока его нет.
Третье: Google открыл код MTP для Gemma 4 в своём репозитории maxtext — это фреймворк для TPU и GPU. Адаптация под MLX требует переписывания под Metal Performance Shaders. Сроки? В официальном репозитории mlx-lm issue #1283 висит с 1 мая с пометкой «under investigation». Никаких прогнозов.
А что говорят бенчмарки на тех, кто всё-таки запустил?
Пока MLX молчит, энтузиасты пробуют MTP на других бэкендах. llama.cpp в версии b4566 добавил экспериментальную поддержку спекулятивного декодирования для Gemma 4. Но результаты, мягко говоря, неоднозначные.
| Бэкенд | Ускорение (промпты 1K) | Ускорение (промпты 8K) | Стабильность |
|---|---|---|---|
| llama.cpp (CUDA) | 1.8x | 1.3x | Средняя |
| Google maxtext (TPU) | 2.7x | 2.2x | Высокая |
| MLX | — | — | Нет поддержки |
Как видите, на длинных контекстах выигрыш падает: спекулятивное декодирование начинает чаще ошибаться, увеличивается число откатов. Для коротких писем или кода — хорошо, для анализа больших документов — не очень.
Что делать пользователям Mac прямо сейчас?
Ждать. Но не пассивно. Есть несколько путей, как ускорить инференс Gemma 4 на Apple Silicon без MTP.
Первый — использовать квантизации более низкого битрейта. Gemma 4 31B в Q3_K_M занимает около 18 ГБ и выдаёт приемлемые 15-18 TPS на M2 Ultra. Обзор квантований и интеграции показывает, что даже без MTP можно получить комфортный опыт.
Второй — перейти на версию Gemma 4 26B A4B (MoE с 4 активными экспертами). Она требует меньше памяти и быстрее работает. Правда, как показало тестирование длинного контекста, стабильность на 94% заполнения контекста немного падает, но для повседневных задач — нормально.
Третий — дождаться обновления mlx-lm. Если вы умеете компилировать из исходников — можете попробовать сами добавить поддержку MTP. Пошаговое обучение LLM с нуля на MacBook поможет разобраться с основами. Но будьте готовы, что придётся писать кастомный драфтер-модуль на Python и Metal Shading Language.
Если вам не терпится попробовать MTP уже сегодня, можно запустить Gemma 4 через llama.cpp. На Linux с NVIDIA получите 1.5-1.8x ускорение. На Mac через Vulkan — увы, производительность просядет из-за накладных расходов.
Стоит ли овчинка выделки?
Честно говоря, я не уверен, что MTP — именно та фича, за которой будущее локальных LLM на Mac. Да, 2-3x ускорение звучит круто. Но на практике мы упёрлись в бутылочное горлышко: даже с MTP токен-генерация на Gemma 4 31B на M2 Ultra не превышает 40-50 TPS — это в 5-10 раз медленнее, чем у GPT-4o-mini в облаке. И это при условии, что MTP заработает стабильно.
Может быть, стоит сосредоточиться на других оптимизациях: аудио-фичи, улучшение работы с инструментами (FunctionGemma), или распараллеливание на несколько GPU. В конце концов, если вашему сценарию нужно 100+ TPS — проще арендовать облачную инстанцию на 10 минут, чем мучиться с локальным запуском.
Но я понимаю энтузиастов. "Железо своё, данные свои, никаких каггловских лимитов" — это философия. И ради неё люди готовы ждать. Надеюсь, в mlx-lm не забросят тикет #1283. А пока — живите с тем, что есть. Без MTP тоже неплохо.
