การเพิ่มประสิทธิภาพ WebAssembly และ WebGPU สำหรับ Web AI ที่เร็วขึ้น ตอนที่ 1

ดูวิธีที่การเพิ่มประสิทธิภาพ WebAssembly และ WebGPU ช่วยปรับปรุงประสิทธิภาพของแมชชีนเลิร์นนิงบนเว็บ

Austin Eng
Austin Eng
Deepti Gandluri
Deepti Gandluri
François Beaufort
François Beaufort

การอนุมานของ AI บนเว็บ

เราทุกคนคงได้ฟังเรื่องราวว่า AI กำลังเปลี่ยนแปลงโลกใบนี้ บนเว็บก็ไม่มีข้อยกเว้น

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

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

การอนุมาน AI บนเว็บพร้อมให้บริการแล้วในปัจจุบันบนอุปกรณ์ส่วนใหญ่ และการประมวลผลด้วย AI อาจเกิดขึ้นในหน้าเว็บเองโดยใช้ประโยชน์จากฮาร์ดแวร์ในอุปกรณ์ของผู้ใช้

ซึ่งมีเหตุผลหลายประการดังนี้

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

วิธีเรียกใช้ภาระงานด้าน AI บนเว็บในปัจจุบัน

ปัจจุบันนักพัฒนาแอปพลิเคชันและนักวิจัยสร้างโมเดลโดยใช้เฟรมเวิร์ก และโมเดลดำเนินการในเบราว์เซอร์โดยใช้รันไทม์อย่าง Tensorflow.js หรือ ONNX Runtime Web และรันไทม์จะใช้ประโยชน์จาก Web API เพื่อการดำเนินการ

รันไทม์ทั้งหมดจะทำงานบน CPU ผ่าน JavaScript หรือ WebAssembly หรือใน GPU ผ่าน WebGL หรือ WebGPU

แผนภาพที่แสดงภาระงานด้าน AI บนอินเทอร์เน็ตในปัจจุบัน

ภาระงานของแมชชีนเลิร์นนิง

ภาระงานของแมชชีนเลิร์นนิง (ML) จะพุช Tensor ผ่านกราฟของโหนดการคำนวณ Tensor คืออินพุตและเอาต์พุตของโหนดเหล่านี้ซึ่งดำเนินการคำนวณจำนวนมากจากข้อมูล

ซึ่งเป็นสิ่งสำคัญเนื่องจากเหตุผลต่อไปนี้

  • Tensor เป็นโครงสร้างข้อมูลขนาดใหญ่มาก ซึ่งทำการคำนวณบนโมเดลที่มีน้ำหนักได้หลายพันล้านครั้ง
  • การปรับขนาดและการอนุมานอาจทําให้ข้อมูลขนานกัน ซึ่งหมายความว่าจะมีการดำเนินการแบบเดียวกันในองค์ประกอบทั้งหมดใน Tensor
  • ML ไม่จำเป็นต้องใช้ความแม่นยำ คุณอาจต้องการเลขทศนิยม 64 บิตเพื่อลงจอดบนดวงจันทร์ แต่ต้องใช้ทะเลที่มีตัวเลข 8 บิตหรือน้อยกว่าสำหรับการจดจำใบหน้า

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

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

WebAssembly

WebAssembly (Wasm) คือรูปแบบโค้ดไบต์ที่กะทัดรัดและมีประสิทธิภาพ ซึ่งรันไทม์สามารถทำความเข้าใจและดำเนินการได้ โดยออกแบบมาเพื่อใช้ประโยชน์จากความสามารถของฮาร์ดแวร์พื้นฐาน เพื่อให้สามารถทำงานได้ที่ความเร็วใกล้เคียงกับเนทีฟ ระบบจะตรวจสอบโค้ดและดำเนินการในสภาพแวดล้อมแบบแซนด์บ็อกซ์ซึ่งปลอดภัยต่อหน่วยความจำ

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

ข้อกำหนดของ WebAssembly เป็นแบบทำซ้ำและดำเนินการในกลุ่มชุมชน W3C แบบเปิด

รูปแบบไบนารีไม่มีข้อสันนิษฐานเกี่ยวกับสภาพแวดล้อมโฮสต์ รูปแบบนี้จึงออกแบบมาให้ทำงานได้ดีในการฝังที่ไม่ใช่เว็บด้วย

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

ภาพแล็ปท็อป แท็บเล็ต และโทรศัพท์

แอปพลิเคชันเวอร์ชันที่ใช้งานจริงส่วนใหญ่ที่เรียกใช้การอนุมาน AI บนเว็บจะใช้ WebAssembly ทั้งสำหรับการประมวลผล CPU และการเชื่อมต่อกับการประมวลผลสำหรับวัตถุประสงค์พิเศษ ในแอปพลิเคชันที่มาพร้อมเครื่อง คุณสามารถเข้าถึงการประมวลผลสำหรับวัตถุประสงค์ทั่วไปและเพื่อวัตถุประสงค์พิเศษ เนื่องจากแอปพลิเคชันสามารถเข้าถึงความสามารถของอุปกรณ์

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

WebAssembly เป็นกระบวนการ Abstraction ของ CPU แบบพกพา ดังนั้นการอนุมาน Wasm ทั้งหมดจึงทำงานบน CPU แม้ว่าตัวเลือกนี้จะไม่ใช่ตัวเลือกที่มีประสิทธิภาพที่สุด แต่ CPU ใช้งานได้อย่างกว้างขวางและใช้งานได้กับภาระงานส่วนใหญ่ในอุปกรณ์ส่วนใหญ่

GPU จะมีราคาแพงสำหรับภาระงานขนาดเล็ก เช่น ภาระงานด้านข้อความหรือเสียง มีตัวอย่างล่าสุดจำนวนหนึ่งที่ Wasm เป็นตัวเลือกที่เหมาะสม ดังนี้

คุณยังสำรวจเพิ่มเติมได้ในการสาธิตโอเพนซอร์ส เช่น whisper-tiny, llama.cpp และ Gemma2B ที่ทํางานในเบราว์เซอร์

เลือกแนวทางที่ครบถ้วนสำหรับแอปพลิเคชันของคุณ

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

ตัวอย่างเช่น ในการตรวจหาจุดสังเกตที่ใบหน้าของ MediaPipe การอนุมาน CPU และการอนุมาน GPU นั้นเปรียบเทียบกันได้ (ทำงานในอุปกรณ์ Apple M1) แต่มีโมเดลที่ความแปรปรวนอาจสูงกว่าอย่างมาก

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

  • แสดงส่วนขยาย CPU ที่สำคัญต่อประสิทธิภาพ
  • เปิดใช้การเรียกใช้โมเดลขนาดใหญ่
  • เปิดใช้งานการทำงานร่วมกันอย่างราบรื่นกับ Web API อื่นๆ

ประมวลผลได้เร็วขึ้น

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

อย่าลืมว่าโมเดล ML ไม่จำเป็นต้องใช้ความแม่นยำสูงเสมอไป SIMD ที่ผ่อนปรนเป็นข้อเสนอที่ลดข้อกำหนดที่เข้มงวดบางอย่างแบบไม่มีกำหนด ทำให้โค้ดเจนเดอร์ทำงานได้เร็วขึ้นสำหรับการดำเนินการเวกเตอร์ซึ่งเป็นจุดที่เป็นปัญหาต่อประสิทธิภาพ นอกจากนี้ผ่อนคลาย SIMD ยังนำเสนอผลิตภัณฑ์แบบจุดใหม่และคำแนะนำ FMA ซึ่งจะช่วยเร่งความเร็วของภาระงานที่มีอยู่จาก 1.5-3 เท่า ซึ่งจัดส่งใน Chrome 114

รูปแบบจุดทศนิยมแบบครึ่งเดียวใช้ 16 บิตสำหรับ IEEE FP16 แทน 32 บิตที่ใช้สำหรับค่าความแม่นยำเดียว เมื่อเทียบกับค่าความแม่นยําค่าเดี่ยวแล้ว มีข้อดีหลายอย่างในการใช้ค่าความแม่นยําแบบครึ่งเดียว ความต้องการหน่วยความจําที่ลดลง ช่วยให้การฝึกใช้งานโครงข่ายประสาทที่มีขนาดใหญ่ขึ้น แบนด์วิดท์ของหน่วยความจําลดลง ความแม่นยำที่ลดลงช่วยเพิ่มความเร็วในการโอนข้อมูลและการดำเนินการทางคณิตศาสตร์

โมเดลขนาดใหญ่

ตัวชี้ไปยังหน่วยความจำเชิงเส้น Wasm จะแสดงเป็นจำนวนเต็ม 32 บิต ซึ่งจะมีผล 2 ประการ คือ ขนาดฮีปจะจำกัดอยู่ที่ 4 GB (เมื่อคอมพิวเตอร์มี RAM ทางกายภาพมากกว่านั้น) และโค้ดแอปพลิเคชันที่กำหนดเป้าหมาย Wasm จะต้องเข้ากันได้กับขนาดตัวชี้ 32 บิต (ซึ่ง)

การโหลดโมเดลเหล่านี้ไปยัง WebAssembly อาจมีข้อจำกัด โดยเฉพาะอย่างยิ่งสำหรับโมเดลขนาดใหญ่อย่างที่เราใช้ในปัจจุบัน ข้อเสนอ Memory64 จะนำข้อจำกัดเหล่านี้ออกโดยหน่วยความจำเชิงเส้นที่มีขนาดใหญ่กว่า 4 GB และตรงกับพื้นที่ที่อยู่ของแพลตฟอร์มเนทีฟ

เราติดตั้งใช้งาน Chrome อย่างเต็มรูปแบบ และคาดว่าจะจัดส่งได้ภายในปีนี้ สำหรับตอนนี้ คุณสามารถทำการทดสอบด้วย Flag chrome://flags/#enable-experimental-webassembly-features และส่งความคิดเห็นถึงเราได้

การทำงานร่วมกันบนเว็บที่ดียิ่งขึ้น

WebAssembly อาจเป็นจุดแรกเข้าสำหรับการประมวลผลสำหรับวัตถุประสงค์พิเศษบนเว็บ

WebAssembly สามารถใช้เพื่อนำแอปพลิเคชัน GPU ไปยังเว็บ ซึ่งหมายความว่าแอปพลิเคชัน C++ เดียวกันที่เรียกใช้ในอุปกรณ์ได้ยังทำงานบนเว็บได้ด้วยการแก้ไขเล็กน้อย

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

การผสานรวม JavaScript (JSPI)

แอปพลิเคชันภาษา C และ C++ ทั่วไป (รวมทั้งภาษาอื่นๆ) มักจะเขียนโดยใช้ API แบบซิงโครนัส ซึ่งหมายความว่าแอปพลิเคชันจะหยุดการดำเนินการจนกว่าการดำเนินการจะเสร็จสมบูรณ์ แอปพลิเคชันการบล็อกเช่นนี้มักจะเขียนได้ง่ายกว่าแอปพลิเคชันที่ทำงานแบบอะซิงโครนัส

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

ตัวอย่างต่อไปนี้คือการคำนวณฟีโบนักชีโดยใช้สัญญา JavaScript สำหรับการบวก

long promiseFib(long x) {
 if (x == 0)
   return 0;
 if (x == 1)
   return 1;
 return promiseAdd(promiseFib(x - 1), promiseFib(x - 2));
}
// promise an addition
EM_ASYNC_JS(long, promiseAdd, (long x, long y), {
  return Promise.resolve(x+y);
});
emcc -O3 fib.c -o b.html -s ASYNCIFY=2

ในตัวอย่างนี้ โปรดพิจารณาสิ่งต่อไปนี้

  • มาโคร EM_ASYNC_JS จะสร้างโค้ดกาวที่จำเป็นทั้งหมดเพื่อให้เราใช้ JSPI เพื่อเข้าถึงผลลัพธ์ของสัญญาได้ เช่นเดียวกับที่ทำกับฟังก์ชันปกติ
  • ตัวเลือกบรรทัดคำสั่งพิเศษ -s ASYNCIFY=2 ซึ่งจะเรียกใช้ตัวเลือกให้สร้างโค้ดที่ใช้ JSPI เพื่ออินเทอร์เฟซกับการนำเข้า JavaScript ที่ให้สัญญา

ดูข้อมูลเพิ่มเติมเกี่ยวกับ JSPI วิธีใช้ และประโยชน์ของ JSPI ได้ที่การแนะนำ WebAssembly JavaScript Promise Integration API ใน v8.dev ดูข้อมูลเกี่ยวกับช่วงทดลองใช้จากต้นทางในปัจจุบัน

การควบคุมหน่วยความจำ

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

ข้อเสนอการควบคุมหน่วยความจำมีเป้าหมายให้การควบคุมหน่วยความจำเชิงเส้นของ Wasm ได้ละเอียดยิ่งขึ้นและลดจำนวนสำเนาในไปป์ไลน์แอปพลิเคชัน ข้อเสนอนี้อยู่ในระยะที่ 1 โดยเรากำลังสร้างต้นแบบนี้ในเวอร์ชัน 8 ซึ่งเป็นเครื่องมือ JavaScript ของ Chrome เพื่อแจ้งถึงวิวัฒนาการของมาตรฐานนี้

เลือกแบ็กเอนด์ที่เหมาะกับคุณ

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

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

อ่านส่วนที่ 2 ต่อ