Google DeepMind робить черговий крок до того, щоб штучний інтелект працював не лише в хмарі, а й безпосередньо на телефонах, ноутбуках та IoT‑пристроях. На сесії AI Engineer Day продакт-менеджер Google AI Edge Чінтан Парік розповів про нове сімейство Gemma 4 — компактні моделі, оптимізовані для роботи на пристрої, з вбудованим викликом інструментів, структурованим JSON‑виводом та режимом «мислення» для прозорого ланцюжка міркувань.
Це не просто ще одна «маленька LLM». Gemma 4 намагається перенести можливості агентів і складного міркування туди, де раніше вистачало хіба що простих фільтрів камери чи автодоповнення тексту. І робить це в межах кількох гігабайтів оперативної пам’яті.
Від чатботів до локальних агентів: що змінює Gemma 4
Gemma як лінійка моделей уже відома тим, що охоплює широкий діапазон розмірів — аж до приблизно 270 мільйонів параметрів у найменших варіантах. Такі моделі можна запускати на дуже обмеженому «залізі» або донавчати під вузькі задачі. Але саме Gemma 4 позначає якісний зсув: акцент зміщується з базових чатботів до автономних агентів, які вміють міркувати, викликати інструменти й працювати з зовнішніми сервісами, залишаючись при цьому локальними.
Ключова новинка — поява спеціальних edge‑варіантів Gemma 4, орієнтованих на роботу безпосередньо на пристрої. Google DeepMind представила дві основні моделі для такого сценарію: Gemma 4 E2B та Gemma 4 E4B. Обидві розраховані на те, щоб інференс відбувався локально, а хмара використовувалася лише там, де це справді потрібно.
Це відповідає загальній тенденції: дедалі більше AI‑навантажень мігрує з дата-центрів на край — у смартфони, ноутбуки, камери спостереження, промислові контролери. Причини очевидні: затримка, приватність, робота офлайн і вартість. Але донині компроміс між розміром моделі та її можливостями був жорстким. Gemma 4 намагається розширити цю «зону можливого».
E2B та E4B: як вмістити агента в 1–2 ГБ RAM
Gemma 4 E2B — це, по суті, робоча конячка для мобільних і вбудованих сценаріїв. Після квантизації її споживання оперативної пам’яті оцінюється приблизно в 1–2 ГБ. Для сучасних смартфонів, планшетів або компактних одноплатних комп’ютерів це вже реалістичний поріг, особливо якщо модель запускається не постійно, а в рамках конкретних завдань: голосовий інтерфейс, локальне резюмування, обробка тексту чи зображень з низькою затримкою.
Цей клас моделей орієнтований на сценарії, де важливі:
- миттєва реакція — наприклад, голосові агенти, які мають відповідати без помітних пауз;
- конфіденційність — коли дані не можна або небажано виводити в хмару;
- робота в умовах нестабільного чи відсутнього підключення.
Gemma 4 E4B, своєю чергою, розрахована на «важчу» техніку: ноутбуки, десктопи, більш потужні IoT‑платформи. Вона вимагає більшого обсягу пам’яті, але натомість дає додатковий запас якості й можливостей для складніших агентних сценаріїв. Якщо E2B — це модель, яку можна «втиснути» в мобільний пристрій, то E4B — інструмент для тих, хто хоче будувати локальні агенти на рівні персонального комп’ютера або edge‑серверів.
Обидві моделі проходять квантизацію до цільового розміру, що дозволяє тонко налаштовувати баланс між якістю й ресурсами. Для розробників це означає можливість підбирати конфігурацію під конкретний клас пристроїв, а не підлаштовуватися під один «універсальний» варіант.
Важливо й те, що Gemma як сімейство не обмежується цими двома моделями. Наявність варіантів аж до ~270 млн параметрів відкриває шлях до надзвичайно компактних рішень — від простих класифікаторів до вузькоспеціалізованих помічників, які можна донавчити під конкретну галузь або продукт.
Вбудований function calling: локальний агент, який керує зовнішнім світом
Одна з найсуттєвіших змін у Gemma 4 — поява вбудованого function calling, тобто можливості викликати інструменти й API безпосередньо з моделі. Це давно стало стандартом для хмарних LLM, але для edge‑моделей така функція — відносно новий рівень складності.
Ідея проста: інференс відбувається на пристрої, але модель може ініціювати виклик локальних або віддалених API, коли це потрібно. Наприклад, локальний агент може:
- обробити голосовий запит на пристрої;
- вирішити, що для відповіді потрібні дані з енциклопедії;
- сформувати структурований виклик до інструмента, який звертається до Wikipedia;
- отримати результат і знову локально згенерувати відповідь користувачу.
Критично, що «мозок» цього процесу — саме Gemma 4, яка працює на пристрої. Вона не просто генерує текст, а виступає оркестратором, що керує інструментами. Це відкриває шлях до локальних агентів, здатних:
- комбінувати кілька інструментів у межах одного сценарію;
- працювати з локальними API, які взагалі не виходять в інтернет;
- гнучко поєднувати edge‑і хмарні сервіси, залишаючи чутливі дані на пристрої.
Для розробників це означає, що логіка інструментів може залишатися в застосунку або бекенді, а модель бере на себе інтерпретацію запитів користувача, планування кроків і виклик потрібних функцій. Вбудований function calling зменшує кількість «костилів» навколо моделі й спрощує побудову агентних систем, де LLM — не кінцевий пункт, а центральний вузол у більшій архітектурі.
Структурований JSON як «рідна мова» моделі
Ще одна важлива інновація Gemma 4 — нативна підтримка структурованого JSON‑виводу на рівні моделі. Замість того, щоб покладатися на хитромудрий prompt engineering і регулярні вирази для парсингу відповіді, розробники можуть очікувати від моделі чітко структурований JSON, який легко інтегрується в застосунок.
Це особливо важливо для edge‑сценаріїв, де:
- ресурси обмежені, і немає бажання витрачати їх на складний постпроцесинг;
- потрібна надійність — наприклад, коли модель повертає конфігурацію для іншого модуля, а не просто текст;
- застосунок повинен працювати стабільно без постійного «ручного» контролю.
Структурований вивід змінює сам підхід до проєктування локальних агентів. Замість «розумного текстового поля» розробник отримує компонент, який поводиться радше як сервіс: на вхід — дані й специфікація формату, на вихід — JSON, готовий до подальшої обробки. Це спрощує інтеграцію з інтерфейсами, базами даних, аналітичними модулями, а також з іншими моделями.
У поєднанні з function calling це дозволяє будувати ланцюжки, де:
- Gemma 4 приймає запит користувача;
- повертає JSON із планом дій або параметрами для інструмента;
- застосунок виконує цей план;
- результати знову подаються моделі у структурованому вигляді для формування відповіді.
Усе це може відбуватися без виходу за межі пристрою, що особливо цінно для конфіденційних або офлайн‑сценаріїв.
«Thinking mode»: як зробити міркування моделі прозорими
Gemma 4 також додає режим chain-of-thought — так званий «thinking mode», який дозволяє експліцитно показувати ланцюжок міркувань моделі. Для хмарних LLM ця техніка вже добре відома: моделі, які «думають уголос», часто дають кращі результати в задачах, що потребують багатокрокового аналізу. Тепер подібний підхід приходить і в edge‑світ.
У практичному вимірі це означає, що застосунок може:
- не лише отримати фінальну відповідь, а й проміжні кроки міркування;
- візуалізувати цей процес для користувача;
- використовувати ланцюжок думок для налагодження, аудиту або подальшої обробки.
Для локальних агентів це відкриває кілька важливих можливостей.
По‑перше, прозорість. Коли модель працює з персональними даними — наприклад, аналізує щоденникові записи, щоб відстежувати настрій і сон за останні сім днів, — користувачеві важливо розуміти, як саме вона дійшла до висновків. «Thinking mode» дозволяє показати, які фрагменти тексту були ключовими, як модель інтерпретувала зміни настрою, які закономірності побачила.
По‑друге, контроль. Розробники можуть аналізувати ланцюжки міркувань, щоб виявляти помилки, упередження або небажану поведінку моделі. Це особливо актуально для edge‑сценаріїв, де оновлення моделі може бути рідшим, а налагодження — складнішим, ніж у хмарі.
По‑третє, кероване міркування. Маючи доступ до проміжних кроків, застосунок може втручатися в процес: обрізати надто довгі ланцюжки, додавати додаткові обмеження, комбінувати міркування моделі з правилами або класичними алгоритмами.
У демонстраційних сценаріях, які показувалися на базі Gemma 4, цей режим використовується для задач, де потрібен не просто «відповісти на запит», а проаналізувати динаміку — наприклад, побудувати тренд настрою за тиждень на основі щоденних записів. Усе це відбувається на пристрої, без відправки персональних даних у хмару.
Оптимізація під «залізо»: одна модель — багато платформ
Щоб edge‑моделі були практично корисними, недостатньо просто зменшити кількість параметрів. Вони мають ефективно працювати на конкретному «залізі» — від мобільних CPU до GPU й NPU у ноутбуках та IoT‑пристроях. Gemma 4 edge‑варіанти оптимізовані саме під таке апаратно‑нативне виконання.
Це означає, що одна й та сама модель може:
- запускатися на різних платформах — Android, iOS, десктопні ОС, вбудовані системи;
- використовувати різні типи прискорювачів — CPU, GPU, а з часом і NPU;
- масштабуватися від легких мобільних сценаріїв до більш вимогливих настільних застосунків.
У демонстраційних прикладах розробники можуть навіть перемикати тип прискорювача — наприклад, запускати генерацію звуку з текстового запиту на CPU або GPU, залежно від доступності ресурсів. Для edge‑екосистеми це важливо: виробники пристроїв і чипів активно просувають власні NPU та інші прискорювачі, і моделі, які вміють ефективно їх використовувати, отримують помітну перевагу в затримці й енергоспоживанні.
Gemma 4 інтегрується в ширший стек Google для on‑device AI, де базовим шаром виступає LiteRT — фреймворк, побудований на форматі TensorFlow Lite. Саме він забезпечує виконання моделей на мільйонах пристроїв, підтримуючи конвертацію з TensorFlow, PyTorch і JAX у єдиний формат. Для розробників це означає, що Gemma 4 edge‑моделі можна вбудовувати в уже існуючу інфраструктуру, не змінюючи повністю стек.
Від демо до продукту: відкриті моделі й екосистема
Щоб зробити Gemma 4 доступною для розробників, Google розміщує моделі на сторінці в Hugging Face під ліцензією Apache 2.0. Це одна з найліберальніших ліцензій у світі open source, яка дозволяє використовувати, модифікувати й вбудовувати моделі в комерційні продукти без складних юридичних обмежень.
Наявність моделей у відкритому доступі важлива з кількох причин.
По‑перше, це знижує бар’єр входу. Розробники можуть завантажити Gemma 4 E2B або E4B, поекспериментувати з ними локально, інтегрувати в прототипи, не чекаючи окремих угод чи доступів.
По‑друге, це стимулює екосистему. Навколо моделей уже формується спільнота, яка ділиться прикладами використання, донавчання, оптимізації під конкретні пристрої. У випадку Gemma 4 це доповнюється відкритими застосунками й репозиторіями, де користувачі публікують власні «скіли» — від запитів до Wikipedia до генерації звуку з тексту.
По‑третє, це створює прозорість. Розробники можуть аналізувати поведінку моделей, тестувати їх на власних датасетах, будувати навколо них додаткові захисні шари, не покладаючись на «чорну скриньку» хмарного API.
У підсумку Gemma 4 edge‑моделі стають не лише технологічним продуктом Google DeepMind, а й будівельним блоком для ширшої екосистеми on‑device AI, де локальні агенти, інструменти й апаратні прискорювачі працюють разом.
Що означає Gemma 4 для майбутнього on‑device AI
Поява Gemma 4 E2B та E4B із вбудованим function calling, нативним JSON‑виводом і режимом chain-of-thought показує, що on‑device AI виходить за межі «урізаних» версій хмарних моделей. Це вже не просто компроміс заради економії трафіку чи затримки, а окремий клас систем із власними сильними сторонами.
Для розробників це відкриває кілька стратегічних напрямів.
По‑перше, побудова гібридних архітектур, де локальні моделі беруть на себе приватні, низьколатентні задачі, а хмара використовується лише там, де потрібні великі моделі або доступ до зовнішніх даних.
По‑друге, створення персоналізованих агентів, які працюють із чутливими даними — щоденниками, фото, аудіозаписами — не виводячи їх за межі пристрою, але при цьому мають доступ до зовнішніх інструментів через контрольовані API.
По‑третє, розгортання інтелекту безпосередньо на краю інфраструктури — в камерах, сенсорах, промислових системах, де затримка й надійність важливіші за абсолютну «потужність» моделі.
Gemma 4 не вирішує всіх проблем on‑device AI, але задає нову планку очікувань: невеликі моделі можуть не лише відповідати на запитання, а й міркувати, планувати, викликати інструменти й працювати зі структурованими даними — і все це в межах кількох гігабайтів оперативної пам’яті.
Як швидко індустрія зможе повністю скористатися цими можливостями, залежить від готовності розробників переосмислити архітектуру своїх застосунків. Але вектор уже окреслено: інтелект рухається ближче до користувача — буквально в його кишеню.
Джерело
Accelerating AI on Edge — Chintan Parikh and Weiyi Wang, Google DeepMind