ComfyUI-Workflow wiederverwenden: Checkliste vom Import bis zur Reproduktion

Nach dem Import eines fremden ComfyUI-Workflows kann die Oberfläche plötzlich voller roter Nodes sein, während die Modellliste leer bleibt. Beim ersten Mal brauchte ich eine halbe Stunde, bis klar war: Es sind meistens drei getrennte Probleme. Nodes fehlen, Modellpfade stimmen nicht, oder Python-Abhängigkeiten sind nicht installiert. Dieser Text erklärt nicht die ComfyUI-Installation, sondern nur diesen konkreten Fall: Sie haben eine workflow JSON oder ein PNG bekommen und wollen sie Schritt für Schritt auffüllen, debuggen und am Ende ein Ergebnis erzeugen, das dem Beispielbild nahekommt. Der Kern ist eine Checkliste, die Sie vom Import bis zur Ablage wiederverwenden können.

Warum ein fremder Workflow nicht läuft

Ein ComfyUI workflow ist im Kern ein Node-Graph. JSON oder PNG metadata speichern Node-Typen, Parameterwerte und Verbindungen. Sie enthalten keine Modelldateien, keine custom nodes und keine Python-Abhängigkeiten. Deshalb zeigt sich beim Import sofort, was in Ihrer lokalen Umgebung fehlt.

Rote Nodes bedeuten, dass ComfyUI den passenden Node-Typ nicht findet. Manche Nodes sind eingebaute core nodes und sollten nicht fehlen. Andere sind Drittanbieter-Erweiterungen, also custom nodes, die lokal noch nicht installiert sind. Selbst wenn die Nodes ergänzt sind, kann das Dropdown von Load Checkpoint oder Load LoRA leer bleiben. Dann liegt die Modelldatei nicht im Standardordner oder die Pfadkonfiguration passt nicht. Danach können einzelne custom nodes immer noch fehlende Python-Pakete wie insightface oder onnxruntime melden.

Diese drei Problemarten überlagern sich. Ein workflow kann gleichzeitig drei custom nodes, zwei checkpoint-Modelle und ein Python-Paket benötigen. Ohne feste Reihenfolge bleibt man leicht an einer Stelle hängen und installiert blind alles Mögliche. Die folgende Checkliste trennt diese Fälle und arbeitet sie nach Priorität ab.

Zwei Workflow-Quellen: JSON vs PNG Metadata

Geteilte workflows kommen meist in zwei Formen: als eigenständige JSON-Datei oder als PNG-Bild mit metadata. JSON ist das native Exportformat von ComfyUI und speichert die Node-Informationen vollständig. PNG metadata ist eine eingebettete Variante; manche generierten Bilder enthalten workflow-Daten in der Datei, aber nur, wenn der Ersteller sie erhalten hat.

JSON-Datei hineinziehen

Wenn Sie eine JSON-Datei haben, ziehen Sie sie direkt in die ComfyUI-Oberfläche. Die Oberfläche lädt den Node-Graphen und zeigt alle Verbindungen. Das ist der zuverlässigste Weg, weil JSON nicht von Bildkompression abhängt und die Node-Daten vollständig bleiben.

Wurde die JSON aus ComfyUI exportiert, sollte das Layout nach dem Import ungefähr dem Layout des Autors entsprechen. Ist es stark verschoben, kann eine andere ComfyUI-Version oder eine manuell bearbeitete JSON die Ursache sein.

Voraussetzung für PNG metadata

Einige KI-generierte PNG-Bilder betten workflow metadata ein. Sie laden sie, indem Sie das Bild in ComfyUI ziehen oder im Menü „Load“ die PNG-Datei auswählen.

Die Voraussetzung ist: Das Bild muss die metadata noch enthalten. Viele soziale Plattformen und Bildhoster komprimieren Dateien oder entfernen metadata beim Upload. Dann gehen die workflow-Daten verloren. Wenn Sie ein Bild aus einem Social-Post speichern, ist die metadata oft schon weg; beim Hineinziehen entsteht dann nur eine leere Arbeitsfläche.

Nutzen Sie bevorzugt JSON-Dateien. PNG metadata ist praktisch für den Autor selbst, aber kein robustes Format für plattformübergreifendes Teilen.

Vergleich: JSON vs PNG Metadata

Prüfen Sie vor dem Import die Quelle. Eine passende Node-Liste, Modellliste oder README ist sicherer als JSON oder PNG allein.

Rote Nodes: Core Node und Custom Node trennen

Nach dem Import können rote Nodes mit Titeln wie „Missing“ oder „Unknown node type“ erscheinen. Installieren Sie nicht sofort Pakete. Bestimmen Sie erst den Node-Typ und dann die Suchrichtung.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Unterschied zwischen Core Node und Custom Node

Core nodes sind in ComfyUI eingebaut und werden mit dem Hauptprogramm installiert. Typische Beispiele sind Load Checkpoint, KSampler, VAE Decode und Save Image. Wenn diese Nodes rot sind, ist die ComfyUI-Installation vermutlich unvollständig; prüfen Sie Version oder Installation.

Custom nodes sind Drittanbieter-Nodes und müssen separat installiert werden. Typische Beispiele sind IP-Adapter Apply, ControlNet Apply und FaceDetailer. Rote Nodes in geteilten workflows sind meistens fehlende custom nodes.

Schauen Sie zuerst auf den Node-Namen. Enthält er bekannte Erweiterungspräfixe wie IPAdapter, ControlNet oder Impact, ist er sehr wahrscheinlich ein custom node. Wenn Sie unsicher sind, klicken Sie in ComfyUI mit rechts, öffnen „Add Node“ und suchen den Namen. Core nodes stehen in der Standardliste, fehlende custom nodes nicht.

Custom Nodes finden

Wenn klar ist, dass es ein custom node ist, gibt es drei Suchwege.

ComfyUI Registry: Das ist das offizielle Registry-System für Nodes. Öffnen Sie registry.comfy.org und suchen Sie nach Node-Name oder Paketname. Die Registry zeigt Quelle, Installationsmethode und Abhängigkeiten. Einige Nodes lassen sich über Manager/Registry installieren, wenn Ihre ComfyUI-Version das unterstützt.

ComfyUI Manager: Das ist ein Drittanbieter-Tool zur Erweiterungsverwaltung. Ist Manager lokal installiert, öffnen Sie in ComfyUI „Manager“ und „Install Custom Nodes“ und suchen den Node-Namen. Manager listet passende Pakete und deren Installationsstatus. Es ist keine core-Funktion von ComfyUI; die Stabilität hängt von der Community-Pflege ab.

GitHub-Suche: Finden Registry und Manager nichts, suchen Sie den Node-Namen auf GitHub. Viele custom-node-Autoren nennen ihre Nodes im README. Wenn Sie das Repository finden, folgen Sie dem README und clonen es nach custom_nodes.

Python-Abhängigkeiten

Einige custom nodes brauchen zusätzliche Python-Pakete. IP-Adapter kann zum Beispiel insightface benötigen, manche ControlNet-Erweiterungen onnxruntime.

Gehen Sie in das Repository des custom node und lesen Sie README oder requirements.txt. Im ComfyUI-Wurzelverzeichnis führen Sie aus:

pip install -r custom_nodes/node-directory/requirements.txt

Manche README-Dateien nennen direkt pip install package-name. Folgen Sie diesen Anweisungen, statt zu raten.

Erst die wirklich fehlenden Nodes bestimmen

Ein workflow kann viele custom nodes referenzieren, aber lokal brauchen Sie nur die tatsächlich verwendeten. Die roten Nodes nach dem Import sind Ihre reale Fehl-Liste. Installieren Sie nicht blind alle beliebten Node-Pakete; jedes Paket verlängert potenziell den Start und kann Konflikte erzeugen.

Modell nicht gefunden: Ordner und externe Modellbibliotheken prüfen

Auch nach ergänzten Nodes können Load Checkpoint, Load LoRA oder Load VAE leere Dropdowns zeigen. Modelldateien werden nicht mit der JSON geteilt. Sie müssen sie manuell in das ComfyUI-Verzeichnis models legen.

Struktur des ComfyUI models-Verzeichnisses

Beim Start scannt ComfyUI Unterordner unter models und lädt Modelle nach Typ. Häufige Ordner sind:

Wenn der Load Checkpoint-Node im workflow sdxl_base.safetensors nennt, legen Sie diese Datei nach models/checkpoints/sdxl_base.safetensors. Das Dropdown zeigt dann die Modelle aus diesem Ordner.

Zweck von extra_model_paths.yaml

Wenn Ihre Modellbibliothek an anderer Stelle liegt, etwa auf einem NAS oder in einem zentralen Modellordner, müssen Sie nicht alles nach models kopieren. Mit extra_model_paths.yaml verweisen Sie auf externe Pfade.

Die Datei liegt im ComfyUI-Wurzelverzeichnis und nutzt YAML. Beispiel:

my_custom_config:
  base_path: /path/to/external
  checkpoints: models/checkpoints
  loras: models/loras
  vae: models/vae
  controlnet: models/controlnet

Beim Start scannt ComfyUI diese Pfade und führt sie mit dem Standardverzeichnis models zusammen. Das genaue Format kann sich je nach Version ändern; prüfen Sie im Zweifel die offizielle Dokumentation oder die Start-Hinweise.

Modellversion prüfen

Modellnamen können täuschen. Zwei Dateien mit gleichem Namen können unterschiedliche Versionen sein; zwei verschiedene Namen können dieselbe umbenannte Datei meinen. Prüfen Sie für Reproduktion:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

• checkpoint-Name und Version
• LoRA-Name, Version und Gewicht
• VAE-Datei
• ControlNet- oder IP-Adapter-Modell
• ob der Autor ein quantisiertes, pruned oder gemergtes Modell genutzt hat

Die Modellversion ist einer der größten Faktoren für abweichende Ergebnisse. Wenn Sie die exakte Datei nicht finden, können Sie vorübergehend ein Modell derselben Architektur nutzen, sollten aber notieren, dass das Ergebnis nicht exakt übereinstimmt.

Warum derselbe workflow trotzdem kein identisches Bild erzeugt

Auch mit installierten Nodes und Modellen kann das Ergebnis vom Beispielbild abweichen. Das ist normal. Ein workflow ist nur ein Teil der Reproduktionsumgebung.

Parametertabelle

Modellversion ist die größte Variable

Wenn das Beispielbild mit einem SDXL-Modell erstellt wurde und Sie es durch ein SD1.5-Modell ersetzen, wird das Ergebnis komplett anders. Selbst innerhalb derselben Architektur können checkpoint-Versionen Stil, Gesichter, Licht und Textur verschieben.

Bevor Sie Prompts anpassen, prüfen Sie zuerst das Basismodell. Wenn der Autor keine Modellversion nennt, betrachten Sie das Ziel als Annäherung.

Ziel ist ähnlicher Stil und ähnliche Komposition, nicht perfekte Identität

Bei den meisten geteilten workflows ist das realistische Ziel kein identisches Bild, sondern ähnlicher Stil und ähnliche Komposition. Exakte Reproduktion erfordert dasselbe Modell, dieselben Parameter, dieselben custom-node-Versionen, dieselben Referenzbilder und manchmal dasselbe Backend. Ändert sich eine Bedingung, driftet das Ergebnis.

Praktisch ist ein kleiner Testlauf. Reduzieren Sie die Größe, deaktivieren Sie nicht nötige Post-Processing-Nodes, fixieren Sie den seed und prüfen Sie die Grundkomposition. Danach aktivieren Sie Upscaling, Gesichtskorrektur oder Farb-Nodes einzeln wieder.

Kopierbare Workflow-Checkliste

Nutzen Sie diese Liste jedes Mal, wenn Sie einen workflow bekommen.

Schritt 1: Quelle bestätigen

• Originale JSON- oder PNG-Datei zuerst sichern.
• Quelle notieren: Autor, Plattform, Beitrag oder Repository.
• Prüfen, ob README, Modellliste oder Node-Liste vorhanden sind.
• Bei PNG prüfen, ob metadata noch enthalten ist.
• Den eigenen Standard-workflow nicht überschreiben, bevor die Quelle klar ist.

Wenn die Quelle unklar ist und der workflow viele unbekannte custom nodes verlangt, seien Sie vorsichtig. Ein workflow ist ausführbare Konfiguration, nicht nur ein Bild.

Schritt 2: Nodes ergänzen

• workflow importieren und alle roten Node-Namen notieren.
• core nodes und custom nodes trennen.
• custom nodes zuerst in Registry oder Manager suchen.
• Falls nichts gefunden wird, GitHub durchsuchen und README lesen.
• Eine Gruppe installieren, ComfyUI neu starten und erneut prüfen.
• Wenn der Node rot bleibt, vor Änderungen an Modellpfaden zuerst requirements.txt im custom-node-Ordner prüfen.

Installieren Sie keine zufälligen Node-Pakete, nur weil ein Tutorial sie erwähnt. Installieren Sie nur, was dieser workflow wirklich braucht.

Schritt 3: Modelle zuordnen

• Modellnamen in Load Checkpoint, Load LoRA, Load VAE, ControlNet und IP-Adapter prüfen.
• checkpoints nach models/checkpoints legen.
• LoRA-Dateien nach models/loras legen.
• VAE-Dateien nach models/vae legen.
• ControlNet- und IP-Adapter-Dateien in die passenden Ordner legen.
• Bei externer Modellbibliothek extra_model_paths.yaml konfigurieren.
• ComfyUI neu starten und prüfen, ob das Modell im Dropdown erscheint.

Modellversionsunterschiede beeinflussen die Reproduktion am stärksten. Prüfen Sie sie zuerst.

Schritt 4: Parameter fixieren

Sind die Modelle vorhanden, prüfen Sie die workflow-Parameter.

• Prüfen Sie, ob der seed fixiert ist. Ohne festen seed können Sie dasselbe Bild nicht reproduzieren, sondern nur den Stil abstimmen.
• Prüfen Sie sampler, steps, CFG Scale und Bildgröße.
• Prüfen Sie, ob VAE geladen und LoRA-Gewichte gesetzt sind.
• Vergleichen Sie Beispielbild und Parameter auf offensichtliche Unterschiede.
• Wenn der Autor Parameteränderungen notiert hat, übernehmen Sie diese Hinweise.

Manchmal hat der Autor nach dem JSON-Export Parameter verändert. Wenn Beispielbild und JSON nicht zusammenpassen, müssen Sie manuell angleichen.

Schritt 5: Minimal testen

Nach der Parameterprüfung folgt ein einfacher Test.

• Einmal mit einem simplen prompt wie „a cat sitting on a chair“ ausführen.
• Prüfen, ob die Ausgabe normal ist: kein Fehler, kein leeres Bild, kein grober Zusammenbruch.
• Bei Fehlern das Terminal-Log lesen und den betroffenen Node oder das Modell bestimmen.
• Wenn die Ausgabe normal ist, Prompt und Parameter Schritt für Schritt in Richtung Beispiel anpassen.
• Nicht mit einem komplexen prompt beginnen; er kann Node- oder Modellprobleme verdecken.

Schritt 6: Benennen und archivieren

Wenn die Reproduktion funktioniert, speichern und ordnen Sie den workflow.

• workflow als neue JSON-Datei speichern.
• Namensschema: [topic]-[model-name]-[date]-v1.json. Beispiel: portrait-sdxl-base-20260623-v1.json.
• Modellversionsinformationen in einer passenden README.txt notieren, nicht auf JSON-Kommentare verlassen.
• checkpoint-Name und Version, LoRA-Name und Gewicht, VAE, sampler-Parameter und Schlüsseldaten notieren.
• Wenn Sie später teilen wollen, Node-Liste, Modellliste, Beispielbild und Parameterhinweise hinzufügen. Modelldateien selbst nicht teilen.

Diese Checkliste lässt sich lokal kopieren und bei jeder workflow-Wiederverwendung abhaken.

Workflow-Verwaltung: Namensschema und Teilen

Nach erfolgreicher Reproduktion verhindert Ordnung, dass Sie beim nächsten Mal wieder von vorn suchen. Beim Teilen reduziert vollständige Information die Fehlersuche der anderen Person.

Namensschema

Unklare Dateinamen machen workflows schwer auffindbar, besonders wenn Sie irgendwann Dutzende gesammelt haben.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Empfohlenes Format: [topic]-[model-name]-[date]-v1.json

Beispiele:

• portrait-sdxl-base-20260623-v1.json: Porträt-Thema, SDXL Base, 23. Juni 2026, Version 1
• landscape-sd15-controlnet-20260620-v1.json: Landschaft, SD1.5 + ControlNet

Das topic kann ein Zweck sein: portrait, landscape, anime, product, concept-art. Schreiben Sie beim Modell den kurzen Namen des Haupt-checkpoints. Nutzen Sie das Datumsformat YYYYMMDD und v1, v2 für Iterationen.

Modellversionen dokumentieren

Die workflow JSON speichert normalerweise nur den Modelldateinamen, nicht die vollständige Modellversion. Wenn eine Modellbibliothek mehrere Versionen mit gleichem Namen hat, wissen Sie später möglicherweise nicht mehr, welche Sie genutzt haben.

Passende README.txt verwenden

Erstellen Sie neben dem workflow eine README-[file-name].txt und notieren Sie checkpoint-Quelle, LoRA-Gewicht, VAE-Quelle, sampler, steps, CFG, Bildgröße und weitere Einstellungen, die das Ergebnis sichtbar verändern.

Nutzen Sie README.txt als Hauptquelle für Versionshinweise. Das ist kompatibler und lässt sich leichter mit JSON und Beispielbildern bündeln.

Workflow teilen

Wenn Sie einen workflow teilen, helfen vollständige Angaben dem Empfänger beim schnellen Einstieg.

Enthalten sein sollten:

• die vollständige workflow-Datei, höchste Priorität.
• alle custom-node-Namen und Quellen, etwa Registry-Links oder GitHub-Repositories.
• checkpoint, LoRA, VAE, ControlNet und weitere Modellnamen plus Quellenhinweise, ohne direkte Download-Links.
• ein generiertes Ergebnis als Reproduktionsziel.
• falls JSON-Parameter und Beispielbild abweichen, die tatsächlich genutzten Parameter notieren.

Nicht enthalten sein sollten:

• Lizenzen sind komplex, daher nicht direkt teilen.
• Modellbibliotheksseiten sind in Ordnung, direkte Downloads sind riskanter.
• Bei speziellen Abhängigkeiten Paketnamen nennen und für exakte Befehle auf das README verweisen.

Fügen Sie eine kurze README mit diesen Angaben hinzu. Dann kann der Empfänger die Checkliste abarbeiten, statt zu raten.

Weiter lesen

Wenn ComfyUI noch nicht installiert ist, beginnen Sie mit dem vollständigen ComfyUI-Einstieg für Installation, Modellordner und das erste Bild. Für Prompt-Optimierung lesen Sie Prompt Engineering in der Praxis. Für medienübergreifende KI-Workflows siehe Kreative Workflows über Medien hinweg. Für lokale Sprachmodelle passt die Ollama-Einführung.