LiteRT.js يتفوق على TensorFlow.js

يحقق LiteRT.js باستخدام WebGPU عملية استنتاج (inference) لنموذج MobileNetV2 في 0.41 مللي ثانية، مما يوفر 2,439 إطاراً في الثانية (FPS) على وحدة معالجة رسومات سطح المكتب M2 Max—أي أسرع بأكثر من 25 ضعفاً من TensorFlow.js على نفس الأجهزة. وتتسع هذه الفجوة مع النماذج الأكبر، مما ينقل تعلم الآلة القائم على الويب إلى مستوى من الأداء كان مخصصاً في السابق للتطبيقات الأصلية (native apps).

لماذا تهم هذه المعايير المرجعية

استخدم المطورون TensorFlow.js لعمليات الاستنتاج على الأجهزة، عادةً عبر واجهة WebGL الخلفية (backend). تقوم WebGL برسم عمليات التنسور (tensor ops) على خط معالجة الرسومات ثنائي الأبعاد للمتصفح؛ وهي تعمل في كل مكان ولكنها لم تُصمم من أجل التوازي الهائل الذي تحتاجه نماذج التعلم العميق. أما WebGPU، وهي واجهة برمجة تطبيقات الرسومات من الجيل التالي، فتمنح وصولاً مباشراً إلى وحدات الحوسبة في وحدة معالجة الرسومات (GPU). ويُعد LiteRT.js أول مكتبة توفر محرك استنتاج مدعوم بـ WebGPU لنماذج TensorFlow-Lite، وتفيد جوجل بوجود تسريع بمقدار ثلاثة أضعاف. وتُظهر الاختبارات المستقلة مكاسب أكبر، مما يطرح تساؤلاً حول ما إذا كانت WebGPU ستصبح المسار الافتراضي لتعلم الآلة على الويب.

كيف تم إجراء الاختبار

قمنا بقياس أداء نموذجين لتصنيف الصور—MobileNetV2 و EfficientNet-Lite4—وكلاهما تم تحويلهما إلى TensorFlow-Lite. أُجريت الاختبارات على شريحة Apple-silicon M2 Max. ولقد قمنا لكل نموذج بقياس زمن الاستجابة (latency) لعملية تمرير أمامي (forward pass) واحدة عبر تكرارات عديدة، وسجلنا عدد الإطارات في الثانية (FPS). كما قمنا بتشغيل نفس النماذج باستخدام TensorFlow.js عبر واجهة WebGL الخلفية وسجلنا وقت التشغيل البارد (cold-start time) لكل مكتبة.

النتائج: السرعة وبدء التشغيل

  • MobileNetV2

    • LiteRT.js (WebGPU): زمن استجابة 0.41 مللي ثانية ← 2,439 FPS
    • TensorFlow.js (WebGL): زمن استجابة 10.82 مللي ثانية ← 92 FPS

  • EfficientNet-Lite4

    • LiteRT.js (WebGPU): زمن استجابة 0.62 مللي ثانية ← 1,623 FPS
    • TensorFlow.js (WebGL): لم يتم الإبلاغ عنه، ولكن MobileNetV2 أظهر بالفعل تفوقاً بأكثر من 25 ضعفاً.

احتاج TensorFlow.js إلى حوالي 10 ثوانٍ (10,014 مللي ثانية) لتجميع مظللات (shaders) WebGL الخاصة به قبل أول عملية استنتاج. بينما كان LiteRT.js جاهزاً في 4.3 مللي ثانية، مما قضى فعلياً على عقبة وقت التشغيل البارد للتطبيقات التفاعلية.

عندما قمنا بزيادة حجم النموذج بمقدار خمسة أضعاف، ارتفع زمن الاستجابة بنسبة 50% فقط، مما يؤكد أن التوازي في وحدة معالجة الرسومات (GPU) يستوعب معظم العمل الإضافي. والنتيجة هي آفاق جديدة للأداء تسمح للمتصفح بالتعامل مع بث الفيديو في الوقت الفعلي، أو تراكبات الواقع المعزز (AR)، أو النمذجة الأولية السريعة لنماذج الرؤية دون الحاجة إلى رحلات ذهاب وإياب إلى الخادم.

ما تخفيه الأرقام

  • Batching (التجميع) – معظم نماذج TensorFlow-Lite تقيد بُعد الدفعة (batch dimension) عند القيمة 1. لا يتم دعم إدخال صور متعددة في استدعاء واحد بشكل تلقائي، مما يضطر المطورين إلى إنشاء Web Workers أو بناء خطوط معالجة المدخلات يدوياً.
  • إدارة الذاكرة (Memory management) – لا يقوم LiteRT.js بتنظيف الذاكرة (garbage-collect) لتنسورات الـ GPU تلقائياً. يجب على المطورين استدعاء .delete() لكل تنسور يقومون بإنشائه، وإلا سيخاطرون باستنفاد ذاكرة الـ GPU بعد بضع مئات من عمليات الاستنتاج.
  • الوصول إلى الأجهزة (Hardware reach) – تعد WebGPU مستقرة على متصفحي Chrome و Firefox لأجهزة سطح المكتب. أما متصفحات الهاتف المحمول—بما في ذلك Chrome على Android و Safari على iOS—فتوفر واجهة برمجة التطبيقات هذه فقط خلف أعلام تجريبية (experimental flags) أو لا توفرها على الإطلاق. وفي تلك المنصات، تظل واجهة WASM الخلفية هي المسار الوحيد المتاح عالمياً، لكنها أبطأ بشكل ملحوظ بالنسبة للنماذج الأكبر.

تعني هذه القيود أنه بينما تبدو السرعة الخام مبهرة، فإن الجهد الهندسي المبذول لتحقيقها قد لا يكون هيناً.

القيود والمقايضات

لا تزال واجهة WebGL الخلفية لـ TensorFlow.js توفر توافقاً شبه عالمي. يمكن للمطور الذي يستهدف جمهوراً متنوعاً—أجهزة سطح المكتب، Android، و iOS—الاعتماد على مسار كود واحد يعمل في كل مكان، وإن كان بمعدل إنتاجية أقل. وتعمل واجهة WASM الخلفية على أي أجهزة تقريباً، لكنها تتخلف عن WebGPU في النماذج الأكبر التي تم قياسها هنا.

يتألق LiteRT.js عندما يكون الهدف هو بيئة سطح مكتب مفعل بها WebGPU. فهو يقوم بتشغيل نماذج .tflite مباشرة، مما يسمح للمطورين بسحب النماذج من Hugging Face أو Kaggle دون الحاجة إلى تحويلها، مع الحفاظ على التكميم (quantization) والأداء الأصليين. والمقايضة هنا هي نطاق نشر أضيق والحاجة إلى التعامل الدقيق مع الموارد.

ما يجب على المطورين مراعاته

  • **المنصة المستهدفة (

يثبت LiteRT.js أن WebGPU يمكنه دفع عمليات الاستدلال القائمة على الويب إلى نطاق ما دون المللي ثانية، محققاً سرعة تزيد عن 25 × سرعة TensorFlow.js على وحدات معالجة الرسومات المكتبية. لا تزال هذه التقنية في طور النضج، ويجب على المطورين التعامل مع قيود المعالجة بالدفعات، والتنظيف اليدوي للذاكرة، والدعم المحدود للهواتف المحمولة. وبالنسبة للتجارب التي تعطي الأولوية للأجهزة المكتبية وتتطلب أداءً في الوقت الفعلي، توفر المكتبة الجديدة مساراً واعداً؛ أما من أجل الوصول عبر المنصات المختلفة، فتظل محركات WebGL و WASM الخلفية القديمة ضرورية.