NAME
webgpu-on-device-ai-browser — WebGPU والذكاء الاصطناعي الموجود على الجهاز: أصبح المتصفح وقت تشغيل خطير
SYNOPSIS
cat webgpu-on-device-ai-browser.md
DESCRIPTION
لسنوات كان المتصفح هو الوجه الجميل للتطبيق وكانت السحابة هي المكان الذي تحدث فيه الأشياء الصعبة. يقوم المستخدم بكتابة ملف، والنقر عليه، وتحميله؛ ترسل الواجهة الأمامية كل شيء إلى الخادم؛ يستدعي الخادم نموذجًا؛ الجواب يعود.
يظل هذا المخطط مفيدًا جدًا، ولكنه ليس مجانيًا. تجلب كل مكالمة أسئلة حول زمن الوصول والتكلفة والتبعية للشبكة والخصوصية. إذا كان المستخدم يكتب جملة ويريد اقتراحًا، فسيتم وزنه بنصف ثانية. إذا كنت تصنف آلاف المدخلات الصغيرة، فإن البنسات تصبح نقودًا حقيقية. إذا كان النص حساسًا، فإن إرساله من الجهاز ليس خيارًا محايدًا.
ولهذا السبب فإن WebGPU والذكاء الاصطناعي الموجود على الجهاز في حالة من الضجيج. ليس لأننا سنقوم بتشغيل كل نموذج في المتصفح غدًا. لأن بعض الميزات الذكية يمكن أن تقترب من المستخدم.
ليس كل شيء يجب أن يصبح محليًا
النسخة الطفولية من الحجة هي: "السحابة مقابل الجهاز". النسخة المفيدة هجينة.
تبدو بعض المهام رائعة على الجهاز: ملخصات قصيرة، اكتشاف اللغة، إعادة الكتابة الضوئية، التصنيفات البسيطة، مرشحات الصور، نماذج الرؤية الصغيرة، التجارب الإبداعية مع ردود الفعل الفورية.
تظل المهام الأخرى أفضل في السحابة: التفكير المعقد، والنماذج الحدودية، والبيانات من جانب الخادم، والتدقيق المركزي، والجودة الموحدة، وسير العمل حيث يتعين عليك التحكم بعناية في كل خطوة.
تقرر البنية الصحية في وقت التشغيل ما يلي:
ليس من الضروري أن يفوز المتصفح على السحابة. يجب أن يحفظ السحابة من القيام بأعمال لا يلزم القيام بها هناك.
لماذا يعد WebGPU مهمًا
WebGPU عبارة عن واجهة برمجة تطبيقات حديثة لاستخدام وحدة معالجة الرسومات (GPU) من المتصفح. لا يقتصر الأمر على الرسومات ثلاثية الأبعاد الجميلة فقط. وهو مهم أيضًا لأنه يكشف عن العناصر الأولية المناسبة للحوسبة: أعباء العمل المتوازية، والتظليل، وخطوط الأنابيب الأقرب إلى ما تقوم به وحدات معالجة الرسومات بشكل جيد.
بالنسبة للذكاء الاصطناعي والتصور العلمي والمحررات ثلاثية الأبعاد ومرشحات الفيديو والأدوات الإبداعية، فإن هذا الاختلاف محسوس. لقد فعل WebGL الكثير للويب، ولكن تم إنشاء WebGPU بنموذج أكثر ملاءمة للوقت الحاضر.
ومع ذلك، فإن أول شيء يجب كتابته ليس التظليل. إنه اكتشاف ميزة رصينة:
export async function requestWebGpuDevice() { if (!('gpu' in navigator)) { return null; } const adapter = await navigator.gpu.requestAdapter({ powerPreference: 'high-performance', }); if (!adapter) { return null; } return adapter.requestDevice(); }
تقول هذه الميزة شيئًا مهمًا: WebGPU ليس حقًا ممنوحًا على كل جهاز. إنها القدرة على التحقق. بعض المتصفحات لا تدعمها بشكل كامل، وبعض وحدات معالجة الرسومات بها قيود، وبعض بيئات المؤسسات تعمل على تعطيل الميزات، ويستخدم بعض المستخدمين أجهزة متواضعة.
الذكاء الاصطناعي المدمج: عندما يقوم المتصفح بإحضار النموذج
يقوم Chrome بدفع واجهات برمجة التطبيقات المضمنة لمهام مثل المطالبات المحلية والتلخيص والكتابة وإعادة الكتابة والترجمة واكتشاف اللغة والتدقيق اللغوي. الفكرة مثيرة للاهتمام للغاية: يقوم المتصفح بإدارة النموذج والتوفر والتحديثات؛ يستخدم التطبيق واجهة برمجة التطبيقات (API) الأقرب إلى النظام الأساسي.
إذا كان يعمل بشكل جيد، فإنه يتغير كثيرا:
- عدد أقل من مكالمات الخادم للمهام البسيطة؛
- البيانات التي قد تبقى على الجهاز؛
- الكمون أقل.
- تجارب غير متصلة بالإنترنت أو شبه متصلة بالإنترنت؛
- تجربة مستخدم أكثر طبيعية للكتابة والترجمة.
ولكن ينبغي التعامل معها على أنها تعزيز تدريجي. بعض واجهات برمجة التطبيقات مستقرة، وبعضها الآخر في مرحلة التجربة أو المعاينة الأصلية، والبعض الآخر لا يزال يعتمد على الإصدار واللغة والجهاز.
type LocalCapability = 'available' | 'downloadable' | 'unsupported'; export async function getLocalSummarizerCapability(): Promise<LocalCapability> { const SummarizerApi = (globalThis as any).Summarizer; if (!SummarizerApi?.availability) { return 'unsupported'; } const availability = await SummarizerApi.availability(); if (availability === 'available') return 'available'; if (availability === 'downloadable') return 'downloadable'; return 'unsupported'; }
سوف يتغير الكود المحدد، ولكن يبقى النمط: يمكنك التحقق من التوفر، وشرح أي تنزيلات، وتقديم بدائل، وقياس الجودة.
التراجع ليس خطة حزينة ب
التراجع السحابي ليس هزيمة. إنه جزء من المنتج.
interface AiRequest { task: 'summarize' | 'rewrite' | 'classify'; input: string; } interface AiResult { output: string; runtime: 'local' | 'cloud'; } export async function runAiTask(request: AiRequest): Promise<AiResult> { const local = await tryLocalAi(request); if (local) { return { output: local, runtime: 'local' }; } const cloud = await fetch('/api/ai', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(request), }).then((res) => res.json()); return { output: cloud.output, runtime: 'cloud' }; }
تسمح لك هذه البنية بالتحسين التدريجي. أولئك الذين لديهم دعم محلي يحصلون على زمن استجابة وخصوصية أفضل. أولئك الذين ليس لديهم هذه الميزة ما زالوا يستخدمونها. يمكنك قياس النسبة المئوية للطلبات المحلية والأوقات والأخطاء والذاكرة والجودة الملموسة والتكلفة.
بدون المقاييس، يصبح الذكاء الاصطناعي الموجود على الجهاز خيارًا جماليًا. ومع المقاييس، يصبح الأمر بمثابة رافعة للمنتج.
تجربة المستخدم للنموذج مهمة
إذا احتاج المتصفح إلى تنزيل نموذج، فسيدركه المستخدم. لا تخفيه وراء الدوار الغامض. من الأفضل أن نكون واضحين: "نحن نجهز النموذج لاستخدام هذه الوظيفة بشكل أسرع وحتى في وضع عدم الاتصال."
تجربة جيدة:
- يظهر حالة التحضير.
- لا يمنع الصفحة بأكملها؛
- يسمح لك بمتابعة التراجع السحابي؛
- وتجنب مفاجآت البطارية والذاكرة؛
- تذكر النموذج كلما أمكن ذلك؛
- اشرح الفائدة في جملة واحدة ملموسة.
أسوأ ما في الأمر هو أن الميزة "الذكية" تبدو معطلة لأنها تقوم بتنزيل شيء ما بصمت.
الخصوصية: أفضل، وليست آمنة تلقائيًا
يمكن أن تكون معالجة البيانات الموجودة على الجهاز ميزة كبيرة. ليس من الضروري أن تخرج مسودة البريد الإلكتروني أو المستند الداخلي أو الملاحظة الشخصية من متصفحك لتلقي اقتراح.
ومع ذلك، المحلي لا يعني تلقائيا آمنة. ومع ذلك، عليك أن تفكر في:
- XSS.
- سجلات عرضية؛
- البيانات المحفوظة في التخزين؛
- الحقن الفوري من محتوى غير موثوق به؛
- الأذونات الممنوحة للنموذج؛
- المخرجات المستخدمة في الإجراءات التلقائية.
إذا كان بإمكان النموذج المحلي قراءة صفحة ويب ثم ملء نموذج، فقد تحاول تلك الصفحة التعامل معه. إذا كان بإمكانه استدعاء الأداة، يلزم التأكيد. إذا كان ينتج مخرجات منظمة، فيجب التحقق من صحته. إن حقيقة تشغيله على الجهاز تقلل من بعض مخاطر الخصوصية، ولكنها لا تلغي نموذج الأمان.
حيث يصبح الأمر مثيرًا للاهتمام حقًا
النص هو مجرد البداية. يجعل WebGPU تجارب الويب ذات مصداقية والتي كانت تبدو حتى وقت قريب وكأنها تطبيق أصلي:
- محررات ثلاثية الأبعاد معقدة؛
- رش غاوسي في المتصفح؛
- مرشحات الفيديو في الوقت الحقيقي.
- CAD خفيف الوزن؛
- تصورات علمية؛
- أدوات إبداعية مع معاينة فورية؛
- استنتاج الرؤية بالقرب من واجهة المستخدم؛
- ألعاب متصفح أكثر طموحًا.
هنا تبدأ الواجهة الأمامية والرسومات والتعلم الآلي في الاختلاط. إنها منطقة غريبة إلى حد ما، ولكنها أيضًا منطقة خصبة: يعود المتصفح إلى كونه منصة تطبيقات جادة، وليس فقط المكان الذي نضع فيه النماذج ولوحات المعلومات.
قائمة المراجعة قبل الإنتاج
قبل وضع ميزة على الجهاز أمام المستخدمين، يجب أن أتحقق مما يلي:
- استهداف المتصفحات والأجهزة.
- سحابة احتياطية أو تدهور أنيق.
- وقت التنزيل وذاكرة التخزين المؤقت للنموذج.
- الذاكرة والبطارية على الأجهزة المتوسطة.
- الجودة مقارنة بالنسخة السحابية.
- سياسة الخصوصية ورسائل المستخدم.
- اختبار مع مدخلات معادية.
- مقاييس منفصلة لوقت التشغيل المحلي والسحابي.
- خطط لتحديث القالب أو تعطيله.
إنها قائمة ملموسة لأن المشكلة ملموسة. لا تصبح ميزة الذكاء الاصطناعي البطيئة أو الهشة أو المبهمة أفضل لمجرد تشغيلها في المتصفح.
التسوية الصحيحة
لا أعتقد أن المستقبل هو "كل شيء على الجهاز". ولا أعتقد أن السحابة ستظل المكان المعقول الوحيد للاستدلال أيضًا. المستقبل الأكثر ترجيحًا هو مزيج: محلي عندما يعمل على تحسين زمن الوصول أو الخصوصية أو التكلفة؛ السحابية عندما تكون هناك حاجة إلى الجودة والبيانات المحدثة والتحكم المركزي.
لا تجعل WebGPU وWebNN وواجهات برمجة التطبيقات AI المضمنة المتصفح قويًا. يجعلونه أكثر نضجا. وبالنسبة لأولئك الذين يقومون ببناء منتجات الويب، فهذه أخبار ضخمة.
مصادر مفيدة
METADATA
- date: 2026-05-24
- reading: 6 min
- author: Filippo Spinella
- tags: WebGPU, AI, Frontend, Web Performance