Смысл предложения Google по LiteRT-LM простой: если разработчики хотят запускать модели уровня Gemma локально, главный барьер уже не только в размере модели. Сложность — в пути выполнения между памятью, ускорителем, состоянием сессии и приложением.
В публикации Google Developers Blog LiteRT-LM описывают как слой inference и orchestration для on-device GenAI на Android, iOS и в вебе. Google говорит, что стек уже используется в продуктах, включая Chrome, ChromeOS, Pixel Watch и приложение Google AI Edge Gallery. Заявленная цель — открыть тот же механизм edge inference внешним разработчикам, которые строят приложения на моделях Gemma.
Это важно, потому что производительность локальной LLM редко решает один показатель в бенчмарке. Обычно всё упирается в самый слабый участок цепочки: пропускную способность памяти, передачи между CPU/GPU, поддержку ускорителей, работу с KV cache, квантизацию модели и то, приходится ли приложению заново пересчитывать контекст каждый раз, когда пользователь возвращается.
Что Google пытается закрыть с помощью LiteRT-LM#
LiteRT-LM входит в стек Google AI Edge и использует LiteRT, ранее TensorFlow Lite, для inference. Google описывает его как runtime-слой для развёртывания моделей Gemma на устройствах с ограниченными ресурсами и неоднородными аппаратными backend.
Проблема знакома всем, кто выпускал локальный ML. Телефоны, ноутбуки, браузеры и носимые устройства не дают одной аккуратной цели для разработки. Модель, которая хорошо идёт по одному GPU-пути, на другом устройстве может болезненно откатиться на запасной вариант. Памяти мало. Ускорители разные. Веб добавляет ещё один слой ограничений.
Ответ Google — стек с поддержкой квантизации, ускоренными kernels и переносимостью между CPU, GPU и NPU. В публикации Google уточняет, что NPU-ускорение сейчас доступно на Android. Для веб-нагрузок указана WebGPU.
Ключевое заявление здесь не просто «быстрый локальный AI». Google пытается спрятать достаточно фрагментации backend, чтобы разработчики целились в runtime, а не вручную настраивали каждый путь развёртывания. Если это выдержит реальные условия приложений, абстракция выбрана правильно.
Цифры производительности сильные, но с узким контекстом#
Google приводит показатели decode для Gemma 4 E2B с LiteRT-LM в тестовых средах Android, iOS и веба. В публикации упоминается скорость decode 52 токена в секунду на Android через GPU backend с OpenCL и включённым Multi-Token Prediction. Также указано до 76 токенов в секунду decode в вебе через WebGPU на MacBook Pro.
Для inference на устройстве это сильные числа. Но это не универсальная гарантия.
Скорость decode зависит от варианта модели, квантизации, длины prompt, нагрева устройства, выбора backend, давления на память и поведения приложения вне самого модельного цикла. Телефон, который хорошо показывает себя в контролируемом прогоне, может вести себя иначе после нескольких минут непрерывной генерации, при активных фоновых приложениях или в режиме экономии батареи.
Самая полезная деталь в публикации — не пиковая пропускная способность. Важнее архитектура за ней: Google фокусируется на сокращении дорогих передач между CPU/GPU и удержании pipeline генерации ближе к железу, которое её выполняет. Именно там многие демо edge AI ломаются, когда становятся продуктами.
Multi-Token Prediction — главный рычаг ускорения#
Google отдельно выделяет встроенную поддержку Multi-Token Prediction, или MTP, в семействе моделей Gemma 4. В публикации сказано, что включение MTP в pipeline LiteRT-LM требует двух строк конфигурации и может дать ускорение decode до 2,2 раза. Google говорит, что эти числа были получены на Samsung S26 Ultra с GPU backend.
Технический смысл стоит отделить от маркетинговой подачи.
Обычный decode в LLM часто ограничен пропускной способностью памяти. Система снова и снова гоняет параметры модели и состояние через память, чтобы выдавать по одному токену. Speculative decoding пытается улучшить это: меньшая drafter-модель предлагает несколько будущих токенов, а основная модель их проверяет.
Наивная speculative-схема может сама добавить накладные расходы, если drafter и основная модель находятся на разных аппаратных путях или требуют дорогой синхронизации. Google утверждает, что LiteRT-LM избегает этого: MTP drafter и основная модель Gemma запускаются на одном аппаратном IP, например GPU, а общий KV cache и activations управляются локально.
Если такой дизайн стабильно работает, это реальное продуктовое преимущество. MTP превращается из трюка уровня статьи в механизм, который приложение может использовать без потери выигрыша на перемещении данных.
Оговорка: speculative decoding ускоряет throughput, когда предсказания достаточно часто принимаются, а путь проверки остаётся эффективным. Это не магия. Нагрузки с другими паттернами генерации, более длинным контекстом или мультимодальными шагами могут не получить тот же выигрыш.
Восстановление сессии может быть важнее пиковых токенов#
Менее шумная, но важная функция в публикации — сохранение и восстановление сессии.
Google говорит, что LiteRT-LM умеет сериализовать и сохранять большие состояния KV cache, позволяя возобновлять long-context диалоги или рабочие процессы без полного пересчёта контекста с нуля. На практике это может снизить prefill-затраты, когда пользователь возвращается к существующей сессии.
Это важно, потому что пользователи не воспринимают LLM как бенчмарк-цикл. Они открывают приложение, уходят, возвращаются, переключаются между задачами, продолжают чат, добавляют изображение или задают уточняющий вопрос. Если каждое возвращение заставляет модель заново строить контекст, продукт ощущается медленным даже при хорошей сырой скорости decode.
Сохранение сессии меняет и профиль ресурсов. Вместо повторной траты вычислений на один и тот же контекст приложение может сохранить состояние и продолжить работу. Это способно снизить задержку и расход энергии — при условии, что хранение, приватность и жизненный цикл реализованы правильно.
Здесь важна модель доверия. Состояние KV cache может отражать чувствительный контекст разговора. Разработчик, использующий восстановление сессии, должен понимать, где это состояние хранится, как оно защищено, когда истекает и может ли утечь между пользователями или контекстами приложения. Публикация Google сфокусирована на производительности, а не на полной security-модели.
Память — главное ограничение edge-сценариев#
Google также говорит о работе над снижением memory footprint для vision- и audio-возможностей Gemma. В блоге сказано, что LiteRT-LM не держит per-layer embeddings в памяти и динамически загружает image- и audio-encoders только тогда, когда они нужны задаче. Поэтому text-only нагрузки не должны платить полную цену мультимодальной поддержки.
Это правильное направление. On-device GenAI не выиграет за счёт постоянной загрузки всех возможных функций. Практичный runtime должен считать текстовый, визуальный и аудиопути условными расходами.
В публикации также сказано, что LiteRT-LM оптимизирует потребление CPU-памяти и направляет разработчиков к официальным model cards за конкретными memory benchmarks. Именно там стоит провести время до выбора архитектуры. Пиковые числа decode выглядят привлекательно. Но потолки памяти решают, какие устройства вообще смогут запустить функцию.
Что проверить перед разработкой на LiteRT-LM#
LiteRT-LM выглядит наиболее уместно для приложений, которым нужны низкая задержка локального inference, offline-режим, обработка чувствительных данных на устройстве или меньшая зависимость от серверов. Менее очевидна польза там, где приложению нужны самые крупные модели, централизованный контроль политик или одинаковое поведение на очень слабых устройствах.
Перед тем как считать LiteRT-LM runtime по умолчанию, разработчикам стоит проверить:
- целевую модель и квантизацию, а не только название семейства моделей
- реальные длины prompt и сессий, включая возврат к сохранённой сессии
- выбор backend на реальных устройствах: CPU, GPU, NPU и WebGPU, где это применимо
- нагрев после длительной генерации
- давление на память во время мультимодальных задач
- хранение и защиту сериализованного состояния сессии
- корректный fallback, когда предпочтительный ускоритель недоступен
Публикация делает убедительный кейс: Google упаковывает серьёзную работу над edge inference в стек, обращённый к разработчикам. Проверять нужно не то, может ли LiteRT-LM быть быстрым. По собственным числам Google — может. Вопрос в другом: останется ли он быстрым, приватным и предсказуемым в messy lifecycle реального приложения.