Запускаємо LLM у браузері з WebAssembly та WebGPU

Відкрийте вебсторінку — без встановлення, без акаунта й без зв'язку з будь-яким AI-сервером — і почніть листуватися з ботом, відповіді якого повністю генеруються на вашому власному ноутбуці. З машини нічого не йде, рахунку за API немає, а мережевий кабель можна висмикнути одразу після завантаження сторінки, і чат-бот цього навіть не помітить.

Це не мрія на п'ять років уперед. Усе це працює вже сьогодні, у тій самій вкладці, де ви читаєте пошту. За цим стоять дві технології, які зазвичай обговорюють окремо, хоча найсильніші вони саме разом: WebAssembly і WebGPU.

Якщо більшість часу ви пишете на JavaScript, ці назви можуть звучати як щось зі світу ігрових рушіїв або турбота команди графіки. Насправді вони змінюють саму суть браузера: із програми, що малює сторінки, він перетворюється на платформу для справжніх обчислень і дедалі частіше — для локального AI-інференсу.

Чому JavaScript потрібна допомога

JavaScript добре справляється з тим, для чого його створювали: робота з DOM, обробка подій, логіка застосунку. Але дайте йому щось по-справжньому важке — декодування відео, обробку зображень, фізичну симуляцію чи нейромережу, — і тріщини стають помітні. Збирання сміття та динамічна типізація роблять мову приємною в роботі, але вони ж заважають, коли на рахунку кожна мілісекунда процесорного часу.

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

WebAssembly та WebGPU не замінюють JavaScript. Вони дають браузеру силу, якої в нього ніколи не було.

WebAssembly у двох словах

Wasm, скорочення від WebAssembly, — це компактний бінарний формат, який виконує стекова віртуальна машина. Ідея в тому, щоб мови високого рівня отримали переносну ціль компіляції, а вебзастосунки змогли наблизитися до нативної швидкості.

Задумували його зовсім не лише для вебу. Wasm працює в ізольованій пісочниці з безпечною пам'яттю і, коли вбудований у сторінку, підкоряється політиці same-origin браузера, але може запускатися й у середовищах, які з вебом нічого спільного не мають.

На практиці процес виглядає так:

• Берете C, C++, Rust або будь-яку мову, для якої є компілятор із підтримкою Wasm.
• Код компілюється у файл .wasm — це бінарний байткод, а не JavaScript, і він значно ближчий до машинної мови.
• Браузер виконує цей байткод у власній пісочниці зі швидкістю, недосяжною для JIT-компільованого JavaScript.
• Wasm викликає JavaScript і навпаки, тож переписувати весь застосунок не треба — переносите лише важкі частини.

Figma використовує Wasm у рушії рендерингу, і багато в чому саме тому редагування дизайну в браузері відчувається таким самим чуйним, як у десктопному застосунку. На ньому ж працює вебверсія Google Earth, а кілька ігрових рушіїв рівня AAA вміють експортувати просто у Wasm.

Головне, що варто запам'ятати: Wasm відповідає за обчислення. Він прискорює важку логіку, але прямого доступу до GPU не дає. Для масового паралелізму й графіки потрібен інший партнер.

WebGPU — наступник WebGL

Якщо ви працювали з WebGL, то WebGPU — його наступник, і це не просто чергове оновлення. Його з нуля спроєктували під сучасні графічні API на кшталт Vulkan, Metal і Direct3D 12. WebGL натомість — обгортка над застарілим OpenGL ES.

У документації MDN цей API описано як спосіб дати веброзробникам доступ до GPU системи для високопродуктивних обчислень і відмальовування складної графіки в браузері. Відмінності від WebGL глибокі:

• WebGL будувався довкола малювання на canvas і ніколи як слід не справлявся з обчисленнями загального призначення на GPU (GPGPU).
• У WebGPU обчислювальні шейдери — повноправна частина API, а не щось прикручене збоку.
• Він дає низькорівневий контроль через такі сутності, як GPUAdapter, GPUDevice і GPUQueue, — це набагато ближче до нативних графічних API.
• Оскільки він напряму лягає на сучасні GPU API, накладні витрати в нього значно менші, ніж у WebGL, який усе транслює через старий шар OpenGL.

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

Два шари, що доповнюють один одного

Легко проґавити, що Wasm і WebGPU — не суперники. Вони доповнюють одне одного.

• Wasm бере на себе оркестрацію та важку логіку на боці CPU. Це розбір моделі, токенізація, керування пам'яттю і весь той складний код, який інструменти машинного навчання зазвичай пишуть на C++ або Rust.
• WebGPU бере на себе масово-паралельне виконання. Це величезні матричні операції в основі будь-якої нейромережі, які на самому CPU ледве повзли б.

Разом вони роблять LLM усередині вкладки браузера технічно реальною. Без WebGPU модель болісно повільно працювала б на CPU. Без Wasm логіку рантайму було б важко оптимізувати на чистому JavaScript.

WebLLM як робочий приклад

Одна з найнаочніших демонстрацій — WebLLM від команди MLC AI. Це рушій LLM-інференсу в браузері з прискоренням на WebGPU і взагалі без сервера. Він повністю сумісний із форматом OpenAI API, тож якщо ви вже викликаєте chat.completions, вчити майже нічого не доведеться. Спрощений приклад використання:

import { CreateMLCEngine } from "@mlc-ai/web-llm";

// Callback to track model download & loading progress
const initProgressCallback = (progress) => {
  console.log(progress.text);
};

// A small model already compiled into MLC format
const selectedModel = "Llama-3-8B-Instruct-q4f32_1-MLC";
async function main() {
  const engine = await CreateMLCEngine(selectedModel, {
    initProgressCallback,
  });
  const reply = await engine.chat.completions.create({
    messages: [
      { role: "user", content: "Explain WebGPU in one sentence" },
    ],
  });
  console.log(reply.choices[0].message.content);
}

main();

Ось що відбувається за лаштунками:

• CreateMLCEngine завантажує ваги моделі, уже стиснуті та квантовані, а також Wasm-бібліотеку з логікою інференсу.
• Шар Wasm виконує токенізацію, керує контекстом діалогу й оркеструє весь процес інференсу.
• Важкі матричні операції, що становлять суть кожного прямого проходу, виконуються як обчислювальні шейдери WebGPU і використовують паралелізм GPU вашого пристрою.
• Усе лишається всередині пісочниці браузера, тож ні промпти, ні дані користувача не залишають пристрій.

У результаті маєте чат-бот, приватний за замовчуванням, що працює офлайн після кешування моделі й не навантажує сервер, за який інакше довелося б платити. Інді-розробники та невеликі команди можуть випускати AI-функції без рахунку за хмарні GPU, який злітає разом із трафіком.

Не лише мовні моделі

Зв'язка Wasm і WebGPU застосовна далеко не тільки до LLM. Ось ще кілька сфер, де її вже використовують:

• Обробка зображень і відео: складні фільтри, видалення фону й апскейлінг, для яких раніше потрібен був запит до сервера, тепер працюють у реальному часі на клієнті.
• Комп'ютерний зір: розпізнавання об'єктів чи облич просто з камери, без надсилання відеопотоку за межі пристрою.
• Інтерактивна робота з даними: важкі чисельні розрахунки в дусі NumPy просто в браузерних ноутбуках.
• 3D-ігри та симуляції: і Unity, і Unreal освоюють експорт під WebGPU, і рендеринг у браузері стає значно ближчим до того, що дають нативні збірки.
• CAD і 3D-дизайн у браузері: робота зі складними 3D-моделями без десктопного софту.

Обмеження, які варто врахувати

Перш ніж переносити кожен AI-бекенд на клієнт, тримайте в голові ці обмеження:

• Підтримка в браузерах поки не всюди. WebGPU увімкнений за замовчуванням у Chrome, Edge і свіжих збірках Safari, але у Firefox він досі експериментальний і вмикається прапорцем.
• Перше завантаження може бути великим. Навіть невелику модель спершу треба доставити в браузер користувача, тож продумайте перший запуск — зазвичай із зрозумілим індикатором прогресу.
• Продуктивність і далі залежить від заліза. Офісний ноутбук із вбудованою графікою й близько не зрівняється з потужною дискретною відеокартою, тож обирайте модель під свою реальну аудиторію.
• Налагодження змінюється. Ви більше не ловите баги в серверній логіці, яку контролюєте. Ви налагоджуєте код, що працює на величезній і непередбачуваній множині клієнтських пристроїв.

Ніщо з цього не привід відмовлятися від технології. Це лише нагадування, що робота на клієнті теж вимагає продуманої архітектури.

Чому цього разу все інакше

Чимало вебтрендів згасає, але тут майже всі великі виробники браузерів тягнуть в один бік. Google, Apple, Microsoft і Mozilla разом розвивають ці стандарти в межах W3C, тож це не ставка одного вендора, від якої можуть тихо відмовитися.

Межа між вебзастосунком і нативним і далі розмивається. Браузер, який колись лише показував документи, тепер здатен на серйозні обчислення й навіть AI-інференс — без встановлення, без зайвого сервера й із помітно кращою приватністю, адже даним користувача не треба залишати пристрій.

Якщо ви вважали Wasm і WebGPU нішевою графічною темою, поставте невеликий експеримент. Завантажте компактну модель через WebLLM у якомусь пет-проєкті й відчуйте, як це — AI, що працює у ваших руках, а не на чужому сервері. Для наступних кроків: код лежить у репозиторії WebLLM, сам стандарт — на webassembly.org, а довідник — на сторінці WebGPU API в MDN.