1~
2I årevis var browseren applikationens pæne ansigt, og skyen var stedet, hvor de svære ting skete. Brugeren skriver, klikker, uploader en fil; frontenden sender alt til serveren; serveren kalder en model; svaret kommer tilbage.
3~
4Denne ordning forbliver meget nyttig, men den er ikke gratis. Hvert opkald bringer spørgsmål om ventetid, omkostninger, netværksafhængighed og privatliv. Hvis brugeren skriver en sætning og ønsker et forslag, vejer et halvt sekund. Hvis du klassificerer tusindvis af små input, bliver øre til rigtige penge. Hvis teksten er følsom, er det ikke et neutralt valg at sende den fra enheden.
5~
6Det er derfor, WebGPU og AI på enheden er i hype. Ikke fordi vi kører alle modeller i browseren i morgen. Fordi nogle af de intelligente funktioner kan komme tættere på brugeren.
7~
8## Ikke alt skal blive lokalt
9~
10Den barnlige version af argumentet er: "sky versus enhed". Den nyttige version er hybrid.
11~
12Nogle opgaver ser godt ud på enheden: korte resuméer, sproggenkendelse, lysomskrivninger, simple klassifikationer, billedfiltre, små visionsmodeller, kreative oplevelser med øjeblikkelig feedback.
13~
14Andre opgaver forbliver bedre i skyen: komplekse ræsonnementer, grænsemodeller, data på serversiden, centraliseret revision, ensartet kvalitet, workflow, hvor du omhyggeligt skal kontrollere hvert trin.
15~
16Den sunde arkitektur bestemmer under kørsel:
17~
18```mermaid
19flowchart TD
20    User[Bruger] --> Browser[Browsere]
21    Browser --> Detect[Funktionsgenkendelse]
22    Detect -->|Understøttet| Local[Lokal slutning]
23    Detect -->|Ikke understøttet| Cloud[Sky faldback]
24    Local --> UX[Hurtig respons]
25    Cloud --> UX
26    UX --> Metrics[Målinger og kvalitet]
27```
28~
29Browseren behøver ikke at vinde mod skyen. Det skal redde skyen fra at udføre arbejde, der ikke skal udføres der.
30~
31## Hvorfor WebGPU betyder noget
32~
33WebGPU er en moderne API til brug af GPU'en fra browseren. Det er ikke kun for pænere 3D-grafik. Det er også vigtigt, fordi det afslører primitiver, der er egnede til computere: parallelle arbejdsbelastninger, shaders, pipelines tættere på, hvad GPU'er gør godt.
34~
35For kunstig intelligens, videnskabelig visualisering, 3D-editorer, videofiltre og kreative værktøjer mærkes denne forskel. WebGL har gjort meget for nettet, men WebGPU blev født med en model, der passer bedre til nutiden.
36~
37Den første ting at skrive, er dog ikke en skygge. Det er en sober funktionsdetektion:
38~
39```typescript
40export async function requestWebGpuDevice() {
41  if (!('gpu' in navigator)) {
42    return null;
43  }
44~
45  const adapter = await navigator.gpu.requestAdapter({
46    powerPreference: 'high-performance',
47  });
48~
49  if (!adapter) {
50    return null;
51  }
52~
53  return adapter.requestDevice();
54}
55```
56~
57Denne funktion siger en vigtig ting: WebGPU er ikke en rettighed, der er givet på alle enheder. Det er en evne til at blive verificeret. Nogle browsere understøtter det ikke fuldt ud, nogle GPU'er har begrænsninger, nogle virksomhedsmiljøer deaktiverer funktioner, nogle brugere bruger beskeden hardware.
58~
59## Indbygget AI: når browseren bringer modellen
60~
61Chrome skubber indbyggede API'er til opgaver som lokale prompter, opsummering, skrivning, omskrivning, oversættelse, sprogregistrering og korrekturlæsning. Ideen er meget interessant: browseren administrerer model, tilgængelighed og opdateringer; appen bruger en API tættere på platformen.
62~
63Hvis det fungerer godt, ændrer det meget:
64~
65- færre serverkald til simple opgaver;
66- data, der kan forblive på enheden;
67- lavere latenstid;
68- offline eller semi-offline oplevelser;
69- Mere naturlig UX til skrivning og oversættelse.
70~
71Men det bør behandles som progressiv forbedring. Nogle API'er er stabile, andre i original prøveversion eller preview, andre afhænger stadig af version, sprog og enhed.
72~
73```typescript
74type LocalCapability = 'available' | 'downloadable' | 'unsupported';
75~
76export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
77  const SummarizerApi = (globalThis as any).Summarizer;
78~
79  if (!SummarizerApi?.availability) {
80    return 'unsupported';
81  }
82~
83  const availability = await SummarizerApi.availability();
84~
85  if (availability === 'available') return 'available';
86  if (availability === 'downloadable') return 'downloadable';
87~
88  return 'unsupported';
89}
90```
91~
92Den specifikke kode vil ændre sig, men mønsteret forbliver: du tjekker tilgængelighed, forklarer eventuelle downloads, tilbyder fallbacks og måler kvalitet.
93~
94## Fallback er ikke en trist plan B
95~
96Cloud fallback er ikke et nederlag. Det er en del af produktet.
97~
98```typescript
99interface AiRequest {
100  task: 'summarize' | 'rewrite' | 'classify';
101  input: string;
102}
103~
104interface AiResult {
105  output: string;
106  runtime: 'local' | 'cloud';
107}
108~
109export async function runAiTask(request: AiRequest): Promise<AiResult> {
110  const local = await tryLocalAi(request);
111~
112  if (local) {
113    return { output: local, runtime: 'local' };
114  }
115~
116  const cloud = await fetch('/api/ai', {
117    method: 'POST',
118    headers: { 'Content-Type': 'application/json' },
119    body: JSON.stringify(request),
120  }).then((res) => res.json());
121~
122  return { output: cloud.output, runtime: 'cloud' };
123}
124```
125~
126Denne arkitektur giver dig mulighed for gradvist at forbedre. Dem med lokal support får bedre latenstid og privatliv. Dem, der ikke har det, bruger stadig funktionen. Du kan måle procentdelen af ​​lokale anmodninger, tidspunkter, fejl, hukommelse, opfattet kvalitet og omkostninger.
127~
128Uden målinger bliver AI på enheden et æstetisk valg. Med målinger bliver det en produkthåndtag.
129~
130## Modellens UX har betydning
131~
132Hvis browseren skal downloade en model, opfatter brugeren den. Gem det ikke bag en vag spinner. Bedre at være klar: "Vi forbereder modellen til at bruge denne funktion hurtigere og endda offline."
133~
134En god oplevelse:
135~
136- viser forberedelsesstatus;
137- blokerer ikke hele siden;
138- giver dig mulighed for at fortsætte med cloud fallback;
139- undgå batteri- og hukommelsesoverraskelser;
140- husk modellen, når det er muligt;
141- forklare fordelen i én konkret sætning.
142~
143Det værste er en "smart" funktion, der ser ud til at være ødelagt, fordi den downloader noget lydløst.
144~
145## Privatliv: bedre, ikke automatisk sikker
146~
147Behandling af data på enheden kan være en stor fordel. Et udkast til e-mail, et internt dokument eller en personlig note behøver ikke at forlade din browser for at modtage et forslag.
148~
149Lokal betyder dog ikke automatisk sikker. Du skal dog tænke på:
150~
151- XSS;
152- utilsigtede logfiler;
153- data gemt på lager;
154- hurtig indsprøjtning fra indhold, der ikke er tillid til;
155- tilladelser givet til modellen;
156- output brugt i automatiske handlinger.
157~
158Hvis en lokal model kan læse en webside og derefter udfylde en formular, kan den side forsøge at manipulere den. Hvis det kan kalde værktøj, er bekræftelse nødvendig. Hvis det producerer struktureret output, skal det valideres. Det faktum, at det kører på enheden, reducerer nogle privatlivsrisici, men eliminerer ikke sikkerhedsmodellen.
159~
160## Hvor det bliver rigtig interessant
161~
162Teksten er kun begyndelsen. WebGPU gør weboplevelser troværdige, der indtil for nylig virkede som en indbygget app:
163~
164- komplekse 3D-editorer;
165- Gaussisk sprøjt i browseren;
166- videofiltre i realtid;
167- Letvægts CAD;
168- videnskabelige visualiseringer;
169- kreative værktøjer med øjeblikkelig forhåndsvisning;
170- vision inferens nær UI;
171- mere ambitiøse browserspil.
172~
173Her begynder frontend, grafik og maskinlæring at blandes. Det er et noget akavet område, men også et frugtbart område: Browseren vender tilbage til at være en seriøs applikationsplatform, ikke kun stedet, hvor vi placerer formularer og dashboards.
174~
175## Tjekliste før produktion
176~
177Før jeg sætter en funktion på enheden foran brugerne, vil jeg tjekke:
178~
1791. Målret browsere og enheder.
1802. Skyfald eller elegant nedbrydning.
1813. Download tid og model cache.
1824. Hukommelse og batteri i gennemsnit hardware.
1835. Kvalitet sammenlignet med cloud-versionen.
1846. Privatlivspolitik og brugerbeskeder.
1857. Test med fjendtlige input.
1868. Separate metrics for lokal og cloud-runtime.
1879. Planlæg at opdatere eller deaktivere skabelonen.
188~
189Det er en konkret liste, fordi problemet er konkret. En langsom, skrøbelig eller uigennemsigtig AI-funktion bliver ikke bedre, bare fordi den kører i browseren.
190~
191## Det rigtige kompromis
192~
193Jeg tror ikke på, at fremtiden er "alt på enheden". Og jeg tror heller ikke, at skyen forbliver det eneste rimelige sted for slutninger. Den mest sandsynlige fremtid er en blanding: lokal, når det forbedrer latens, privatliv eller omkostninger; cloud, når der er behov for kvalitet, opdaterede data og centraliseret kontrol.
194~
195WebGPU, WebNN og indbyggede AI API'er gør ikke browseren almægtig. De gør ham mere voksen. Og for dem, der bygger webprodukter, er dette store nyheder.
196~
197## Nyttige kilder
198~
199- [WebGPU API - MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)
200- [WebGPU-specifikation - W3C](https://www.w3.org/TR/webgpu/)
201- [Indbygget AI - Chrome for udviklere](https://developer.chrome.com/docs/ai/built-in)
202- [Indbyggede AI API'er - Chrome for udviklere](https://developer.chrome.com/docs/ai/built-in-apis)
203- [WebNN API](https://webnn.io/)
204~