9 июля 2026 года Google выпустила LiteRT.js — привязку JavaScript для своей библиотеки вывода ИИ на устройстве, которая позволяет веб-разработчикам запускать модели машинного обучения прямо в вкладке браузера, без серверных вызовов и без передачи пользовательских данных с устройства. Библиотека обеспечивает ускоренный вывод на GPU через WebGPU в Chrome и Safari, достигая скорости до 3× выше, чем предыдущие веб-среды выполнения для моделей зрения и аудио, и до 60× выше, чем собственный CPU-путь, для требовательных рабочих нагрузок в реальном времени. Для разработчиков, которые сейчас платят за серверный вывод на небольших и средних моделях, последствия очевидны: эти нагрузки теперь могут выполняться на стороне клиента без затрат на каждый вызов, с той же нативной средой выполнения, которую Google использует на Android и iOS.
Запуск является частью более широкой инициативы Google, которую компания вновь дала понять на этой неделе. 13 июля на Google I/O Connect India компания продемонстрировала Gemma 4 E2B — свою новейшую малую языковую модель — работающую нативно на выделенном тензорном блоке обработки Pixel 10 полностью офлайн, и открыла Tensor SDK Beta для разработчиков, создающих решения для этого оборудования. LiteRT.js — это веб-уровень той же экосистемы: одна среда выполнения вывода, теперь охватывающая мобильные устройства, настольные ПК и браузеры.
TensorFlow.js против LiteRT.js: что изменилось и почему это важно
Предыдущее предложение Google для браузерного ИИ, TensorFlow.js, реализовывало свои ядра вывода на JavaScript и абстракциях более старой эпохи WebGL. Эти реализации ядер вносили накладные расходы из-за проверки типов, сборки мусора и интерпретируемой диспетчеризации — узкие места, которые делали браузерный вывод значительно медленнее нативного кода даже на быстром оборудовании. LiteRT.js применяет другой архитектурный подход: Google скомпилировала свою нативную среду выполнения на C++, включая библиотеку ускорения CPU XNNPACK и движок вывода GPU ML Drift, в WebAssembly. Этот WebAssembly-пакет и доставляется в браузер, полностью минуя уровень ядер JavaScript.
Практическое следствие: веб-приложение, использующее LiteRT.js, наследует тот же оптимизированный путь вывода, который работает в функциях ИИ на миллиардах устройств Android и iOS. Улучшения ядер, достижения в квантовании и аппаратная настройка, разработанная для мобильных устройств, автоматически распространяются на браузерные развёртывания через общую кодовую базу — без каких-либо дополнительных действий со стороны веб-разработчика.
LiteRT.js не заменяет TensorFlow.js полностью. Google позиционирует его как новый уровень выполнения для вывода моделей, в то время как TensorFlow.js остаётся рекомендуемым инструментом для пред- и постобработки — форматирования изображений, разбора выходных данных и подобных этапов пайплайна. Пакет @litertjs/tfjs-interop передаёт тензоры между двумя библиотеками, поэтому миграция является поэтапной: замените вызов выполнения модели, оставив существующую логику приложения на месте.
Как WebAssembly и WebGPU делают это возможным
Механизм работы LiteRT.js требует двух возможностей браузера, которые развивались параллельно. WebAssembly — портативный двоичный формат байт-кода, ставший рекомендацией W3C в 2019 году, — позволяет компилировать код на C++ и других нативных языках в формат, который любой современный браузер может выполнять с почти нативной производительностью в безопасной изолированной среде. Без WebAssembly не было бы практического способа доставить C++-ядра вывода Google на веб-страницу.
WebGPU обеспечивает второй уровень. В отличие от предшественника WebGL, WebGPU предоставляет выделенные вычислительные шейдеры — программы, выполняющиеся параллельно на сотнях ядер GPU, — предназначенные специально для вычислений общего назначения, а не для рендеринга графики. LiteRT.js направляет вывод на GPU через WebGPU с помощью ML Drift — движка вывода на GPU текущего поколения от Google. Итог: матричные умножения, свёртки и другие операции с тензорами выполняются как параллельные программы вычислительных шейдеров WGSL на графическом оборудовании пользователя, а не как последовательные инструкции JavaScript на одном потоке CPU.
Результат — два отдельных показателя производительности в тестах Google, проведённых на MacBook Pro 2024 года с чипом M4 в контролируемой браузерной среде. По сравнению с другими веб-средами выполнения LiteRT.js обеспечивает до 3× более быстрый вывод на классических моделях компьютерного зрения и обработки аудио. По сравнению с собственным путём CPU, переключение на ускорение GPU или NPU даёт ускорение от 5× до 60× для требовательных рабочих нагрузок в реальном времени, включая отслеживание объектов, транскрипцию аудио и манипуляцию изображениями. Google отмечает, что индивидуальные результаты будут различаться в зависимости от возможностей локального GPU, тепловых условий и оптимизации драйверов браузера — MacBook M4 представляет собой лучшее оборудование.
Три бэкенда, один API
LiteRT.js предоставляет три бэкенда вывода через единый интерфейс JavaScript. Путь CPU использует XNNPACK поверх WebAssembly с поддержкой многопоточности и сборкой с ослабленным SIMD для повышения пропускной способности. Этот путь работает в любом современном браузере независимо от наличия GPU и имеет самое широкое покрытие операций — что делает его универсальным запасным вариантом, когда модель не может быть запущена на аппаратных ускорителях.
Путь GPU использует ML Drift поверх WebGPU — именно здесь находится заявленная производительность. Путь NPU использует WebNN — развивающийся API, нацеленный на выделенные нейронные процессоры — ускорители машинного обучения, которые сейчас устанавливаются в потребительские ноутбуки и телефоны, — для энергоэффективного вывода с малой задержкой.
Ограничения V1, которые разработчикам нужно учитывать
Несколько ограничений в первоначальной версии требуют особого внимания при развёртывании в производственной среде.
LiteRT.js не поддерживает частичное делегирование. Граф модели не может быть разделён между CPU и GPU — делегирование является полным для каждой модели. В браузерах, поддерживающих JSPI (JavaScript Promise Integration), модель, граф которой содержит операции, неподдерживаемые бэкендом WebGPU, будет делегировать только эти операции обратно на путь CPU через WebAssembly. В стандартном Chrome без флагов JSPI вся модель переключается на выполнение на CPU, если хотя бы одна операция не поддерживается WebGPU. Это делает тестирование конкретных графов моделей на целевом оборудовании обязательным условием, а не дополнительной опцией; Google предоставляет для этого @litertjs/model-tester.
Тензоры, находящиеся на GPU, используют ручное управление памятью. Результаты, возвращаемые из вывода на GPU, находятся вне кучи, не управляются сборщиком мусора JavaScript. Разработчики должны явно вызывать .delete() для выходных тензоров, иначе возникнут утечки памяти GPU. Это задокументированное ограничение версии V1, не имеющее автоматического обходного пути.
Входные и выходные тензоры ограничены типами int32 и float32. Модели, требующие других точностей на границах ввода-вывода, не могут использовать LiteRT.js в текущем виде, хотя внутренние веса можно квантовать через AI Edge Quantizer для уменьшения размера и повышения скорости.
Очень большие модели могут превысить лимит памяти WebAssembly. Во многих средах этот предел составляет около 2 ГБ, что делает LiteRT.js плохо подходящим для больших языковых моделей и других тяжёлых архитектур в его текущей форме. Дорожная карта Google решает эту проблему с помощью LiteRT-LM.js — сопутствующего пакета, анонсированного на Google I/O 2026 в мае, который расширит поддержку браузеров специально для больших языковых моделей.
Поддержка WebGPU в браузерах также неравномерна, что скрывается за заголовками о производительности. Chrome (версия 113 и новее), Edge и Safari 26 на macOS Tahoe и iOS 26 поддерживают WebGPU. Firefox поддерживает WebGPU в Windows (версия 141 и новее) и на Mac с Apple Silicon (версия 145 и новее), но Firefox на Linux, Firefox на Android и Firefox на Intel Mac не имеют поддержки WebGPU по умолчанию по состоянию на середину 2026 года. Для этих пользователей и для любых пользователей на старых операционных системах LiteRT.js бесшумно переключается на путь CPU Wasm/XNNPACK — который всё ещё функционален, но работает на уровне производительности CPU, а не на показателях GPU, упомянутых в заголовках.
WebNN остаётся экспериментальным и требует ручного включения флагов JSPI; на момент написания статьи он не доступен ни в одном браузере.
Что можно запустить уже сегодня
Несмотря на ограничения, первоначальный выпуск включает рабочие демонстрации, выходящие далеко за рамки доказательства концепции. Google запустила LiteRT.js вместе с обнаружением объектов в реальном времени с помощью YOLO26 в браузере, оценкой глубины по одному изображению, преобразующей прямой эфир с веб-камеры в интерактивное 3D-облако точек через Depth-Anything-V2, увеличением разрешения изображения в 4× с помощью Real-ESRGAN и семантическим векторным поиском на стороне клиента с EmbeddingGemma. Демонстрации доступны через репозиторий LiteRT на GitHub и Ultralytics, который добавил официальную поддержку экспорта LiteRT в свой пакет Python.
Действительно ли пайплайн PyTorch сокращается до одного шага?
Формулировка «четыре шага конвертации до одного» верна для моделей, удовлетворяющих определённому условию: модели PyTorch должны быть экспортируемы через torch.export.export — путь экспорта, совместимый с TorchDynamo. Модели, содержащие ветвления на Python, зависящие от значений тензоров во время выполнения, или имеющие динамические размеры входа/выхода, включая размер батча, несовместимы с одношаговой конвертацией LiteRT Torch. Для таких моделей по-прежнему требуется более длинный путь конвертации. Для моделей, которые подходят, путь сокращается с PyTorch → ONNX → TensorFlow → TensorFlow.js до прямого преобразования PyTorch → .tflite, что является существенным упрощением разработки.
Что будет после LiteRT.js
Публично объявленная дорожная карта Google содержит два ближайших приоритета. Более глубокая интеграция WebNN нацелена на NPU, которые сейчас устанавливаются в потребительские устройства — путь, который обеспечит энергоэффективный вывод с малой задержкой в браузерах на оборудовании со встроенными ускорителями ИИ. LiteRT-LM.js, уже анонсированный на Google I/O 2026 и доступный через отдельный пакет, расширяет возможности браузерного вывода на большие языковые модели, позволяя запускать генеративный ИИ в браузере без сервера. Тесты Google для LiteRT-LM.js показывают скорость декодирования до 76 токенов в секунду на MacBook Pro с чипом M-series через WebGPU.
Более долгосрочный вопрос, на который компания не ответила напрямую, — это отношение между LiteRT.js и TensorFlow.js. В FAQ Google 2024 года, выпущенном после переименования TFLite в LiteRT, прямо говорилось, что «TensorFlow.js продолжит работать независимо как часть кодовой базы TensorFlow». О закрытии не объявлено. Заменит ли в конечном итоге TF.js LiteRT.js в качестве единственной собственной библиотеки веб-ML, или они будут сосуществовать в разных нишах — TF.js для предобработки, LiteRT.js для выполнения — остаётся открытым организационным вопросом, за которым разработчикам стоит следить.
Для разработчиков, оценивающих LiteRT.js сегодня
Система принятия решений проще, чем кажется на первый взгляд. Модели зрения, аудиоклассификаторы, генераторы эмбеддингов и пайплайны обработки изображений, которые уже работают как модели .tflite, выигрывают напрямую; их развёртывание в браузере теперь не требует серверного бэкенда вывода, затрат на каждый вывод в облаке и передачи пользовательских данных с устройства. Пользователи TensorFlow.js с существующими пайплайнами могут мигрировать поэтапно, заменяя только вызов выполнения модели, оставляя логику пред- и постобработки на месте.
Три случая, выходящие за рамки текущих возможностей: модели, слишком большие для лимита памяти Wasm; рабочие нагрузки, требующие централизованного управления — немедленного обновления моделей, аудита, ограничения скорости — что обеспечивает серверное развёртывание; и приложения, нацеленные на пользователей Firefox на Linux или Android, для которых ускорение WebGPU пока недоступно и для которых необходимо явно проектировать запасной путь на CPU.
LiteRT.js уже доступен как @litertjs/core в npm. Документация — LiteRT.js documentation.
Чем LiteRT.js отличается от TensorFlow.js для запуска ИИ в браузере?
TensorFlow.js реализовывал свои ядра вывода на JavaScript, что вносило накладные расходы, не позволяющие достичь скорости нативного оборудования. LiteRT.js поставляет реальный движок вывода Google на C++ — XNNPACK на CPU и ML Drift на GPU, скомпилированный в WebAssembly. Результат — тот же оптимизированный путь кода, который работает на устройствах Android и iOS, теперь доступен в браузере. TensorFlow.js не прекращает работу; они сосуществуют: LiteRT.js отвечает за выполнение модели, а TensorFlow.js остаётся полезным для этапов предобработки и постобработки данных.
Работает ли LiteRT.js в Firefox?
Частично. Путь на CPU через WebAssembly в LiteRT.js работает в любом современном браузере, включая Firefox, и показывает достойную производительность для небольших моделей. Путь с ускорением на GPU через WebGPU работает в Firefox 141 и новее в Windows, а также в Firefox 145 и новее на Mac с Apple Silicon. Firefox на Linux, Firefox на Android и Firefox на Intel Mac пока не поддерживают WebGPU по умолчанию, поэтому пользователи в этих конфигурациях получат только производительность на CPU. Если ваша аудитория включает значительное количество пользователей Firefox на Linux или Android, явно запланируйте и протестируйте запасной путь на CPU перед запуском.
Какие модели хорошо работают в LiteRT.js прямо сейчас?
Лучше всего подходят небольшие и средние модели зрения, аудио и эмбеддингов в формате .tflite — обнаружение объектов, классификация изображений, транскрипция аудио, оценка глубины и семантический поиск. Модели должны принимать входные и выходные данные типов float32 или int32. Очень большие модели, включая большинство больших языковых моделей, превышают лимит памяти WebAssembly во многих браузерных средах; LiteRT-LM.js — сопутствующий пакет, уже анонсированный и используемый, решает задачу вывода LLM с дополнительным управлением памятью для генеративных нагрузок.
Какова самая главная причина перейти с серверного бэкенда вывода на LiteRT.js?
Для любой нагрузки, работающей с пользовательским контентом — фотографиями, голосовыми записями, документами, данными о здоровье — архитектурный ответ — конфиденциальность: входные данные никогда не покидают устройство. Для разработчиков второй ответ — экономия: после того как пользователь загрузил модель, каждый вызов вывода ничего не стоит. Никакой подписки на API, никакого экземпляра GPU, никакой платы за запрос. Компромисс — размер модели и необходимость проектировать и тестировать плавный запасной путь на CPU для браузеров и устройств, где WebGPU недоступен.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Jerry Owens
