Runpod تشرح كيفية تشغيل واجهة API خاصة بك على Serverless في أربع خطوات

نشرت Runpod دليلًا تفصيليًا خطوة بخطوة لإنشاء واجهة API خاصة بك على منصة Serverless. يستغرق الانتقال من مجلد فارغ إلى نقطة نهاية HTTP عاملة أربع خطوات: كتابة worker، واختباره محليًا، وبناء صورة Docker، وإنشاء endpoint في لوحة التحكم. تضيف المنصة تلقائيًا خمسة مسارات خدمية وطابور طلبات وتوسيعًا آليًا، ولا تتقاضى سوى ثمن الثواني التي يعالج فيها الـ worker المهمة.

المادة تمهيدية ولا تتضمن أي ميزات جديدة. لكنها تمثّل نقطة دخول مريحة للفرق التي تريد إخراج استدلال النموذج (inference) إلى خدمة مستقلة دون إعداد كتلة خوادم (cluster) لهذا الغرض.

كيف يعمل الـ worker

جوهر الحل كله هو دالة المعالجة (handler). تستقبل الدالة قاموسًا يصف المهمة، وتوجد بيانات الإدخال في المفتاح input. ويمكن تنفيذ أي شيء داخلها: تحميل النموذج في ذاكرة الفيديو عند بدء تشغيل الحاوية، أو توليد نص، أو معالجة صورة، أو حتى جمع رقمين للتحقق فقط. تُرجع الدالة النتيجة ككائن Python عادي، وتتولى المنصة تسلسله إلى JSON.

ولتحويل الدالة إلى worker، تُمرَّر إلى runpod.serverless.start({"handler": handler}). وهذه هي نقطة التكامل الوحيدة مع SDK. أما الكائنات الثقيلة، مثل أوزان النموذج، فمن المنطقي تهيئتها خارج handler، على مستوى الوحدة (module). عندها تُحمَّل مرة واحدة عند بدء تشغيل الـ worker، لا مع كل طلب.

يمكن اختبار الشيفرة قبل النشر. فإذا وُضع ملف test_input.json بجوارها وشُغِّل السكربت، يُجري SDK المعالج على مدخلات الاختبار ويعرض النتيجة في الطرفية. وهناك أيضًا وضع الخادم المحلي بالمسارات نفسها الموجودة في السحابة، ويمكن الوصول إليه عبر curl أو Postman.

نقاط النهاية وأنماط الاستدعاء

بعد إنشاء نقطة النهاية، تمنحك Runpod معرّفًا وعنوانًا عامًا بصيغة api.runpod.ai/v2/{id}. وتتم مصادقة الطلبات بمفتاح API في ترويسة Bearer. مجموعة المسارات ثابتة:

• /run: تشغيل غير متزامن، ويصل في الرد معرّف المهمة id؛
• /runsync: استدعاء متزامن، يبقى فيه الاتصال مفتوحًا حتى جاهزية النتيجة؛
• /status/{job_id}: حالة المهمة غير المتزامنة ونتيجتها؛
• /cancel/{job_id}: إلغاء مهمة في الطابور أو قيد التنفيذ؛
• /health: حالة الـ workers والطابور.

يحدد زمن المهمة الاختيار بين /run و/runsync. فالعمليات القصيرة يُفضَّل استدعاؤها بشكل متزامن. أما توليد الصور، وتفريغ الصوت الطويل نصيًا، وكل ما قد يستغرق دقائق، فالأفضل إرساله بشكل غير متزامن مع استطلاع الحالة. وللردود المتدفقة، مثل إخراج نموذج لغوي رمزًا تلو الآخر، يمكن جعل handler مولِّدًا (generator).

النشر والتكلفة

تُغلَّف الشيفرة والاعتماديات في صورة Docker تُنشر في سجل (registry). وعند إنشاء نقطة النهاية في لوحة التحكم، تُحدَّد الصورة ونوع GPU أو CPU وحد الـ workers والمهلات الزمنية. بعد ذلك تشغّل المنصة الحاويات وتوقفها تلقائيًا بحسب طول الطابور.

هناك نمطان. تبدأ workers من نوع Flex عند الطلب وتُطفأ عند الخمول، فلا يُدفع مقابل وقت الخمول، لكن أول طلب بعد التوقف ينتظر بدءًا بارد (cold start). وقد يكون ذلك ملحوظًا في النماذج ذات الأوزان الكبيرة. أما workers من نوع Active فتعمل باستمرار: زمن الاستجابة أقل، وسعر الثانية أقل أيضًا، لكنها تُحتسب مشغولة حتى دون حركة مرور. وتتم المحاسبة بالثانية.

من أين تبدأ

تكفي لأول تجربة مجموعة دنيا من الإجراءات:

1. تثبيت حزمة runpod وكتابة handler يُرجع نتيجة بسيطة. 2. تشغيله محليًا عبر test_input.json والتأكد من أن صيغتي الإدخال والإخراج تناسبان العميل. 3. بناء الصورة ودفعها إلى السجل وإنشاء endpoint بـ worker واحد ومهلة قصيرة. 4. استدعاء /runsync عبر curl، ثم الانتقال إلى /run و/status. 5. وبعد ذلك فقط، إضافة النموذج الفعلي وقياس البدء البارد.

من الأفضل قياس زمن أول استجابة بعد فترة الخمول فورًا ومقارنته بمتطلبات المنتج. ويتوقف على هذا الرقم الاختيار بين workers من نوع flex وactive. كما يؤثر حجم الصورة في البدء البارد، ولذلك يُستحسن الاحتفاظ بأوزان النماذج الكبيرة في تخزين شبكي أو تخزينها مؤقتًا (cache)، بدلًا من تضمينها في الصورة دون حاجة.