Sa loob ng maraming taon ang browser ay ang magandang mukha ng application at ang ulap ay ang lugar kung saan nangyari ang mahirap na bagay. Nagsusulat, nag-click, nag-upload ng file ang user; ang frontend ay nagpapadala ng lahat sa server; ang server ay tumatawag ng isang modelo; babalik ang sagot.

Ang scheme na ito ay nananatiling lubhang kapaki-pakinabang, ngunit hindi ito libre. Ang bawat tawag ay nagdadala ng latency, gastos, dependency sa network, at mga tanong sa privacy. Kung ang gumagamit ay nagsusulat ng isang pangungusap at nais ng isang mungkahi, kalahating segundo ay tumitimbang. Kung nag-uuri ka ng libu-libong maliliit na input, ang mga pennies ay magiging totoong pera. Kung sensitibo ang text, hindi neutral na pagpipilian ang pagpapadala nito sa device.

Kaya naman ang WebGPU at on-device AI ay nasa hype. Hindi dahil papatakbuhin namin ang bawat modelo sa browser bukas. Dahil ang ilan sa mga matalinong tampok ay maaaring maging mas malapit sa gumagamit.

Hindi lahat ay kailangang maging lokal

Ang pambatang bersyon ng argumento ay: "cloud versus device". Ang kapaki-pakinabang na bersyon ay hybrid.

Ang ilang mga gawain ay mukhang mahusay sa device: maiikling buod, pagtuklas ng wika, magaan na pagsusulat, simpleng pag-uuri, mga filter ng larawan, mga modelo ng maliit na pananaw, mga malikhaing karanasan na may agarang feedback.

Ang iba pang mga gawain ay nananatiling mas mahusay sa cloud: kumplikadong pangangatwiran, mga modelo ng hangganan, data sa panig ng server, sentralisadong pag-audit, pare-parehong kalidad, daloy ng trabaho kung saan kailangan mong maingat na kontrolin ang bawat hakbang.

Ang malusog na arkitektura ay nagpapasya sa runtime:

Ang browser ay hindi kailangang manalo laban sa cloud. Dapat nitong i-save ang cloud mula sa paggawa ng trabaho na hindi kailangang gawin doon.

Bakit mahalaga ang WebGPU

Ang WebGPU ay isang modernong API para sa paggamit ng GPU mula sa browser. Ito ay hindi lamang para sa mas magandang 3D graphics. Mahalaga rin ito dahil inilalantad nito ang mga primitive na angkop para sa pag-compute: parallel workloads, shaders, pipelines na mas malapit sa kung ano ang mahusay na ginagawa ng mga GPU.

Para sa AI, scientific visualization, 3D editor, video filter at creative tool, nararamdaman ang pagkakaibang ito. Maraming nagawa ang WebGL para sa web, ngunit ipinanganak ang WebGPU na may modelong mas angkop sa kasalukuyan.

Ang unang bagay na isusulat, gayunpaman, ay hindi isang shader. Isa itong matino na pagtuklas ng tampok:

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

Ang feature na ito ay nagsasabi ng isang mahalagang bagay: Ang WebGPU ay hindi isang karapatang ibinibigay sa bawat device. Ito ay isang kakayahang ma-verify. Ang ilang mga browser ay hindi ganap na sumusuporta dito, ang ilang mga GPU ay may mga limitasyon, ang ilang mga enterprise environment ay hindi pinagana ang mga tampok, ang ilang mga gumagamit ay nasa katamtamang hardware.

Built-in na AI: kapag dinala ng browser ang modelo

Itinutulak ng Chrome ang mga built-in na API para sa mga gawain tulad ng mga lokal na prompt, pagbubuod, pagsusulat, muling pagsusulat, pagsasalin, pagtukoy ng wika, at pag-proofread. Ang ideya ay lubhang kawili-wili: pinamamahalaan ng browser ang modelo, kakayahang magamit at mga update; gumagamit ang app ng API na mas malapit sa platform.

Kung gumagana ito nang maayos, malaki ang pagbabago nito:

• mas kaunting mga tawag sa server para sa mga simpleng gawain;
• data na maaaring manatili sa device;
• mas mababang latency;
• offline o semi-offline na mga karanasan;
• Mas natural na UX para sa pagsulat at pagsasalin.

Ngunit dapat itong ituring bilang progresibong pagpapahusay. Ang ilang mga API ay matatag, ang iba ay nasa pinagmulang pagsubok o preview, ang iba ay nakadepende pa rin sa bersyon, wika at device.

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

Magbabago ang partikular na code, ngunit nananatili ang pattern: titingnan mo ang availability, ipaliwanag ang anumang mga pag-download, nag-aalok ng mga fallback, at sinusukat ang kalidad.

Ang Fallback ay hindi isang malungkot na plano B

Hindi pagkatalo ang Cloud fallback. Ito ay bahagi ng produkto.

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

Ang arkitektura na ito ay nagpapahintulot sa iyo na unti-unting pagbutihin. Ang mga may lokal na suporta ay nakakakuha ng mas mahusay na latency at privacy. Ginagamit pa rin ng mga wala nito ang feature. Maaari mong sukatin ang porsyento ng mga lokal na kahilingan, oras, error, memorya, pinaghihinalaang kalidad at gastos.

Kung walang sukatan, ang on-device na AI ay nagiging isang aesthetic na pagpipilian. Sa mga sukatan, ito ay nagiging isang product lever.

Mahalaga ang UX ng modelo

Kung kailangan ng browser na mag-download ng modelo, nakikita ito ng user. Huwag itago ito sa likod ng hindi malinaw na spinner. Mas mahusay na maging malinaw: "Inihahanda namin ang modelo upang gamitin ang function na ito nang mas mabilis at kahit offline."

Isang magandang karanasan:

• nagpapakita ng katayuan ng paghahanda;
• hindi hinaharangan ang buong pahina;
• nagbibigay-daan sa iyo na magpatuloy sa cloud fallback;
• maiwasan ang mga sorpresa sa baterya at memorya;
• tandaan ang modelo hangga't maaari;
• ipaliwanag ang benepisyo sa isang kongkretong pangungusap.

Ang pinakamasama ay isang "matalinong" na feature na mukhang sira dahil tahimik itong nagda-download ng isang bagay.

Privacy: mas mabuti, hindi awtomatikong secure

Ang pagpoproseso ng data sa device ay maaaring maging isang malaking kalamangan. Ang isang draft na email, panloob na dokumento, o personal na tala ay hindi kailangang umalis sa iyong browser upang makatanggap ng mungkahi.

Gayunpaman, ang lokal ay hindi awtomatikong nangangahulugang ligtas. Gayunpaman, kailangan mong mag-isip tungkol sa:

• XSS;
• hindi sinasadyang mga tala;
• data na naka-save sa imbakan;
• agarang iniksyon mula sa hindi pinagkakatiwalaang nilalaman;
• mga pahintulot na ibinigay sa modelo;
• mga output na ginagamit sa mga awtomatikong pagkilos.

Kung mababasa ng isang lokal na modelo ang isang web page at pagkatapos ay punan ang isang form, maaaring subukan ng page na iyon na manipulahin ito. Kung maaari itong tumawag sa tool, kailangan ang kumpirmasyon. Kung ito ay gumagawa ng nakabalangkas na output, dapat itong mapatunayan. Ang katotohanang tumatakbo ito sa device ay nagpapababa ng ilang panganib sa privacy, ngunit hindi inaalis ang modelo ng seguridad.

Kung saan ito ay talagang kawili-wili

Ang teksto ay simula pa lamang. Ginagawa ng WebGPU na kapani-paniwala ang mga karanasan sa web na hanggang kamakailan ay tila isang katutubong app:

• kumplikadong 3D editor;
• Gaussian splatting sa browser;
• real-time na mga filter ng video;
• Magaang CAD;
• pang-agham na visualization;
• malikhaing tool na may instant preview;
• vision inference malapit sa UI;
• mas ambisyosong mga laro sa browser.

Dito nagsisimulang maghalo ang frontend, graphics at machine learning. Ito ay isang medyo awkward na lugar, ngunit isa ring mataba: ang browser ay bumalik sa pagiging isang seryosong platform ng aplikasyon, hindi lamang ang lugar kung saan kami naglalagay ng mga form at dashboard.

Checklist bago ang produksyon

Bago maglagay ng feature sa device sa harap ng mga user, susuriin ko:

1. I-target ang mga browser at device.
2. Cloud fallback o eleganteng pagkasira.
3. Oras ng pag-download at cache ng modelo.
4. Memorya at baterya sa karaniwang hardware.
5. Kalidad kumpara sa bersyon ng cloud.
6. Patakaran sa privacy at mga mensahe ng user.
7. Pagsubok gamit ang mga pagalit na input.
8. Paghiwalayin ang mga sukatan para sa lokal at cloud runtime.
9. Plano na i-update o i-disable ang template.

Ito ay isang kongkretong listahan dahil ang problema ay konkreto. Ang isang mabagal, marupok, o opaque na feature ng AI ay hindi nagiging mas mahusay dahil lang sa tumatakbo ito sa browser.

Ang tamang kompromiso

Hindi ako naniniwala na ang hinaharap ay "lahat ng bagay sa device". At sa palagay ko ay hindi rin mananatiling ang ulap ang tanging makatwirang lugar para sa hinuha. Ang pinaka-malamang na hinaharap ay isang halo: lokal kapag pinahusay nito ang latency, privacy, o gastos; cloud kapag kailangan ang kalidad, na-update na data at sentralisadong kontrol.

Hindi ginagawa ng WebGPU, WebNN at mga built-in na AI API ang browser na makapangyarihan sa lahat. Ginagawa nila siyang mas matanda. At para sa mga gumagawa ng mga produkto sa web, ito ay malaking balita.

Mga kapaki-pakinabang na mapagkukunan

• WebGPU API - MDN
• Detalye ng WebGPU - W3C
• Built-in na AI - Chrome para sa Mga Developer
• Mga Built-in na AI API - Chrome para sa Mga Developer
• WebNN API