Google показала, как Gemma 4 MTP может ускорить генерацию текста почти в три раза без заметной потери качества ответа. Для разработчиков, которые гоняют модели локально или пытаются выжать больше из потребительских GPU и мобильных устройств, это не академическая мелочь, а вполне прикладной способ сократить задержку без перехода на более слабую модель.
О нововведении сообщает InfoQ: Gemma 4 теперь можно использовать вместе с так называемыми multi-token prediction drafters — легковесными вспомогательными моделями, которые заранее предлагают сразу несколько следующих токенов. Базовая, более тяжелая модель затем проверяет эти варианты за один проход. Идея не новая сама по себе, но Google делает ставку на то, что в связке с Gemma 4 она дает ощутимый выигрыш именно там, где inference упирается не столько в «ум», сколько в пропускную способность памяти.
Проблема хорошо знакома всем, кто запускал крупные LLM вне дата-центра: на каждом шаге генерации процессор или ускоритель снова и снова таскает миллиарды параметров из VRAM в вычислительные блоки. На бумаге железо выглядит мощно, на практике значительная часть времени уходит на перемещение данных, а не на вычисление как таковое. Отсюда и парадокс современной генерации: модель тратит сопоставимый объем ресурсов и на очевидное продолжение фразы, и на действительно сложный логический кусок. В Google предлагают использовать этот перекос в свою пользу: пока тяжелая модель занята, компактный «черновик» успевает предсказать несколько вероятных токенов вперед.
Дальше включается speculative decoding. Условная Gemma 4 31B выступает как target model, а рядом с ней работает MTP-drafter, который быстро выдает кандидатов на несколько следующих токенов. Затем основная модель не принимает их на веру, а валидирует параллельно. Если предположения совпали с тем, что выбрала бы сама Gemma, пользователь получает тот же результат, но быстрее. Именно поэтому Google и говорит об ускорении без потери качества: финальное решение остается за основной моделью, а не за вспомогательной. Для разработчиков это важная оговорка. Речь не о том, что модель стала «умнее», а о том, что тот же уровень качества можно доставить с меньшей задержкой.
Google утверждает, что такой подход применим на разных классах устройств. Для персональных компьютеров и потребительских GPU компания упоминает Gemma 26B MoE и 31B dense, а для мобильных сценариев — E2B и E4B. Это хороший индикатор того, куда вообще движется рынок открытых моделей: оптимизация inference уже становится не менее важной темой, чем очередной прирост в бенчмарках. Если несколько лет назад обсуждение шло вокруг размера модели и качества на тестах, то теперь не меньший интерес вызывают latency, стоимость ответа и возможность запускать приличную LLM вне облака. Особенно это заметно на фоне роста edge-сценариев, on-device AI и корпоративного запроса на более предсказуемую инфраструктуру.
При этом у техники есть и вполне земные ограничения. В обсуждении на Reddit пользователь FarrisAT назвал Gemma 4 MTP «довольно впечатляющей штукой», но напомнил, что локальные модели по-прежнему слишком часто ошибаются, и максимальная польза от подобных оптимизаций проявится, когда open-weight модели еще сильнее подтянутся к лидерам рынка. Другой комментатор, Gohab2001, отметил более приземленный минус: speculative decoding обычно означает, что в памяти нужно держать сразу две модели. Для локального запуска это неприятный компромисс, потому что выигрыш по скорости может съедаться накладными расходами по памяти. Впрочем, в случае с реализацией Google, по его словам, важным улучшением стало совместное использование shared KV cache целевой модели, что действительно помогает уменьшить overhead. И это уже не маркетинговая формулировка, а инженерная деталь, которая определяет, стоит ли вся схема реального внедрения.
Схожий скепсис прозвучал и на Hacker News. Пользователь zozbot234 обратил внимание, что MTP особенно полезен в сценариях с одним или несколькими пользователями, когда вычислительные ресурсы простаивают и их можно задействовать для параллельного чернового предсказания. То есть техника хорошо ложится на мобильные устройства, edge-инференс и локальные рабочие станции, где задача — ускорить ответ конкретному человеку. А вот для крупных API-провайдеров картина сложнее: там важна не только скорость одного ответа, но и плотность обслуживания потока запросов, эффективность батчинга и общая экономика GPU-кластера. Проще говоря, то, что отлично смотрится в локальном Ollama, не обязано столь же красиво окупаться в большом облаке.
Для русскоязычной IT-аудитории здесь сразу несколько практических выводов. Разработчикам, которые строят продукты поверх локальных LLM, стоит внимательно следить не только за релизами новых весов, но и за тем, как именно эти веса исполняются. В 2026 году выигрыш все чаще приходит не от «еще плюс 10 миллиардов параметров», а от грамотной инженерии вокруг inference. Продактам и CTO это тоже знакомый сюжет: когда качество модели уже приемлемо, следующий рычаг — задержка и стоимость. Если ответ можно отдать в два-три раза быстрее без деградации качества, меняется UX, снижается порог для on-device функций и становятся реальнее сценарии, где раньше приходилось мириться с облачным вызовом.
Отдельно интересно, что Gemma 4 MTP-варианты уже доступны сразу на нескольких площадках, включая Hugging Face, Kaggle, Ollama и другие. Это снижает трение для экспериментов: технология не заперта внутри одной демо-страницы и не требует ждать, пока ее кто-то завернет в удобный SDK. Для команд, которые уже тестируют локальные LLM в службах поддержки, внутренних copilot-инструментах или мобильных продуктах, это означает одну простую вещь: проверить тезис про «до трех раз быстрее» можно не в презентации, а на собственной нагрузке.
Главный вопрос теперь не в том, работает ли speculative decoding вообще — это рынок давно понял, — а в том, насколько хорошо такие оптимизации будут встраиваться в реальные стек и экономику продукта. Если производители открытых моделей продолжат улучшать не только сами сети, но и обвязку для быстрого inference, конкуренция между облачными и локальными сценариями станет заметно жестче.