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