У Google DeepMind активно вибудовують нову інфраструктуру для штучного інтелекту «на краю» — безпосередньо на смартфонах, ноутбуках, IoT‑девайсах та навіть у браузері. На конференції AI Engineer продукт‑менеджер Google Чінтан Парік розповів про LiteRT — оновлений on‑device фреймворк, що лежить в основі Google AI Edge, та про те, як він поєднує сучасні моделі на кшталт Gemma 4 з апаратним прискоренням і кросплатформенним деплоєм.
Сьогодні LiteRT — це не експериментальний SDK, а промисловий стек, який працює в понад 100 тисячах застосунків із мільярдами активних користувачів. Його завдання — дати розробникам єдиний формат моделей, єдину точку деплою та доступ до CPU, GPU й NPU на різних платформах, не змушуючи переписувати код під кожен тип пристрою.
Від TensorFlow Lite до LiteRT: що саме змінилося
LiteRT — це нове ім’я для добре знайомої екосистеми TensorFlow Lite, але з чітким позиціонуванням як універсального on‑device AI‑фреймворку Google. В основі LiteRT лежить той самий формат моделей TensorFlow Lite (TFLite), який роками використовувався в Android‑застосунках, вбудованих системах та на інших платформах.
Ключовий момент: моделі, побудовані раніше на TensorFlow Lite, продовжують працювати під LiteRT без будь‑яких змін формату. Для розробників, які вже мають продакшн‑додатки з TFLite‑моделями, це означає повну зворотну сумісність. Немає потреби перетреновувати, переконвертовувати чи мігрувати моделі в новий бінарний формат — LiteRT просто підхоплює існуючий стек.
Водночас LiteRT формалізує те, що давно назріло в індустрії: тренувати можна де завгодно, а деплоїти — в один уніфікований формат. Фреймворк підтримує моделі, які походять з TensorFlow, PyTorch та JAX, за умови, що вони конвертовані у файл формату TensorFlow Lite. Це створює багатофреймворкову історію тренування з єдиною ціллю деплою: незалежно від того, де й як ви тренували модель, на пристрої вона виглядає як TFLite‑файл, який виконує LiteRT.
Для Google це спосіб закріпити TFLite як де‑факто стандарт on‑device формату, а для розробників — спосіб уникнути фрагментації, коли під кожен фреймворк чи платформу потрібен свій рантайм.
Один формат — усі платформи: як LiteRT розв’язує кросплатформений хаос
Одна з головних обіцянок LiteRT — однаковий формат моделі й однаковий стек виконання на всіх основних платформах. Той самий TFLite‑файл, який працює на Android, може бути використаний на iOS, macOS, Linux, Windows, у вебі та на IoT‑пристроях.
Це важливо з кількох причин.
По‑перше, зникає потреба підтримувати окремі гілки моделей під мобільні, десктопні та вбудовані системи. Команда може мати один артефакт моделі, який проходить тестування й валідацію, а потім розповсюджується в усі клієнтські застосунки.
По‑друге, спрощується життєвий цикл оновлень. Коли виходить нова версія моделі — наприклад, оновлений варіант Gemma 4 для кращого reasoning чи нових функцій — розробник не мусить готувати окремі збірки під кожну ОС. Достатньо оновити TFLite‑файл і, за потреби, налаштування LiteRT‑рантайму.
По‑третє, це знижує поріг входу для команд, які хочуть вийти за межі однієї платформи. Якщо стартап починає з Android‑додатку, але згодом вирішує зробити десктопний клієнт або веб‑демо, модельна частина залишається незмінною. LiteRT бере на себе роботу з адаптації до конкретного середовища виконання.
У підсумку LiteRT перетворюється на своєрідний «універсальний адаптер» між світом тренування моделей і строкатим зоопарком клієнтських пристроїв. Для Google це також спосіб забезпечити консистентну поведінку моделей у власних і партнерських продуктах, незалежно від того, де саме вони працюють.
Масштаб продакшену: 100 тисяч застосунків і мільярди користувачів
На відміну від багатьох нових AI‑фреймворків, LiteRT не стартує з нуля. Це еволюція стеку, який уже давно використовується в екосистемі Google та поза нею. За оцінками компанії, LiteRT (на базі TensorFlow Lite) розгорнутий більш ніж у 100 000 застосунків, які сумарно обслуговують мільярди активних користувачів.
Ці цифри важливі не лише як маркетинговий аргумент. Вони означають, що:
модельний формат перевірений у величезній кількості сценаріїв — від простих класифікаторів до складних мультимодальних пайплайнів;
рантайм витримує навантаження з мільярдами щоденних інференсів, включно з жорсткими вимогами до енергоспоживання, затримок і стабільності;
екосистема інструментів, прикладів і best practices навколо TFLite/LiteRT уже сформована, а не створюється з нуля.
Для розробників це означає, що LiteRT — не експериментальний шлях, а продакшен‑рішення, яке вже використовується у великій кількості комерційних продуктів. А для Google — що будь‑які зміни в стеку мусять бути обережними й зворотно сумісними, і саме тому збереження TFLite‑формату стало ключовим принципом LiteRT.
CPU, GPU, NPU: як LiteRT працює з апаратним прискоренням
Одне з головних завдань on‑device AI — знайти баланс між продуктивністю та енергоспоживанням. LiteRT пропонує розробникам гнучкий доступ до різних типів апаратних ресурсів, дозволяючи обирати, де саме виконувати модель: на CPU, GPU чи NPU, залежно від можливостей пристрою й вимог застосунку.
Підтримка CPU є базовою й універсальною. Вона гарантує, що модель запуститься практично на будь‑якому пристрої, навіть якщо там немає спеціалізованого прискорювача. Для багатьох сценаріїв — наприклад, періодичної обробки тексту чи невеликих моделей — цього достатньо.
GPU‑прискорення дає змогу суттєво зменшити затримки для більш важких моделей або реального часу, наприклад, для обробки відео чи складних мультимодальних задач. LiteRT підтримує GPU на кількох платформах, що дозволяє використовувати графічні процесори як універсальний прискорювач там, де немає NPU.
Найцікавіший напрямок — інтеграція з нейромережевими процесорами (NPU) у сучасних мобільних SoC. LiteRT уже завершив інтеграцію з Qualcomm та MediaTek, що означає можливість апаратно‑нативного виконання моделей на їхніх NPU. Для розробників це відкриває шлях до:
значно кращої енергоефективності порівняно з GPU;
нижчих затримок для складних моделей, зокрема мовних;
звільнення CPU та GPU для інших задач застосунку.
У демо‑сценаріях, які показувалися разом із Gallery‑застосунком, розробник міг перемикатися між CPU та GPU, а NPU‑підтримка позначалася як наступний крок. У продакшн‑середовищі LiteRT прагне зробити цей вибір максимально прозорим: фреймворк має самостійно підбирати оптимальний бекенд, а розробник — лише визначати пріоритети між швидкістю, якістю й енергоспоживанням.
Фактично LiteRT перетворює різнорідний парк мобільних і вбудованих чипів на єдину абстракцію, де модель «бачить» лише доступні прискорювачі, а не конкретні реалізації від Qualcomm чи MediaTek.
Gemma 4 і LiteRT: відкриті моделі для on‑device‑сценаріїв
Хоча ця стаття зосереджена на LiteRT, важливо, що Google розвиває стек у зв’язці з власними моделями. Для on‑device‑сценаріїв ключову роль відіграють Gemma 4 E2B та E4B — компактні мовні моделі на 2 та 4 мільярди параметрів, оптимізовані для роботи на пристрої після квантизації.
E2B орієнтована на використання приблизно 1–2 ГБ оперативної пам’яті, що робить її придатною для сучасних смартфонів та інших обмежених пристроїв. Вона підходить для голосових інтерфейсів, локального підсумовування, приватних чат‑сценаріїв та інших задач, де важливі низька затримка й офлайн‑режим.
E4B розрахована на більші платформи — ноутбуки, десктопи, потужні IoT‑девайси — і вимагає більше пам’яті, але натомість дає вищу якість і складніші можливості. Обидві моделі після квантизації можуть виконуватися через LiteRT, використовуючи CPU, GPU або NPU залежно від пристрою.
Gemma 4 додає кілька важливих можливостей на рівні самої моделі: вбудований function calling для виклику інструментів та API з on‑device‑інференсу, нативну підтримку структурованого JSON‑виводу та «thinking mode» з chain‑of‑thought, який дозволяє експліцитно відображати хід міркувань моделі. Усе це працює в тісній зв’язці з LiteRT як рантаймом, що забезпечує виконання на пристрої.
Ще один важливий елемент — спосіб розповсюдження моделей. Google розміщує Gemma та інші невеликі моделі на сторінці в Hugging Face під ліцензіями Apache 2.0. Це спрощує їх отримання й інтеграцію в застосунки на базі LiteRT: розробник може завантажити модель, сконвертувати її в TFLite‑формат (якщо це не зроблено заздалегідь), а далі використовувати як стандартний артефакт у своєму on‑device‑стеку.
Таким чином, LiteRT і Gemma 4 утворюють повноцінний ланцюжок: від відкритих моделей, доступних на Hugging Face, до їхнього виконання на смартфонах, ноутбуках і IoT‑пристроях із використанням апаратного прискорення.
Gallery як вітрина стеку: що показує демо‑застосунок
Щоб продемонструвати, як LiteRT працює в реальних сценаріях, Google створила Gallery — відкритий застосунок‑пісочницю, який показує можливості Gemma 4 на пристрої. Усі ключові сценарії в Gallery — від агентних навичок до аудіо‑транскрипції, запитів до зображень і чат‑інтерфейсів — виконуються локально, поверх LiteRT.
Gallery виконує кілька ролей одночасно. Для розробників це практичний приклад того, як будувати on‑device‑агентів, інтегрувати function calling, працювати зі структурованим JSON‑виводом і комбінувати різні модальності. Для інженерів‑платформників — демонстрація того, як LiteRT взаємодіє з CPU, GPU й у перспективі NPU, і як можна перемикати бекенди залежно від задачі.
Кожна можливість у Gallery супроводжується зразком коду, який можна взяти за основу. Сам застосунок є open source на GitHub, його можна форкнути й модифікувати під власні потреби. Окремий публічний репозиторій слугує майданчиком, де користувачі діляться власними «skills» — розширеннями агентних можливостей, які також працюють повністю на пристрої.
Gallery не є обов’язковою частиною LiteRT, але добре ілюструє, як виглядає повний стек Google AI Edge у дії: відкриті моделі Gemma 4, TFLite‑формат, LiteRT як рантайм, апаратне прискорення й прикладний рівень у вигляді агентів, що працюють без підключення до хмари.
Чому LiteRT важливий для майбутнього on‑device AI
Розвиток LiteRT відображає ширший тренд в індустрії: дедалі більше AI‑навантажень переїжджають з хмари на край. Причини очевидні — затримки, приватність, вартість токенів і трафіку, офлайн‑режим. Але для того, щоб цей перехід став масовим, потрібна стабільна, кросплатформена й апаратно‑агностична інфраструктура.
LiteRT претендує на роль такого базового шару. Він пропонує:
єдиний формат моделей на основі TensorFlow Lite, який уже довів свою життєздатність у продакшені;
багатофреймворкову історію тренування з конвертацією з TensorFlow, PyTorch і JAX;
кросплатформенний деплой на Android, iOS, десктопах, вебі та IoT без зміни модельного формату;
гнучке апаратне прискорення з підтримкою CPU, GPU та інтеграцією NPU від Qualcomm і MediaTek;
зворотну сумісність із наявними TFLite‑моделями, що захищає інвестиції розробників.
У поєднанні з відкритими моделями Gemma 4, доступними на Hugging Face під Apache 2.0, це створює відносно прозорий шлях від досліджень до продакшену: модель можна тренувати в улюбленому фреймворку, конвертувати в TFLite, розгорнути через LiteRT і доставити на будь‑який пристрій — від смартфона до ноутбука чи IoT‑сенсора.
У міру того, як моделі стають меншими й ефективнішими, а апаратні прискорювачі — потужнішими й масовішими, роль таких стеків лише зростатиме. LiteRT уже сьогодні показує, як може виглядати стандартна інфраструктура для on‑device AI, де розробник думає не про те, як змусити модель запуститися на конкретному чипі, а про те, які саме можливості дати користувачеві — з урахуванням затримок, приватності та вартості.
Висновок
LiteRT — це спроба Google стандартизувати й спростити весь ланцюжок on‑device AI: від тренування в різних фреймворках до виконання на широкому спектрі пристроїв з використанням CPU, GPU та NPU. Збереження формату TensorFlow Lite як основи, зворотна сумісність із наявними моделями, кросплатформенна підтримка й глибока інтеграція з мобільними SoC роблять LiteRT не просто ще одним SDK, а фундаментальним елементом екосистеми Google AI Edge.
У поєднанні з відкритими моделями Gemma 4, які легко отримати з Hugging Face під Apache 2.0, LiteRT формує практичний шлях для команд, що хочуть перенести AI‑функціональність ближче до користувача — на сам пристрій. І судячи з масштабу вже існуючого розгортання, цей шлях перестав бути нішевим експериментом і перетворюється на нову норму.
Джерело
Accelerating AI on Edge — Chintan Parikh and Weiyi Wang, Google DeepMind