Comfy API يحوّل سير عمل ComfyUI إلى نقطة نهاية إنتاجية

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

لطالما يعني نقل سير عمل ComfyUI إلى بيئة الإنتاج إعادة بناء بيئته في مكان آخر. تستأجر وحدات GPU، وتثبّت كل عقدة مخصصة ونموذج مرة أخرى، وتفكّك تشابكات اعتماديات Python حتى تتوقف عن التصادم، ثم تكتب منطق التوسّع حولها. الرسم البياني نفسه، لكن الهندسة جديدة تمامًا، وهي نوع من العمل لا علاقة له بالسبب الذي بنيت من أجله سير العمل في المقام الأول.

أطلقت ComfyUI واجهة Comfy API في نهاية سبتمبر لسدّ هذه الفجوة. وهي متاحة للجميع على خطة Comfy مدفوعة، وتفعل ما يوحي به الاسم: تحوّل سير عمل ComfyUI إلى نقطة نهاية API قابلة للتوسّع التلقائي دون أن تغيّر سير العمل.

حزّم مرة واحدة، وانشر على GPU الذي تختاره

تجدر معرفة الآلية لأن معظم القيمة تكمن فيها. تبدأ بملف JSON لسير العمل، أو تصدّر لقطة من Comfy Desktop. يقرأ أداة البناء سير العمل، ويعثر على النماذج والعقد المخصصة التي يحتاجها، ويساعد في حلّ تعارضات اعتماديات Python. ويمكنك تجاوز أي إصدار يختاره.

تُلتقط خطوة الحلّ تلك في Build: إصدار ComfyUI، والعقد المخصصة، والنماذج، وLoRAs، واعتماديات Python التي يتوقعها سير عملك، مثبّتة معًا. ومن Build تقطع إصدارًا غير قابل للتغيير وتنشر ذلك الإصدار كنقطة نهاية مُدارة لها عنوان URL خاص بها.

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

يجري النشر على Developer Platform من ComfyUI، حيث تعيش عمليات البناء والنشر والاستخدام والإنفاق ومفاتيح API في لوحة تحكم واحدة. يمكنك العمل من المتصفح، أو من الطرفية، أو مع وكيل برمجة. ومسار سطر الأوامر موجز. شغّل `comfy build init` فيفحص تثبيت ComfyUI بحثًا عن العقد المخصصة والنماذج والاعتماديات المثبّتة؛ وشغّل `comfy build push --release` لحزم النشر والنشر. وهناك أيضًا مطالبة جاهزة للنسخ واللصق لوكيل برمجة على صفحة Comfy API لمن يفضّل تسليم الأمر كله إلى مساعد برمجة.

التسعير، ولمن هذا فعلاً

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

تُحتسب فاتورة GPU بالثانية، بأسعار منشورة: RTX PRO 6000 بسعر 4.54 دولار في الساعة، وH100 بسعر 6.23 دولار، وH200 بسعر 7.71 دولار، وB200 بسعر 11.23 دولار. يلزم وجود خطة مدفوعة، Standard فما فوق، ويُحتسب الاستخدام بشكل منفصل.

أصدق ما في الإطلاق هو ما تقوله ComfyUI عمّن لا ينبغي لهم استخدامه. تشير الفريق إلى أنه إذا كان RunPod أو Modal يعمل معك بالفعل، فاستمر في استخدامه، وتضع Comfy API كخيار مناسب عندما تكون إدارة بيئة ComfyUI نفسها هي المشكلة. هذا تمركز أكثر فائدة من عرض «منصة لكل شيء» المعتاد، وهو يخبرك بالعميل المستهدف: من تكون عنق زجاجته إدارة الاعتماديات، لا شراء الحوسبة الخام.

لماذا يغيّر هذا ما يمكن لفريق صغير شحنه

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

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

بالنسبة لخطط Team وEnterprise، يمكن لأعضاء الفريق العمل من Build نفسه، مع تثبيت الإصدار والنماذج والعقد المخصصة والاعتماديات معًا. ويحصل عملاء Enterprise على Managed Builds وضوابط حوكمة لتوحيد الإصدارات والاعتماديات المعتمدة عبر الفرق. وتعالج هذه القدرة الأخيرة خطرًا حقيقيًا في المؤسسات الكبيرة، حيث تحافظ ثلاثة فرق على ثلاث بيئات ComfyUI غير متوافقة ولا يستطيع أحد تحديد أيّها أنتج أصلًا معينًا.

الصورة الأكبر

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

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

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