Runpod تشرح كيفية بناء قالب Vlad Diffusion الخاص بك للتشغيل على وحدات GPU السحابية

نشرت Runpod في مدونتها دليلًا تفصيليًا خطوة بخطوة لإنشاء قالب خاص بـ Vlad Diffusion. وهو فرع من Stable Diffusion WebUI طوّره Vladimir Mandic بالتوازي مع AUTOMATIC1111، ثم أعاد تسميته لاحقًا إلى SD.Next. الفكرة بسيطة: تصف البيئة مرة واحدة، ثم تشغّلها على أي بطاقة رسوميات مناسبة في السحابة بنقرتين. المادة نفسها قصيرة وتطبيقية، لذا يركّز العرض أدناه في الغالب على آلية العمل وحدود هذا النهج.

لماذا تحتاج إلى قالب خاص بك

توجد على Runpod قوالب جاهزة لـ Stable Diffusion، لكنها مصممة للمستخدم المتوسط. فقد تتأخر نسخة الواجهة فيها عن الإصدار الأحدث، وتكون مجموعة الإضافات ثابتة، ويتعين عليك تنزيل النماذج التي تحتاجها يدويًا في كل مرة تشغّل فيها القالب. ويختلف Vlad Diffusion عن WebUI الكلاسيكي في بنية الواجهة الخلفية (backend)، ومجموعة خياراته الخاصة، وتحديثاته الأكثر تكرارًا. وإذا كنت تحتاج إلى فرع معين أو إصدار محدد من PyTorch أو مجموعة بعينها من الإضافات، فمن الأسهل أن تبني صورة تناسب احتياجاتك.

يصف القالب في مصطلحات Runpod طريقة تشغيل الـ pod، أي الحاوية المستأجرة المزوّدة بـ GPU. تأخذ المنصة الصورة من السجل (registry)، وتربط الأقراص، وتفتح المنافذ، وتنفّذ أمر البدء. أما كل ما عدا ذلك فيجري داخل الحاوية.

مم يتكوّن القالب

وفق منطق المنصة، تُحدَّد في الإعدادات المعاملات التالية:

• اسم القالب ونوع التشغيل (pod مزوّد بـ GPU)؛
• صورة الحاوية: إما صورة جاهزة من Docker Hub، أو صورة خاصة بك مثبّت فيها Vlad Diffusion بكل تبعياته؛
• حجم قرص الحاوية المخصص للنظام والملفات المؤقتة؛
• حجم وحدة التخزين الدائمة (volume) لنقاط الحفظ (checkpoints) وLoRA ونتائج التوليد؛
• منفذ HTTP لواجهة الويب، وهو عادةً 7860 في SD.Next والمشاريع المشابهة؛
• متغيرات البيئة وأمر البدء مع خيارات التشغيل.

يتعلق القرار العملي الأهم هنا بالفصل بين الأقراص. فقرص الحاوية يختفي مع الـ pod، بينما تبقى وحدة التخزين بعد إيقافه. وتتراوح أحجام نماذج Stable Diffusion بين بضعة غيغابايت وعشرات الغيغابايت، لذا ينبغي تخزينها على وحدة التخزين. وإلا ستعيد تنزيلها عند كل تشغيل وتدفع مقابل بقاء البطاقة الرسومية خاملة.

ماذا يكسب المستخدم

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

والاقتصاديات واضحة كذلك. تحتسب Runpod أجر GPU بالساعة، وما دام الـ pod متوقفًا فإنك تدفع في الأساس مقابل تخزين وحدة التخزين. وبالنسبة لمن يولّدون الصور بين الحين والآخر، فهذا أرخص من شراء بطاقة خاصة. أما لمن يعملون يوميًا ولساعات طويلة، فقد تختلف الحسابات، ويستحسن إجراؤها مسبقًا بالاستناد إلى التعرفة الفعلية للبطاقة المختارة.

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

من أين تبدأ

إذا أردت تكرار هذا المخطط، فالخطوات كالتالي:

1. اتخذ أساسًا لك صورة جاهزة تحوي PyTorch وCUDA، أو ابنِ Dockerfile خاصًا بك يستنسخ مستودع SD.Next. 2. انشر الصورة في سجل تملك Runpod حق الوصول إليه. 3. أنشئ القالب، وحدّد فيه الصورة ومنفذ الواجهة وأحجام الأقراص وأمر البدء مع الخيارات المطلوبة. 4. شغّل الـ pod على بطاقة غير مرتفعة التكلفة، وتحقق من أن الواجهة تُفتح عبر العنوان الوسيط (proxy) الذي توفره Runpod. 5. ضع النماذج على وحدة التخزين الدائمة، وتأكد من تحديد المسار المؤدي إليها في الإعدادات. 6. بعد الاختبار، أوقف الـ pod كي لا تدفع مقابل وقت الخمول.

ومن العادات المفيدة أن تحتفظ بـ Dockerfile وقائمة الخيارات في مستودع. عندها يمكنك إعادة إنشاء القالب خلال دقائق إذا اضطررت إلى تحديث الصورة أو نقلها إلى مزوّد آخر.