أضافت Hugging Face ميزة gradio.Server: أصبح بالإمكان الآن ربط واجهة أمامية مخصصة بخلفية Gradio

في الأول من أبريل عام 2026، قدمت Hugging Face نظام gradio.Server — وهو وضع جديد لـ Gradio يتيح نقل الواجهة خارج المكونات القياسية مع الاحتفاظ بكل طبقة البرامج الخلفية للمنصة. الآن يمكن للمطور بناء واجهة مستخدم باستخدام React أو Svelte أو HTML/JS خالص، بينما يفوّض طابور الطلبات وعمل وحدات معالجة الرسومات وتوزيع الواجهات البرمجية إلى Gradio.

لماذا يُعتبر Server ضروريًا

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

في مدونتهم، يوضح الفريق هذا من خلال مثال تطبيق Text Behind Image، حيث يقوم المستخدم بتحميل صورة، ويزيل النموذج الخلفية، ثم في المتصفح يمكنك وضع النص بين المقدمة والخلفية للصورة. بالنسبة لمثل هذه المهمة، تحتاج إلى طبقات وتأثيرات وتصدير PNG ومنطق من جانب العميل يصعب التعبير عنه من خلال كتل Gradio القياسية.

كيفية عمل ذلك

يمتد gradio.Server من FastAPI. هذا يعني أن المطور يحصل على مسارات قياسية وبرامج وسيطة وتحميل ملفات وردود عشوائية، لكن بالإضافة إلى ذلك — محرك واجهة برمجية Gradio. العنصر الرئيسي هنا هو المزخرف @app.api()، الذي يلتف حول دالة في طابور التنفيذ ويراقب تزامن الطلبات ويحافظ على التوافق مع gradio_client. بالنسبة للتطبيقات التي تعمل على وحدات معالجة الرسومات، هذا مهم بشكل خاص: لا تبدأ استدعاءات متعددة متزامنة في التنافس على نفس المورد.

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

في المثال من المقالة، تشغل الواجهة الخلفية بأكملها حوالي 50 سطر من Python: يتم تحميل نموذج التقسيم عند البدء، وتعمل دالة إزالة الخلفية من خلال مزخرف GPU في Spaces، والصفحة الرئيسية HTML يتم تقديمها عبر مسار @app.get("/") قياسي. يمكن الاحتفاظ بالواجهة الأمامية نفسها بدون React وبدون أي أداة بناء على الإطلاق.

ما يتغير للمطورين

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

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

• يمكنك الاحتفاظ بأي واجهة أمامية — من HTML/JS خالص إلى React أو Svelte
• تحصل طرق الواجهة البرمجية من خلال @app.api() تلقائيًا على طابور والتحكم في التزامن
• تبقى الطرق نفسها متاحة من خلال gradio_client لتطبيقات وسكريبتات أخرى
• يمكن تقديم الصفحات الثابتة والمسارات المخصصة مباشرة من نفس التطبيق
• يستمر ZeroGPU وبقية البنية الأساسية لـ Spaces في العمل بدون إعدادات منفصلة

بشكل أساسي، لا يعد الاختيار بين «واجهة مخصصة جميلة» و«واجهة خلفية ملائمة من Gradio» خيارًا صعبًا. إذا كنت بحاجة إلى واجهة مستخدم قياسية، يمكنك بالاستمرار استخدام Blocks أو Interface أو ChatInterface. إذا كنت بحاجة إلى واجهة أمامية كاملة للمنتج، يمكنك الآن توصيلها بنفس المحرك دون التخلي عن عالم Hugging Face ودون بناء طبقة طابور منفصلة يدويًا حول النموذج.

هذا مهم بشكل خاص للأدوات التي تحتوي على قماش ومحررين وعدة صفحات ومنطق عميل معقد.

ما يعنيه هذا

يجعل gradio.Server نظام Gradio أكثر نضجًا بشكل ملحوظ كأداة للسيناريوهات الإنتاجية. بالنسبة للسوق، هذا يشير إلى أن Hugging Face تريد أن تكون ليس فقط منصة لعروض النماذج، بل أيضًا أساس لتطبيقات ذكاء اصطناعي كاملة بواجهات خاصة بها وواجهات برمجية والتحكم في موارد الحوسبة — وليس فقط واجهة عرض للتجارب السريعة.