← أحدث الأبحاث
🤖 machine learning

Measuring and Reducing WebGPU Dispatch Overhead for LLM Inference

تكشف هذه الورقة أن عبء الإرسال في WebGPU، وليس جودة النواة، هو العائق الأساسي لاستنتاج النماذج اللغوية الكبيرة (LLM) ذات الدفعة الواحدة في المتصفحات، مما يثبت أن القياسات البسيطة تبالغ في تقدير التكاليف بسبب تداخل التزامن وتخلص إلى أن تقليل عدد عمليات الإرسال من خلال التجميع هو استراتيجية التحسين الأكثر فعالية.

المؤلفون الأصليون: Jędrzej Maczan

نُشر 2026-08-11
📖 5 دقيقة قراءة🧠 قراءة متعمّقة

المؤلفون الأصليون: Jędrzej Maczan

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

ومع ذلك، هناك عقبة. في الماضي، عندما حاول المطورون جعل نماذج الذكاء الاصطناعي هذه أسرع، ركزوا على جعل خطوات الرياضيات الفردية (التي تسمى "kernels") أكثر كفاءة، مثل صقل محرك السيارة. لكن هذا البحث يطرح سؤالاً مختلفاً: ماذا لو كانت السيارة جيدة، ولكن السائق يقضي وقتاً طويلاً في الصعود والنزول من المركبة؟ في عالم المتصفح، تتطلب كل خطوة رياضية واحدة "إرسال طلب" (dispatch) — وهو طلب يُرسل من المتصفح إلى بطاقة الرسوميات لبدء العمل. كان اللغز الكبير هو: كم من الوقت يُهدر فعلياً فقط في إرسال هذه الطلبات، مقابل الوقت المستغرق في إجراء الرياضيات الفعلية؟ فهم هذا الأمر أمر بالغ الأهمية لأنه إذا أهدرت الكثير من الوقت فقط في طلب العمل من الكمبيوتر، فسيشعر المستخدم أن روبوت الدردشة بطيء وثقيل، بغض- النظر عن مدى ذكاء العمليات الحسابية.


ازدحام مروري من نوع "التوقف والانطلاق"

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

يوضح البحث أن القياسات السابقة كانت تشبه توقيت تلك الرحلة الكاملة ذهاباً وإياباً لكل طرد على حدة. لقد خلطوا بين الوقت المستغرق في إرسال الطلب (الـ dispatch) وبين الوقت المستغرق في انتظار الكمبيوتر ليقول "حسناً، لقد انتهيت" (المزامنة/synchronization). وقت الانتظار هذا ضخم — فهو يصل إلى 450 ميكروثانية. وعندما أضاف الباحثون وقت الانتظار هذا إلى كل خطوة، اعتقدوا أن تكلفة إرسال الطلب أعلى بنحو 20 ضعفاً مما هي عليه في الواقع.

باستخدام طريقة جديدة تسمى "الإرسال المتسلسل" (sequential-dispatch)، تمكن المؤلف من معرفة كيفية توقيت عملية إرسال الطلب فقط، دون الانتظار الطويل بين الخطوات. ووجد أن التكلفة الحقيقية أقل بكثير: ما بين 24 إلى 36 ميكروثانية في بعض الأنظمة (Vulkan) وما بين 32 إلى 71 ميكروثانية في أنظمة أخرى (Metal). ومن المثير للاهتمام أن هذه التكلفة هي نفسها سواء كان الكمبيوتر يستخدم أرقام "float32" أو "float16" (طريقتان مختلفتان لتخزين الأرقام العشرية)، مما يثبت أن التأخير ناتج عن قواعد المتصفح، وليس عن العمليات الحسابية نفسها.

العائق الحقيقي: الكثير من التوقفات

بمجرد معرفة التكلفة الحقيقية لطلب واحد، سأل الفريق: "هل يهم هذا حقاً؟" ولمعرفة ذلك، أجروا تجربة منضبطة. أخذوا نموذج ذكاء اصطناعي قياسي وغيروا طريقة تغليفه. بدلاً من إرسال 876 طلباً صغيراً إلى بطاقة الرسوميات لمعالجة كلمة واحدة من النص، قاموا بـ "دمج" (fuse) بعض الخطوات معاً بحيث لم تضطر البطاقة لاستقبال سوى 564 طلباً.

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

النتيجة؟ أصبح الذكاء الاصطناعي أسرع بنسبة 53%. انخفض الوقت المستغرق لإنشاء أول كلمة من الاستجابة من 71.4 مللي ثانية إلى 41.6 مللي ثانية.

أثبتت هذه التجربة أنه عند الإعداد الأكثر شيوعاً (معالجة كلمة واحدة في كل مرة، والمعروف باسم "حجم الدفعة 1" أو batch size 1)، فإن المشكلة الكبرى ليست في أن الرياضيات بطيئة جداً أو أن الذاكرة ممتلئة. المشكلة ببساطة هي وجود الكثير من "الطرقات على الباب". وقد استبعد المؤلف صراحةً فكرة أن تحسين كود الرياضيات أو تقليل استخدام الذاكرة كان السبب في زيادة السرعة؛ الشيء الوحيد الذي تغير هو عدد عمليات الإرسال (dispatches).

ماذا يعني هذا للمستقبل

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

يشير المؤلف إلى أن الحل يكمس في "توزيع تكلفة الإرسال" (dispatch amortization) — وهي طريقة معقدة تعني أننا بحاجة إلى توزيع تكلفة تلك "الطرقات" على العديد من المهام حتى لا يؤثر التأخير كثيراً. ويشير إلى أن هذا قد يتطلب تغييرات ليس فقط في البرامج التي تشغل الذكاء الاصطناعي، بل ربما في قواعد WebGPU نفسها، ربما بالسماح للمتصفح باستقبال "رسم بياني للأوامر" (command graph) — أي مسار مخطط له مسبقاً — بدلاً من التحقق من كل خطوة على حدٍ.

ورغم أن هذه النتائج تستند إلى أجهزة محددة (مثل NVIDIA RTX 5090) وطريقة واحدة لتشغيل الذكاء الاصطناعي، إلا أن الرسالة واضحة: في الوقت الحالي، سر جعل الذكاء الاصطناعي في متصفحك أسرع ليس في امتلاك محرك أسرع؛ بل في تقليل عدد التوقفات.

غارق في أبحاث مجالك؟

تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.

جرّب Digest →