Генератори зображень на базі штучного інтелекту, такі як Stable Diffusion, не створюють малюнки піксель за пікселем зліва направо. Вони починають з шуму і поетапно вдосконалюють усе зображення паралельно до досягнення стабільності, що називається дифузійним процесом. Протягом років застосування цього ж принципу до генерації тексту залишалося недосяжним у масштабі.
Стандартні мовні моделі працюють подібно до друкарської машинки: один токен за іншим, зліва направо, без можливості перегляду вже згенерованого вихідного тексту. Цей підхід ефективний у хмарних середовищах, де великі пакети даних максимально завантажують обчислювальні потужності GPU. Однак для локального виконання або розгортання з низькою паралельністю GPU залишається в простої більшу частину часу.
DiffusionGemma від Google, представлений цього тижня, є експериментальною моделлю з відкритим кодом, яка застосовує дифузійний підхід до генерації тексту в промислових масштабах. Побудована на базі Gemma 4 і випущена під ліцензією Apache 2.0, вона є першою дифузійною мовною моделлю, яка нативно підтримується у відкритій платформі vLLM для інференсу. Вона генерує блок з 256 токенів паралельно, а не послідовно, причому кожна позиція токена взаємодіє з усіма іншими. Google стверджує, що DiffusionGemma генерує текст до 4 разів швидше, ніж стандартні моделі на GPU. При пакеті розміром 1 на одному Nvidia H100 модель досягає 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 ГБ відеопам’яті на споживчому обладнанні, включаючи 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 надає доступ через стандартний OpenAI-сумісний endpoint vLLM без необхідності внесення специфічних для дифузії змін у конвеєр.
Це не універсальне оновлення моделі.
Для команд, що виконують локальний інференс або інференс з низькою паралельністю, вибір архітектури тепер розширився. До цього моменту зменшення затримки генерації на виділеному обладнанні GPU означало використання меншої моделі та прийняття компромісу щодо якості. DiffusionGemma пропонує третій шлях з тим самим розміром параметрів, на споживчому обладнанні, з підтримкою vLLM того ж дня.
Для робочих навантажень із обмеженою генерацією варто розглянути двонаправлену увагу. Доповнення коду, генерація структурованих даних та завдання, де правильний вихід залежить від контексту, який ще не згенеровано, — це ті сфери, де ця архітектура має структурну перевагу.
Інтерфейс ModelState, створений для цієї інтеграції, призначений для узагальнення по мірі появи додаткових дифузійних моделей.
Компроміс щодо якості є реальним, і Google це визнає. Для команд, які виконують локальний інференс на виділеному обладнанні GPU, це варто протестувати.
Прогноз ІТ-Блогу: Дифузійні мовні моделі, подібні до DiffusionGemma, ймовірно, стануть стандартом для певних завдань, де швидкість та ефективність локального виконання є пріоритетом. Очікується подальше покращення якості вихідних даних та розширення підтримки в різних інференс-платформах, що зробить їх привабливою альтернативою традиційним авторегресійним моделям для багатьох сценаріїв використання.
Подробиці можна знайти на сайті: venturebeat.com