تعرَّف على كيفية مساهمة تحسينات WebAssembly وWebGPU في تحسين أداء تعلُّم الآلة على الويب.
الاستنتاج المستنِد إلى الذكاء الاصطناعي على الويب
لقد سمعنا جميعًا القصة: الذكاء الاصطناعي يغيّر عالمنا. لا يُستثنى من ذلك الويب.
أضاف Chrome هذا العام ميزات الذكاء الاصطناعي التوليدي، بما في ذلك إنشاء مظاهر مخصّصة ومساعدتك في كتابة المسودة الأولى للنص. أما الذكاء الاصطناعي فهو أكثر من ذلك بكثير، يمكن للذكاء الاصطناعي إثراء تطبيقات الويب نفسها.
يمكن أن تتضمّن صفحات الويب مكوّنات ذكية للرؤية، مثل التعرّف على الوجوه أو التعرّف على الإيماءات أو لتصنيف الصوت أو التعرّف على اللغة. في العام الماضي، شهدنا انتشارًا للذكاء الاصطناعي التوليدي، بما في ذلك بعض العروض التوضيحية الرائعة للنماذج اللغوية الكبيرة على الويب. اطّلِع على المقالة العملي عن الذكاء الاصطناعي على الجهاز لمطوّري البرامج على الويب.
يتوفّر استنتاج الذكاء الاصطناعي على الويب حاليًا على قسم كبير من الأجهزة، ويمكن أن تتم معالجة الذكاء الاصطناعي في صفحة الويب نفسها، ويستفيدون من الأجهزة المتوفّرة على أجهزة المستخدمين.
وتعود فعالية ذلك إلى عدة أسباب:
- خفض التكاليف: يؤدي إجراء الاستنتاج على برنامج المتصفّح إلى تقليل تكاليف الخادم بشكل كبير، ويمكن أن يكون ذلك مفيدًا بشكل خاص لطلبات البحث المستنِدة إلى الذكاء الاصطناعي التوليدي والتي يمكن أن تكون أعلى تكلفة من طلبات البحث العادية.
- وقت الاستجابة: بالنسبة إلى التطبيقات الأكثر حساسية لوقت الاستجابة، مثل تطبيقات الصوت أو الفيديو، يؤدي إجراء كل عمليات المعالجة على الجهاز إلى تقليل وقت الاستجابة.
- الخصوصية: عند العمل من جهة العميل، يمكن أيضًا أن يؤدي العمل من جهة العميل إلى فتح فئة جديدة من التطبيقات التي تتطلب مزيدًا من الخصوصية، بحيث لا يمكن إرسال البيانات إلى الخادم.
كيفية تشغيل أعباء العمل المستنِدة إلى الذكاء الاصطناعي على الويب في الوقت الحالي
في الوقت الحالي، يصمم مطورو التطبيقات والباحثون نماذج باستخدام أطر العمل، ويتم تنفيذها في المتصفح باستخدام بيئة تشغيل مثل Tensorflow.js أو ONNX Runtime Web، كما تستفيد أوقات التشغيل من واجهات برمجة تطبيقات الويب في التنفيذ.
وتصبح كل بيئات التشغيل هذه تعمل على وحدة المعالجة المركزية (CPU) من خلال JavaScript أو WebAssembly أو على وحدة معالجة الرسومات من خلال WebGL أو WebGPU.
أعباء العمل بتقنية تعلُّم الآلة
تدفع أعباء عمل التعلم الآلي (ML) أحمال التوتر عبر رسم بياني للعُقد الحاسوبية. أدوات الاستشعار هي مدخلات ومخرجات هذه العُقد التي تُجري عمليات حسابية كبيرة على البيانات.
وهذا أمر مهم لأنه:
- الأوتار هي بنى بيانات كبيرة جدًا، وتجري عمليات حسابية على النماذج التي يمكن أن تحتوي على مليارات الأوزان.
- يمكن أن يؤدي تغيير الحجم والاستنتاج إلى توازي البيانات. وهذا يعني أنه يتم تنفيذ نفس العمليات على جميع العناصر في العشرات.
- لا يتطلب تعلُّم الآلة دقة. قد تحتاج إلى رقم نقطة عائمة بتنسيق 64 بت للهبوط على سطح القمر، ولكن قد تحتاج فقط إلى عدد كبير من أرقام 8 بت أو أقل للتعرف على الوجوه.
ولحسن الحظ، أضاف مصممو الرقائق ميزات تجعل النماذج تعمل بشكل أسرع وأكثر برودة وحتى جعل من الممكن تشغيلها تمامًا.
في الوقت نفسه، نحن نعمل في فريقَي WebAssembly وWebGPU على إتاحة هذه الإمكانات الجديدة لمطوّري البرامج على الويب. إذا كنت مطور تطبيقات ويب، فمن غير المحتمل أن تستخدم هذه الأساسيات منخفضة المستوى بشكل متكرر. نتوقّع أن تتوافق سلاسل الأدوات أو أُطر العمل التي تستخدمها مع ميزات وإضافات جديدة، وبالتالي يمكنك الاستفادة من إجراء تغييرات بسيطة على البنية الأساسية. ولكن إذا كنت تريد ضبط التطبيقات يدويًا لتحقيق الأداء، فهذه الميزات ذات صلة بعملك.
WebAssembly
WebAssembly (Wasm) هو تنسيق رمز بايت مضغوط وفعّال يمكن لبيئات التشغيل فهمه وتنفيذه. وقد تم تصميمه للاستفادة من إمكانات الأجهزة الأساسية، وبذلك يمكن تشغيله بالسرعات الأصلية القريبة. تم التحقّق من صحة الرمز البرمجي وتنفيذه في بيئة محمية بالذاكرة ومحمية.
يتم تمثيل معلومات وحدة Wasm بترميز ثنائي كثيف. بالمقارنة مع التنسيق المستند إلى النص، هذا يعني فك الترميز بشكل أسرع وتحميل أسرع وتقليل استخدام الذاكرة. وهي قابلة للحمل بمعنى أنها لا تضع افتراضات حول البنية الأساسية التي ليست شائعة بالفعل في البُنى الهندسية الحديثة.
إنّ مواصفات WebAssembly متكررة ويتم العمل عليها ضمن مجموعة منتدى W3C مفتوحة.
ولا يضع التنسيق الثنائي افتراضات حول البيئة المضيفة، ولذلك تم تصميمه ليعمل بشكل جيد في التضمينات غير المستندة إلى الويب أيضًا.
يمكن تجميع تطبيقك مرة واحدة وتشغيله في أي مكان: سواء كان جهاز كمبيوتر مكتبيًا أو كمبيوتر محمولاً أو هاتفًا أو أي جهاز آخر مزود بمتصفّح. لمزيد من المعلومات حول هذا الموضوع، يمكنك الاطّلاع على مقالة كتابة مرة واحدة، وإنجازها في أي مكان أخيرًا باستخدام WebAssembly.
تستخدم معظم تطبيقات الإنتاج التي تستخدم استنتاج الذكاء الاصطناعي على الويب تقنية WebAssembly، سواء كنت تستخدم حوسبة وحدة المعالجة المركزية (CPU) أو تتفاعل مع عمليات الحوسبة ذات الأغراض الخاصّة. أمّا في التطبيقات الأصلية، فيمكنك الوصول إلى الحوسبة ذات الأغراض العامة والأغراض الخاصة، حيث يمكن للتطبيق الوصول إلى إمكانات الجهاز.
بالنسبة إلى الويب، بالنسبة إلى إمكانية النقل والأمان، نقيّم بعناية مجموعة الأساسيات التي يتم الكشف عنها. ومن شأن هذا تحقيق التوازن بين إمكانية الوصول إلى الويب وتحقيق أقصى قدر من الأداء الذي توفّره الأجهزة.
WebAssembly هو اختصار محمول لوحدات المعالجة المركزية (CPU)، لذا يتم تشغيل جميع استنتاجات Wasm على وحدة المعالجة المركزية (CPU). وبالرغم من أن هذا ليس الخيار الأفضل أداءً، إلا أن وحدات المعالجة المركزية متاحة على نطاق واسع وتعمل عبر معظم أعباء العمل على معظم الأجهزة.
بالنسبة إلى أعباء العمل الأصغر حجمًا، مثل أعباء العمل النصية أو الصوتية، قد تكون وحدة معالجة الرسومات مُكلفة. هناك عدد من الأمثلة الحديثة حيث يكون Wasm هو الخيار الصحيح:
- يستخدم Adobe Tensorflow.js بغرض تحسين Photoshop للويب.
- أضاف Google Meet تمويه الخلفية، وهو أحد تأثيرات الفيديو الأولى المستندة إلى Wasm على الويب.
- توفّر منصة YouTube العديد من تأثيرات الواقع المعزّز.
- يتيح تطبيق "صور Google" إمكانية التعديل على الإنترنت.
يمكنك اكتشاف المزيد من خلال الإصدارات التجريبية المفتوحة المصدر، مثل: whisper-tiny وllama.cpp وGemma2B قيد التشغيل في المتصفّح.
اتباع نهج شامل في تطبيقاتك
عليك اختيار الأساسيات استنادًا إلى نموذج تعلُّم الآلة والبنية الأساسية للتطبيق وتجربة التطبيق المقصودة بشكل عام للمستخدمين.
على سبيل المثال، في ميزة "رصد معالِم الوجه" في MediaPipe، يتشابه استنتاج وحدة المعالجة المركزية (CPU) واستنتاج وحدة معالجة الرسومات (يتم تشغيله على جهاز Apple M1)، ولكن هناك طُرز قد يكون فيها التباين أعلى بكثير.
عندما يتعلق الأمر بأعباء عمل تعلُّم الآلة، نأخذ في الاعتبار طريقة عرض شاملة للطلبات، مع الاستماع إلى مؤلفي إطارات العمل وشركاء التطبيقات، لتطوير وشحن التحسينات الأكثر طلبًا. وتنقسم هذه على نطاق واسع إلى ثلاث فئات:
- توضيح أهمية إضافات وحدة المعالجة المركزية في الأداء
- تفعيل تشغيل نماذج أكبر
- تفعيل إمكانية التشغيل التفاعلي السلس مع واجهات برمجة تطبيقات الويب الأخرى
حوسبة أسرع
ولا تتضمن مواصفات WebAssembly كما هي، إلا مجموعة معينة من التعليمات التي نعرضها على الويب. مع ذلك، تواصل الأجهزة إضافة تعليمات أحدث لزيادة الفجوة بين أداء واجهة برمجة التطبيقات الأصلية وأداء WebAssembly.
يُرجى العلم أنّ نماذج تعلُّم الآلة لا تتطلب دائمًا مستويات عالية من الدقة. اختصار SIMD المخفّف هو اقتراح يقلل من بعض المتطلبات الصارمة غير الحاسمية، ما يؤدي إلى إنشاء ترميز أسرع لبعض عمليات المتجهات التي تمثّل نقاطًا عالية الأداء. علاوةً على ذلك، تقدِّم شريحة SIMD المريحة منتجات نقطية جديدة وتعليمات FMA التي تساعد على تسريع أعباء العمل الحالية من 1.5 إلى 3 مرات. تم شحنها في Chrome 114.
يستخدم تنسيق النقطة العائمة نصف الدقة 16 وحدة بت لـ IEEE FP16 بدلاً من 32 بت المستخدم لقيم الدقة الفردية. ومقارنة بقيم الدقة الفردية، هناك العديد من المزايا في استخدام قيم نصف الدقة، وتقليل متطلبات الذاكرة، والتي تتيح تدريب شبكات عصبية أكبر ونشرها، وتقليل معدل نقل البيانات للذاكرة. تؤدي الدقة المنخفضة إلى تسريع عمليات نقل البيانات والرياضيات.
نماذج أكبر
يتم تمثيل المؤشرات في ذاكرة Wasm الخطية في شكل أعداد صحيحة 32 بت. وينتج عن ذلك نتيجتان: تقتصر أحجام وحدات الذاكرة إلى 4 غيغابايت (عندما تحتوي أجهزة الكمبيوتر على ذاكرة وصول عشوائي فعلية أكثر من ذلك)، ويجب أن يكون رمز التطبيق الذي يستهدف 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، إلا أن هذا ليس الخيار الأفضل دائمًا، حيث يكون الرمز أكبر حجمًا وغير فعال بالقدر نفسه.
المثال التالي هو حوسبة فيبوناتشي، باستخدام وعود جافا سكريبت بالإضافة.
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 الخطية وتقليل عدد النُسخ في مسار التطبيق. ويأتي هذا الاقتراح في المرحلة الأولى، حيث ننشئ نموذجًا أوليًا له في V8، وهو محرك JavaScript في Chrome، وذلك لتطوير هذا المعيار.
تحديد الخلفية المناسبة لك
على الرغم من انتشار وحدة المعالجة المركزية (CPU)، إلا أنها ليست الخيار الأفضل دائمًا. إنّ الحوسبة ذات الأغراض الخاصة باستخدام وحدة معالجة الرسومات أو مسرِّعات الأعمال يمكن أن تقدّم أداءً أعلى من ذلك، لا سيما للطُرز الأكبر حجمًا والأجهزة المتطورة. وينطبق هذا على كل من التطبيقات الأصلية وتطبيقات الويب.
تعتمد الواجهة الخلفية التي تختارها على التطبيق أو إطار العمل أو سلسلة الأدوات، بالإضافة إلى عوامل أخرى تؤثر في الأداء. ومع ذلك، نواصل الاستثمار في الاقتراحات التي تمكّن Wasm الأساسية من العمل بشكل جيد مع بقية منصة الويب، وبشكل أكثر تحديدًا مع WebGPU.