Как это работает: архитектура клиентского инференса
Разработчик создал кастомный бэкенд, который запускает малые языковые модели прямо в браузере пользователя. Никаких запросов к серверу, никакой облачной инфраструктуры. Модели LFM 2.5 (230 миллионов параметров) и Bonsai (1.7 миллиарда параметров) загружаются в видеопамять GPU и выполняются локально через WebGPU. Результат - полная автономность, приватность данных и нулевая серверная задержка.
Техническая схема выглядит так: браузер получает скомпилированные шейдеры и веса модели, кастомный бэкенд распределяет вычисления между специализированными ядрами, а WebGPU выступает мостом между JavaScript и нативными возможностями видеокарты. Пока проект экспериментальный, но уже демонстрирует производительность, сопоставимую с нативными решениями.
WebGPU как основа: почему не WebGL или WASM?
WebGL не поддерживает compute shaders - это сразу исключает его из гонки за производительным ML-инференсом. WASM даёт прирост относительно чистого JavaScript, но для матричных операций, лежащих в основе трансформеров, он остаётся узким горлышком: нет прямого доступа к GPU-пайплайну, все вычисления идут через CPU.
WebGPU решает обе проблемы. Низкоуровневый доступ к GPU, нативные compute shaders и явное управление памятью позволяют реализовать те же оптимизации, что и в CUDA-бэкендах, но в браузерной песочнице. Именно это дало возможность создать аппаратно-специфичные ядра, которые выжимают максимум из конкретного железа.
Практический смысл такого подхода уже подтверждён в смежных проектах. Например, Project Zero показал, что грамотная низкоуровневая оптимизация под конкретную архитектуру CPU даёт прирост в 1.8 раза даже без GPU. Здесь та же логика перенесена в браузер, но с фокусом на видеокарты.
Производительность на реальном железе: цифры и контекст
Цифры говорят сами за себя. На RTX 3090 модель LFM 2.5 генерирует 1400–1500 токенов в секунду. На Apple M4 - 400–500 токенов в секунду. Для контекста: средняя скорость чтения человека - около 300–400 слов в минуту, что эквивалентно 5–7 токенам в секунду. Браузерный инференс обгоняет человека в сотни раз.
На практике это означает, что ответ средней длины (200–300 токенов) формируется за 150–200 миллисекунд на RTX 3090 и за 400–600 миллисекунд на M4. Пользователь не видит задержки - текст появляется мгновенно. Это сопоставимо с работой ChatGPT в потоковом режиме, но без сервера.
NVIDIA RTX 3090: агрессивная фузия и рекордные 1440 токенов/с
Ключ к рекордной скорости на NVIDIA - многопроходная фузия. Вместо того чтобы выполнять каждый слой трансформера отдельно (загрузка данных, вычисление внимания, сохранение промежуточных результатов, снова загрузка для feed-forward), бэкенд объединяет несколько операций в один проход. Это радикально снижает накладные расходы на переключение контекста GPU и передачу данных между этапами вычислений.
RTX 3090 с её 24 ГБ VRAM и высокой пропускной способностью памяти позволяет держать всю модель в видеопамяти и не тратить время на подкачку. Агрессивная фузия дополнительно повышает утилизацию шейдерных блоков, приближая её к теоретическому максимуму.
Apple Silicon M4: мега-ядро под TBDR
Архитектура GPU в чипах Apple принципиально отличается от NVIDIA. Вместо immediate mode rendering здесь используется TBDR (Tile-Based Deferred Rendering) - рендеринг разбивается на тайлы, геометрия накапливается, а затем обрабатывается плитками. Это снижает нагрузку на память и энергопотребление, но требует иного подхода к оптимизации.
Разработчик применил единое мега-ядро - гигантский шейдер, который охватывает весь transformer block целиком. Такой подход минимизирует количество переключений между kernel-вызовами и эффективнее использует тайловую архитектуру M4. Результат - 400–500 токенов в секунду на интегрированной графике, что ещё пару лет назад казалось недостижимым для браузерного инференса.
Для сравнения: GLM-5.2 на 8× GB10 в серверном режиме показывает 33–54 токен/с decode. Браузерный бэкенд на одном потребительском GPU обгоняет серверные решения по скорости генерации, хотя и работает с моделями на порядок меньшего размера.
Аппаратно-специфичные ядра: ключ к максимальной скорости
Главная техническая находка проекта - отказ от универсального подхода. Вместо одного бэкенда, который работает везде усреднённо, созданы два принципиально разных ядра под конкретные архитектуры GPU.
Для NVIDIA применяется многопроходная фузия. Слои внимания (QKV-проекции, вычисление скора, взвешенное суммирование) и feed-forward слои (линейные преобразования, активации) объединяются в каскады. Это позволяет держать промежуточные тензоры в регистрах и shared memory GPU, избегая дорогих записей в глобальную память между операциями. Такой подход хорошо ложится на архитектуру CUDA-ядер с их глубоким конвейером и большим регистровым файлом.
Для Apple Silicon использовано единое мега-ядро. Весь transformer block компилируется в один гигантский compute shader. TBDR-архитектура Apple эффективно работает именно с крупными шейдерами, где данные можно долго держать в тайловой памяти без сброса во внешнюю VRAM. Меньше kernel-запусков - меньше оверхеда на драйвер WebGPU, который в браузере особенно чувствителен к частым вызовам.
Почему универсальный подход не дал бы такой производительности? Потому что оптимизация под TBDR (крупные шейдеры, минимум kernel-границ) прямо противоречит оптимизации под NVIDIA (многопроходная фузия с ручным управлением регистрами). Попытка усреднить эти стратегии привела бы к потере 30–50% скорости на каждой платформе. Именно гибкость WebGPU как низкоуровневого API позволила реализовать оба подхода в одном проекте.
Похожая история с аппаратно-специфичными оптимизациями разбиралась в контексте чипов Apple M5 и скрытого режима w4a8, где экспериментальные ядра дали прирост до 1.4x только за счёт учёта особенностей архитектуры.
Интеграция в Sipp и будущее клиентского AI
Проект войдёт в состав библиотеки Sipp - это упростит интеграцию для разработчиков и снизит порог входа. Вместо ручной настройки шейдеров и управления памятью достаточно будет вызвать высокоуровневый API, который сам определит доступное железо и подберёт оптимальное ядро.
Практические сценарии, которые открывает эта технология:
- Офлайн-помощники, работающие без интернета на ноутбуке или телефоне
- Приватные чат-боты для корпоративных данных, которые не покидают устройство
- Локальная обработка и суммаризация документов без загрузки в облако
- Встраивание AI-функций в веб-приложения без затрат на серверную инфраструктуру
От браузера к десктопу: Electron и Tauri
Технология не ограничена веб-страницами. Electron и Tauri позволяют упаковать браузерный движок с WebGPU-бэкендом в нативное десктопное приложение. Это даёт дополнительные возможности: доступ к файловой системе для загрузки локальных моделей, интеграцию с системными уведомлениями, распространение через магазины приложений.
Tauri выглядит особенно интересно - он легче Electron и использует системный WebView вместо бандла Chromium. На macOS и Windows системный WebView уже поддерживает WebGPU, что делает Tauri-приложения с локальным инференсом компактными и быстрыми.
Для тех, кто выбирает бэкенд под конкретную задачу, полезно ознакомиться с сравнением vLLM, LMDeploy и Triton с TensorRT-LLM - принципы выбора между универсальностью и аппаратной оптимизацией работают и в серверном, и в клиентском контексте.
Ограничения и статус разработки
Проект находится в активной разработке. Это означает несколько важных ограничений, которые нужно учитывать перед внедрением.
API может измениться. Совместимость между версиями не гарантируется. Если вы планируете использовать бэкенд в продукте, закладывайте время на адаптацию при обновлениях. Не все модели поддерживаются - пока протестированы только LFM 2.5 (230M) и Bonsai (1.7B). Модели других архитектур могут не запуститься или показать низкую производительность.
Производительность сильно варьируется в зависимости от браузера. Chrome и Edge на Chromium показывают лучшие результаты благодаря зрелой реализации WebGPU. Firefox отстаёт - его имплементация WebGPU всё ещё экспериментальная и не оптимизирована для compute-нагрузок. Версия драйверов GPU также критична: устаревшие драйверы могут давать падение скорости на 20–40%.
Потолок по размеру модели - примерно 1.7 миллиарда параметров. Более крупные модели упираются в ограничения WebGPU по размеру шейдеров и доступной видеопамяти в браузерной песочнице. Это не замена серверному инференсу для больших LLM, а нишевый инструмент для малых моделей, где важна скорость и локальность.
Для продакшена проект пока непригоден без тщательного тестирования на целевом парке устройств. Но для прототипов, исследований и персональных инструментов - вполне рабочий вариант.
Сравнение с аналогами: WebLLM, Transformers.js и другие
WebLLM от MLC и Transformers.js от Hugging Face - два основных конкурента в нише браузерного инференса. WebLLM использует Apache TVM для компиляции моделей под WebGPU и показывает хорошие результаты на широком спектре устройств. Transformers.js базируется на ONNX Runtime Web и ориентирован на совместимость с экосистемой Hugging Face.
Главное отличие нового бэкенда - аппаратно-специфичные ядра. WebLLM и Transformers.js применяют универсальные оптимизации, которые работают на всех GPU, но не выжимают максимум из конкретной архитектуры. Многопроходная фузия для NVIDIA и мега-ядро для Apple Silicon дают прирост в 1.5–2 раза на поддерживаемых конфигурациях.
Обратная сторона - narrower support. WebLLM работает на большем количестве устройств, включая мобильные GPU и старые интегрированные чипы. Новый бэкенд пока оптимизирован только под NVIDIA RTX и Apple M-серию. Расширение поддержки - вопрос времени, но сейчас это инструмент для конкретных платформ, а не универсальное решение.
Ситуация напоминает оптимизацию DeepSeek-V4-Flash на одном B300, где универсальный подход дал 770 токенов/с вместо ожидаемых тысяч, и только аппаратно-специфичные оптимизации позволили приблизиться к теоретическому потолку. Та же логика работает в браузере: хочешь максимум - оптимизируй под конкретное железо.