Jarenlang was de browser het mooie gezicht van de applicatie en de cloud de plek waar de harde dingen gebeurden. De gebruiker schrijft, klikt, uploadt een bestand; de frontend stuurt alles naar de server; de server roept een model aan; het antwoord komt terug.

Dit schema blijft erg handig, maar het is niet gratis. Elk gesprek brengt latentie, kosten, netwerkafhankelijkheid en privacyvragen met zich mee. Als de gebruiker een zin schrijft en een suggestie wil, weegt een halve seconde. Als je duizenden kleine inputs classificeert, worden centen echt geld. Als de tekst gevoelig is, is het verzenden ervan vanaf het apparaat geen neutrale keuze.

Dat is de reden waarom WebGPU en AI op het apparaat in een hype zijn. Niet omdat we morgen elk model in de browser zullen draaien. Omdat sommige intelligente functies dichter bij de gebruiker kunnen komen.

Niet alles hoeft lokaal te worden

De kinderachtige versie van het argument is: ‘cloud versus device’. De nuttige versie is hybride.

Sommige taken zien er geweldig uit op het apparaat: korte samenvattingen, taaldetectie, lichte herschrijvingen, eenvoudige classificaties, beeldfilters, kleine visiemodellen, creatieve ervaringen met onmiddellijke feedback.

Andere taken blijven beter in de cloud: complex redeneren, grensmodellen, server-side data, gecentraliseerde audit, uniforme kwaliteit, workflow waarbij je elke stap zorgvuldig moet controleren.

De gezonde architectuur beslist tijdens runtime:

De browser hoeft niet te winnen van de cloud. Het moet de cloud behoeden voor werk dat daar niet gedaan hoeft te worden.

Waarom WebGPU belangrijk is

WebGPU is een moderne API voor het gebruik van de GPU vanuit de browser. Het is niet alleen voor mooiere 3D-graphics. Het is ook belangrijk omdat het primitieven blootlegt die geschikt zijn voor computergebruik: parallelle werklasten, shaders, pijplijnen die dichter bij datgene liggen waar GPU's goed in zijn.

Voor AI, wetenschappelijke visualisatie, 3D-editors, videofilters en creatieve tools is dit verschil voelbaar. WebGL heeft veel voor het web gedaan, maar WebGPU werd geboren met een model dat beter geschikt was voor het heden.

Het eerste dat u moet schrijven, is echter geen shader. Het is een nuchtere functiedetectie:

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

Deze functie zegt één belangrijk ding: WebGPU is niet een recht dat op elk apparaat wordt verleend. Het is een vermogen om te verifiëren. Sommige browsers ondersteunen het niet volledig, sommige GPU's hebben beperkingen, sommige bedrijfsomgevingen schakelen functies uit, sommige gebruikers gebruiken bescheiden hardware.

Ingebouwde AI: wanneer de browser het model brengt

Chrome pusht ingebouwde API's voor taken zoals lokale aanwijzingen, samenvattingen, schrijven, herschrijven, vertalen, taaldetectie en proeflezen. Het idee is erg interessant: de browser beheert het model, de beschikbaarheid en updates; de app gebruikt een API dichter bij het platform.

Als het goed werkt, verandert er veel:

• minder serveroproepen voor eenvoudige taken;
• gegevens die mogelijk op het apparaat achterblijven;
• lagere latentie;
• offline of semi-offline ervaringen;
• Meer natuurlijke UX voor schrijven en vertalen.

Maar het moet worden beschouwd als een progressieve verbetering. Sommige API's zijn stabiel, andere zijn in de oorspronkelijke proefversie of preview, andere zijn nog steeds afhankelijk van versie, taal en apparaat.

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

De specifieke code verandert, maar het patroon blijft: je checkt de beschikbaarheid, legt eventuele downloads uit, biedt fallbacks aan en meet de kwaliteit.

Terugval is geen triest plan B

Terugval in de cloud is geen nederlaag. Het maakt deel uit van het product.

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

Met deze architectuur kunt u geleidelijk verbeteren. Degenen met lokale ondersteuning krijgen betere latentie en privacy. Degenen die het niet hebben, gebruiken de functie nog steeds. U kunt het percentage lokale verzoeken, tijden, fouten, geheugen, waargenomen kwaliteit en kosten meten.

Zonder statistieken wordt AI op het apparaat een esthetische keuze. Met statistieken wordt het een producthefboom.

De UX van het model is belangrijk

Als de browser een model moet downloaden, neemt de gebruiker dit waar. Verberg het niet achter een vage spinner. Voor alle duidelijkheid: "We bereiden het model voor om deze functie sneller en zelfs offline te gebruiken."

Een goede ervaring:

• toont de bereidingsstatus;
• blokkeert niet de hele pagina;
• stelt u in staat door te gaan met cloud-fallback;
• vermijd batterij- en geheugenverrassingen;
• onthoud het model waar mogelijk;
• leg het voordeel in één concrete zin uit.

Het ergste is een "slimme" functie die kapot lijkt te zijn omdat er iets stil wordt gedownload.

Privacy: beter, niet automatisch veilig

Het verwerken van gegevens op het apparaat kan een groot voordeel zijn. Een concept-e-mail, intern document of persoonlijke notitie hoeft uw browser niet te verlaten om een ​​suggestie te ontvangen.

Lokaal betekent echter niet automatisch veilig. U moet echter nadenken over:

• XSS;
• onbedoelde logboeken;
• gegevens opgeslagen in opslag;
• snelle injectie van niet-vertrouwde inhoud;
• machtigingen verleend aan het model;
• uitgangen die worden gebruikt in automatische acties.

Als een lokaal model een webpagina kan lezen en vervolgens een formulier kan invullen, kan die pagina proberen deze te manipuleren. Als het gereedschap kan oproepen, is bevestiging nodig. Als het gestructureerde output oplevert, moet het gevalideerd worden. Het feit dat het op het apparaat draait, vermindert enkele privacyrisico's, maar elimineert het beveiligingsmodel niet.

Waar het echt interessant wordt

De tekst is nog maar het begin. WebGPU maakt webervaringen geloofwaardig die tot voor kort een native app leken:

• complexe 3D-editors;
• Gaussiaanse splatting in de browser;
• real-time videofilters;
• Lichtgewicht CAD;
• wetenschappelijke visualisaties;
• creatieve tools met direct voorbeeld;
• visie-inferentie nabij de gebruikersinterface;
• ambitieuzere browsergames.

Hier beginnen frontend, graphics en machine learning zich te vermengen. Het is een wat lastig gebied, maar ook een vruchtbaar gebied: de browser wordt weer een serieus applicatieplatform, niet alleen de plek waar we formulieren en dashboards plaatsen.

Controlelijst vóór productie

Voordat ik een functie op het apparaat aan gebruikers beschikbaar stel, zou ik het volgende controleren:

1. Doelbrowsers en apparaten.
2. Terugval in de cloud of elegante degradatie.
3. Download tijd- en modelcache.
4. Geheugen en batterij op gemiddelde hardware.
5. Kwaliteit vergeleken met de cloudversie.
6. Privacybeleid en gebruikersberichten.
7. Testen met vijandige input.
8. Afzonderlijke statistieken voor lokale runtime en cloudruntime.
9. Plan om de sjabloon bij te werken of uit te schakelen.

Het is een concrete lijst omdat het probleem concreet is. Een trage, kwetsbare of ondoorzichtige AI-functie wordt niet beter alleen omdat deze in de browser draait.

Het juiste compromis

Ik geloof niet dat de toekomst “alles op het apparaat” is. En ik denk ook niet dat de cloud de enige redelijke plaats voor gevolgtrekkingen zal blijven. De meest waarschijnlijke toekomst is een mix: lokaal als het de latentie, privacy of kosten verbetert; cloud wanneer kwaliteit, bijgewerkte gegevens en gecentraliseerde controle nodig zijn.

WebGPU, WebNN en ingebouwde AI API’s maken de browser niet almachtig. Ze maken hem volwassener. En voor degenen die webproducten bouwen is dit groot nieuws.

Nuttige bronnen

• WebGPU-API - MDN
• WebGPU-specificatie - W3C
• Ingebouwde AI - Chrome voor ontwikkelaars
• Ingebouwde AI API's - Chrome voor ontwikkelaars
• WebNN-API