Wiederaufbau von AUTOMATIC1111 mit Gradio Workflow: 73 Knoten, 11 Pipelines

Hintergrund und Problemstellung

AUTOMATIC1111s stable-diffusion-webui (A1111) gilt seit seiner Veröffentlichung als einer der leistungsfähigsten AI-Bildgeneratoren. Mit Funktionen wie Text-zu-Bild, Bild-zu-Bild, High-Resolution-Fix, Prompt-Matrizen, PNG-Metadaten-Parsing und ControlNet-Integration deckt es nahezu alle Anwendungsfälle von Anfängern bis zu Profis ab. Die Architektur ist jedoch grundsätzlich monolithisch: Sämtliche Funktionen sind in einer einzigen großen Gradio-Blocks-Oberfläche hartcodiert. Jede Erweiterung oder Modifikation erfordert ein tiefes Verständnis des gesamten Codebaums. Eine flexible Kombination verschiedener Pipelines – etwa die direkte Einspeisung von LLM-generierten Prompts in ein Diffusionsmodell oder die Verbindung von Detektionsmasken mit Inpainting-Pipelines – ist ohne Eingriffe in den Quellcode nicht möglich.

Diese Einschränkungen werden mit der rasanten Entwicklung generativer KI immer drängender. Neue Modelle wie FLUX.1-Kontext, Qwen3-4B oder DETR erfordern jeweils separate Integration und Tests. Die Community benötigt dringend eine modulare, bausteinartige Methode, bei der KI-Pipelines wie Schaltpläne lesbar, veränderbar und teilbar sind. Genau hier setzt das Team von Hugging Face an: Mit Gradio Workflow (gr.Workflow) haben sie in 73 Knoten und 11 Pipelines die Kernfunktionen von A1111 rekonstruiert und das Projekt als Workflow1111 auf Hugging Face Spaces veröffentlicht. Jeder Benutzer kann sich mit seinem Hugging-Face-Account anmelden, Modelle über Inference Providers aufrufen und sein eigenes Kontingent verwalten. Es handelt sich nicht um eine bloße Demo, sondern um eine lauffähige, produktionsnahe Referenzimplementierung, die sich wie ein Steckbrett neu verdrahten lässt.

Architektur und Mechanismus

Die zugrunde liegende Philosophie von Workflow1111 ist denkbar einfach: Alle Medienpipelines werden aus vier Operatortypen aufgebaut, die auf der Leinwand als Knoten mit Ein- und Ausgabeports erscheinen. Der Typ `fn` repräsentiert eine reine Python-Funktion, etwa für Textbereinigung, Prompt-Stil-Kombination oder das Schreiben von PNG-Metadaten. Der Typ `model` kapselt einen Aufruf über den Hugging Face InferenceClient – sei es ein Diffusionsmodell, ein LLM, ein VLM oder ein ViT-Klassifikator. Der Typ `space` bindet einen anderen Gradio Space ein, sodass bestehende Anwendungen wie Hintergrundentferner oder Super-Resolution-Tools nahtlos integriert werden können. Der Typ `dataset` schließlich greift auf eine Zeile aus einem Hub-Datensatz zu, etwa für Batch-Verarbeitung oder Template-Lesen.

Alle Knoten sind gleichberechtigt; es müssen keine benutzerdefinierten Knoten wie bei ComfyUI geschrieben werden. Am Beispiel der zentralen Text-zu-Bild-Pipeline: Der Benutzer gibt einen Prompt ein, der zunächst einen `fn`-Knoten (prompt-builder) durchläuft. Diese Funktion kombiniert die Eingabe mit einer ausgewählten Stilvorlage und entfernt überflüssige Leerzeichen. Das Ergebnis wird an einen `model`-Knoten weitergeleitet, der über den InferenceClient ein bestimmtes Checkpoint-Modell aufruft. Das generierte Bild durchläuft einen weiteren `fn`-Knoten, der Sampling-Parameter wie Schritte, CFG-Skala und Seed in die PNG-Metadaten schreibt und das Bild mit allen Metadaten ausgibt.

Die High-Resolution-Fix-Pipeline erweitert die Text-zu-Bild-Pipeline um einen zusätzlichen `model`-Knoten: Das Ausgabebild der ersten Runde wird an FLUX.1-Kontext übergeben, zusammen mit einer verfeinerten Anweisung („Details und Mikrotexturen verstärken, Komposition beibehalten“). Das Ergebnis ist ein hochauflösendes, schärferes Bild. Der gesamte Vorgang benötigt nur zwei Knoten und reproduziert die Logik von A1111, die sonst zwei vollständige Generierungsdurchläufe erfordert. Noch beeindruckender ist die crossmodale Kombination: Ein `model`-Knoten ruft Qwen3-4B auf und wandelt einen groben Prompt („Ein Leuchtturm im Sturm“) in eine strukturierte Liste von Tags um („stürmische See, nasse Felsen, dramatische Komposition …“). Die Ausgabe wird direkt mit dem Prompt-Eingang des Diffusionsmodells verbunden. Parallel dazu kann ein VLM-Knoten (Qwen2.5-VL) ein Foto einlesen und rückwärts einen beschreibenden Prompt generieren, während ein ViT-Klassifikator-Knoten parallel Konfidenzlabels ausgibt. Da beide Knoten denselben Bildeingang teilen, führt gr.Workflow sie automatisch parallel aus – die Gesamtzeit entspricht nur der eines einzelnen Knotens.

Benchmarks und praktischer Nutzen

Obwohl Workflow1111 keine umfassenden Benchmark-Ergebnisse veröffentlicht hat, lassen sich aus dem Design mehrere entscheidende Vorteile ableiten. Der offensichtlichste ist die automatische Parallelisierung: Wenn mehrere Knoten denselben Eingang teilen, plant Gradio Workflow sie gleichzeitig ein. So laufen VLM-Analyse und ViT-Klassifikation nebeneinander ab, und der Benutzer erhält beide Ergebnisse in einem Bruchteil der Zeit, die für sequenzielle Ausführung nötig wäre. In A1111 müsste man diese Schritte manuell nacheinander ausführen oder auf externe Plugins zurückgreifen.

Ein weiterer Gewinn ist das Fehlen benutzerdefinierter Knoten. Werkzeuge wie ComfyUI verlangen, dass Entwickler Python-Klassen schreiben, um neue Knoten zu registrieren. Workflow1111 kommt mit nur vier Operatortypen aus, die die häufigsten Rechenformen abdecken: Funktionen, Modelle, Spaces und Datensätze. Jedes neue Modell oder jeder neue Dienst wird einfach als `model`- oder `space`-Operator eingebunden – ohne zusätzlichen Klebecode. Das senkt die Einstiegshürde für die Weiterentwicklung drastisch.

Hinzu kommt die hohe Wiederverwendbarkeit: Jeder Knoten und jede Verbindung kann direkt in andere Projekte importiert werden. Ein Benutzer kann den gesamten Space in sein eigenes Konto kopieren und dann per Drag & Drop modifizieren – etwa das Checkpoint in der Text-zu-Bild-Pipeline gegen ein anderes Open-Source-Modell austauschen oder den High-Resolution-Fix-Knoten an das Ende einer anderen Pipeline hängen. Dieses „Fork-and-Rewire“-Modell ist intuitiver und sicherer als das traditionelle Kopieren von Codebasen. Da sämtliche Modellaufrufe über die Hugging Face Inference Providers laufen und das eigene Kontingent nutzen, verbraucht Workflow1111 selbst keine zusätzlichen Rechenressourcen. Die Benutzer zahlen nur für die tatsächlich ausgeführten Aufrufe. Zudem startet der gesamte Workflow deutlich schneller als die vollständige WebUI von A1111, weil die Knoten leichtgewichtig sind.

Ausblick und industrielle Bedeutung

Die Bedeutung von Workflow1111 geht weit über eine bloße A1111-Nachbildung hinaus. Es demonstriert die Machbarkeit des Prinzips „Workflow als Anwendung“ für KI-Werkzeugketten. Statt Code zu schreiben, verbindet der Entwickler Knoten auf einer Leinwand. In A1111 musste man für eine neue Funktion das Gradio-Layout anpassen, Callbacks ändern und die Zustandssynchronisation handhaben. In Workflow1111 fügt man für eine LLM-Prompt-Optimierung einfach einen `model`-Knoten hinzu und verbindet ihn mit dem Prompt-Eingang. Dieses Low-Code-Paradigma senkt die Schwelle für die KI-Anwendungsentwicklung von „Python beherrschen“ auf „Flussdiagramme zeichnen können“.

Die Interoperabilität des Ökosystems wird durch den `space`-Operator massiv gesteigert: Workflow1111 kann jeden vorhandenen Gradio Space einbetten – sei es zur Hintergrundentfernung, zur Super-Resolution oder zur Gesichtsrekonstruktion. Tausende von Gradio-Anwendungen aus der Community werden so zu Bausteinen, die sich in größere Workflows einfügen lassen. Das beschleunigt die Prototypenerstellung und die Funktionsintegration enorm.

In der Zukunft sind zahlreiche Erweiterungen denkbar. Workflow1111 deckt derzeit 11 Pipelines ab, aber das Framework begrenzt die Knotenanzahl nicht. Theoretisch könnten Knoten für Videogenerierung (z. B. AnimateDiff), 3D-Rekonstruktion oder Echtzeit-Streaming hinzugefügt werden. Mit der Weiterentwicklung von Gradio Workflow sind visuelles Debugging (Breakpoints an Knoten), bedingte Verzweigungen und Schleifensteuerung zu erwarten – Funktionalitäten, die den Workflow zu einer vollwertigen Programmiersprache machen.

Workflow1111 will A1111 nicht ersetzen, sondern eine alternative Architektur anbieten. Die tiefe Anpassbarkeit von A1111 (etwa durch Skripte und Plugins) bleibt wertvoll, aber die modulare Denkweise von Workflow1111 eignet sich besser für schnelle Experimente und die Wiederverwendung von Komponenten. Langfristig werden sich beide Ansätze gegenseitig befruchten: A1111 könnte einen Workflow-Engine integrieren, um die Plugin-Entwicklung zu vereinfachen, während Workflow1111 von der UI-Verfeinerung von A1111 profitieren könnte. Workflow1111 ist ein wegweisendes Engineering-Projekt, das mit 73 Knoten zeigt, dass die Zukunft von KI-Anwendungen möglicherweise auf einer großen, ziehbaren, teilbaren und weiterentwickelbaren Leinwand liegt.