ExecuTorch يشغّل PyTorch في المتصفح على وحدة معالجة الرسوميات: توليد النصوص أسرع بمقدار 2 إلى 10 مرات

إذا كان فريقك يدرّب نموذجًا في PyTorch، فإن تشغيله في المتصفح يعني عادةً مهمة هندسية إضافية: نقله إلى صيغة مناسبة ثم التأكد من أن كل شيء يعمل بعد النقل. تختصر الواجهة الخلفية الجديدة WebGPU في ExecuTorch هذا المسار. يُصدَّر النموذج إلى ملف بصيغة .pte، وتُنفَّذ الحسابات على وحدة معالجة الرسوميات في جهاز المستخدم. وفي الاختبار المنشور تبيّن أن توليد النصوص أسرع من نسخة وحدة المعالجة المركزية بمقدار 2 إلى 10 مرات. وهذا سبب للمطوّر كي يتحقق من الجزء الذي يمكن نقله من الخادم إلى علامة تبويب المتصفح.

ما الذي يتغير للفريق

تخيّل تطبيق ويب يرفع فيه المستخدم صورة منتج ويزيل الخلفية. عند المعالجة على الخادم، يجب استلام الصورة ووضع المهمة في الطابور وتشغيل النموذج وإعادة النتيجة. أما الخيار المحلي فيتيح سيناريو مختلفًا: ينزّل المتصفح النموذج ثم يعالج الصورة على جهاز المستخدم. هذا مثال على تطبيق التقنية، وليس قياسًا لخدمة تجارية جاهزة.

الفرق بالنسبة للفريق ملموس تمامًا. فإذا كانت المعالجة مناسبة لجهاز العميل، فلن تضطر إلى دفع تكلفة التشغيل على الخادم لكل صورة. لكن ستظهر تكاليف أخرى: توصيل الأوزان، ودعم أجهزة متنوعة، وتحليل الأخطاء في المتصفح. ويجب احتساب التوفير بحسب حركة المرور الخاصة بك، لا استنتاجه من مجرد ظهور WebGPU.

داخليًا تُستخدم حزمة WebAssembly وWebGPU. تتيح الأولى عمل بيئة التنفيذ في المتصفح، وتمنح الثانية الوصول إلى الحسابات على بطاقة الرسوميات. ويبقى التصدير ضمن أدوات PyTorch: ولا حاجة للانتقال إلى صيغة إطار عمل آخر. ولا يزال هذا مرحلة مستقلة لإعداد النموذج، وليس إمكانية إدراج شيفرة Python عشوائية في صفحة ويب. وقد وُصف التصميم ونتائج الاختبار في منشور فريق PyTorch.

من أين جاء التسريع بمقدار 2 إلى 10 مرات

قارن الفريق WebGPU بالواجهة الخلفية لوحدة المعالجة المركزية الخاصة بـ ExecuTorch، التي تستخدم WebAssembly وXNNPACK. أُجريت القياسات في Chrome على Apple M1 Pro مع نموذجي Llama 3.2 1B وQwen3-0.6B بعد التكميم. تسارعت معالجة سياق الإدخال بمقدار 4 إلى 7 مرات، وتسارع التوليد المتتابع للرموز بمقدار 2 إلى 10 مرات. وتخص هذه الأرقام مقارنة محددة، لا جميع طرق تشغيل النماذج في المتصفح.

من المهم لمدير المنتج أن يفصل بين زمنَي انتظار. أولًا يجب أن يحصل التطبيق على النموذج ويُعدّه للعمل. ثم ينتظر المستخدم الرد على طلبه. تسريع الحسابات مفيد، لكنه وحده لا يجيب عن سؤال كم من الوقت سيحدّق الناس في الشاشة عند فتح التطبيق للمرة الأولى. هذا مؤشر مستقل يستحق القياس في نموذج أولي.

ولذلك من الأفضل بناء الاختبار العملي حول فعل المستخدم: فتح الصفحة عبر شبكة عادية، وتحميل ملف حقيقي، والحصول على النتيجة، وتكرار العملية. قارن بين التشغيل الأول وما يليه، وتحقق من الذاكرة المتاحة والسلوك على حاسوب محمول ضعيف. فالاستجابة السريعة على جهاز المطوّر لا تُظهر بعدُ التجربة التي سيحصل عليها الجمهور كله.

ما الذي يمكن تجربته وأين الحدود

يمكن البدء من Playground الرسمي. وتتوفر فيه دردشة محلية وتعرّف على الكلام وتحديد الأجسام وتقدير العمق من صورة الكاميرا. والمنصة موسومة بأنها تجريبية؛ ومن المناسب استخدامها للتحقق من السيناريو نفسه على أجهزتك قبل إعداد تصديرك الخاص.

وبالنسبة لتطبيق يتعامل مع الصور أو الصوت، تغيّر المعالجة المحلية أيضًا مسار البيانات: فلا حاجة لإرسال المُدخل إلى الخادم من أجل الاستدلال. لكن هذه خاصية تنفيذ بعينه. فإذا أضفت رفع المصادر إلى أدوات التحليلات أو سيناريو احتياطيًا سحابيًا، فسيتعيّن إعادة النظر في الوعد المقدَّم للمستخدم. ويجب فحص بنية المعالجة وطلبات الشبكة الفعلية معًا.

أما الواجهة الخلفية نفسها فلا تزال في مرحلة مبكرة من التطوير. لذلك فإن الخطوة التالية المعقولة هي اختيار وظيفة محدودة واحدة، وتحديد الأجهزة المدعومة، ومقارنتها بالحل الحالي. على سبيل المثال، اختبار إزالة الخلفية على صور العملاء النموذجية. وينبغي اتخاذ قرار الاعتماد استنادًا إلى الزمن حتى النتيجة وجودة المعالجة وتكلفة الدعم. إن المسار الجديد من PyTorch إلى المتصفح يجعل مثل هذه التجربة أسهل، لكن على الفريق أن يقيس نتيجتها بنفسه.