Новость — не релиз, а подробный отчёт

Команда Google DeepMind опубликовала технический отчёт DiffusionGemma — открытой экспериментальной языковой модели, которая генерирует текст не строго по одному токену слева направо, а итеративно уточняет блок из 256 токенов. Первая версия отчёта поступила на arXiv 31 июля 2026 года. Сама модель и веса появились 10 июня, поэтому событие сейчас — раскрытие архитектуры, измерений и ограничений, а не повторный «запуск» старого релиза.

Главная цифра отчёта — около 1500 выходных токенов в секунду на одной NVIDIA H100. Но это не универсальная скорость для любой локальной установки. Результат получен в FP8 при единичном запросе, с входом 4096 и выходом 1024 токена; авторы отдельно анализируют режим низкой параллельной нагрузки. Для бизнеса важнее не рекорд, а новый компромисс: можно обменять часть качества и больше вычислений на один токен на очень короткую задержку для отдельного пользователя.

DiffusionGemma опубликована с открытыми весами под Apache 2.0. Модель основана на Gemma 4 MoE, содержит 25,2 млрд параметров, но активирует примерно 3,85 млрд на токен. Доступны реализации для Hugging Face Transformers и vLLM, а также FP8 и NVFP4-квантизации. Это уже проверяемый стек, но разработчики называют выпуск экспериментальным.

Как diffusion LLM печатает абзац целиком

Обычная авторегрессионная LLM напоминает машинистку: следующий токен появляется после предыдущего. Даже если видеокарта умеет выполнять намного больше операций, каждый шаг снова читает веса и KV-кэш из памяти. При одном или нескольких запросах вычислительные блоки ускорителя могут простаивать, пока ограничением остаётся пропускная способность памяти.

DiffusionGemma сначала кодирует промпт и сохраняет контекст в KV-кэше. Затем создаёт «холст» из 256 случайных токенов и несколько раз пропускает весь блок через двунаправленное внимание. На каждом шаге более уверенные позиции фиксируются, остальные снова уточняются. После завершения блок записывается в историю, и начинается следующий.

По отчёту модель в среднем принимает около 20 токенов за один прямой проход и обычно завершает холст примерно за 12 проходов при адаптивной остановке. Для сравнения, современные варианты speculative decoding в описанном авторами режиме принимают ориентировочно 3–6 токенов за проход.

Каждый diffusion-проход тяжелее обычного: нужно обработать 256 позиций, больше экспертов MoE, двунаправленное внимание и отдельный sampler. На H100 один такой шаг оказался примерно в 3,2 раза медленнее одиночного авторегрессионного шага, но выпускал намного больше токенов. Поэтому итоговая скорость выросла.

Где бизнес действительно заметит разницу

Наиболее подходящий сценарий — локальная интерактивная система с одним пользователем или небольшой очередью, где ответ должен появляться почти сразу.

**Структурированное извлечение.** В отчёте показано, что жёстко заданный JSON и близкий к исходнику текст могут сходиться за два-три шага: синтаксис и большая часть содержимого предсказуемы сразу по всему блоку. Практическое применение — локальное извлечение полей из заявок, актов, счетов и анкет. Но JSON Schema и бизнес-проверки всё равно нужны после модели.

**Встроенное редактирование.** Двунаправленное уточнение естественно подходит для заполнения пропуска внутри текста или кода. Сотрудник фиксирует начало и конец фрагмента, а модель восстанавливает середину, учитывая оба края. Это полезнее обычного чата в редакторе договора, инструкции или программного кода.

**Короткие ответы агента.** Когда агент уже собрал факты из RAG и должен быстро сформировать компактный результат, низкая задержка улучшает ощущение от рабочего интерфейса. Особенно это заметно в локальном приложении, где нет большого пула одновременных пользователей.

**OCR и нормализация документов.** Diffusion-подход может одновременно исправлять связанные позиции, например структуру таблицы или формат реквизитов. Однако визуальная точность DiffusionGemma ниже обычной Gemma 4 в опубликованных сравнениях, поэтому исходные значения нужно сверять детерминированно.

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

1500 токенов в секунду — при каких условиях

В отчёте средний показатель для H100 FP8 составляет 1456 токенов в секунду при batch size 1; авторы округляют его до 1500. В том же измерении Gemma 4 AR дала 204 токена в секунду, а версия с multi-token prediction — 303. Это сравнение на одинаковом серверном ускорителе и в указанной конфигурации, а не обещание для ноутбука или обычной офисной видеокарты.

Ускорение возникает потому, что diffusion-декодирование меняет узкое место: меньше раз переносит большие объёмы данных из памяти, но выполняет больше арифметики. На современном GPU с высокой вычислительной плотностью это выгодно. На CPU, слабом ускорителе или архитектуре с другим соотношением памяти и вычислений преимущество может уменьшиться или исчезнуть.

Есть и предел по параллелизму. По измерениям авторов DiffusionGemma выигрывает у Gemma 4 с MTP по пользовательской задержке и общему throughput примерно до 32 одновременных запросов. Выше обычная авторегрессионная модель начинает выигрывать по общей пропускной способности из-за меньшей вычислительной стоимости токена. Команда подчёркивает, что реализацию ещё не оптимизировали специально для больших batch size и полноценные испытания на реальном трафике остаются будущей работой.

Вывод для малого и среднего бизнеса парадоксален: diffusion LLM интереснее не там, где огромная очередь, а там, где дорогая видеокарта обслуживает одного специалиста, локального агента или несколько интерактивных рабочих мест и недогружена вычислительно.

Качество: скорость оплачена компромиссом

DiffusionGemma не превосходит исходную Gemma 4 по большинству опубликованных тестов. В модельной карточке MMLU-Pro составляет 77,6% против 82,6%, AIME 2026 без инструментов — 69,1% против 88,3%, LiveCodeBench v6 — 69,1% против 77,1%. Это цифры разработчика, а не независимый аудит, и они не прогнозируют качество на русских документах конкретной компании.

Авторы прямо перечисляют причины разрыва: модель начинали с авторегрессионных весов вместо обучения diffusion-архитектуры с нуля, SFT был сравнительно коротким, а reinforcement learning и distillation целенаправленно оптимизировали малое число проходов. Иначе говоря, скорость заложена в функцию обучения, а не получена бесплатно.

Известные ограничения включают:

  • склонность к очень кратким ответам, что уменьшает потенциал длинных рассуждений;
  • редкие локальные повторы токенов или «заикание»;
  • иногда незакрытые теги размышления в мультимодальном режиме;
  • падение преимущества при высокой параллельной нагрузке;
  • фактические ошибки и неоднозначность, свойственные другим LLM.

Для производственного контура нужен watchdog: ограничение длины, обнаружение повторов, тайм-аут, валидация структуры и автоматический переход на обычную модель или очередь человеку.

Что потребуется для локального пилота

Полные веса BF16 для 25,2 млрд параметров теоретически занимают около 50 ГБ только под параметры, без KV-кэша, активаций и служебной памяти. Поэтому исходная версия рассчитана на ускоритель с большим объёмом памяти или распределённое размещение. FP8 примерно вдвое уменьшает объём весов, а 4-битная версия — примерно вчетверо; фактическое потребление будет выше этих нижних оценок из-за рантайма и контекста.

Минимальный проверяемый стек:

  • официальный checkpoint `google/diffusiongemma-26B-A4B-it`;
  • актуальные Transformers или vLLM;
  • отдельный тестовый GPU-контур;
  • OpenAI-совместимый шлюз для сравнения с текущей моделью;
  • журнал версии весов, sampler, квантизации и параметров остановки;
  • набор реальных обезличенных задач с эталонными ответами.

На старте не полагайтесь на случайную GGUF-конвертацию как на доказательство поддержки. В июньском объявлении официальная интеграция `llama.cpp` ещё была обещанием «скоро», хотя в репозитории уже существует экспериментальный diffusion CLI для нескольких архитектур. Для рабочего сервера нужно отдельно подтвердить именно DiffusionGemma, API-совместимость, качество квантизации и стабильность sampler на выбранной сборке.

Экономика: считать результат, а не токены

Рекорд TPS легко превращается в неверное инвестиционное решение. Если оператор ждёт 1,5 секунды вместо пяти, но затем исправляет каждый третий ответ, бизнес проигрывает. Если фоновая обработка документов идёт ночью большой пачкой, авторегрессионный сервер с batching может быть дешевле.

Модельный пример: 20 специалистов запускают по 50 коротких операций в день, каждая экономит три секунды ожидания. Это всего 50 минут командного времени в сутки. Даже при высокой стоимости часа такая экономия сама по себе может не окупить H100-класс. Но если задержка мешает интерактивному редактированию, увеличивает число прерванных сессий или тормозит цепочку из десяти шагов агента, эффект может быть намного больше.

Сравнивайте на одной задаче и по одному SLA:

  • p50 и p95 полной задержки, включая prefill и сеть;
  • число принятых без существенной правки результатов;
  • критические ошибки на 1000 операций;
  • запросы в час при реальной конкуренции пользователей;
  • энергопотребление и стоимость GPU-часа;
  • цена одного принятого результата;
  • доля запросов, ушедших на резервную модель или человеку.

TPS остаётся инженерной метрикой. Руководителю нужен рубль за проверенный результат и время до завершённого процесса.

Пилот на десять рабочих дней

**Дни 1–2.** Выберите один короткий сценарий с высокой ценностью задержки: JSON из заявки, исправление кода или заполнение пропуска в документе. Зафиксируйте качество и задержку текущей авторегрессионной модели.

**Дни 3–4.** Разверните DiffusionGemma в отдельном контуре. Используйте одинаковые входы, длину результата и правила постобработки. Не подключайте запись в CRM.

**Дни 5–7.** Прогоните не менее 200 типовых и граничных примеров. Измерьте не только скорость, но факты, структуру, повторы и долю ручных исправлений. Повторите тест при 1, 4, 16 и ожидаемом максимуме одновременных пользователей.

**Дни 8–9.** Добавьте автоматический fallback при повторе, тайм-ауте и провале схемы. Проверьте, не съедает ли переключение выигрыш по задержке.

**День 10.** Принимайте решение по матрице «качество — p95 — цена принятого результата». Если выигрыш есть только на H100, которого в производстве не будет, пилот не прошёл.

Что взять руководителю

Технический отчёт DiffusionGemma показывает, что diffusion LLM уже стала проверяемой инженерной альтернативой, а не только исследовательской идеей. Но её преимущество узкое: мощный локальный GPU, небольшая параллельная нагрузка, короткий структурированный результат и допустимый компромисс по качеству.

Не заменяйте текущую модель целиком. Выберите один latency-critical процесс, сравните две архитектуры на одном железе и оставьте маршрутизацию: diffusion для быстрых предсказуемых ответов, обычная LLM — для сложных задач. Внутрик уже печатает абзац целиком; редактор всё равно проверяет, не попала ли в тираж лишняя строка.