На конференции FrontKon в Праге разработчица Сильвия Ласковска спросила зал, кто слышал про WebGPU. Руку подняли три или четыре человека. В зале сидели люди, которые каждый день делают веб-приложения, и почти никто не знал про API, ускоряющий параллельные вычисления в браузере в десятки раз. Без него не было бы главного сюжета последних двух лет: нейросетей, которые работают прямо в браузерной вкладке.

Год назад Ласковска уже экспериментировала с моделями в браузере и посмеивалась: забавная игрушка, не больше. Перед FrontKon она обновила Transformers.js до версии 4.3.1, взяла свежие модели и пересобрала демо. Результат оказался другим. Пять функций, каждая из которых могла бы жить в обычном продукте: удаление фона у фотографии, генерация alt-текстов, превращение хаотичной жалобы в структурированную заявку в поддержку, семантический поиск по базе обращений и вопросы к камере в реальном времени. Код открыт на GitHub, демо можно потрогать руками.

В этом разборе: что именно умеет ИИ в браузере уже сегодня, какие модели за этим стоят, сколько они весят и где технология честно ломается.

Что такое ИИ в браузере

ИИ в браузере означает запуск нейросетей силами самой веб-страницы: модель скачивается один раз, кэшируется и дальше работает на устройстве пользователя через WebGPU или WebAssembly. Внешний сервер не участвует ни в вычислениях, ни в передаче данных.

Ещё недавно такие модели годились только для демок. Сейчас изменились три вещи: библиотеки довели до зрелости (в демо используется Transformers.js 4.3.1), появились компактные, но способные модели, а WebGPU наконец пришёл в основные браузеры. WebGPU даёт странице прямой доступ к GPU, и для параллельных вычислений это ускорение в десятки раз по сравнению с CPU. Именно поэтому удивление в зале FrontKon было таким показательным: технология уже здесь, просто о ней мало кто знает.

Само демо устроено буднично. Это обычное React-приложение на TypeScript. Модели подключены через Transformers.js: там, где есть WebGPU, инференс идёт на видеокарте, на остальных устройствах включается запасной путь через WebAssembly на CPU. Вычисления вынесены в Web Workers, чтобы не блокировать интерфейс, а модели загружаются по требованию: чтобы открыть приложение, не нужно качать все пять сразу. Ни одного обращения к AI-бэкенду.

Мы уже разбирали внутренности похожего проекта: в расширении Chrome с Gemma 4 модель живёт в service worker, чат в side panel, а content script достаёт данные со страницы. Демо Ласковской это следующий шаг: не расширение, а обычный сайт, где локальные модели решают пять прикладных задач. Ещё одна оговорка от автора: это пока не агенты. Каждая модель решает одну конкретную задачу, про браузерных агентов Ласковска обещает рассказать отдельно.

Из этого устройства следует ещё одно свойство, о котором редко вспоминают: после первой загрузки модели функции работают офлайн. Если само приложение умеет обходиться без сети, поиск по базе обращений и генерация alt-текстов продолжат работать в самолёте или при упавшем Wi-Fi, потому что инференс никуда не ходит.

Что умеет ИИ в браузере: пять рабочих примеров

Автор специально брала не игрушки, а сценарии из реальных продуктов: электронная коммерция, доступность, поддержка клиентов.

Удаление фона у фотографии

Модель RMBG-1.4, около 44 млн параметров, весит примерно 170 МБ. Она отделяет объект от фона и отдаёт прозрачный PNG, и делает это на удивление хорошо. Представьте доску объявлений или маркетплейс: кнопка «убрать фон» встроена прямо в форму продажи товара. Продавцу не нужен фоторедактор, а фотография не покидает его устройство. Заодно это доказательство, что текстовая генерация не единственное, что умеют браузерные модели: работа с изображениями тоже поехала. Одна оговорка: у самой модели есть лицензионные условия, и перед коммерческим запуском их нужно проверить.

Alt-тексты для картинок

Florence-2-base-ft, около 230 млн параметров, 350-450 МБ в зависимости от точности вычислений. Сценарий про доступность: при загрузке изображения сайт предлагает готовое описание, которое человек редактирует перед публикацией. Автор честно предупреждает, что хороший alt-текст зависит от контекста, которого модель не знает, поэтому она иногда путает детали и добавляет лишнее. Она годится как черновик для редактора, а не как финальный текст без проверки.

Из хаоса в структуру: заявка в поддержку

Qwen2.5-0.5B-Instruct, около 500 млн параметров, примерно 786 МБ плюс файлы токенизатора. Идея: пользователь пишет жалобу как умеет, а приложение превращает её в заявку с заполненными полями. Ласковска ожидала, что это будет самая лёгкая функция, и ошиблась сильнее всего. Уложить языковую модель в стабильный формат оказалось тяжело: она то выдумывала лишние поля, то возвращала битый JSON. Пришлось подбирать промпт, разбирать вывод парсером и валидировать схему через Zod. Заявка остаётся редактируемой, человек проверяет её перед отправкой. Именно этот паттерн, где ИИ делает скучную черновую работу, а человек контролирует результат, автор советует для продакшена.

Семантический поиск

all-MiniLM-L6-v2, всего 22 млн параметров: 23 МБ в квантованном варианте для CPU или 90 МБ для WebGPU. Здесь маленькие модели раскрываются лучше всего. Приложение ищет не по совпадению слов, а по смыслу: обращения и запрос превращаются в векторы, похожесть считается через косинусную близость, генеративная модель не нужна вовсе. Рядом стоит обычный поиск по ключевым словам, и разницу видно сразу. Главный урок экспериментов: для узкой задачи специализированная маленькая модель часто полезнее большой универсальной. Для чувствительных данных это ещё и приватность: обращения не уходят на внешний сервер, поиск идёт по векторам внутри вкладки.

Пауза и вопрос к камере

LFM2.5-VL-450M, около 450 млн параметров, 350-400 МБ. Два режима: живое описание того, что видит веб-камера, и пауза с вопросами по застывшему кадру. Самая эффектная и самая ненадёжная функция. Модель уверенно описывает сцену и так же уверенно ошибается в мелочах. Автор считает это экспериментом в области visual question answering, где модель отвечает на вопросы о содержимом кадра, а не инструментом доступности.

Что мешает: WebGPU не везде, а модели тяжёлые

Пять функций работают настолько хорошо в основном благодаря WebGPU, и здесь начинаются сложности. Поддержка зависит от версии браузера, операционной системы, видеокарты и драйверов. Даже если API доступен, у пользователей разное железо. Особенно больно на мобильных: у Ласковской Samsung Galaxy S24 FE, и два демо на телефоне просто не запустились по таймауту. Это не музейный экспонат, а вполне рабочий смартфон. Когда WebGPU недоступен, Transformers.js иногда откатывается на CPU-путь через WebAssembly с SIMD и многопоточностью, но скорость падает заметно.

Второе ограничение это размеры загрузки. В демо модели весят от 23 МБ до почти 800 МБ. Первый визит с мобильного интернета превращается в скачивание сотен мегабайт, а браузерный кэш никто не гарантирует навсегда. Отсюда практическое правило: такие функции стоит предлагать как опциональное улучшение, а не как обязательную загрузку при входе. Платить приходится не только трафиком: вычисления ложатся на батарею и процессор пользователя, а вкладка с работающей моделью ест заметно больше памяти. Один из инженеров в комментариях к разбору пошутил, что несколько таких вкладок превратят Chrome в настоящего пожирателя ресурсов. Шутка с намёком: поэтому такие функции включают по требованию, а не держат запущенными постоянно.

Третье: часть идей не взлетела. Распознавание текста на изображениях не дало приемлемого качества ни в одной из перепробованных конфигураций, и из демо его убрали. Контекстные alt-тексты, где к картинке добавляется пояснение вроде «эта собака из приюта, её можно забрать», модель так и не научилась учитывать: пришлось оставить простой вариант, где контекст присоединяется к описанию сбоку.

Готов ли ИИ в браузере к продакшену

Вердикт автора: да, но с оговорками. Не как замена облачных моделей и не как критичная зависимость без запасного пути. Как опциональная функция, которая улучшает продукт, уже сейчас. Экономика здесь простая: нет счёта за токены, нет лимитов API, пользовательские данные не уходят третьей стороне. Всё упирается в устройство: скорость зависит от железа, а качество от того, насколько узкая задача и насколько удачно подобрана модель.

Есть и показательная деталь: Chrome давно сам скачивает модель Gemini Nano размером около четырёх гигабайт, так что к загрузке моделей браузеры уже привыкли. Разница в подходе: у Gemini Nano решение принимает вендор, а у Transformers.js вы решаете сами, какую модель, когда и зачем грузить.

Практический вывод для команд: берите узкие специализированные модели вместо большой универсальной, проверяйте лицензии весов до релиза, проектируйте каждую функцию как улучшение с фолбэком и оставляйте человеку последнее слово там, где модель может выдумать детали.

С чего начать

Повторить эксперимент можно без специальной инфраструктуры. Transformers.js подключается как обычная JavaScript-библиотека, готовые модели с ONNX-весами открыто лежат на Hugging Face, а весь код демо выложен на GitHub. Начинать логичнее не с большой языковой модели, а с узкой задачи: семантический поиск на 22-миллионной модели подключается за минуты и почти ничего не весит, а впечатление производит сразу. Генерацию текста стоит добавлять последней, когда уже понятно, что остальные функции работают.

Частые вопросы

Это работает во всех браузерах?

Нет. WebGPU полностью доступен в Chrome, а в Firefox и Safari поддержка частичная. Transformers.js умеет работать и без него, через WebAssembly на CPU, но заметно медленнее. Для кросс-браузерных проектов это важный фактор: путь через ONNX и WebAssembly шире по совместимости, чем решения, завязанные только на WebGPU.

Сколько стоит инференс в браузере?

Для компании почти ничего: нет счетов за токены, потому что вычисления идут на устройстве пользователя. Платить приходится трафиком первой загрузки модели, от 23 до 800 МБ, и производительностью клиентского железа. Пользователь платит временем ожидания при первом визите. Экономия проявляется на объёме: задача, которая в облаке тарифицируется за каждый вызов, в браузере выполняется сколько угодно раз бесплатно.

Можно ли доверять таким моделям в продакшене?

Только как опциональному слою с фолбэком и проверкой человеком. Маленькие модели ошибаются, могут выдумывать детали и сильно зависят от железа. Для критичных сценариев оставляйте серверную или облачную модель, а браузерную версию запускайте как улучшение, а не как основу.

Итог

Год назад модели в браузере были забавным аттракционом. Теперь это набор функций, которые можно показать заказчику: удаление фона и семантический поиск работают уже сегодня, генерация текста требует аккуратности, камера пока остаётся экспериментом. ИИ в браузере не заменяет облако, зато даёт то, чего у облака нет: нулевую стоимость инференса и приватность по умолчанию.

Код и живое демо открыты: github.com/sylwia-lask/practical-browser-ai. Откройте одну и ту же страницу на ноутбуке и на телефоне: разница между устройствами будет честным тестом технологии. А если хотите понять, как такие приложения устроены внутри, начните с разбора Chrome-расширения с Gemma 4.