WebGPU: jak GPU w przeglądarce zmienia zasady gry dla frontendowców i modeli AI

Przez lata przeglądarka była czymś w rodzaju piaskownicy - bezpiecznej, ale też mocno ograniczonej. Skomplikowane obliczenia trafiały na serwer, grafika 3D wymagała WebGL z jego archaicznym API, a modele uczenia maszynowego można było co najwyżej uruchamiać wolno, z CPU. WebGPU zmienia ten układ. Nie stopniowo, lecz dość radykalnie.

Czym właściwie jest WebGPU i dlaczego WebGL już nie wystarcza

WebGL, oparty na OpenGL ES 2.0, pochodzi z 2011 roku. Przez ponad dekadę był jedynym sposobem na dostęp do GPU w przeglądarce. Problem polega na tym, że nowoczesne karty graficzne działają zupełnie inaczej niż zakładało OpenGL - mają własne modele pamięci, obsługują obliczenia równoległe wykraczające daleko poza rendering pikseli i wymagają innego sposobu zarządzania zasobami.

WebGPU to standard W3C projektowany od podstaw pod współczesne GPU API: Metal na macOS/iOS, Vulkan na Linuksie i Androidzie, Direct3D 12 na Windows. Specyfikacja trafiła do głównych przeglądarek w 2023 i 2024 roku - Chrome i Edge obsługują ją od wersji 113, Safari od wersji 26, Firefox stopniowo wprowadza wsparcie przez flagi eksperymentalne.

Kluczowa różnica techniczna leży w dwóch miejscach. Po pierwsze, WebGPU ekspozuje tzw. compute shaders - programy uruchamiane bezpośrednio na GPU, które nie mają nic wspólnego z renderowaniem grafiki. Piszesz kod w WGSL (WebGPU Shading Language), wysyłasz dane na kartę graficzną i dostajesz wynik. To GPGPU - General-Purpose GPU Computing - dostępne wprost z navigator.gpu bez żadnych dodatków. Po drugie, model pamięci i synchronizacji jest znacznie bardziej explicite niż w WebGL, co pozwala unikać ukrytych pułapek wydajnościowych.

Obliczenia AI w przeglądarce: ile to realnie przyspiesza

To właśnie compute shadery robią z WebGPU coś więcej niż tylko "lepszy WebGL". Biblioteka TensorFlow.js już od dłuższego czasu eksperymentuje z backendem WebGPU - i różnica wobec WebGL jest widoczna gołym okiem. Mnożenie macierzy, operacje splotu, obliczenia uwagi w transformerach - wszystko to sprowadza się do masowo równoległych operacji, dla których GPU zostało stworzone.

Testy przeprowadzone przez zespół Chrome DevRel na modelu klasyfikacji obrazów pokazały, że backend WebGPU w TensorFlow.js działa ok. 3 razy szybciej od backendu WebGL przy inferencji na typowych sieciach konwolucyjnych. Przy bardziej złożonych modelach ta różnica rośnie, bo WebGPU lepiej radzi sobie z zarządzaniem pamięcią GPU i nie wymusza zbędnych synchronizacji.

Co to oznacza w praktyce? Kilka konkretnych scenariuszy:

Inferencja lokalnie - model do klasyfikacji zdjęć, wykrywania obiektów albo sentiment analysis działa w przeglądarce użytkownika, bez wysyłania danych na serwer
Segmentacja w czasie rzeczywistym - usuwanie tła w wideokonferencji, efekty AR nakładane na kamerę
Asystenci offline - małe modele językowe (do kilku miliardów parametrów) działające bez połączenia z internetem
Przetwarzanie dokumentów po stronie klienta - OCR, analiza PDF, ekstrakcja danych bez uploadu do chmury

Ten ostatni punkt jest szczególnie interesujący z punktu widzenia prywatności. Dane użytkownika nie opuszczają urządzenia - są przetwarzane lokalnie, co eliminuje całą klasę problemów związanych z RODO i retencją danych po stronie serwera.

Przykład: compute shader w WebGPU

Żeby to nie było abstrakcyjne, poniżej minimalny przykład inicjalizacji WebGPU i dispatchu compute shadera:

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

// Bufor wejściowy: 1024 liczby float
const inputBuffer = device.createBuffer({
  size: 1024 * 4,
  usage: GPUBufferUsage.STORAGE | GPUBufferUsage.COPY_DST,
});

const shaderModule = device.createShaderModule({
  code: `
    @group(0) @binding(0) var<storage, read_write> data: array<f32>;
    
    @compute @workgroup_size(64)
    fn main(@builtin(global_invocation_id) id: vec3<u32>) {
      data[id.x] = data[id.x] * 2.0;
    }
  `,
});

// pipeline, bindGroup, commandEncoder...
// device.queue.submit([...]);

To szkielet - cały pipeline jest bardziej rozbudowany, ale schemat jest czytelny: definiujesz shader w WGSL, tworzysz pipeline obliczeniowy, wysyłasz zadanie na GPU.

Grafika 3D: nowe możliwości dla aplikacji webowych

Poza obliczeniami, WebGPU to też znaczący skok dla renderingu. Kilka możliwości, których WebGL po prostu nie oferował:

Indirect rendering - GPU samo decyduje, ile obiektów wyrenderować, bez konieczności przesyłania tych danych z CPU. Przy scenach ze złożonym cullingiem (odrzucaniem niewidocznych obiektów) to spora oszczędność przepustowości magistrali CPU-GPU.

Compute-driven rendering - generowanie geometrii i parametrów renderingu bezpośrednio w shaderach obliczeniowych. Particle systems, symulacje tkanin, systemy LOD - wszystko to można teraz liczyć po stronie GPU zamiast CPU.

Lepsza obsługa zasobów - explicit resource management oznacza, że deweloper kontroluje cykl życia buforów i tekstur. Mniej "magii" niż w WebGL, ale też mniej niespodzianek wydajnościowych.

Praktyczne zastosowania? Frameworki 3D dla webdeweloperów już migrowały lub migrują na WebGPU: Babylon.js ma pełne wsparcie, Three.js przygotowuje renderer WebGPURenderer jako alternatywę obok WebGLRenderer. Dla kogoś, kto buduje konfigurator produktów 3D, edytor architektoniczny albo wizualizację danych w przestrzeni - to konkretna poprawa jakości działania.

Prywatność, koszty, UX - gdzie naprawdę zmienia się rachunek

Z perspektywy architektury aplikacji, przeniesienie obliczeń na stronę klienta ma kilka wymiernych konsekwencji.

Koszty infrastruktury - inferencja modelu AI na GPU w chmurze kosztuje. Instancja z GPU (np. T4 na Google Cloud) to kilkadziesiąt centów za godzinę. Jeśli aplikacja obsługuje miliony użytkowników, te koszty szybko rosną. Część z tych obliczeń można przenieść do przeglądarki - na GPU użytkownika, które i tak stoi bezczynnie.

Latencja - round-trip do API OpenAI czy podobnego serwisu to zawsze kilkaset milisekund. Inferencja lokalna jest natychmiastowa. Przy aplikacjach wymagających odpowiedzi w czasie rzeczywistym (autouzupełnianie, korekta live, efekty kamery) ta różnica jest odczuwalna.

Prywatność - to nie tylko kwestia regulacyjna. Użytkownicy są coraz bardziej świadomi tego, gdzie trafiają ich dane. Możliwość przetworzenia wrażliwych dokumentów lokalnie (np. skany dokumentów tożsamości do aplikacji fintech, zdjęcia medyczne w aplikacjach wellness) to realny argument marketingowy i prawny jednocześnie.

Nie jest to jednak bez wad. GPU w laptopie użytkownika to nie centrum danych - modele muszą być lżejsze, zoptymalizowane pod kątem rozmiaru (kwantyzacja, pruning). Pobranie modelu przy pierwszej wizycie może ważyć dziesiątki megabajtów. Nie każde urządzenie ma GPU obsługujące WebGPU - starsze telefony i budżetowe laptopy mogą wymagać fallbacku na CPU lub API.

Co musi zmienić się w myśleniu frontendowca

WebGPU otwiera obszar, który dotychczas był domeną wyspecjalizowanych inżynierów ML i grafiki. Dla typowego frontendowca to nowe terytorium - inne model mentalny, inne narzędzia, inne błędy.

Kilka rzeczy, o których warto wiedzieć:

Asynchroniczność jest wszędzie - WebGPU API jest w pełni asynchroniczne. requestAdapter(), requestDevice(), mapowanie buforów - wszystko zwraca Promise. Zarządzanie tym w złożonej aplikacji wymaga staranności.

Debugowanie jest trudniejsze - kodu działającego na GPU nie debuguje się jak JavaScript. Przydają się narzędzia takie jak PIX (Windows), RenderDoc czy wbudowane narzędzia przeglądarki (Chrome ma zakładkę WebGPU w DevTools).

Biblioteki są tu po to, żeby z nich korzystać - TensorFlow.js, ONNX Runtime Web, MediaPipe - te biblioteki abstrakcja trudne szczegóły WebGPU dla przypadków AI/ML. Pisanie własnych shaderów obliczeniowych od zera ma sens tylko dla naprawdę specyficznych zastosowań.

Fallback strategy jest obowiązkowa - navigator.gpu może być undefined. Aplikacja musi działać bez WebGPU, być może korzystając z wolniejszego backendu CPU lub przenosząc obliczenia na serwer.

Wsparcie przeglądarek - stan na 2025

Przeglądarka	Wsparcie	Uwag
	---	---	---
Chrome 113+	Pełne	Desktop i Android		Edge 113+
Pełne	Oparty na Chromium		Safari 26+	Pełne
macOS i iOS		Firefox	Eksperymentalne	Za flagą dom.webgpu.enabled

Globalny coverage przez caniuse.com oscyluje wokół 75-80% użytkowników. Dla aplikacji kierowanych do profesjonalistów tech lub użytkowników macOS/iOS liczby są wyższe.

WebGPU a WebGL: kiedy co wybrać

WebGPU nie deprecjonuje WebGL z dnia na dzień. Kilka argumentów za pozostaniem przy WebGL:

Projekt musi działać na starszych urządzeniach i przeglądarkach (WebGL ma 98%+ wsparcia)
Zespół używa dojrzałych bibliotek głęboko opartych na WebGL (Three.js WebGLRenderer)
Zakres obliczeń nie uzasadnia migracji - proste sceny 3D, podstawowe efekty

Argumenty za WebGPU:

Obliczenia AI/ML po stronie klienta - tu WebGPU jest bezkonkurencyjne
Złożone sceny 3D z tysiącami obiektów dynamicznych
Symulacje fizyczne liczone na GPU
Nowe projekty startujące od zera - warto budować na nowszym fundamencie

Praktyczne projekty, które dziś można zbudować

Żeby artykuł nie zakończył się na poziomie teorii - kilka konkretnych typów projektów, które stają się realne dzięki WebGPU:

Asystent działający offline - lokalne LLM rzędu 1-3 mld parametrów (np. Gemma 2B, Phi-2 w kwantyzacji 4-bit) uruchamiane przez WebLLM lub Transformers.js z backendem WebGPU. Użytkownik pobiera model przy pierwszym uruchomieniu (~500 MB - 2 GB), potem działa bez internetu.

Konfigurator produktów z fizyką - tkaniny, ciecze, odkształcenia materiałów liczone na GPU. Coś, co do tej pory wymagało drogiego backendu renderingowego albo dedykowanej aplikacji.

Analiza wideo w czasie rzeczywistym - wykrywanie twarzy, gest recognition, śledzenie postawy (pose estimation) w strumieniu z kamery, bez wysyłania wideo na serwer. Przydatne w aplikacjach sportowych, edukacyjnych, zdrowotnych.

Zaawansowane wizualizacje danych - miliony punktów danych renderowanych i filtrowanych w czasie rzeczywistym bezpośrednio na GPU, z interaktywną eksploracją.

To nie są scenariusze na papierze - projekty takie jak WebLLM (Carnegie Mellon University), MediaPipe Web czy Babylon.js pokazują, że to działa produkcyjnie już teraz.

WebGPU to coś, na co środowisko webowe czekało od dawna - bezpośredni dostęp do prawdziwej mocy obliczeniowej GPU bez warstwy kompromisów, które odziedziczyliśmy po WebGL z czasów, gdy smartfony miały 512 MB RAM. Dla frontendowców, którzy chcą budować aplikacje z elementami AI i zaawansowaną grafiką, znajomość tego API przestaje być ciekawostką, a zaczyna być praktyczną umiejętnością. Wsparcie przeglądarek jest już wystarczające, narzędzia dojrzewają, a ekosystem bibliotek rośnie w widocznym tempie.

Źródła

WebGPU Specification - W3C / gpuweb - oficjalna specyfikacja API, aktualizowana na bieżąco przez W3C WebGPU Community Group
WebGPU now supported in all three major browser engines - blog Chrome for Developers, ogłoszenie pełnego wsparcia w głównych przeglądarkach, 2024
WebGPU - Chrome for Developers overview - obszerny przegląd techniczny WebGPU: kontekst historyczny, możliwości compute shaderów, porównanie z WebGL, przykłady zastosowań, 2023/2024