RunPod تعرض طريقة نشر Stable Diffusion A1111 كواجهة serverless API

نشرت RunPod في مدونتها درس فيديو من استوديو generativelabs.co حول نشر Stable Diffusion A1111 كواجهة API على منصة RunPod Serverless. لا يتعلق الأمر بإصدار أو منتج جديد، بل بدليل عملي. لكن الموضوع مطلوب، لأن كثيرًا من خدمات توليد الصور الصغيرة تُبنى على هذا النمط. فما دامت لا توجد workers قيد التشغيل، لا تكون وحدة GPU مشغولة ولا ترتفع الفاتورة.

ما الذي يعرضه الدرس

يبقى A1111، أي AUTOMATIC1111 Stable Diffusion web UI، من أكثر الواجهات انتشارًا لتشغيل Stable Diffusion. وله أيضًا وضع برمجي: إذا شغّلته بالمعامل `--api`، فإنه يوفّر نقاط وصول HTTP مثل `/sdapi/v1/txt2img`. وهذا الوضع تحديدًا يحوّل الواجهة الرسومية الموجّهة للهواة إلى خلفية (backend) يمكن ربطها بتطبيق أو بوت أو أداة داخلية.

وتضيف RunPod Serverless إلى ذلك طبقة تنسيق (orchestration). تحزم البيئة في صورة Docker، وتنشئ نقطة وصول، ثم تتولى المنصة بنفسها تشغيل الـ workers على وحدات GPU، وإدخال الطلبات في قائمة انتظار، وإيقاف الـ workers عندما لا يوجد عمل. ويستعرض مؤلفو الدرس هذا المسار خطوة بخطوة. أما في مادة RunPod الأصلية فلا تكاد توجد تفاصيل: لا بطاقات رسوميات محددة، ولا أسعار، ولا قياسات لزمن الاستجابة. وعليك أن تتحقق من هذه المعايير بنفسك.

مكوّنات هذه البنية

• الصورة: حاوية Docker فيها A1111 وتبعياته ومعالج للطلبات خاص بـ RunPod.
• نقطة الوصول: مدخل مزوّد بقائمة انتظار. يرسل التطبيق JSON يحتوي على الـ prompt ومعاملات التوليد، ويتلقى صورة في المقابل.
• الـ workers: نسخ GPU تشغّلها المنصة مع وصول الطلبات وتوقفها عند الخمول.
• النماذج: أوزان checkpoint وLoRA وVAE، إما مدمجة في الصورة وإما موجودة على وحدة تخزين شبكية.
• الدفع: بحسب زمن تشغيل الـ workers، وليس بحسب المدة الزمنية لاستئجار الجهاز. اطّلع على الأسعار الحالية في موقع RunPod.

أين تكمن المحاذير

يُعرف الثمن الرئيسي لنهج serverless باسم البدء البارد (cold start). فإذا كان الـ worker متوقفًا، فعلى الطلب الأول أن ينتظر حتى تعمل الحاوية وتُحمَّل أوزان النموذج في ذاكرة GPU. وفي حالة Stable Diffusion، حيث تبلغ checkpoint عدة غيغابايتات، قد يكون هذا التأخير محسوسًا. وهو حرج بالنسبة إلى روبوت الدردشة أو المحرر التفاعلي، لكنه مقبول في التوليد بالخلفية والمهام الدفعية والخدمات ذات الطلبات النادرة.

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

وهناك نقطة أخرى تخص A1111 نفسه. فهو في المقام الأول واجهة موجّهة للبشر، وليس خادم inference صناعيًا. وقد تتعارض الإضافات والإصدارات والتبعيات، لذا يُستحسن تثبيت إصدارات الصورة. وفي الأحمال العالية، ينتقل كثير من الفرق لاحقًا إلى ComfyUI أو diffusers أو معالجات خاصة بها.

من أين تبدأ عمليًا

ابدأ بتحديد نمط الحمل. فإذا كانت الطلبات نادرة وغير منتظمة، يحقق serverless وفرًا حقيقيًا مقارنة بوحدة GPU مستأجرة بشكل دائم. وإذا كان الحمل مستقرًا وعاليًا، فإن النسخة المخصصة تكون عادةً أكثر قابلية للتنبؤ من حيث التكلفة.

بعد ذلك، ابنِ صورة بسيطة بنموذج واحد وقِس كميتين: زمن البدء البارد وزمن توليد صورة واحدة. وبعد ذلك فقط أضف LoRA والإضافات ونقاط checkpoint الإضافية. فعّل حدودًا لعدد الـ workers ولزمن تنفيذ المهمة، حتى لا يتحول خطأ في كود العميل إلى فاتورة غير متوقعة. وتحقق من تراخيص النماذج: فالاستخدام التجاري ليس مسموحًا به لكل الأوزان المتاحة على المنصات العامة.

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