تعرَّف على كيفية تحسين ميزتَي WebAssembly وWebGPU لأداء تعلُّم الآلة على الويب.
الاستنتاج بالذكاء الاصطناعي على الويب
لقد سمعنا جميعًا أنّ الذكاء الاصطناعي يغيّر عالمنا. ولا يُستثنى من ذلك الإنترنت.
أضاف Chrome هذا العام ميزات الذكاء الاصطناعي التوليدي، بما في ذلك إنشاء مظهر مخصّص و/أو مساعدتك في كتابة مسودة أولى للنص. ولكنّ الذكاء الاصطناعي يقدّم أكثر من ذلك بكثير، إذ يمكنه تحسين تطبيقات الويب نفسها.
يمكن أن تضمّن صفحات الويب مكونات ذكية للرؤية، مثل اختيار الوجوه أو التعرّف على الإيماءات، أو لتصنيف الصوت، أو لرصد اللغة. في العام الماضي، شهدنا تطوّر الذكاء الاصطناعي التوليدي، بما في ذلك بعض العروض التوضيحية المميّزة للنماذج اللغوية الكبيرة على الويب. احرص على الاطّلاع على استخدام الذكاء الاصطناعي على الأجهزة لتطبيقات الويب.
تتوفّر ميزة الاستنتاج بالذكاء الاصطناعي على الويب اليوم على نطاق واسع من الأجهزة، ويمكن أن تتم معالجة الذكاء الاصطناعي في صفحة الويب نفسها، وذلك من خلال الاستفادة من الأجهزة على جهاز المستخدم.
وهذا مفيد لعدة أسباب:
- تقليل التكاليف: يؤدي تشغيل الاستنتاج على مزوّد خدمة المتصفّح إلى تقليل تكاليف الخادم بشكل كبير، ويمكن أن يكون ذلك مفيدًا بشكل خاص لطلبات البحث الذكية التوليدية التي يمكن أن تكون أكثر تكلفة بمرات عديدة من طلبات البحث العادية.
- وقت الاستجابة: بالنسبة إلى التطبيقات الحسّاسة بشكل خاص لوقت الاستجابة، مثل تطبيقات الصوت أو الفيديو، يؤدي إجراء جميع عمليات المعالجة على الجهاز إلى تقليل وقت الاستجابة.
- الخصوصية: يمكن أن يؤدي التشغيل من جهة العميل أيضًا إلى فتح فئة جديدة من التطبيقات التي تتطلّب خصوصية أكبر، حيث لا يمكن إرسال البيانات إلى الخادم.
كيفية تنفيذ أعباء الذكاء الاصطناعي على الويب اليوم
في الوقت الحالي، ينشئ مطوّرو التطبيقات والباحثون النماذج باستخدام إطارات العمل، ويتم تنفيذ النماذج في المتصفّح باستخدام منصّة تشغيل مثل Tensorflow.js أو ONNX Runtime Web، وتستخدِم منصّات التشغيل واجهات برمجة تطبيقات الويب لتنفيذ النماذج.
وفي النهاية، تنخفض جميع أوقات التشغيل إلى الحد الأدنى لتتم معالجتها على وحدة المعالجة المركزية من خلال JavaScript أو WebAssembly أو على وحدة معالجة الرسومات من خلال WebGL أو WebGPU.
أعباء عمل تعلُّم الآلة
تدفع أعباء عمل تعلُّم الآلة مصفوفات تانسور من خلال رسم بياني للعقد الحسابية. المتجهات هي مدخلات ومخرجات هذه العقد التي تُجري قدرًا كبيرًا من العمليات الحسابية على البيانات.
هذا أمر مهم، لأنّه:
- مصفوفات السلاسل هي بنى بيانات كبيرة جدًا، وتعمل على إجراء عمليات حسابية على النماذج التي يمكن أن تحتوي على مليارات المَعلمات.
- يمكن أن يؤدي التوسيع والاستنتاج إلى توازُن البيانات. وهذا يعني أنّه يتم تنفيذ العمليات نفسها على جميع العناصر في مصفوفات السلاسل المتسلسلة.
- لا تتطلّب تكنولوجيات الذكاء الاصطناعي الدقة. قد تحتاج إلى رقم عشري متغير بسعة 64 بت للهبوط على سطح القمر، ولكن قد تحتاج فقط إلى عدد كبير من الأرقام بسعة 8 بت أو أقل للتعرّف على الوجوه.
لحسن الحظ، أضاف مصمّمو الرقاقات ميزات لتشغيل النماذج بشكل أسرع وأكثر برودة، بل وجعلوا تشغيلها ممكنًا على الإطلاق.
في الوقت الحالي، نعمل في فِرق WebAssembly وWebGPU على توفير هذه الإمكانات الجديدة لمطوّري الويب. إذا كنت مطوّر تطبيقات ويب، من غير المرجّح أن تستخدم هذه العناصر الأساسية ذات المستوى المنخفض بشكل متكرّر. نتوقع أن تتيح لك أدوات السلسلة أو الإطارات الأساسية التي تستخدمها الاستفادة من الميزات والإضافات الجديدة، وبالتالي يمكنك إجراء تغييرات طفيفة على بنيتك الأساسية. ولكن إذا كنت تفضّل ضبط تطبيقاتك يدويًا لتحسين الأداء، تكون هذه الميزات مفيدة لك.
WebAssembly
WebAssembly (Wasm) هو تنسيق رمز ثنائي صغير الحجم وفعّال يمكن لوقت التشغيل فهمه وتنفيذه. تم تصميمه للاستفادة من إمكانات الأجهزة الأساسية، حتى يمكن تنفيذه بسرعات قريبة من السرعات الأصلية. يتم التحقّق من صحة الرمز البرمجي وتنفيذه في بيئة محمية من الذاكرة.
يتم تمثيل معلومات وحدة Wasm باستخدام ترميز ثنائي كثيف. مقارنةً بالتنسيق المستنِد إلى النص، يعني ذلك فك ترميز أسرع وتحميل أسرع واستخدام ذاكرة أقل. وهي قابلة للنقل بمعنى أنّها لا تفترض أيّ أمور عن البنية الأساسية غير الشائعة في البنى الحديثة.
مواصفات WebAssembly هي تصاعدية ويتم العمل عليها في مجموعة منتدى W3C مفتوحة.
لا يفترض التنسيق الثنائي أيّ افتراضات حول بيئة المضيف، لذا تم تصميمه للعمل بشكل جيد في عمليات التضمين غير المخصّصة للويب أيضًا.
يمكن تجميع تطبيقك مرة واحدة وتشغيله في أي مكان: كمبيوتر مكتبي أو كمبيوتر محمول أو هاتف أو أي جهاز آخر مزوّد بمتصفّح. اطّلِع على الكتابة مرة واحدة والتشغيل في أي مكان أصبحا متاحَين أخيرًا باستخدام WebAssembly لمعرفة المزيد من المعلومات عن هذا الموضوع.
إنّ معظم تطبيقات الإنتاج التي تُجري استنتاجات الذكاء الاصطناعي على الويب تستخدِم WebAssembly، سواءً لإجراء عمليات الحساب باستخدام وحدة المعالجة المركزية أو للتفاعل مع عمليات الحساب المخصّصة للأغراض الخاصة. في التطبيقات الأصلية، يمكنك الوصول إلى إمكانات الحوسبة العامة والخاصة، لأنّ التطبيق يمكنه الوصول إلى إمكانات الجهاز.
على الويب، نُقيّم بعناية مجموعة العناصر الأساسية التي يتم عرضها لضمان قابلية النقل والأمان. ويوازن ذلك بين سهولة الوصول إلى الويب والأداء الأقصى الذي يوفّره الجهاز.
WebAssembly هو نموذج تجريدي محمول لوحدات المعالجة المركزية، لذا يتم تشغيل جميع عمليات الاستنتاج في Wasm على وحدة المعالجة المركزية. على الرغم من أنّ هذا الخيار ليس الأفضل أداءً، إلا أنّ وحدات المعالجة المركزية متاحة على نطاق واسع وتعمل على معظم الأجهزة في معظم أعباء العمل.
بالنسبة إلى أحمال العمل الأصغر حجمًا، مثل أحمال العمل النصية أو الصوتية، سيكون استخدام وحدة معالجة الرسومات باهظًا. هناك عدد من الأمثلة الحديثة التي يكون فيها WebAssembly هو الخيار المناسب:
- تستخدم Adobe Tensorflow.js لتحسين Photoshop للويب.
- أضاف تطبيق Google Meet ميزة تمويه الخلفية، وهي إحدى أوائل تأثيرات الفيديو المستندة إلى WebAssembly على الويب.
- تتوفّر في YouTube العديد من مؤثرات الواقع المعزّز.
- تسمح "صور Google" بالتعديل على الإنترنت.
يمكنك الاطّلاع على المزيد من المعلومات في العروض التوضيحية المفتوحة المصدر، مثل: whisper-tiny وllama.cpp وGemma2B التي تعمل في المتصفّح.
اتّباع نهج شامل في تطبيقاتك
يجب اختيار العناصر الأساسية استنادًا إلى نموذج الذكاء الاصطناعي (ML) وبنية التطبيق الأساسية وتجربة التطبيق المقصودة بشكل عام للمستخدمين.
على سبيل المثال، في ميزة "اكتشاف معالم الوجه" من MediaPipe، تكون الاستنتاجات التي تستند إلى وحدة المعالجة المركزية (CPU) والاستنتاجات التي تستند إلى وحدة معالجة الرسومات (GPU) متشابهة (يتم تشغيلها على جهاز Apple M1)، ولكن هناك نماذج قد يكون التباين فيها أعلى بكثير.
عندما يتعلق الأمر بأعمال ML، نأخذ في الاعتبار عرضًا شاملاً للتطبيق، وننصت إلى مؤلفي إطار العمل وشركاء التطبيقات لتطوير التحسينات الأكثر طلبًا وطرحها. تندرج هذه الطلبات بشكل عام ضمن ثلاث فئات:
- عرض إضافات وحدة المعالجة المركزية (CPU) المهمة للأداء
- تفعيل تشغيل النماذج الأكبر حجمًا
- تفعيل إمكانية التشغيل التفاعلي السلس مع واجهات برمجة تطبيقات الويب الأخرى
معالجة أسرع
في الوقت الحالي، لا تتضمّن مواصفات WebAssembly سوى مجموعة معيّنة من التعليمات التي نعرضها على الويب. ومع ذلك، تستمر الأجهزة في إضافة تعليمات جديدة تزيد من الفجوة بين أداء التطبيقات الأصلية وWebAssembly.
تذكَّر أنّ نماذج الذكاء الاصطناعي لا تتطلّب دائمًا مستويات عالية من الدقة. Relaxed SIMD هو اقتراح يقلل من بعض متطلبات عدم الحتمية الصارمة، ما يؤدي إلى تسريع عملية إنشاء الرموز البرمجية لبعض عمليات المتجهات التي تُعدّ نقاطًا ساخنة للأداء. بالإضافة إلى ذلك، توفّر تعليمات SIMD المُبسّطة تعليمات جديدة لحاصل ضرب نقطي وتعليمات FMA تُسرع من حمولات العمل الحالية من 1.5 إلى 3 مرات. تم طرح هذه الميزة في الإصدار 114 من Chrome.
يستخدم تنسيق النقطة العائمة بنصف الدقة 16 بتًا لتنسيق IEEE FP16 بدلاً من 32 بتًا المستخدَمة لقيم الدقة الواحدة. مقارنةً بقيم الدقة الواحدة، هناك العديد من المزايا لاستخدام قيم الدقة النصف، وانخفاض متطلبات الذاكرة، ما يتيح تدريب الشبكات العصبية الأكبر ونشرها، وانخفاض معدل نقل البيانات في الذاكرة. يؤدي تقليل الدقة إلى تسريع نقل البيانات والعمليات الحسابية.
الطُرز الأكبر حجمًا
يتم تمثيل المؤشرات إلى الذاكرة الخطية في Wasm كأرقام صحيحة 32 بت. يترتب على ذلك نتيجتان: تقتصر أحجام الحِزم على 4 غيغابايت (عندما تكون أجهزة الكمبيوتر مزوّدة بذاكرة وصول عشوائي (RAM) فعلية أكبر من ذلك)، ويجب أن يكون رمز التطبيق الذي يستهدف Wasm متوافقًا مع حجم مؤشر 32 بت (الذي).
قد يكون تحميل هذه النماذج في WebAssembly مقيّدًا، خاصةً مع النماذج الكبيرة التي نستخدمها اليوم. يزيل اقتراح Memory64 هذه القيود من خلال ذاكرة خطية أكبر من 4 غيغابايت ومطابقة مساحة العناوين للمنصات الأصلية.
لقد أكملنا عملية التنفيذ بالكامل في Chrome، ومن المتوقّع طرحها في وقت لاحق من هذا العام. في الوقت الحالي، يمكنك إجراء تجارب باستخدام العلامة chrome://flags/#enable-experimental-webassembly-features وإرسال ملاحظاتك إلينا.
تحسين إمكانية التشغيل التفاعلي على الويب
يمكن أن يكون WebAssembly نقطة الدخول لمعالجة البيانات لأغراض خاصة على الويب.
يمكن استخدام WebAssembly لتوفير تطبيقات وحدة معالجة الرسومات على الويب. وهذا يعني أنّ تطبيق C++ نفسه الذي يمكن تشغيله على الجهاز يمكن تشغيله أيضًا على الويب، مع إجراء تعديلات طفيفة.
تتضمّن Emscripten، وهي سلسلة أدوات مُجمِّع Wasm، ربطًا لواجهة برمجة التطبيقات WebGPU. وهو نقطة الدخول لاستنتاج الذكاء الاصطناعي على الويب، لذا من المهم أن يكون بإمكان Wasm التفاعل بسلاسة مع بقية منصة الويب. نحن نعمل على اقتراحات مختلفة في هذا القسم.
دمج وعد JavaScript (JSPI)
يتم عادةً كتابة تطبيقات C وC++ النموذجية (بالإضافة إلى العديد من اللغات الأخرى) باستخدام واجهة برمجة تطبيقات متزامنة. وهذا يعني أنّه سيتم إيقاف تنفيذ التطبيق إلى أن تكتمل العملية. وعادةً ما يكون من الأسهل كتابة تطبيقات الحظر هذه مقارنةً بالتطبيقات التي تتضمّن عمليات غير متزامنة.
عندما تحظر العمليات المكلّفة سلسلة التعليمات الرئيسية، يمكن أن تحظر وحدات الإدخال والإخراج ويظهر الارتباك للمستخدمين. هناك عدم تطابق بين نموذج البرمجة المتزامنة للتطبيقات الأصلية والنموذج غير المتزامن للويب. ويشكّل ذلك مشكلة كبيرة خاصةً للتطبيقات القديمة التي سيكون نقلها مكلفًا. توفّر Emscripten طريقة لإجراء ذلك باستخدام Asyncify، ولكن هذا ليس الخيار الأفضل دائمًا، لأنّ حجم التعليمات البرمجية أكبر وليس بنفس الكفاءة.
يحسب المثال التالي سلسلة فيبوناتشي، باستخدام وعد JavaScript للإضافة.
long promiseFib(long x) {
if (x == 0)
return 0;
if (x == 1)
return 1;
return promiseAdd(promiseFib(x - 1), promiseFib(x - 2));
}
// promise an addition
EM_ASYNC_JS(long, promiseAdd, (long x, long y), {
return Promise.resolve(x+y);
});
emcc -O3 fib.c -o b.html -s ASYNCIFY=2
في هذا المثال، انتبه إلى ما يلي:
- ينشئ ماكرو
EM_ASYNC_JSكل الرموز البرمجية اللازمة لنتمكّن من استخدام JSPI للوصول إلى نتيجة الوعد، تمامًا كما هو الحال مع الدالة العادية. - خيار سطر الأوامر الخاص
-s ASYNCIFY=2يؤدي ذلك إلى تفعيل خيار إنشاء رمز برمجي يستخدم JSPI للتفاعل مع عمليات استيراد JavaScript التي تُعرِض وعدًا.
لمزيد من المعلومات حول واجهة برمجة التطبيقات JSPI وكيفية استخدامها ومزاياها، يُرجى الاطّلاع على المقالة تقديم واجهة برمجة التطبيقات WebAssembly JavaScript Promise Integration API على v8.dev. تعرَّف على الإصدار التجريبي الحالي من الواجهة.
التحكّم في الذاكرة
لا يملك المطوّرون قدرة كبيرة على التحكّم في ذاكرة Wasm، لأنّ الوحدة تملك ذاكرتها الخاصة. يجب أن تنسخ أي واجهات برمجة تطبيقات تحتاج إلى الوصول إلى هذه الذاكرة البيانات إليها أو نسخها منها، ويمكن أن يتراكم هذا الاستخدام. على سبيل المثال، قد يحتاج تطبيق الرسومات إلى نسخ البيانات ولصقها لكل إطار.
يهدف اقتراح التحكّم في الذاكرة إلى توفير إمكانية التحكّم بشكل أدق في الذاكرة الخطية لـ Wasm والحدّ من عدد النُسخ في مسار التطبيق. هذا الاقتراح في المرحلة 1، ونحن بصدد إنشاء نماذج أولية له في V8، وهو محرّك JavaScript في Chrome، لتحديد مسار تطوير المعيار.
تحديد الخلفية المناسبة لك
على الرغم من أنّ وحدة المعالجة المركزية (CPU) متوفّرة في كل مكان، إلا أنّها ليست الخيار الأفضل في بعض الأحيان. يمكن أن توفّر وحدات الحوسبة المخصّصة للغرض على وحدة معالجة الرسومات أو مسرعات الأداء أداءً أعلى بكثير، خاصةً للطُرز الأكبر والأجهزة المتطوّرة. وينطبق ذلك على كلٍّ من التطبيقات المتوافقة مع نظام التشغيل والتطبيقات على الويب.
يعتمد اختيارك لنظام التشغيل الأساسي على التطبيق أو إطار العمل أو سلسلة الأدوات، بالإضافة إلى عوامل أخرى تؤثّر في الأداء. ومع ذلك، نواصل الاستثمار في الاقتراحات التي تتيح لـ Wasm الأساسية العمل بشكل جيد مع بقية منصة الويب، وعلى وجه التحديد مع WebGPU.