Google DiffusionGemma: генеруйте 256 токенів паралельно та самокоригуйтеся в процесі

Генератори зображень на базі штучного інтелекту, як-от Stable Diffusion, не малюють картинку піксель за пікселем зліва направо. Вони починають із шуму та поступово вдосконалюють усе зображення паралельно до його збіжності, у процесі, відомому як дифузія. Протягом багатьох років застосування цього ж принципу до генерації тексту залишалося недосяжним у масштабі.

Стандартні мовні моделі працюють подібно до друкарської машинки: один токен за раз, зліва направо, без можливості редагувати вже виведений результат. Така схема добре працює в хмарних середовищах, де розмір пакетів завдань забезпечує повне завантаження GPU. Для локальних обчислень або розгортання з низькою паралельністю GPU більшу частину часу простоює.

DiffusionGemma від Google, представлена цього тижня, є експериментальною моделлю з відкритим вихідним кодом, яка застосовує дифузію до генерації тексту в промислових масштабах. Побудована на базі Gemma 4 і випущена під ліцензією Apache 2.0, вона є першою дифузійною мовною моделлю, що нативно підтримується в платформі інференсу vLLM з відкритим кодом. Вона генерує блок з 256 токенів паралельно, а не послідовно, при цьому кожна позиція токена взаємодіє з усіма іншими. Google стверджує, що DiffusionGemma генерує текст до 4 разів швидше, ніж стандартні моделі на GPU. При розмірі пакету 1 на одному Nvidia H100 версія FP8 досягає 1008 токенів на секунду. На H200 показник становить 1288 — приблизно вшість разів швидше, ніж у стандартної авторегресійної моделі, згідно з результатами тестування vLLM, опублікованими сьогодні.

Незважаючи на приріст швидкості, Google не переоцінює можливості свого випуску. У дописі про запуск компанія прямо визнала, що загальна якість виведення DiffusionGemma нижча, ніж у стандартної Gemma 4, додавши: “Для застосувань, що вимагають максимальної якості, ми рекомендуємо розгортати стандартну Gemma 4”.

Що вміє DiffusionGemma

DiffusionGemma не генерує токени по порядку. Вона починає з блоку з 256 випадкових токенів-заповнювачів, фактично з чистого аркуша, і виконує кілька проходів уточнення по всьому блоку одночасно. На кожному проході вона оцінює кожну позицію і фіксує ті, в яких вона найбільш впевнена. Невизначені позиції рандомізуються і переглядаються на наступному проході, причому модель використовує те, що було вирішено на попередньому етапі, для наступної спроби. Блок поступово збігається доти, доки достатня кількість позицій не стабілізується, щоб закріпити решту.

З цієї архітектури випливають дві переваги:

• Самокорекція. Авторегресивна модель, яка робить вибір на користь неправильного токена, залишається з ним, оскільки наступні токени вже залежать від цієї помилки. DiffusionGemma може виявляти позиції з низькою впевненістю і переоцінювати їх на наступному проході.

• Двостороння контекстність. Кожна позиція одночасно взаємодіє з кожною іншою позицією в блоці, включаючи токени, що з’являються пізніше в послідовності. Це робить модель структурно краще пристосованою до завдань генерації з обмеженнями, де генерація зліва направо не працює.

Google продемонстрував обидві властивості за допомогою доналатованого розв’язувача судоку. Базова модель не розв’язала жодної головоломки. Після доналаштування на наборі даних судоку вона досягла 80% успіху і збіжності за 12 кроків шумозаглушення замість 48. Приріст ефективності був безпосередньо пов’язаний зі здатністю моделі самокоригуватися та зупинятися раніше.

Як це було створено

DiffusionGemma працює як модель Mixture of Experts (MoE) з 26 мільярдами параметрів, з яких під час інференсу активуються лише 3.8 мільярда. У квантованому вигляді вона вміщується в 18 ГБ VRAM на споживчому обладнанні, включаючи Nvidia RTX 4090 і 5090. Google і NVIDIA також оптимізували її для корпоративних серверів Hopper та Blackwell, використовуючи ядра NVFP4.

Інтеграція з vLLM вимагала нової роботи, оскільки DiffusionGemma не відповідає стандартній моделі обслуговування. Типовий пакет vLLM застосовує однаковий тип уваги до кожного запиту. Запити DiffusionGemma чергуються між причинною та двосторонньою увагою під час циклів читання підказок, уточнення полотна та фіксації блоку. Команда вбудувала перемикання уваги для кожного запиту як у бекенди Triton, так і в FlashAttention 4, і повторно використала існуючий шлях спекулятивного декодування для циклу уточнення.

Новий інтерфейс ModelState, розроблений командою для цієї інтеграції, призначений для підтримки додаткових дифузійних моделей у vLLM у міру їх появи.

Де спостерігається приріст швидкості, а де ні

Перевага DiffusionGemma у швидкості є реальною, але обумовленою. Її застосовність залежить виключно від контексту розгортання.

Цифри. При розмірі пакету 1 на одному H100, опубліковані бенчмарки vLLM показують, що модель FP8 приблизно вп’ятеро швидша за стандартну авторегресійну модель. На H200 — приблизно вшість разів. Ці пікові показники відображають оптимальні умови: один користувач, виділене обладнання, квантування FP8.

Де виграє. Локальний інференс, однокористувацькі застосунки та обслуговування з низькою паралельністю. За таких умов GPU має вільні обчислювальні потужності, а вузьким місцем стає пропускна здатність пам’яті. Паралельна генерація блоків DiffusionGemma заповнює цю прогалину.

Де не виграє. Хмарне обслуговування з високою пропускною здатністю. Коли сервер обробляє сотні одночасних запитів, авторегресивні моделі вже повністю завантажують доступні обчислювальні ресурси, і паралельне декодування DiffusionGemma дає незначний приріст.

Стеля якості. Гільєрме О’Тіна, дослідник ШІ, уточнив це на X. “Локальні артефакти проти галюцинацій — це різні проблеми, і саме це визначає, де саме це виграє”, — написав О’Тіна.

Порівняння

Дифузійні мовні моделі — не нове явище. Дослідники створювали їх у менших масштабах протягом кількох років, а Mercury Coder від Inception Labs комерційно застосував цей підхід до завдань кодування у 2025 році. DiffusionGemma додає масштабу — базову модель MoE на 26 мільярдів параметрів, нативне обслуговування через vLLM та модель загального призначення, що пройшла інструктивне налаштування, а не вузькоспеціалізовану.

Більш корисним порівнянням для інженерів, які оцінюють її проти існуючих інструментів інференсу, є спекулятивне декодування, і ця відмінність має значення. Спекулятивне декодування зберігає стандартну авторегресивну цільову модель і використовує меншу модель-чернетку для передбачення кількох наступних токенів. Цільова модель перевіряє їх за один прохід. Якщо вибірка правильна, розподіл вихідних даних залишається ідентичним цільовому. Архітектура не змінюється.

Ендрю Кунцевич, дослідник у галузі машинного навчання та ШІ, який спеціалізується на виробничих системах ШІ, прямо заявив на X: “DiffusionGemma відрізняється. Вона не просто вгадує майбутні токени. Вона створює зашумлене полотно з 256 токенів і багаторазово розшумлює весь блок паралельно. Отже, це не просто трюк декодування — це інший парадигма генерації”.

Порівняно зі стандартною Gemma 4, це компроміс між швидкістю та якістю. Дані бенчмарків Google показують, що DiffusionGemma поступається стандартній Gemma 4 за загальними показниками якості виведення, причому розрив залежить від завдання.

На структурованих завданнях з обмеженнями, включаючи доповнення коду, генерацію шаблонів та задачі, що вимагають двостороннього поширення обмежень, архітектура має структурну перевагу, яку може проявити доналаштування, як демонструє результат судоку. Для генерації у відкритому форматі стандартна Gemma 4 залишається потужнішим варіантом.

Що це означає для підприємств

DiffusionGemma надається через стандартний endpoint, сумісний з OpenAI для vLLM, без необхідності будь-яких специфічних для дифузії змін у конвеєрі.

Це не загальна модернізація моделі.

Для команд, що виконують локальний інференс або інференс з низькою паралельністю, вибір архітектури щойно розширився. До цього моменту, зменшення затримки генерації на виділеному обладнанні GPU означало використання меншої моделі та прийняття компромісу щодо якості. DiffusionGemma пропонує третій шлях з тим самим обсягом параметрів, на споживчому обладнанні, з підтримкою vLLM того ж дня.

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

Інтерфейс ModelState, розроблений для цієї інтеграції, призначений для узагальнення з появою додаткових дифузійних моделей.

Компроміс у якості є реальним, і Google це визнає. Для команд, що виконують локальний інференс на виділеному обладнанні GPU, це варто протестувати.

Порада від INFBusiness:

Ця новина є надзвичайно актуальною для розробників та інженерів, які займаються впровадженням моделей штучного інтелекту, особливо в сценаріях з обмеженими ресурсами або потребою у високій швидкості генерації. DiffusionGemma пропонує новий підхід до обробки тексту, який може суттєво прискорити локальні обчислення та покращити ефективність для специфічних завдань. Хоча якість може поступатися стандартним моделям, для певних застосувань, де швидкість є пріоритетом, це може стати революційним рішенням.

За даними порталу: venturebeat.com