WebGPU és on-device AI: A böngésző komoly futási környezetté válik
· 6 min read · Filippo Spinella · WebGPU, AI, Frontend, Web Performance
Évekig a böngésző volt az alkalmazás szép arca, a felhő pedig az a hely, ahol a nehéz dolgok megtörténtek. A felhasználó ír, kattint, feltölt egy fájlt; a frontend mindent elküld a szervernek; a szerver modellt hív; jön vissza a válasz.
Ez a rendszer továbbra is nagyon hasznos, de nem ingyenes. Minden hívás késleltetéssel, költséggel, hálózatfüggőséggel és adatvédelmi kérdésekkel jár. Ha a felhasználó egy mondatot ír, és javaslatot szeretne, fél másodperc a súlya. Ha több ezer apró bemenetet osztályoz, a fillérekből valódi pénz lesz. Ha a szöveg érzékeny, akkor a készülékről való elküldése nem semleges választás.
Ezért van felhajtás a WebGPU és az eszközön lévő mesterséges intelligencia. Nem azért, mert holnap minden modellt futtatunk a böngészőben. Mert az intelligens funkciók egy része közelebb kerülhet a felhasználóhoz.
Nem kell mindennek helyisé válnia
Az érvelés gyerekes változata: "felhő versus eszköz". A hasznos változat a hibrid.
Néhány feladat remekül mutat a készüléken: rövid összefoglalók, nyelvészlelés, fényátírások, egyszerű osztályozások, képszűrők, kis látásmodellek, kreatív élmények azonnali visszajelzéssel.
A többi feladat jobb marad a felhőben: összetett érvelés, határmodellek, szerveroldali adatok, központosított audit, egységes minőség, munkafolyamat, ahol minden lépést gondosan ellenőrizni kell.
Az egészséges architektúra futás közben dönt:
A böngészőnek nem kell nyernie a felhővel szemben. Meg kell mentenie a felhőt azoktól a munkáktól, amelyeket ott nem kell elvégezni.
Miért számít a WebGPU?
A WebGPU egy modern API a GPU böngészőből történő használatához. Nem csak a szebb 3D-s grafikákra való. Ez azért is fontos, mert a számítástechnikára alkalmas primitíveket: párhuzamos munkaterheléseket, shadereket, pipeline-okat közelebb hoz a GPU-k által jól teljesítettekhez.
A mesterséges intelligencia, a tudományos vizualizáció, a 3D szerkesztők, a videószűrők és a kreatív eszközök esetében ez a különbség érezhető. A WebGL sokat tett a webért, de a WebGPU a jelennek jobban megfelelő modellel született.
Az első dolog, amit meg kell írni, azonban nem árnyékoló. Ez egy józan funkciófelismerés:
export async function requestWebGpuDevice() { if (!('gpu' in navigator)) { return null; } const adapter = await navigator.gpu.requestAdapter({ powerPreference: 'high-performance', }); if (!adapter) { return null; } return adapter.requestDevice(); }
Ez a funkció egy fontos dolgot mond: a WebGPU nem minden eszközön biztosított. Ez egy igazolható képesség. Egyes böngészők nem támogatják teljes mértékben, néhány GPU-nak vannak korlátozásai, egyes vállalati környezetek letiltják a funkciókat, néhány felhasználó szerény hardverrel rendelkezik.
Beépített mesterséges intelligencia: amikor a böngésző hozza a modellt
A Chrome beépített API-kat kínál az olyan feladatokhoz, mint a helyi felszólítások, összegzés, írás, átírás, fordítás, nyelvészlelés és lektorálás. Az ötlet nagyon érdekes: a böngésző kezeli a modellt, a rendelkezésre állást és a frissítéseket; az alkalmazás a platformhoz közelebbi API-t használ.
Ha jól működik, sokat változtat:
- kevesebb szerverhívás egyszerű feladatokhoz;
- adatok, amelyek az eszközön maradhatnak;
- alacsonyabb késleltetési idő;
- offline vagy félig offline élmények;
- Természetesebb UX íráshoz és fordításhoz.
De ezt progresszív fejlesztésként kell kezelni. Egyes API-k stabilak, mások eredeti próbaverzióban vagy előnézetben vannak, mások továbbra is a verziótól, a nyelvtől és az eszköztől függenek.
type LocalCapability = 'available' | 'downloadable' | 'unsupported'; export async function getLocalSummarizerCapability(): Promise<LocalCapability> { const SummarizerApi = (globalThis as any).Summarizer; if (!SummarizerApi?.availability) { return 'unsupported'; } const availability = await SummarizerApi.availability(); if (availability === 'available') return 'available'; if (availability === 'downloadable') return 'downloadable'; return 'unsupported'; }
A konkrét kód megváltozik, de a minta megmarad: ellenőrizni kell a rendelkezésre állást, elmagyarázza a letöltéseket, tartalékokat kínál, és méri a minőséget.
A visszaesés nem szomorú B-terv
A felhő visszaesése nem vereség. A termék része.
interface AiRequest { task: 'summarize' | 'rewrite' | 'classify'; input: string; } interface AiResult { output: string; runtime: 'local' | 'cloud'; } export async function runAiTask(request: AiRequest): Promise<AiResult> { const local = await tryLocalAi(request); if (local) { return { output: local, runtime: 'local' }; } const cloud = await fetch('/api/ai', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(request), }).then((res) => res.json()); return { output: cloud.output, runtime: 'cloud' }; }
Ez az architektúra lehetővé teszi a fokozatos fejlesztést. A helyi támogatással rendelkezők jobb késleltetést és adatvédelmet kapnak. Akinek nincs, az továbbra is használja a funkciót. Mérheti a helyi kérések százalékos arányát, az időket, a hibákat, a memóriát, az észlelt minőséget és a költségeket.
Mutatók nélkül az eszközön lévő mesterséges intelligencia esztétikai választássá válik. A mérőszámokkal termékkarcává válik.
A modell felhasználói élménye számít
Ha a böngészőnek le kell töltenie egy modellt, a felhasználó észleli azt. Ne rejtsd el egy homályos forgó mögé. Jobb, ha egyértelmű: "Felkészítjük a modellt a funkció gyorsabb és akár offline használatára."
Egy jó tapasztalat:
- mutatja az előkészítés állapotát;
- nem blokkolja a teljes oldalt;
- lehetővé teszi a felhőalapú visszaállítás folytatását;
- elkerülje az akkumulátor és a memória meglepetéseit;
- emlékezzen a modellre, amikor csak lehetséges;
- magyarázza el az előnyt egy konkrét mondatban.
A legrosszabb egy „okos” funkció, amely meghibásodottnak tűnik, mert csendben tölt le valamit.
Adatvédelem: jobb, nem automatikusan biztonságos
Az adatok feldolgozása az eszközön nagy előnyt jelenthet. Az e-mail piszkozatnak, belső dokumentumnak vagy személyes feljegyzésnek nem kell elhagynia a böngészőt ahhoz, hogy javaslatot kapjon.
A helyi azonban nem jelent automatikusan biztonságosat. Azonban gondolnia kell a következőkre:
- XSS;
- véletlen naplók;
- tárolóban mentett adatok;
- gyors injektálás nem megbízható tartalomból;
- a modellnek adott engedélyek;
- automatikus műveletekben használt kimenetek.
Ha egy helyi modell képes elolvasni egy weboldalt, majd kitölteni egy űrlapot, az oldal megpróbálhatja manipulálni. Ha képes hívni az eszközt, megerősítésre van szükség. Ha strukturált kimenetet állít elő, akkor azt érvényesíteni kell. Az a tény, hogy az eszközön fut, csökkenti bizonyos adatvédelmi kockázatokat, de nem szünteti meg a biztonsági modellt.
Ahol ez igazán érdekessé válik
A szöveg csak a kezdet. A WebGPU hitelessé teszi a webes élményeket, amelyek egészen a közelmúltig natív alkalmazásnak tűntek:
- összetett 3D szerkesztők;
- Gauss fröccs a böngészőben;
- valós idejű videoszűrők;
- Könnyű CAD;
- tudományos vizualizációk;
- kreatív eszközök azonnali előnézettel;
- látási következtetés a felhasználói felület közelében;
- ambiciózusabb böngészős játékok.
Itt kezd keveredni a frontend, a grafika és a gépi tanulás. Ez egy kissé kínos, de egyben termékeny terület is: a böngésző ismét komoly alkalmazásplatformmá válik, nem csak az űrlapok és az irányítópultok elhelyezésére.
Gyártás előtti ellenőrző lista
Mielőtt egy eszközön lévő funkciót a felhasználók elé helyeznék, ellenőrizném:
- Célozzon böngészőket és eszközöket.
- Felhővisszaesés vagy elegáns leromlás.
- Letöltési idő és modell gyorsítótár.
- Memória és akkumulátor átlagos hardver.
- Minőség a felhő verzióhoz képest.
- Adatvédelmi szabályzat és felhasználói üzenetek.
- Tesztelés ellenséges bemenetekkel.
- Külön mérőszámok a helyi és a felhőalapú futásidőhöz.
- Tervezze meg a sablon frissítését vagy letiltását.
Ez egy konkrét lista, mert a probléma konkrét. Egy lassú, törékeny vagy átláthatatlan AI-funkció nem válik jobbá csak azért, mert a böngészőben fut.
A helyes kompromisszum
Nem hiszem, hogy a jövő „minden a készüléken” múlik. És nem hiszem, hogy a felhő marad az egyetlen ésszerű hely a következtetésekhez. A legvalószínűbb jövő egy keverék: helyi, ha javítja a késleltetést, az adatvédelmet vagy a költségeket; felhő, ha minőségre, frissített adatokra és központi vezérlésre van szükség.
A WebGPU, WebNN és a beépített AI API-k nem teszik a böngészőt mindenhatóvá. Felnőttebbé teszik. És azok számára, akik webes termékeket építenek, ez óriási hír.