WebGPU och on-device AI: Webbläsaren håller på att bli en seriös runtime

I flera år var webbläsaren applikationens trevliga ansikte utåt och molnet var platsen där de svåra sakerna hände. Användaren skriver, klickar, laddar upp en fil; gränssnittet skickar allt till servern; servern anropar en modell; svaret kommer tillbaka.

Detta schema är fortfarande mycket användbart, men det är inte gratis. Varje samtal medför fördröjning, kostnader, nätverksberoende och integritetsfrågor. Om användaren skriver en mening och vill ha ett förslag väger en halv sekund. Om du klassificerar tusentals små insatser, blir öre riktiga pengar. Om texten är känslig är det inte ett neutralt val att skicka den från enheten.

Det är därför WebGPU och on-device AI är i hype. Inte för att vi kommer att köra alla modeller i webbläsaren imorgon. Eftersom några av de intelligenta funktionerna kan komma närmare användaren.

Allt måste inte bli lokalt

Den barnsliga versionen av argumentet är: "moln kontra enhet". Den användbara versionen är hybrid.

Vissa uppgifter ser bra ut på enheten: korta sammanfattningar, språkdetektering, lätta omskrivningar, enkla klassificeringar, bildfilter, små visionmodeller, kreativa upplevelser med omedelbar feedback.

Andra uppgifter förblir bättre i molnet: komplexa resonemang, gränsmodeller, data på serversidan, centraliserad revision, enhetlig kvalitet, arbetsflöde där du noggrant måste kontrollera varje steg.

Den sunda arkitekturen avgör vid körning:

Webbläsaren behöver inte vinna mot molnet. Det måste rädda molnet från att utföra arbete som inte behöver göras där.

Varför WebGPU är viktigt

WebGPU är ett modernt API för att använda GPU från webbläsaren. Det är inte bara för snyggare 3D-grafik. Det är också viktigt eftersom det avslöjar primitiver som är lämpliga för datoranvändning: parallella arbetsbelastningar, shaders, pipelines närmare vad GPU:er gör bra.

För AI, vetenskaplig visualisering, 3D-redigerare, videofilter och kreativa verktyg känns denna skillnad. WebGL har gjort mycket för webben, men WebGPU föddes med en modell bättre anpassad till nutiden.

Det första man ska skriva är dock inte en shader. Det är en sober funktionsdetektering:

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();
}

Den här funktionen säger en viktig sak: WebGPU är inte en rättighet som beviljas på varje enhet. Det är en förmåga att verifieras. Vissa webbläsare stöder det inte fullt ut, vissa GPU:er har begränsningar, vissa företagsmiljöer inaktiverar funktioner, vissa användare använder blygsam hårdvara.

Inbyggd AI: när webbläsaren tar med modellen

Chrome driver inbyggda API:er för uppgifter som lokala uppmaningar, sammanfattningar, skrivning, omskrivning, översättning, språkidentifiering och korrekturläsning. Idén är mycket intressant: webbläsaren hanterar modell, tillgänglighet och uppdateringar; appen använder ett API närmare plattformen.

Om det fungerar bra förändras det mycket:

• färre serveranrop för enkla uppgifter;
• data som kan finnas kvar på enheten;
• lägre latens;
• offline eller semi-offline upplevelser;
• Mer naturlig UX för skrivande och översättning.

Men det bör behandlas som progressiv förbättring. Vissa API:er är stabila, andra i ursprungstest eller förhandsgranskning, andra beror fortfarande på version, språk och enhet.

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';
}

Den specifika koden kommer att ändras, men mönstret består: du kontrollerar tillgänglighet, förklarar eventuella nedladdningar, erbjuder reservdelar och mäter kvalitet.

Fallback är ingen sorglig plan B

Cloud fallback är inte ett nederlag. Det är en del av produkten.

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' };
}

Denna arkitektur tillåter dig att successivt förbättra. De med lokal support får bättre latens och integritet. De som inte har det använder fortfarande funktionen. Du kan mäta procentandel av lokala förfrågningar, tider, fel, minne, upplevd kvalitet och kostnad.

Utan mätvärden blir AI på enheten ett estetiskt val. Med mätvärden blir det en produktspak.

Modellens användarupplevelse spelar roll

Om webbläsaren behöver ladda ner en modell uppfattar användaren den. Göm det inte bakom en vag spinner. Bättre att vara tydlig: "Vi förbereder modellen för att använda den här funktionen snabbare och till och med offline."

En bra upplevelse:

• visar beredningsstatus;
• blockerar inte hela sidan;
• låter dig fortsätta med molnfallback;
• undvik batteri- och minnesöverraskningar;
• kom ihåg modellen när det är möjligt;
• förklara nyttan i en konkret mening.

Det värsta är en "smart" funktion som verkar trasig eftersom den laddar ner något tyst.

Sekretess: bättre, inte automatiskt säker

Att bearbeta data på enheten kan vara en stor fördel. Ett utkast till e-post, internt dokument eller personlig anteckning behöver inte lämna din webbläsare för att få ett förslag.

Lokal betyder dock inte automatiskt säker. Du måste dock tänka på:

• XSS;
• oavsiktliga loggar;
• data sparade i lagring;
• snabb injektion från opålitligt innehåll;
• tillstånd som beviljats modellen;
• utgångar som används i automatiska åtgärder.

Om en lokal modell kan läsa en webbsida och sedan fylla i ett formulär, kan den sidan försöka manipulera den. Om det kan anropa verktyget krävs bekräftelse. Om den producerar strukturerad produktion måste den valideras. Det faktum att den körs på enheten minskar vissa integritetsrisker, men eliminerar inte säkerhetsmodellen.

Där det blir riktigt intressant

Texten är bara början. WebGPU gör webbupplevelser trovärdiga som tills nyligen verkade som en inbyggd app:

• komplexa 3D-redigerare;
• Gaussiska stänk i webbläsaren;
• realtidsvideofilter;
• Lätt CAD;
• vetenskapliga visualiseringar;
• kreativa verktyg med omedelbar förhandsvisning;
• vision slutledning nära UI;
• mer ambitiösa webbläsarspel.

Här börjar frontend, grafik och maskininlärning blandas. Det är ett lite besvärligt område, men också ett bördigt sådant: webbläsaren återgår till att vara en seriös applikationsplattform, inte bara platsen där vi lägger formulär och instrumentpaneler.

Checklista före produktion

Innan jag lägger en funktion på enheten framför användarna, skulle jag kontrollera:

1. Rikta in webbläsare och enheter.
2. Molntillbakagång eller elegant nedbrytning.
3. Ladda ner tid och modellcache.
4. Minne och batteri i genomsnitt hårdvara.
5. Kvalitet jämfört med molnversionen.
6. Sekretesspolicy och användarmeddelanden.
7. Testa med fientliga ingångar.
8. Separat mätvärde för lokal och molnkörning.
9. Planera att uppdatera eller inaktivera mallen.

Det är en konkret lista eftersom problemet är konkret. En långsam, ömtålig eller ogenomskinlig AI-funktion blir inte bättre bara för att den körs i webbläsaren.

Rätt kompromiss

Jag tror inte att framtiden är "allt på enheten". Och jag tror inte heller att molnet kommer att förbli den enda rimliga platsen för slutsatser. Den mest troliga framtiden är en blandning: lokal när den förbättrar latens, integritet eller kostnad; moln när kvalitet, uppdaterad data och centraliserad kontroll behövs.

WebGPU, WebNN och inbyggda AI API:er gör inte webbläsaren allsmäktig. De gör honom mer vuxen. Och för dem som bygger webbprodukter är detta enorma nyheter.

Användbara källor

• WebGPU API - MDN
• WebGPU-specifikation - W3C
• Inbyggd AI - Chrome för utvecklare
• Inbyggda AI API:er - Chrome för utvecklare
• WebNN API