ปรับปรุงประสิทธิภาพและ UX สำหรับ AI ฝั่งไคลเอ็นต์

Maud Nalpas
Maud Nalpas

แม้ว่าฟีเจอร์ AI ส่วนใหญ่บนเว็บจะอาศัยเซิร์ฟเวอร์ แต่ AI ฝั่งไคลเอ็นต์จะทำงานในเบราว์เซอร์ของผู้ใช้โดยตรง ซึ่งมีข้อดีต่างๆ เช่น เวลาในการตอบสนองต่ำ ต้นทุนฝั่งเซิร์ฟเวอร์ลดลง ไม่ต้องใช้คีย์ API ความเป็นส่วนตัวของผู้ใช้เพิ่มขึ้น และการเข้าถึงแบบออฟไลน์ คุณสามารถใช้ AI ฝั่งไคลเอ็นต์ที่ทํางานในเบราว์เซอร์ต่างๆ ด้วย TensorFlow.js, Transformers.js และ MediaPipe GenAI

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

  • Use Case ของคุณ AI ฝั่งไคลเอ็นต์เป็นตัวเลือกที่เหมาะสมสําหรับฟีเจอร์ของคุณหรือไม่ ฟีเจอร์ของคุณอยู่ในเส้นทางของผู้ใช้ที่สําคัญหรือไม่ และหากใช่ คุณมีทางเลือกอื่นไหม
  • แนวทางปฏิบัติแนะนำสำหรับการดาวน์โหลดและการใช้โมเดล โปรดอ่านต่อเพื่อดูข้อมูลเพิ่มเติม

ก่อนดาวน์โหลดโมเดล

คลังความคิดและขนาดโมเดล

หากต้องการใช้ AI ฝั่งไคลเอ็นต์ คุณจะต้องมีโมเดลและมักจะต้องมีไลบรารีด้วย เมื่อเลือกคลัง ให้ประเมินขนาดของคลังเช่นเดียวกับเครื่องมืออื่นๆ

ขนาดของโมเดลก็สำคัญเช่นกัน ข้อมูลขนาดใหญ่สำหรับโมเดล AI นั้นขึ้นอยู่กับ 5 MB เป็นค่าประมาณที่มีประโยชน์เนื่องจากเป็นเปอร์เซ็นต์ไทล์ที่ 75 ของขนาดหน้าเว็บมัธยฐาน จำนวนที่ผ่อนปรนกว่านั้นคือ 10MB

สิ่งสำคัญที่ควรพิจารณาเกี่ยวกับขนาดโมเดลมีดังนี้

  • โมเดล AI เฉพาะงานจำนวนมากอาจมีขนาดเล็กมาก โมเดลอย่าง BudouX สำหรับตัวแบ่งอักขระที่ถูกต้องในภาษาเอเชียมีขนาดเล็กเพียง 9.4 KB เมื่อเป็นไฟล์ GZipped โมเดลการตรวจจับภาษาของ MediaPipe มีขนาดใหญ่ 315 KB
  • แม้แต่โมเดลภาพก็สามารถปรับขนาดให้เหมาะสมได้ โมเดล Handpose และทรัพยากรที่เกี่ยวข้องทั้งหมดมีทั้งหมด 13.4 MB แม้ว่าจะมีขนาดใหญ่กว่าแพ็กเกจหน้าเว็บที่คอมไพล์ให้เล็กที่สุดส่วนใหญ่ แต่ก็เทียบเท่ากับหน้าเว็บค่ามัธยฐานซึ่งมีขนาด 2.2MB (2.6MB ในเดสก์ท็อป)
  • โมเดล Generative AI อาจมีขนาดใหญ่เกินขนาดที่แนะนำสำหรับทรัพยากรเว็บ DistilBERT ซึ่งถือว่าเป็น LLM ขนาดเล็กมากหรือโมเดล NLP แบบง่าย (ความคิดเห็นแตกต่างกันไป) มีน้ำหนัก 67 MB แม้แต่ LLM ขนาดเล็กอย่าง Gemma 2B ก็สามารถเก็บข้อมูลได้สูงสุด 1.3 GB ซึ่งมีขนาดมากกว่าหน้าเว็บค่ามัธยฐาน 100 เท่า

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

ในแผงเครือข่ายของเครื่องมือสําหรับนักพัฒนาเว็บใน Chrome ให้ดูขนาดการดาวน์โหลดของโมเดลการตรวจจับภาษา MediaPipe สาธิต
ในแผงเครือข่ายของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Chrome ให้ดูขนาดการดาวน์โหลดสำหรับโมเดล AI ทั่วไป ได้แก่ Gemma 2B (LLM ขนาดเล็ก), DistilBERT (NLP ขนาดเล็ก / LLM ขนาดเล็กมาก)

เพิ่มประสิทธิภาพขนาดโมเดล

  • เปรียบเทียบคุณภาพของโมเดลและขนาดการดาวน์โหลด โมเดลขนาดเล็กอาจมีความแม่นยำเพียงพอสำหรับกรณีการใช้งานของคุณ ทั้งยังเล็กกว่ามาก การปรับแต่งอย่างละเอียดและเทคนิคการลดขนาดโมเดลมีไว้เพื่อลดขนาดโมเดลได้อย่างมากในขณะที่ยังคงความแม่นยำไว้อย่างเพียงพอ
  • เลือกโมเดลเฉพาะทางเมื่อเป็นไปได้ โมเดลที่ปรับให้เหมาะกับงานบางอย่างมักจะมีขนาดเล็กกว่า เช่น หากต้องการทํางานบางอย่างที่เฉพาะเจาะจง เช่น การวิเคราะห์ความรู้สึกหรือความเป็นพิษ ให้ใช้โมเดลที่เชี่ยวชาญในงานเหล่านี้แทน LLM ทั่วไป
ตัวเลือกโมเดลสําหรับการสาธิตการถอดเสียงเป็นคำด้วย AI ฝั่งไคลเอ็นต์โดย j0rd1smit

แม้ว่าโมเดลทั้งหมดนี้จะทํางานแบบเดียวกัน แต่ความแม่นยำจะแตกต่างกันไป และมีขนาดตั้งแต่ 3 MB ถึง 1.5 GB

ตรวจสอบว่าโมเดลทํางานได้หรือไม่

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

ในระหว่างนี้ คุณสามารถดำเนินการต่อไปนี้ได้

  • ตรวจสอบการรองรับ WebGPU ไลบรารี AI ฝั่งไคลเอ็นต์หลายรายการ รวมถึง Transformers.js เวอร์ชัน 3 และ MediaPipe ใช้ WebGPU ขณะนี้ไลบรารีบางรายการเหล่านี้จะไม่เปลี่ยนไปใช้ Wasm โดยอัตโนมัติหากระบบไม่รองรับ WebGPU คุณสามารถลดปัญหานี้ได้โดยการใส่โค้ดที่เกี่ยวข้องกับ AI ไว้ในการตรวจสอบการตรวจหาฟีเจอร์ WebGPU หากทราบว่าคลัง AI ฝั่งไคลเอ็นต์ต้องใช้ WebGPU
  • ตัดอุปกรณ์ที่มีประสิทธิภาพต่ำออก ใช้ Navigator.hardwareConcurrency, Navigator.deviceMemory และ Compute Pressure API เพื่อประมาณความสามารถและภาระของอุปกรณ์ เบราว์เซอร์บางรุ่นไม่รองรับ API เหล่านี้ และ API เหล่านี้มีไว้เพื่อไม่แม่นยำโดยเจตนาเพื่อป้องกันการระบุตัวตนโดยอิงตามข้อมูลลายนิ้วมือของอุปกรณ์ แต่ก็ยังช่วยตัดอุปกรณ์ที่ดูเหมือนจะมีประสิทธิภาพต่ำมากออกได้

สัญญาณการดาวน์โหลดขนาดใหญ่

สำหรับโมเดลขนาดใหญ่ ให้เตือนผู้ใช้ก่อนดาวน์โหลด ผู้ใช้เดสก์ท็อปมีแนวโน้มที่จะยอมรับการดาวน์โหลดขนาดใหญ่มากกว่าผู้ใช้อุปกรณ์เคลื่อนที่ หากต้องการตรวจหาอุปกรณ์เคลื่อนที่ ให้ใช้ mobile จาก User-Agent Client Hints API (หรือสตริง User-Agent หากระบบไม่รองรับ UA-CH)

จำกัดการดาวน์โหลดไฟล์ขนาดใหญ่

  • ดาวน์โหลดเฉพาะสิ่งที่จําเป็น โดยเฉพาะอย่างยิ่งหากโมเดลมีขนาดใหญ่ ให้ดาวน์โหลดเมื่อมีความมั่นใจในระดับหนึ่งว่าจะใช้ฟีเจอร์ AI เช่น หากคุณมีฟีเจอร์ AI คำแนะนำในการพิมพ์ล่วงหน้า ให้ดาวน์โหลดเมื่อผู้ใช้เริ่มใช้ฟีเจอร์การพิมพ์เท่านั้น
  • แคชโมเดลอย่างชัดเจนในอุปกรณ์โดยใช้ Cache API เพื่อหลีกเลี่ยงการดาวน์โหลดทุกครั้งที่เข้าชม อย่าใช้เพียงแคช HTTP ของเบราว์เซอร์โดยนัย
  • แบ่งการดาวน์โหลดโมเดลเป็นหลายส่วน fetch-in-chunks จะแบ่งการดาวน์โหลดขนาดใหญ่ออกเป็นหลายส่วนเล็กๆ

การดาวน์โหลดและเตรียมโมเดล

อย่าบล็อกผู้ใช้

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

ตรวจสอบว่าผู้ใช้ยังคงโพสต์ได้
ผู้ใช้จะยังคงโพสต์รีวิวได้แม้ว่าฟีเจอร์ AI ฝั่งไคลเอ็นต์จะยังไม่พร้อมใช้งานก็ตาม สาธิตโดย @maudnals

ระบุความคืบหน้า

ขณะที่ดาวน์โหลดโมเดล ระบบจะระบุความคืบหน้าที่เสร็จสมบูรณ์และเวลาที่เหลือ

การแสดงความคืบหน้าการดาวน์โหลดโมเดล การติดตั้งใช้งานที่กําหนดเองด้วย fetch-in-chunks Demo โดย @tomayac

จัดการการหยุดชะงักของเครือข่ายอย่างราบรื่น

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

การเชื่อมต่อที่ไม่เสถียรเป็นอีกเหตุผลหนึ่งที่ต้องดาวน์โหลดเป็นกลุ่มๆ

โอนงานที่มีค่าใช้จ่ายสูงไปยัง Web Worker

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

ดูการสาธิตและการใช้งานแบบเต็มโดยอิงตาม Web Worker

การติดตามประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
ด้านบน: มี Web Worker ด้านล่าง: ไม่มี Web Worker

ระหว่างการอนุมาน

เมื่อดาวน์โหลดโมเดลและพร้อมใช้งานแล้ว คุณจะเรียกใช้การอนุมานได้ การคํานวณการอนุมานอาจใช้ทรัพยากรมาก

ย้ายการอนุมานไปยังเว็บเวิร์กเกอร์

หากการอนุมานเกิดขึ้นผ่าน WebGL, WebGPU หรือ WebNN ระบบจะใช้ GPU ซึ่งหมายความว่าการดำเนินการเกิดขึ้นในกระบวนการแยกต่างหากที่ไม่ได้บล็อก UI

แต่สําหรับการใช้งานที่อิงตาม CPU (เช่น Wasm ซึ่งสามารถใช้เป็นทางเลือกสําหรับ WebGPU ได้หากระบบไม่รองรับ WebGPU) การเปลี่ยนการอนุมานไปยัง Web Worker จะช่วยให้หน้าเว็บตอบสนองได้อยู่เสมอ เช่นเดียวกับระหว่างการเตรียมโมเดล

การติดตั้งใช้งานอาจง่ายขึ้นหากโค้ดทั้งหมดที่เกี่ยวข้องกับ AI (การดึงข้อมูลโมเดล การเตรียมโมเดล การอนุมาน) อยู่ในที่เดียวกัน คุณจึงเลือก Web Worker ได้ไม่ว่าจะมีการใช้ GPU หรือไม่ก็ตาม

จัดการข้อผิดพลาด

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

  • จัดการข้อผิดพลาดในการอนุมาน ใส่การอนุมานไว้ในบล็อก try/catch และจัดการข้อผิดพลาดรันไทม์ที่เกี่ยวข้อง
  • จัดการข้อผิดพลาดของ WebGPU ทั้งข้อผิดพลาดที่ไม่คาดคิดและ GPUDevice.lost ซึ่งเกิดขึ้นเมื่อมีการรีเซ็ต GPU เนื่องจากอุปกรณ์ทำงานได้ไม่ดี

ระบุสถานะการอนุมาน

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

ตัวอย่างภาพเคลื่อนไหวระหว่างการอนุมาน
เดโมโดย @maudnals และ @argyleink

ทำให้ยกเลิกการอนุมานได้

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