เป็นเวลาหลายปีที่เบราว์เซอร์เป็นหน้าตาที่สวยงามของแอปพลิเคชัน และระบบคลาวด์คือจุดที่เรื่องยากๆ เกิดขึ้น ผู้ใช้เขียน คลิก อัพโหลดไฟล์ ส่วนหน้าส่งทุกอย่างไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์เรียกโมเดล คำตอบกลับมา

โครงการนี้ยังคงมีประโยชน์มาก แต่ก็ไม่ฟรี การโทรทุกครั้งทำให้เกิดความล่าช้า ค่าใช้จ่าย การพึ่งพาเครือข่าย และคำถามเกี่ยวกับความเป็นส่วนตัว หากผู้ใช้เขียนประโยคและต้องการคำแนะนำ ให้ใช้เวลาครึ่งวินาที หากคุณจำแนกปัจจัยการผลิตเล็กๆ น้อยๆ นับพันเพนนีก็จะกลายเป็นเงินจริง หากข้อความมีความละเอียดอ่อน การส่งออกจากอุปกรณ์ก็ไม่ใช่ทางเลือกที่เป็นกลาง

นั่นเป็นเหตุผลว่าทำไม WebGPU และ AI บนอุปกรณ์ถึงได้รับความนิยม ไม่ใช่เพราะเราจะเรียกใช้ทุกรุ่นในเบราว์เซอร์พรุ่งนี้ เพราะฟีเจอร์อัจฉริยะบางอย่างสามารถเข้าใกล้ผู้ใช้ได้มากขึ้น

ไม่ใช่ทุกอย่างจะต้องกลายเป็นท้องถิ่น

อาร์กิวเมนต์เวอร์ชันเด็กๆ คือ: "คลาวด์กับอุปกรณ์" เวอร์ชันที่มีประโยชน์คือไฮบริด

งานบางอย่างดูดีบนอุปกรณ์: สรุปสั้นๆ, การตรวจจับภาษา, การเขียนแสงใหม่, การจำแนกประเภทอย่างง่าย, ฟิลเตอร์ภาพ, โมเดลการมองเห็นขนาดเล็ก, ประสบการณ์ที่สร้างสรรค์พร้อมการตอบรับทันที

งานอื่นๆ ยังคงดีกว่าในระบบคลาวด์: การใช้เหตุผลที่ซับซ้อน โมเดลขอบเขต ข้อมูลฝั่งเซิร์ฟเวอร์ การตรวจสอบจากส่วนกลาง คุณภาพที่สม่ำเสมอ ขั้นตอนการทำงานที่คุณต้องควบคุมแต่ละขั้นตอนอย่างระมัดระวัง

สถาปัตยกรรมที่ดีจะตัดสินใจที่รันไทม์:

เบราว์เซอร์ไม่จำเป็นต้องเอาชนะระบบคลาวด์ จะต้องช่วยให้คลาวด์ไม่ต้องทำงานที่ไม่จำเป็นต้องทำที่นั่น

เหตุใด WebGPU จึงมีความสำคัญ

WebGPU เป็น API ที่ทันสมัยสำหรับการใช้ GPU จากเบราว์เซอร์ ไม่ใช่เพียงเพื่อกราฟิก 3D ที่สวยงามยิ่งขึ้นเท่านั้น นอกจากนี้ยังเป็นสิ่งสำคัญเนื่องจากจะเปิดเผยสิ่งพื้นฐานที่เหมาะสมสำหรับการประมวลผล: ปริมาณงานแบบขนาน, เชเดอร์, ไปป์ไลน์ที่ใกล้เคียงกับสิ่งที่ GPU ทำได้ดี

สำหรับ AI การสร้างภาพทางวิทยาศาสตร์ โปรแกรมแก้ไข 3 มิติ ตัวกรองวิดีโอ และเครื่องมือสร้างสรรค์ รู้สึกถึงความแตกต่างนี้ได้ WebGL ทำประโยชน์มากมายให้กับเว็บ แต่ WebGPU เกิดมาพร้อมกับโมเดลที่เหมาะกับปัจจุบันมากกว่า

สิ่งแรกที่ต้องเขียนไม่ใช่เชเดอร์ เป็นการตรวจจับคุณสมบัติที่เงียบขรึม:

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

คุณลักษณะนี้กล่าวถึงสิ่งสำคัญอย่างหนึ่ง: WebGPU ไม่ได้รับการอนุญาตในทุกอุปกรณ์ เป็นความสามารถที่จะตรวจสอบได้ เบราว์เซอร์บางตัวไม่รองรับอย่างเต็มที่, GPU บางตัวมีข้อจำกัด, สภาพแวดล้อมองค์กรบางอย่างปิดการใช้งานคุณสมบัติ, ผู้ใช้บางคนใช้ฮาร์ดแวร์เพียงเล็กน้อย

AI ในตัว: เมื่อเบราว์เซอร์นำโมเดลมา

Chrome กำลังผลักดัน API ในตัวสำหรับงานต่างๆ เช่น ข้อความแจ้งในเครื่อง การสรุป การเขียน การเขียนใหม่ การแปล การตรวจหาภาษา และการพิสูจน์อักษร แนวคิดนี้น่าสนใจมาก: เบราว์เซอร์จัดการโมเดล ความพร้อมใช้งาน และการอัปเดต แอปใช้ API ใกล้กับแพลตฟอร์มมากขึ้น

ถ้ามันทำงานได้ดีก็เปลี่ยนแปลงไปมาก:

• การเรียกเซิร์ฟเวอร์น้อยลงสำหรับงานง่ายๆ
• ข้อมูลที่อาจยังคงอยู่ในอุปกรณ์
• เวลาแฝงที่ต่ำกว่า;
• ประสบการณ์ออฟไลน์หรือกึ่งออฟไลน์
• UX ที่เป็นธรรมชาติมากขึ้นสำหรับการเขียนและการแปล

แต่ควรถือเป็นการเพิ่มประสิทธิภาพแบบก้าวหน้า API บางตัวมีเสถียรภาพ ส่วนบางตัวอยู่ในช่วงทดลองใช้หรือดูตัวอย่างจากต้นทาง ส่วนบางตัวยังคงขึ้นอยู่กับเวอร์ชัน ภาษา และอุปกรณ์

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

รหัสเฉพาะจะเปลี่ยนแปลง แต่รูปแบบยังคงอยู่: คุณตรวจสอบความพร้อมใช้งาน อธิบายการดาวน์โหลด เสนอทางเลือกสำรอง และวัดคุณภาพ

ทางเลือกสำรองไม่ใช่แผน B ที่น่าเศร้า

Cloud Fallback ไม่ใช่ความพ่ายแพ้ เป็นส่วนหนึ่งของผลิตภัณฑ์

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

สถาปัตยกรรมนี้ช่วยให้คุณปรับปรุงได้อย่างต่อเนื่อง ผู้ที่ได้รับการสนับสนุนในท้องถิ่นจะได้รับเวลาแฝงและความเป็นส่วนตัวที่ดีขึ้น ผู้ที่ไม่มีมันยังคงใช้คุณสมบัตินี้ คุณสามารถวัดเปอร์เซ็นต์ของคำขอภายในเครื่อง เวลา ข้อผิดพลาด หน่วยความจำ คุณภาพที่รับรู้ และต้นทุน

หากไม่มีการวัดผล AI บนอุปกรณ์ก็จะกลายเป็นตัวเลือกที่สวยงาม ด้วยตัวชี้วัด มันจะกลายเป็นคันโยกผลิตภัณฑ์

UX ของโมเดลมีความสำคัญ

หากเบราว์เซอร์จำเป็นต้องดาวน์โหลดโมเดล ผู้ใช้จะรับรู้ได้ อย่าซ่อนมันไว้ข้างหลังสปินเนอร์ที่คลุมเครือ ให้ชัดเจนดีกว่า: "เราเตรียมโมเดลเพื่อใช้ฟังก์ชันนี้เร็วขึ้นและออฟไลน์ด้วย"

ประสบการณ์ที่ดี:

• แสดงสถานะการเตรียมการ
• ไม่ปิดกั้นทั้งหน้า
• ช่วยให้คุณสามารถใช้ระบบคลาวด์สำรองต่อไปได้
• หลีกเลี่ยงแบตเตอรี่และหน่วยความจำที่น่าประหลาดใจ
• จำโมเดลทุกครั้งที่เป็นไปได้
• อธิบายประโยชน์ในประโยคเดียวที่เป็นรูปธรรม

สิ่งที่แย่ที่สุดคือฟีเจอร์ "อัจฉริยะ" ที่ดูเหมือนจะใช้งานไม่ได้เพราะกำลังดาวน์โหลดบางอย่างอย่างเงียบๆ

ความเป็นส่วนตัว: ดีกว่า ไม่ปลอดภัยโดยอัตโนมัติ

การประมวลผลข้อมูลบนอุปกรณ์อาจเป็นข้อได้เปรียบอย่างมาก อีเมลฉบับร่าง เอกสารภายใน หรือบันทึกส่วนตัวไม่จำเป็นต้องออกจากเบราว์เซอร์เพื่อรับคำแนะนำ

อย่างไรก็ตาม ท้องถิ่นไม่ได้หมายความว่าปลอดภัยโดยอัตโนมัติ อย่างไรก็ตาม คุณต้องคำนึงถึง:

• เอสเอสเอส;
• บันทึกโดยไม่ได้ตั้งใจ
• ข้อมูลที่บันทึกไว้ในที่จัดเก็บ
• การฉีดทันทีจากเนื้อหาที่ไม่น่าเชื่อถือ
• การอนุญาตที่มอบให้กับโมเดล
• เอาต์พุตที่ใช้ในการดำเนินการอัตโนมัติ

หากโมเดลท้องถิ่นสามารถอ่านเว็บเพจแล้วกรอกแบบฟอร์มได้ เพจนั้นก็สามารถพยายามจัดการมันได้ หากสามารถเรียกเครื่องมือได้ จำเป็นต้องมีการยืนยัน หากสร้างเอาต์พุตที่มีโครงสร้าง จะต้องได้รับการตรวจสอบความถูกต้อง ความจริงที่ว่าอุปกรณ์ทำงานบนอุปกรณ์ช่วยลดความเสี่ยงด้านความเป็นส่วนตัว แต่ไม่ได้กำจัดรูปแบบการรักษาความปลอดภัย

มันน่าสนใจตรงไหน.

ข้อความเป็นเพียงจุดเริ่มต้น WebGPU ทำให้ประสบการณ์การใช้งานเว็บมีความน่าเชื่อถือจนเมื่อไม่นานมานี้ดูเหมือนเป็นแอปแบบเนทีฟ:

• โปรแกรมแก้ไข 3D ที่ซับซ้อน
• การสาดแบบเกาส์ในเบราว์เซอร์
• ตัวกรองวิดีโอแบบเรียลไทม์
• CAD น้ำหนักเบา;
• การสร้างภาพข้อมูลทางวิทยาศาสตร์
• เครื่องมือสร้างสรรค์พร้อมดูตัวอย่างทันที
• การอนุมานการมองเห็นใกล้กับ UI;
• เกมเบราว์เซอร์ที่ทะเยอทะยานมากขึ้น

ส่วนหน้า กราฟิก และการเรียนรู้ของเครื่องเริ่มผสมผสานกันที่นี่ มันเป็นพื้นที่ที่ค่อนข้างอึดอัด แต่ก็อุดมสมบูรณ์เช่นกัน เบราว์เซอร์กลับมาเป็นแพลตฟอร์มแอปพลิเคชันที่จริงจัง ไม่ใช่แค่ที่ที่เราวางแบบฟอร์มและแดชบอร์ด

รายการตรวจสอบก่อนการผลิต

ก่อนที่จะแสดงคุณสมบัติบนอุปกรณ์ต่อหน้าผู้ใช้ ฉันจะตรวจสอบ:

1. กำหนดเป้าหมายเบราว์เซอร์และอุปกรณ์
2. Cloud fallback หรือการเสื่อมสภาพที่สวยงาม
3. เวลาในการดาวน์โหลดและแคชโมเดล
4. หน่วยความจำและแบตเตอรี่บนฮาร์ดแวร์โดยเฉลี่ย
5. คุณภาพเมื่อเทียบกับเวอร์ชันคลาวด์
6. นโยบายความเป็นส่วนตัวและข้อความของผู้ใช้
7. การทดสอบด้วยอินพุตที่ไม่เป็นมิตร
8. แยกเมตริกสำหรับรันไทม์ในเครื่องและบนคลาวด์
9. วางแผนที่จะอัปเดตหรือปิดใช้งานเทมเพลต

มันเป็นรายการที่เป็นรูปธรรมเพราะปัญหาเป็นรูปธรรม คุณลักษณะ AI ที่ช้า เปราะบาง หรือทึบแสงไม่ได้ดีขึ้นเพียงเพราะมันทำงานในเบราว์เซอร์

การประนีประนอมที่ถูกต้อง

ฉันไม่เชื่อว่าอนาคตคือ "ทุกสิ่งบนอุปกรณ์" และฉันไม่คิดว่าคลาวด์จะยังคงเป็นเพียงที่เดียวที่สมเหตุสมผลสำหรับการอนุมานเช่นกัน อนาคตที่เป็นไปได้มากที่สุดคือการผสมผสาน: ในท้องถิ่นเมื่อปรับปรุงเวลาแฝง ความเป็นส่วนตัว หรือต้นทุน คลาวด์เมื่อจำเป็นต้องมีคุณภาพ ข้อมูลที่อัปเดต และการควบคุมแบบรวมศูนย์

WebGPU, WebNN และ AI API ในตัวไม่ได้ทำให้เบราว์เซอร์มีอำนาจทุกอย่าง พวกเขาทำให้เขาเป็นผู้ใหญ่มากขึ้น และสำหรับผู้ที่สร้างผลิตภัณฑ์บนเว็บ นี่เป็นข่าวใหญ่

แหล่งข้อมูลที่เป็นประโยชน์

• WebGPU API - MDN
• ข้อมูลจำเพาะ WebGPU - W3C
• AI ในตัว - Chrome สำหรับนักพัฒนา
• AI API ในตัว - Chrome สำหรับนักพัฒนา
• เว็บเอ็นเอ็นเอพีไอ