Навіщо запускати AI в браузері

Серверний вивід дає контроль середовища й дозволяє тримати великі моделі. Ціна — оренда GPU, затримка мережі, передача документів на чужий хост і масштабування під піки. Для бланків, чеків і внутрішніх форм питання «куди пішла фотографія» часто важливіше за «наскільки розумна модель».

Клієнтський шлях: перший візит качає ваги (або бере їх із кешу), далі вивід моделі локально. Сервер зберігає результати, права доступу й оркестрацію — не зобов’язаний бачити сире зображення. Головне питання статті практичне: чи можна перетворити звичайний React-сайт на клієнт AI-системи? Так — якщо задача вміщується в розмір моделі, холодний старт і підтримку WebGPU/WASM на пристроях аудиторії.

WebGPU простими словами

Нейромережі — це масові операції над матрицями. CPU добрий для різнорідних послідовних задач. GPU — для тисяч однотипних паралельних кроків. Спрощено: один виконавець робить тисячу операцій підряд проти тисячі маленьких виконавців одночасно.

До WebGPU у браузері були JavaScript на CPU, WebAssembly і WebGL. WebGL заточений під графіку; для ML його доводиться «ламати» через текстури й шейдери — незручно й обмежено. WebGPU — наступник із прямішою моделлю доступу до сучасного GPU і підтримкою обчислень загального призначення: саме те, що потрібно середовищам виконання машинного навчання.

Важливо розвести шари:

JavaScript
   ↓
ML-каркас / середовище виконання
   ↓
WebGPU
   ↓
GPU API платформи
   ↓
GPU

WebGPU сам по собі не класифікує зображення і не читає текст. Він дає середовищу виконання виконати граф обчислень на залізі користувача.

Transformers.js і зв’язок з ONNX

Transformers.js (пакет @huggingface/transformers) — JavaScript-бібліотека екосистеми Hugging Face для запуску моделей у браузері й у Node. Через конвеєри задач доступні текстова класифікація, ембединги, розпізнавання мовлення, класифікація й детекція зображень, OCR-сценарії, генерація тексту та інші задачі на базі Transformer-моделей і моделей зору, експортованих у ONNX.

Що таке ONNX (коротко)

ONNX (Open Neural Network Exchange) — відкритий формат графа нейромережі: вузли (операції), тензори, константи. Це не «ще один фреймворк навчання» і не заміна PyTorch. Навчання зазвичай лишається в PyTorch чи іншому каркасі; в ONNX модель експортують, щоб один і той самий артефакт можна було ганяти різними рушіями.

ONNX Runtime (ORT) — рушій, який читає цей граф і виконує його: на сервері (CPU / CUDA), у Node або в браузері (ONNX Runtime Web з бекендами WASM / WebGPU). Transformers.js якраз спирається на ONNX Runtime Web: ви викликаєте зручний pipeline, а під капотом крутиться ONNX-граф.

Мінімальний ланцюжок:

Навчена модель (PyTorch тощо)
        ↓
   експорт в ONNX
        ↓
ONNX Runtime (Web / сервер)
        ↓
   WebGPU / WASM / CUDA …

Без цієї ланки «своя CRNN у браузері» не склеюється: React не виконує .pt напряму. Розбір експорту, opset, динамічних осей і паритету з Python — в окремій статті ONNX: від PyTorch до Runtime.

Життєвий цикл моделі:

Перший запуск → завантаження файлів → кеш браузера → локальний вивід

Розмір ваг б’є по холодному старту: сотні мегабайт на мобільному — уже продуктове рішення, а не «дрібниця для демо».

Ролі в стеку:

Схема цілком:

React / JavaScript
        ↓
Transformers.js
        ↓
`ONNX Runtime Web`
        ↓
   WebGPU або WASM
        ↓
     GPU / CPU

WebGPU, WASM і сервер: що обрати

Робочі сходи для продукту:

WebGPU → якщо немає → WASM → якщо модель занадто важка / повільна → вивід на сервері

Не обирайте бекенд «за модою». Обирайте за задачею, 95-го перцентиля часу на реальних пристроях аудиторії й політикою даних.

Перша модель і device: 'webgpu'

Встановлення:

npm install @huggingface/transformers

Мінімальний приклад класифікації тексту:

import { pipeline } from '@huggingface/transformers';

const classifier = await pipeline(
  'text-classification',
  'Xenova/distilbert-base-uncased-finetuned-sst-2-english',
);

const result = await classifier('Hello world');

Після pipeline бібліотека знаходить картку моделі, качає ONNX-файли, готує середовище виконання, обирає бекенд, виконує вивід і повертає результат. Щоб явно взяти GPU:

const pipe = await pipeline(
  'image-classification',
  'onnx-community/mobilenetv4_conv_small.e2400_r224_in1k',
  { device: 'webgpu' },
);

Так само вмикають embeddings і розпізнавання мовлення — у гайді Hugging Face по WebGPU. device: 'webgpu' не гарантує успіх: потрібна підтримка API, робочий драйвер і модель, чиї оператори середовище виконання вміє на цьому бекенді. Обгортайте ініціалізацію в перевірку й запасний шлях на WASM (або на сервер).

React: де тримати модель і навіщо робочий потік

Не створюйте pipeline всередині кожного рендеру. Потрібні лінива ініціалізація, сервіс-одинак або React-хук useAIModel(), який вантажить модель один раз і віддає статус: idle → loading → ready → error. Поки йде завантаження, UI показує прогрес і не блокує решту сторінки. Повторний вхід на екран OCR має брати вже теплий екземпляр із модуля-сервісу, а не качати ваги знову.

Для UI зручна схема:

React UI → useAIModel() → Model Service → Transformers.js → ORT → WebGPU

Вивід моделі й розбір великих тензорів на головному потоці можуть заморозити інтерфейс: прокрутка зупиняється, кліки «губляться». Виносьте завантаження й вивід у робочий потік: головний потік шле повідомлення з ArrayBuffer зображення або OffscreenCanvas, робочий потік відповідає результатом, метриками часу й кодом помилки. Патерн близький до інших важких клієнтських задач — див. також Web Worker для клієнтських обчислень.

Окремо продумайте скасування: користувач обрав інше фото, поки крутиться вивід. Робочий потік має ігнорувати застарілий requestId, інакше в UI приїде результат від попереднього файлу.

Комп’ютерний зір і OCR у браузері

Технологія цікава не лише для обробки тексту. Типовий конвеєр зору:

Зображення → preprocessing → детект / кроп → класифікація або OCR → результат

Сценарії: документи, чеки, бланки, схеми, технічні форми. Класичний серверний OCR шле файл на API. Браузерний шлях тримає зображення на пристрої:

Браузер → зображення → попередня обробка → модель → текст

Плюси: дані не їдуть геть, нижча мережева затримка, немає вартості GPU-інстанса, можливий офлайн після кешування. Мінуси: розмір моделі, вимоги до пристрою, обмеження пісочниці браузера, складніше катати дуже важкі ваги.

Для бланків із замірами вигідніший ланцюжок «знайти таблицю → знайти комірку → кроп → компактний OCR», ніж слати весь скан у велику мовну модель. Це та сама дисципліна, що в практиці CRNN на замірах УЗТ і розборі рукописних цифр — лише середовище виконання зміщується ближче до клієнта.

Власна CRNN, YOLO і зір за документами

Власну модель із PyTorch можна вести в браузер так:

PyTorch → навчена CRNN → export ONNX → `ONNX Runtime Web` → (Transformers.js або прямий ORT) → WebGPU

Перевіряйте: усі оператори є в цільовому провайдері виконання; попередня обробка в браузері збігається з Python (нормалізація, порядок каналів, розмір); постобробка (CTC, argmax) дає ті самі рядки на контрольному наборі. Розбіжність «у Colab 0.98, у вкладці сміття» майже завжди в препроцесі або в іншій версії квантування — не в «магії WebGPU».

Сценарій із детектором:

Image → YOLO → bounding boxes → crop → OCR

YOLO відповідає «де об’єкт», OCR — «що всередині». Обидві моделі можуть жити локально, якщо стиснуті за розміром. Клієнтський конвеєр зору за документами — реалістична мета для внутрішніх інструментів, де документи не мають покидати робочу станцію. Інженерна логіка детектора розібрана в опорний розбір про YOLO.

Коли корисно, розмір моделі і квантування

Хороші кандидати: OCR невеликих кропів, класифікація, детекція об’єктів, ембединги, компактні моделі зору, мовлення, локальні інструменти, застосунки «спочатку офлайн».

Погані: дуже великі мовні моделі, величезні мережі зору, задачі з великим обсягом оперативної та відеопам’яті, оператори поза підтримкою ONNX Runtime, моделі з нестерпним холодним стартом.

Парадокс поставки:

Server:  10 MB JS + 5 GB модель на сервері
Browser: 10 MB JS + 500 MB модель у користувача

Користувач платить трафіком і диском. Пом’якшують: квантування, стиснення, кеш (Cache Storage / IndexedDB), ліниве підвантаження, CDN, кілька малих моделей замість однієї величезної.

Квантування спрощено:

FP32 → FP16 → INT8 → менший розмір і пам’ять → часто швидше

Це компроміс розміру, швидкості й якості — не безкоштовне «стиснути без втрат». Міряйте точність на своєму валідаційному наборі після кожного кроку.

Приватність, режим «спочатку офлайн» і порівняння з сервером

Локальний вивід зменшує витік сирих документів на сервер виводу. Це не абсолютна безпека: модель і залежності все одно скачуються, пісочниця браузера обмежує, але не скасовує ланцюжки постачання; шкідливий або підмінений артефакт моделі — окремий ризик. Контролюйте джерела ваг і цілісність (хеші, свій CDN).

Режим «спочатку офлайн» після прогріву кешу:

React → Local AI Model → WebGPU → GPU
(інтернет може бути вимкнений)

PWA, Cache Storage і IndexedDB тримають UI і ваги. Порівняння з сервером:

Як міряти і які помилки ламають проєкт

Рахуйте не лише «запрацювало». Фіксуйте: розмір моделі (MB на диску й у пам’яті), час завантаження з мережі й із кешу, холодний старт першого виводу, теплий вивід, частку часу попередньої й постобробки, пік пам’яті вкладки, частку пристроїв із успішним WebGPU. Без розрізу «перший візит vs повторний» ви оптимізуєте не той шлях: у повторних користувачів модель уже в Cache Storage, а в нових — ще немає.

Приклад звіту для стенду:

Завантаження моделі (холодна мережа):  2.8 s
Завантаження моделі (влучання в кеш):     0.4 s
Перший вивід:               450 ms
Теплий вивід:                 85 ms
Розмір моделі:                    120 MB
Успіх WebGPU (стенд):      9/10 devices

Типові помилки: плутати Transformers.js із «нейромережею» і WebGPU з ML-фреймворком; тягнути занадто велику модель «бо на сервері тягне»; крутити вивід на потоці інтерфейсу; не мати запасного шляху на WASM; ігнорувати холодний старт; слати всю фотографію, коли потрібен кроп; кликати мовну модель там, де вистачає детектора й OCR; порівнювати якість браузерного виводу з Python без фіксації версії квантування.

Скелет для промислового контуру:

React → AI Service → робочий потік → Transformers.js → `ONNX Runtime Web` → WebGPU
Fallback: WebGPU → WASM → серверний API

Велика мовна модель ≠ будь-який ШІ. Для документів часто виграє:

YOLO → OCR → Classifier → Rules

замість «картинка → величезна мовна модель → JSON». Місце серверної мовної моделі лишається там, де потрібна широка міркувальна модель — поруч із клієнтським контуром, а не замість нього. Про шари LLM-стеку див. три шари стеку LLM.

Майбутнє: зріліший WebGPU, API на кшталт WebNN, SIMD у WASM, квантовані й мультимодальні моделі, сценарії зі збереженням приватності. Відділяйте вже доступне (device: 'webgpu' сьогодні) від дорожньої карти браузерів, інакше план перетворюється на слайд-шоу без дати поставки.

Міні-проєкт: AI OCR у вкладці

Зберіть чернетку застосунку:

1. Завантаження зображення і попередній перегляд.
2. Перевірка navigator.gpu / спроба device: 'webgpu'.
3. Завантаження компактної моделі з індикатором прогресу.
4. Попередня обробка і (за можливості) пошук області документа.
5. OCR → JSON у UI.
6. Друк часу завантаження й теплого виводу.
7. Перемикач запасного шляху на WASM.

Архітектура цілі:

Image → React → робочий потік → Model → WebGPU → OCR → JSON → UI

Так ви перевіряєте гіпотезу на своїх пристроях раніше, ніж обіцяти замовнику «весь AI у браузері».

Часті питання

Далі за темою

• Інженерія YOLO і зв’язок з OCR
• Компактна CRNN для замірів
• Рукописні цифри: CNN, CTC, TrOCR
• Три шари стеку LLM
• Web Worker для важких клієнтських задач
• Документація: запуск моделей на WebGPU

Ідеї наступних матеріалів серії: ONNX: від PyTorch до Runtime, ML-фреймворки, YOLO в браузері, CRNN на WebGPU, квантування без магії, ШІ «спочатку офлайн».

Окремо варто зафіксувати очікування замовника: «ШІ в браузері» не означає «без інфраструктури». Вам усе одно потрібні хостинг статичних ваг або CDN, політика оновлення моделей, телеметрія помилок на клієнті та план, що робити, коли на слабкому ноутбуці теплий вивід виходить за бюджет часу. Саме ці домовленості відрізняють демо від продукту.

Висновок

WebGPU дає браузеру GPU-обчислення. Transformers.js спрощує запуск моделей. ONNX Runtime Web зв’язує ваги з провайдерами виконання. Разом вони дозволяють тримати OCR, детект і компактний зір на пристрої користувача — з чесним запасним шляхом, бюджетом розміру моделі й робочим потоком навколо інтерфейсу. Майбутнє веб-ШІ виглядає не як «усе лише в браузері» чи «усе лише на сервері», а як поєднання клієнтського виводу для чутливих і частих задач із серверним контуром для важких моделей і контролю.