Google показала DiffusionGemma: быстрая Gemma пишет текст блоками, но пока уступает обычной модели

Google выпустила DiffusionGemma 26B-A4B-it — экспериментальную открытую модель семейства Gemma, которая пробует другой способ генерации текста. Вместо привычного движения слева направо по одному токену она работает с блоком из 256 токенов: сначала заполняет его шумом, затем несколько раз уточняет весь фрагмент, фиксирует результат и переходит к следующему блоку.

Это не новая «лучшая Gemma» и не замена production-моделям. Google прямо называет релиз экспериментальным и пишет, что стандартная Gemma 4 остаётся выбором для максимального качества. Но DiffusionGemma важна как инженерная проверка идеи: можно ли заставить локальную LLM быстрее отвечать одному пользователю, если дать GPU не маленький последовательный шаг, а большой параллельный кусок работы.

Как работает текстовая диффузия

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

DiffusionGemma пытается поменять узкое место. Она берёт canvas длиной 256 токенов и обновляет все позиции параллельно. На ранних проходах начало блока обычно получается увереннее, дальние позиции могут быть шумными, но следующие итерации используют уже найденные токены как контекст и постепенно исправляют слабые места. Для текста длиннее 256 токенов блоки сшиваются последовательно: готовый canvas добавляется в историю, после чего модель начинает следующий.

По сути, Google смешивает диффузионный подход с авторегрессией: внутри блока идёт параллельное очищение шума, между блоками сохраняется последовательная структура. Поэтому модель интересна не только чатам, но и задачам, где полезно видеть весь фрагмент сразу: редактирование внутри текста, заполнение кода, строгие шаблоны, табличные или графовые структуры.

Скорость куплена качеством

Заявленные числа впечатляют. В официальном бенчмарк-слайде Google указывает 1107 токенов в секунду на H100 FP8 при batch size 1 против 303 у Gemma 4 26B A4B с MTP. В анонсе и developer guide также указаны 1000+ токенов в секунду на одной H100 и 700+ на GeForce RTX 5090. Hugging Face model card формулирует это как больше 1100 токенов в секунду в low-batch сценариях.

Но та же таблица объясняет компромисс. DiffusionGemma заметно уступает Gemma 4 26B A4B на MMLU Pro, AIME 2026, LiveCodeBench, GPQA Diamond, Tau2 и мультимодальных тестах. Модель всё равно поддерживает reasoning, code generation, long context до 256K токенов, image understanding, function calling и мультиязычность, но Google не прячет статус tech preview: если нужен лучший ответ, а не самая быстрая итерация, обычная Gemma 4 надёжнее.

Важно и то, где ускорение должно проявиться. Google отдельно предупреждает, что преимущество сильнее в локальном и low-concurrency выводе на выделенном ускорителе. В облаке с высоким потоком запросов классические авторегрессионные модели уже умеют эффективно загружать GPU батчами, поэтому выигрыш DiffusionGemma может уменьшаться или становиться дороже.

Почему это всё равно стоит внимания

Для разработчиков главный вопрос не «победила ли диффузия авторегрессию», а «какие интерфейсы становятся возможны при такой скорости». Если модель может быстро переписывать большой фрагмент, закрывать Markdown, дополнять код или перебирать варианты локально, появляется другой класс интерактивных инструментов: редакторы, IDE-помощники, быстрые агенты с множеством коротких шагов.

Пока это исследовательская ветка, а не новый стандарт. Но релиз показывает, что гонка открытых моделей идёт не только за размером, контекстом и бенчмарками. Следующий важный фронт — задержка для одного пользователя: как сделать локального ассистента не просто умным, а достаточно быстрым, чтобы он ощущался как часть рабочего интерфейса.