Comfy API verwandelt einen ComfyUI-Workflow in einen Produktions-Endpunkt

Es gibt eine ganz bestimmte Frustration, die jeder kennt, der in ComfyUI etwas Nützliches gebaut hat. Der Workflow läuft auf deinem Rechner, über Wochen abgestimmt, mit den richtigen Custom Nodes, dem richtigen LoRA, der richtigen gepinnten Version von allem. Dann bittet dich jemand, ihn dem restlichen Team oder einem Produkt zur Verfügung zu stellen, und die Arbeit, die du für erledigt hieltest, ist plötzlich nur halb fertig.

Einen ComfyUI-Workflow in die Produktion zu bringen bedeutete traditionell, seine Umgebung woanders neu aufzubauen. Du mietest GPUs, installierst jeden Custom Node und jedes Modell erneut, entwirrst Python-Abhängigkeiten, bis sie aufhören zu kämpfen, und schreibst die Skalierungslogik drumherum. Der Graph ist derselbe, aber die Engineering-Arbeit ist völlig neu, und sie hat nichts damit zu tun, warum du den Workflow ursprünglich gebaut hast.

ComfyUI hat Ende September Comfy API auf den Markt gebracht, um diese Lücke zu schließen. Es ist für alle mit einem bezahlten Comfy-Plan live und tut, was der Name vermuten lässt: Es verwandelt einen ComfyUI-Workflow in einen autoskalierenden API-Endpunkt, ohne dass du den Workflow änderst.

Einmal paketieren, auf der GPU deiner Wahl deployen

Der Mechanismus ist es wert, verstanden zu werden, denn hier liegt der größte Teil des Nutzens. Du beginnst mit einer Workflow-JSON oder exportierst einen Snapshot aus Comfy Desktop. Ein Builder liest den Workflow, findet die benötigten Modelle und Custom Nodes und hilft, widersprüchliche Python-Abhängigkeiten aufzulösen. Du kannst jede Version überschreiben, die er auswählt.

Dieser Auflösungsschritt wird in einem Build festgehalten: die ComfyUI-Version, Custom Nodes, Modelle, LoRAs und Python-Abhängigkeiten, die dein Workflow erwartet, alle zusammen gepinnt. Aus einem Build schneidest du ein unveränderliches Release und deployst dieses Release als verwalteten Endpunkt mit eigener URL.

Das unveränderliche Release ist der wichtige Teil. Da sich das Release nach dem Schneiden nicht mehr ändert, ist die Umgebung, die du getestet hast, auch die Umgebung, die du deployst. Wenn du eine Änderung vornehmen musst, aktualisierst du den Build und schneidest ein neues Release, ohne das live laufende anzufassen. Jeder, der miterlebt hat, wie eine funktionierende Pipeline kaputtging, weil eine Abhängigkeit sich darunter verschoben hat, erkennt, warum das mehr als nur Bequemlichkeit ist.

Das Deployment läuft auf ComfyUIs Developer Platform, wo Builds, Deployments, Nutzung, Ausgaben und API-Schlüssel in einer Konsole liegen. Du kannst im Browser, vom Terminal aus oder mit einem Coding-Agenten arbeiten. Der Kommandozeilenweg ist kompakt. Führe `comfy build init` aus, und es scannt die ComfyUI-Installation nach Custom Nodes, Modellen und gepinnten Abhängigkeiten; führe `comfy build push --release` aus, um zu paketieren und zu veröffentlichen. Auf der Comfy-API-Seite gibt es außerdem einen Copy-and-paste-Agenten-Prompt für alle, die das Ganze lieber einem Coding-Assistenten übergeben.

Die Preisgestaltung und für wen es wirklich gedacht ist

Workloads skalieren bei Leerlauf auf null, was bedeutet, dass keine GPU-Zeit abgerechnet wird, wenn keine Worker laufen. Für stoßweise kreative Pipelines ist das der Unterschied zwischen einer festen monatlichen GPU-Rechnung und der Bezahlung nur der tatsächlich geleisteten Arbeit. Teams mit latenzempfindlichen Anfragen können Worker stattdessen warm halten und tauschen Kosten gegen das Fehlen von Cold Starts.

Die GPU-Abrechnung erfolgt pro Sekunde, mit veröffentlichten Preisen: eine RTX PRO 6000 für 4,54 $ pro Stunde, eine H100 für 6,23 $, eine H200 für 7,71 $ und eine B200 für 11,23 $. Ein bezahlter Plan, Standard und höher, ist erforderlich, und die Nutzung wird separat abgerechnet.

Das Ehrlichste am Launch ist, was ComfyUI darüber sagt, wer es nicht nutzen sollte. Das Team merkt an, dass du RunPod oder Modal weiter nutzen solltest, wenn das für dich bereits funktioniert, und positioniert Comfy API als passend für den Fall, dass die Verwaltung der ComfyUI-Umgebung selbst das Kopfzerbrechen bereitet. Das ist eine nützlichere Positionierung als der übliche Alles-Plattform-Pitch, und es verrät dir den Zielkunden: jemanden, dessen Engpass das Abhängigkeitsmanagement ist, nicht die Beschaffung von Rechenleistung.

Warum das verändert, was ein kleines Team ausliefern kann

Am klarsten sieht man die Verschiebung am Übergabeproblem. Die Person, die einen Workflow baut, ist oft nicht die einzige, die ihn ausführen muss. Ein Designer stimmt einen Workflow für Produktfotografie mit Custom Nodes und einem feinabgestimmten LoRA ab und braucht dann eine einfache Oberfläche, damit der Rest des Teams ihn ausführen kann, ohne ComfyUI zu öffnen. Ein Produktteam möchte, dass Kunden ein Bild umstylen können, wobei die App jede Anfrage an einen Workflow sendet, den das Team kontrolliert, und mit dem Traffic skaliert. Ein Betriebsteam möchte, dass neue Katalogartikel jede Woche automatisch durch einen Workflow laufen, ohne dass jemand den Graphen beobachtet.

Alle drei sind Varianten desselben Bedürfnisses: einen Graphen zu nehmen, der echte Expertise kodiert, und andere Leute ihn nutzen zu lassen, ohne ihn offenzulegen oder neu aufzubauen. Genau darauf zielt Comfy API. Es lässt dich deinem Team ein Tool geben, einem Produkt eine Funktion hinzufügen oder wiederholbare kreative Arbeit automatisieren, ohne dass diese Nutzer den Graphen verstehen müssen.

Bei Team- und Enterprise-Plänen können Teammitglieder mit demselben Build arbeiten, wobei Version, Modelle, Custom Nodes und Abhängigkeiten zusammen gepinnt sind. Enterprise-Kunden erhalten Managed Builds und Governance-Kontrollen, um genehmigte Versionen und Abhängigkeiten teamübergreifend zu standardisieren. Diese letzte Fähigkeit adressiert ein reales Risiko in großen Organisationen, in denen drei Teams drei inkompatible ComfyUI-Umgebungen pflegen und niemand sagen kann, welche ein bestimmtes Asset produziert hat.

Das größere Bild

Was ComfyUI effektiv getan hat, ist, sich von einem lokalen Tool zu einem gehosteten Stack für Mediengenerierung aufzuwerten. Die Engine bleibt Open Source, und Builds bleiben auf Hardware portierbar, die dir gehört, sodass das Unternehmen nicht versucht, den Workflow in seiner Cloud einzusperren. Diese Portabilität ist eine bemerkenswerte Entscheidung in einem Markt, in dem gehostete Tools üblicherweise in die andere Richtung ziehen.

Der Launch sagt auch etwas darüber aus, wohin der Wert bei der Bild- und Videogenerierung gewandert ist. Vor einem Jahr lag die Differenzierung im Modell. Jetzt, da leistungsfähige Modelle für alle verfügbar sind und offene Gewichte viele davon auf lokale Hardware bringen, verschiebt sich die Differenzierung zum Workflow: die spezifische Abfolge von Nodes und Einstellungen, die ein allgemeines Modell in eine zuverlässige Ausgabe für einen engen Zweck verwandelt. Diese Workflows sind der Ort, an dem Domänenexpertise kodiert wird, und bis jetzt waren sie schwer zu operationalisieren.

Ob Comfy API der Standardweg dafür wird, ist eine offene Frage. Es erfordert einen bezahlten Plan, läuft auf ComfyUIs eigener Plattform und konkurriert nicht über den reinen Preis mit den spezialisierten GPU-Clouds. Was es bietet, ist die Beseitigung des am wenigsten kreativen und fehleranfälligsten Teils der Auslieferung von KI-Medien. Für viele kleine Teams ist dieser Tausch der ganze Grund, warum sie ein internes Tool in etwas verwandeln können, das sie verkaufen können.