تسريع WebGPU بنسبة 2.57x من Hugging Face يأتي مرفقًا بـ176 خسارة

نشرت Hugging Face ‏207 نوى WebGPU تحت منظمة webgpu-kernels الجديدة على Hub، بالإضافة إلى محمّل JavaScript يُدعى @huggingface/kernels يقوم بتنزيلها وتشغيلها في المتصفح. وقطعة ثالثة، Fleet، تقيس أداء تلك النوى على أي GPU يملكه الزائر.

يأتي الإصدار مرفقًا برقم: تسريع بنسبة 2.57x في المتوسط الهندسي، مقيسًا مقابل خلفية WebGPU في ONNX Runtime Web على Apple M4، و1.90x عند الوسيط. كلا الرقمين حقيقي. وكلاهما أضيق مما يبدوان عليه.

ما الذي تقيسه نسبة 2.57x فعليًا

أُجريت المقارنة المباشرة على GPU من Apple M4 مقابل ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a. بدأت Hugging Face من 1,756 حالة اختبار تغطي جميع العمليات الـ207، ثم أبقت 809 حالة حيث أنتج كلا التنفيذين مخرجات متطابقة وتوقيتات موثوقة. أما الحالات الـ947 الأخرى فليست ضمن الرقم.

يغطي التوقيت عمل GPU وحده. تحميل النوى، وإنشاء الجلسات، ورفع المدخلات، وتجميع التظليل (shaders)، وقراءة المخرجات مرة أخرى مستبعدة على الجانبين. وتحذر Hugging Face من أن أحمال العمل القصيرة جدًا يصعب قياسها وأن الحالات الصغيرة قد تستفيد من ذاكرة GPU المؤقتة (cache)، لذا تُقرأ هذه الأرقام بشكل أفضل كمقارنة لا كوعد لتطبيق معين. كما أن جهازًا واحدًا على متصفح واحد لا يوصف WebGPU أيضًا، وهو تحفظ تطرحه الشركة بنفسها.

Einsum بفارق 10,000x وCumSum بفارق 301x

يقع مدخلان خارج المجموع بعيدًا. عملية Einsum ثنائية الخطية بحجم 4096 استغرقت 0.136 ms مقابل 1,396 ms في ORT WebGPU، بفارق يزيد على 10,000x. وعملية CumSum صفية على مدخل [256, 4096] انتهت في 0.016 ms مقابل 4.784 ms، أي 301x. وتصف Hugging Face كلتيهما بالغير معتادتين وتعزو ذلك إلى تنفيذ عام يسقط في مسار بطيء.

أما العمليات العادية فتحكي قصة أقل إثارة:

تتحسن MatMul بنسبة 1.14x. وتفوز Add بنسبة 3.52x، مع أن جمع حفنة من أعداد الفاصلة العائمة ليس حيث يذهب زمن الاستدلال. ولا يفصّل الإصدار الانتصارات الـ629 حسب فئة العملية، لذا فإن أي أحمال العمل يسرّعها المجموع أكثر ليس شيئًا تحسمه البيانات المنشورة.

الخسائر الـ176

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

نوى تُحزَّم كعقود، لا كشيدرز

كل نواة هي مستودع خاص بها مع بطاقة خاصة بها توثّق الدلالات، والمدخلات، والمخرجات، والسمات، وأنواع البيانات المدعومة، وملفات المصدر. وخلف البطاقة تقف خمسة أنواع من المخرجات: manifest.json، وهو المصدر الموثوق لعقد العملية؛ وmetadata.json للمعرّفات والبصمات (digests) والمنشأ؛ وtest.json لحالات الصواب؛ وbench.json لحالات القياس والضبط؛ وملفات *.wgsl.jinja التي تضم WGSL المُعامَل والمتخصص حسب الطلب والجهاز.

يبقى إصدار العقود منفصلاً عن إصدار ONNX نفسه. الإصدار الممرر إلى getKernel ليس opset، ولا since_version لمشغّل، ولا مراجعة نموذج، ما يسمح للتطبيق بالاعتماد على واجهة JavaScript مستقرة بينما تتحرك تنفيذات التظليل تحتها. وتشحن نواة Add أربعة متغيرات: للأشكال المتساوية، والبث المتجهي، والمعالجة العددية، والبث العام، لأن جمع البث يحتاج إلى فهرسة مختلفة.

import { getKernel } from "@huggingface/kernels";
const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });
const { c } = await add({
  a: { data: new Float32Array([1, 2, 3, 4, 5, 6]), shape: [2, 3] },
  b: { data: new Float32Array([10, 20, 30]), shape: [3] },
});

يستنتج المحمّل شكل المخرجات من manifest.json ويخصص النتيجة، لذا يبقى نمط الاستدعاء نفسه للعمليات الثقيلة التي تستحق فيها النوى العناء فعلاً. وتقول Hugging Face إنها تعمل مع فريق ONNX Runtime لرفع هذه التحسينات إلى المنبع في ONNX Runtime Web. وإذا تحقق ذلك، تكفّ التسريعات عن كونها سببًا لتبني محمّل Hugging Face وتصبح شيئًا يحصل عليه مستخدمو ORT Web افتراضيًا.

Fleet والموافقة والمسافة إلى نموذج

تشغّل Fleet فحوص الصحة والأداء في المتصفح وتُبلغ بالنتائج للجهاز المحلي. المساهمة اختيارية: مع الموافقة، تضيف كل عملية تشغيل ما تسميه Hugging Face دليلاً خاصًا، يُستخدم للعثور على إخفاقات خاصة بالجهاز، ومقارنة المتغيرات، وتحسين قواعد الاختيار عبر عتاد لا يستطيع مختبر اختبار تقليدي تغطيته. ودعم WebGPU نفسه يتفاوت حسب المتصفح، ونظام التشغيل، وGPU، وبرنامج التشغيل، ويمكن اكتشافه بواسطة "gpu" in navigator.

لا شيء من هذا هو معيار قياس لنموذج. القياسات لكل عملية، والنموذج الذي يعمل في المتصفح هو سلسلة من عمليات GPU لا يمكن أن يكون زمن تشغيله أكثر كفاءة من العمليات التي يرسلها. ورفع الحد الأدنى تحت Add وSoftmax وLayerNormalization لا يضمن أن الطبقة الأعلى تُبلغ عن المضاعف نفسه.

الأجزاء التي تقرر ما إذا كان أي من هذا مهمًا مملة: ما إذا كان عمل رفع المنبع إلى ONNX Runtime يتحقق، وما إذا كانت أدلة Fleet تصل بسرعة كافية لإصلاح ما تجده، وما إذا كان عمود الخسائر يتقلص. لقد طبعت Hugging Face ذلك بجانب الانتصارات، وهذه ليست الطريقة التي تُكتب بها عادةً إطلاقات النوى.