LiteRT.js กำลังเอาชนะ TensorFlow.js

LiteRT.js พร้อม WebGPU สามารถรันการอนุมาน (inference) ของ MobileNetV2 ได้ในเวลาเพียง 0.41 มิลลิวินาที (ms) โดยทำความเร็วได้ถึง 2,439 FPS บน GPU ของเดสก์ท็อป M2 Max ซึ่งเร็วกว่า TensorFlow.js บนฮาร์ดแวร์เดียวกันมากกว่า 25 เท่า และช่องว่างนี้จะยิ่งกว้างขึ้นเมื่อใช้โมเดลที่มีขนาดใหญ่ขึ้น ซึ่งเป็นการยกระดับการเรียนรู้ของเครื่อง (machine learning) บนเว็บไปสู่ระดับประสิทธิภาพที่เคยสงวนไว้สำหรับแอปพลิเคชันแบบ native เท่านั้น

ทำไมผลการทดสอบนี้จึงสำคัญ

นักพัฒนาใช้ TensorFlow.js สำหรับการอนุมานบนอุปกรณ์ (on-device inference) โดยมักจะผ่าน WebGL backend ซึ่ง WebGL จะแมปการทำงานของ tensor เข้ากับกราฟิกพายป์ไลน์แบบ 2 มิติของเบราว์เซอร์ แม้ว่าจะใช้งานได้ทุกที่ แต่ WebGL ไม่ได้ถูกสร้างมาเพื่อรองรับการประมวลผลแบบขนาน (parallelism) มหาศาลที่โมเดล deep learning ต้องการ ในขณะที่ WebGPU ซึ่งเป็น graphics API ยุคใหม่ ช่วยให้เข้าถึงหน่วยประมวลผล (compute units) ของ GPU ได้โดยตรง LiteRT.js เป็นไลบรารีแรกที่เปิดตัวเอนจินการอนุมานที่รองรับ WebGPU สำหรับโมเดล TensorFlow-Lite และ Google รายงานว่ามีความเร็วเพิ่มขึ้นถึงสามเท่า อย่างไรก็ตาม ผลการทดสอบที่เป็นอิสระแสดงให้เห็นถึงประสิทธิภาพที่เพิ่มขึ้นมากกว่านั้น ซึ่งนำไปสู่คำถามที่ว่า WebGPU จะกลายเป็นเส้นทางหลักสำหรับการทำ ML บนเว็บหรือไม่

วิธีการทดสอบ

เราได้ทำการทดสอบประสิทธิภาพ (benchmark) ของโมเดลจำแนกภาพสองโมเดล ได้แก่ MobileNetV2 และ EfficientNet-Lite4 ซึ่งทั้งคู่ถูกแปลงเป็น TensorFlow-Lite โดยทำการทดสอบบนชิป Apple-silicon M2 Max สำหรับแต่ละโมเดล เราได้วัดค่าความหน่วง (latency) ของการทำ forward pass หนึ่งครั้งผ่านการทำซ้ำหลายรอบ และรายงานผลเป็นเฟรมต่อวินาที (FPS) นอกจากนี้ เรายังได้รันโมเดลเดียวกันด้วย TensorFlow.js บน WebGL backend และบันทึกเวลาในการเริ่มต้นระบบ (cold-start time) ของแต่ละไลบรารีด้วย

ผลลัพธ์: ความเร็วและการเริ่มต้นใช้งาน

  • MobileNetV2

    • LiteRT.js (WebGPU): ความหน่วง 0.41 ms → 2,439 FPS
    • TensorFlow.js (WebGL): ความหน่วง 10.82 ms → 92 FPS

  • EfficientNet-Lite4

    • LiteRT.js (WebGPU): ความหน่วง 0.62 ms → 1,623 FPS
    • TensorFlow.js (WebGL): ไม่มีการรายงานผล แต่ MobileNetV2 แสดงให้เห็นถึงความได้เปรียบมากกว่า 25 เท่าแล้ว

TensorFlow.js ต้องใช้เวลาประมาณ 10 วินาที (10,014 ms) ในการคอมไพล์ WebGL shaders ก่อนที่จะเริ่มการอนุมานครั้งแรก ในขณะที่ LiteRT.js พร้อมใช้งานภายใน 4.3 ms ซึ่งช่วยขจัดปัญหาความล่าช้าจากการเริ่มต้นระบบ (cold-start penalty) สำหรับแอปพลิเคชันแบบโต้ตอบ (interactive apps) ได้อย่างสิ้นเชิง

เมื่อเราเพิ่มขนาดโมเดลขึ้น 5 เท่า ค่าความหน่วงเพิ่มขึ้นเพียง 50% เท่านั้น ซึ่งเป็นการยืนยันว่าการประมวลผลแบบขนานของ GPU สามารถรองรับภาระงานที่เพิ่มขึ้นส่วนใหญ่ได้ ผลลัพธ์ที่ได้คือขีดจำกัดด้านประสิทธิภาพใหม่ที่ช่วยให้เบราว์เซอร์สามารถจัดการกับวิดีโอสตรีมแบบเรียลไทม์, การซ้อนทับภาพ AR (AR overlays) หรือการทำต้นแบบโมเดลคอมพิวเตอร์วิทัศน์ (vision models) อย่างรวดเร็วได้โดยไม่ต้องส่งข้อมูลกลับไปกลับมาระหว่างเซิร์ฟเวอร์

สิ่งที่ตัวเลขไม่ได้บอกเรา

  • Batching – โมเดล TensorFlow-Lite ส่วนใหญ่จะล็อกมิติของ batch ไว้ที่ 1 การป้อนรูปภาพหลายรูปในการเรียกใช้งานเพียงครั้งเดียวจึงไม่ได้รับการรองรับโดยตรง (out of the box) ทำให้นักพัฒนาต้องสร้าง Web Workers หรือจัดการ pipeline ของอินพุตด้วยตนเอง
  • Memory management – LiteRT.js ไม่ได้ทำ garbage-collect สำหรับ GPU tensors โดยอัตโนมัติ นักพัฒนาต้องเรียกใช้ .delete() ในแต่ละ tensor ที่สร้างขึ้น มิฉะนั้นอาจเสี่ยงต่อการทำให้หน่วยความจำ GPU เต็มหลังจากทำการอนุมานไปเพียงไม่กี่ร้อยครั้ง
  • Hardware reach – WebGPU มีความเสถียรบน Chrome และ Firefox เวอร์ชันเดสก์ท็อป ส่วนเบราว์เซอร์บนมือถือ—รวมถึง Chrome บน Android และ Safari บน iOS—จะเปิดให้ใช้งาน API นี้ผ่าน experimental flags เท่านั้น หรืออาจไม่รองรับเลย ในแพลตฟอร์มเหล่านั้น WASM backend ยังคงเป็นเส้นทางเดียวที่ใช้งานได้ทั่วไป แต่จะทำงานช้ากว่าอย่างเห็นได้ชัดสำหรับโมเดลที่มีขนาดใหญ่

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

ข้อจำกัดและการแลกเปลี่ยน (trade-offs)

WebGL backend ของ TensorFlow.js ยังคงให้ความสามารถในการทำงานร่วมกันได้เกือบทุกแพลตฟอร์ม นักพัฒนาที่ต้องการเข้าถึงกลุ่มผู้ใช้ที่หลากหลาย ทั้งเดสก์ท็อป, Android และ iOS สามารถพึ่งพาโค้ดชุดเดียวที่ทำงานได้ทุกที่ แม้ว่าจะได้ throughput ที่ต่ำกว่าก็ตาม ส่วน WASM backend สามารถทำงานได้บนฮาร์ดแวร์เกือบทุกชนิด แต่ยังตามหลัง WebGPU เมื่อต้องจัดการกับโมเดลขนาดใหญ่ตามที่วัดผลในที่นี้

LiteRT.js จะโดดเด่นเมื่อกลุ่มเป้าหมายคือสภาพแวดล้อมแบบเดสก์ท็อปที่เปิดใช้งาน WebGPU โดยสามารถรันโมเดล .tflite ได้โดยตรง ช่วยให้นักพัฒนาสามารถดึงโมเดลจาก Hugging Face หรือ Kaggle มาใช้ได้โดยไม่ต้องแปลงไฟล์ ซึ่งช่วยรักษาคุณภาพการทำ quantization และประสิทธิภาพดั้งเดิมเอาไว้ ข้อแลกเปลี่ยนคือขอบเขตการใช้งาน (deployment envelope) ที่แคบกว่า และความจำเป็นในการจัดการทรัพยากรอย่างระมัดระวัง

สิ่งที่นักพัฒนาควรพิจารณา

  • Target platform – สำหรับเครื่องมือบนเดสก์ท็อปที่ใช้งานผ่านเว็บเท่านั้น (เช่น แอปออกแบบที่ใช้ style transfer แบบเรียลไทม์) การใช้ WebGPU ร่วมกับ LiteRT.js น่าจะเป็นตัวเลือกที่ดีที่สุด
  • Model size – โมเดลขนาดใหญ่ที่ต้องใช้การคำนวณสูงจะได้รับประโยชน์สูงสุดจากการประมวลผลแบบขนานของ GPU ส่วนโมเดลขนาดเล็กอาจไม่คุ้มค่ากับความพยายามทางวิศวกรรมที่เพิ่มขึ้น
  • Memory discipline – วางแผนการลบ tensor อย่างชัดเจน หรือครอบการเรียกใช้งานการอนุมานไว้ใน scope ที่สามารถคืนทรัพยากรได้โดยอัตโนมัติ
  • Fallback strategy – เตรียมทางเลือกสำรอง (fallback) เป็น WASM หรือ WebGL สำหรับเบราว์เซอร์ที่ไม่สามารถเปิดใช้งาน WebGPU ได้ เพื่อให้แอปยังคงใช้งานได้สำหรับกลุ่มผู้ใช้ที่กว้างขึ้น

บทสรุป

LiteRT.js พิสูจน์ให้เห็นว่า WebGPU สามารถผลักดันการทำ inference บนเว็บเข้าสู่ระดับต่ำกว่ามิลลิวินาที โดยให้ความเร็วมากกว่า 25 × ของ TensorFlow.js บน desktop GPU เทคโนโลยีนี้ยังอยู่ในช่วงกำลังพัฒนา และนักพัฒนาต้องรับมือกับข้อจำกัดในการทำ batching, การจัดการคืนหน่วยความจำด้วยตนเอง และการรองรับบนมือถือที่ยังจำกัด สำหรับประสบการณ์ที่เน้นการใช้งานบนเดสก์ท็อปเป็นหลักซึ่งต้องการประสิทธิภาพแบบเรียลไทม์ ไลบรารีใหม่นี้ถือเป็นแนวทางที่น่าสนใจอย่างยิ่ง ส่วนสำหรับการเข้าถึงแบบข้ามแพลตฟอร์ม แบ็กเอนด์ WebGL และ WASM แบบเดิมยังคงมีความสำคัญ