ComfyUI-Fehler beheben: Rote Nodes, VAE-Probleme und Rollbacks

Du öffnest einen geteilten Workflow und siehst eine Reihe roter unknown nodes. Nach Install Missing Custom Nodes in Manager und einem Neustart sind sie weiterhin rot. Manager ist kein universelles Reparaturwerkzeug: Er verwaltet Node-Code, garantiert aber weder eine erfolgreiche Installation aller Abhängigkeiten noch die Bereitstellung von Modelldateien.

Rote Nodes sind nur ein Einstieg in die ComfyUI-Fehlerbehebung. ComfyUI kann bei loading hängen, die Oberfläche kann leer bleiben, ein bisher funktionierender Workflow kann nach einem Update ausfallen, die VAE-Ausgabe kann grau oder schwarz werden oder ein kopiertes Modell kann im Dropdown fehlen. Dahinter stecken meist Konflikte mit Custom Nodes, Paketversionen, Modellpfade, Präzisionsflags oder VRAM-Spitzen.

Gehe vom Symptom aus: Ordne es einem Bereich zu und führe zuerst den kleinsten aussagekräftigen Test aus.

Schnellübersicht nach Symptom

Die Tabelle deckt sechs typische Einstiege ab. Wähle das Symptom in der ersten Spalte, schränke in der zweiten die Ursache ein und beginne mit der dritten.

Symptom	Wahrscheinlichste Ursache	Erste Maßnahme
Rote Nodes / unknown nodes	Fehlender Custom Node, umbenannter Node oder fehlgeschlagener Import	Node-Namen in Manager oder Registry suchen und Konsole auf Import failed prüfen
Hängt bei loading / leere Seite / blank screen	Konflikt einer Custom-Node-Frontend-Erweiterung	Mit python main.py --disable-all-custom-nodes testen
Prompt execution failed nach Queue	Custom-Node-Fehler, Modellproblem oder zu wenig VRAM	Show report öffnen und fehlerhafte Komponente identifizieren
Graue, weiße, verfärbte oder schwarze VAE-Ausgabe	VAE passt nicht oder falsche Präzision	VAE-Loader-Verbindung, Dateizuordnung und --fp16-vae prüfen
Workflow fällt nach Update aus	Versionskonflikt zwischen Core und Nodes oder Paketkonflikt	Ermitteln, was aktualisiert wurde, und Skripte in update prüfen
Kopiertes Modell fehlt im Dropdown	Falscher Modellpfad oder veraltete Node-Definitionen	Passenden ComfyUI/models/-Unterordner prüfen, neu starten oder aktualisieren

Lösche nicht sofort die Installation. Sichere Workflow, Logs, Node-Liste und Versionsstände, bevor du die Umgebung änderst.

Rote Nodes einordnen: Custom Node oder Modell?

Ein roter unknown node bedeutet meist, dass ComfyUI den Node-Typ nicht findet. Der Custom Node kann fehlen, umbenannt oder deaktiviert sein oder beim Import seiner Abhängigkeiten scheitern. Ein fehlendes Modell verschwindet eher aus dem Loader-Dropdown oder verursacht bei der Ausführung einen Modellfehler. Behandle beide Fälle getrennt.

1. Was behebt Install Missing in Manager?

Install Missing Custom Nodes in ComfyUI-Manager behebt vor allem fehlenden Node-Code. Manager installiert Nodes über Registry oder Quellrepository, doch folgende Teile können weiterhin separate Arbeit erfordern:

• Python-Abhängigkeiten des Nodes, etwa torch, numpy oder xformers aus requirements.txt
• Modelldateien wie Checkpoints, VAEs, LoRAs und ControlNets
• Eigene Modellpfade eines Custom Nodes, die in dessen README stehen

Comfy Desktop enthält Manager und aktiviert ihn standardmäßig. Bei aktuellen Portable- und Manual-Installationen ist der neue Manager in ComfyUI Core integriert, benötigt aber manager_requirements.txt und den Startparameter --enable-manager. Fehlt ein Node in Manager, ist er eventuell nicht registriert oder die Liste zeigt wegen eines Netzwerkfehlers nur Cache- oder lokale Daten. Prüfe das Originalrepository, bevor du ein ähnlich benanntes Paket installierst.

Nutze diese Reihenfolge: Konsole auf Import failed prüfen → Node in Manager oder Registry suchen → Modellpfad prüfen. Der vollständige Importablauf steht in ComfyUI-Workflows reproduzierbar machen.

2. Import failed richtig lesen

Bei Import failed enthält der letzte Abschnitt des Tracebacks meist das fehlende Modul oder die kollidierende Version. Die Fehlerklasse bestimmt den nächsten Schritt:

Entscheidungsweg:

1. ModuleNotFoundError: No module named 'xxx' → Python-Paket fehlt

   • Nicht in System-Python installieren, sondern in ComfyUIs eigener Python-Umgebung
   • Portable: python_embeded\python.exe -m pip install -r custom_nodes\xxx\requirements.txt
   • Desktop und Manual verwenden andere Pfade; ermittle die tatsächlich von ComfyUI verwendete Python-Datei

2. Fehler mit torch / CUDA / cuDNN → PyTorch und GPU-Backend passen nicht zusammen

   • PyTorch prüfen: python -c "import torch; print(torch.__version__)"
   • Prüfen, ob der GPU-Treiber die aktuellen Systemanforderungen erfüllt
   • Ein Node kann eine torch-Version verlangen, die mit ComfyUIs installierter Version kollidiert

3. Ausnahme im Custom Node → fehlerhafte Node-Version oder Codeproblem

   • GitHub Issues des Nodes nach demselben Traceback durchsuchen
   • Bei einer Regression einen bekannten funktionierenden Commit testen

Versionsabhängiger Hinweis: Zum Zeitpunkt der Paketierung empfiehlt ComfyUI Python 3.13; Python 3.12 dient als Ausweichoption, wenn Custom-Node-Abhängigkeiten unter 3.13 scheitern. PyTorch- und CUDA-Vorgaben ändern sich schnell, daher gelten die aktuellen Systemanforderungen.

3. In Manager installiert, aber weiterhin nicht verfügbar

Ein installierter Status beweist nicht, dass der Node erfolgreich geladen wird. Nach dem Neustart kann er rot bleiben oder einen Konflikt zwischen torch und torchvision auslösen.

Warum ein installierter Node fehlen kann:

• Netzwerkfehler verhinderten den vollständigen Download von Repository oder Abhängigkeiten
• Python-Anforderungen wurden nicht in ComfyUIs Umgebung installiert
• Der Node ist deaktiviert oder scheitert beim Import
• Die Node-Version ist mit der aktuellen ComfyUI-Version inkompatibel

Warum Abhängigkeiten kollidieren:

• Verschiedene Custom Nodes verlangen unterschiedliche Versionen von torch, torchvision oder numpy
• Eine strenge Version in requirements.txt kollidiert mit bereits installierten Paketen

Reihenfolge zur Behebung:

1. Den vollständigen letzten Traceback lesen und nach dem vorherigen Abschnitt einordnen
2. Den verdächtigen Node deaktivieren oder entfernen und ComfyUI erneut testen
3. requirements.txt auf strenge Pins wie torch==2.4.1 prüfen
4. Bleibt der Konflikt, ein Issue mit folgenden Daten eröffnen:
   • Vollständiger Traceback
   • Ergebnis von python main.py --disable-all-custom-nodes
   • Versionen von Python, PyTorch und GPU-Treiber

Versionsabhängiger Hinweis: Manager wechselt zwischen neuer, integrierter und Legacy-Oberfläche. Bezeichnungen und Menüpositionen stehen in der aktuellen Dokumentation. Bei OOM oder einer VRAM-Spitze geht es mit ComfyUI für 6–8 GB VRAM optimieren weiter.

4. Modellpfade und fehlende Dropdown-Einträge

ComfyUI enthält keine Modellgewichte. Checkpoints, VAEs, LoRAs, ControlNets und Upscaler werden separat geladen und in den passenden Unterordner von ComfyUI/models/ gelegt.

Prüfreihenfolge bei fehlender Datei:

1. Richtiger Ordner

   • Checkpoints nach ComfyUI/models/checkpoints/
   • VAEs nach ComfyUI/models/vae/
   • LoRAs, ControlNets und Upscaler in die jeweiligen Typordner
   • Verwendet ein Custom Node andere Pfade, gilt seine README

2. Neustart oder Aktualisierung

   • ComfyUI neu starten oder die von der aktuellen UI unterstützte Aktualisierung der Node-Definitionen ausführen

3. Datei vollständig

   • Dateigröße mit der Downloadquelle vergleichen
   • Unvollständige Datei neu laden oder prüfen

4. Passender Loader

   • Loader und Workflow-Vorlage für den Modelltyp wählen
   • FLUX, SD3.x und weitere neuere Architekturen können bestimmte Text-Encoder, VAEs und Node-Kombinationen benötigen
   • Modellpfade von Custom Nodes können von der allgemeinen ComfyUI/models/-Struktur abweichen

5. extra_model_paths.yaml

   • Portable und Manual können externe Modellbibliotheken über extra_model_paths.yaml einbinden; danach neu starten
   • Desktop verwendet eine eigene Extra-Models-Konfiguration; den aktuellen offiziellen Pfad verwenden

Hinweise zur Modell- und VAE-Zuordnung stehen in Stable-Diffusion-Modelle auswählen.

Hängenden Start mit —disable-all-custom-nodes untersuchen

Wenn ComfyUI bei loading hängen bleibt, eine leere Seite zeigt oder die UI nicht rendert, ist häufig eine Frontend-Erweiterung eines Custom Nodes beteiligt. --disable-all-custom-nodes zeigt schnell, ob Custom Nodes zur Ursache gehören.

1. Ohne Custom Nodes starten

Befehl:

python main.py --disable-all-custom-nodes

Windows Portable:

run_nvidia_gpu.bat oder run_cpu.bat kopieren, --disable-all-custom-nodes an den Startbefehl anhängen und als separates Safe-Start-Skript speichern.

Ergebnis auswerten:

• Fehler verschwindet ohne Custom Nodes → ein Custom Node ist verantwortlich
  • Mit der binären Suche fortfahren
• Fehler bleibt bestehen → Ursache liegt nicht in Custom Nodes
  • ComfyUI Core, Systemanforderungen, GPU-Treiber sowie Python/PyTorch prüfen
  • Modelldateien und Pfade prüfen
  • VRAM-Spitzen mit ComfyUI für 6–8 GB VRAM optimieren untersuchen

Versionsabhängiger Hinweis: Aktuelle Startparameter mit python main.py --help bestätigen.

2. Problematischen Node binär eingrenzen

Beweist der Safe-Start-Test, dass ein Custom Node verantwortlich ist, halbiert eine binäre Suche die Kandidaten ohne Raten.

Prinzip: In jedem Test die Hälfte der Custom Nodes verschieben oder aktivieren, Ergebnis beobachten und die verdächtige Menge wieder halbieren.

Schritte:

1. ComfyUI/custom_nodes/ sichern
2. Die Hälfte der Node-Ordner in ein temporäres Testverzeichnis verschieben
3. ComfyUI starten und den Fehler reproduzieren
4. Ergebnis auswerten:
   • Fehler verschwindet → problematischer Node liegt in der verschobenen Hälfte
   • Fehler bleibt → problematischer Node liegt in der verbleibenden Hälfte
5. Wiederholen, bis ein Node oder eine kleine Interaktion übrig bleibt

Nach der Eingrenzung:

• GitHub Issues nach demselben Traceback durchsuchen
• requirements.txt auf strenge Versionspins prüfen
• Node aktualisieren, ersetzen, deaktivieren oder entfernen
• Bei einer Regression den vorherigen bekannten funktionierenden Commit testen

Daten für ein Issue:

• ComfyUI-Version
• Vollständiger Fehler und Reproduktionsschritte
• Betriebssystem
• Ergebnis des Tests mit --disable-all-custom-nodes
• Python-, PyTorch-, GPU-Treiber- und Hardwaredaten

Graue, schwarze oder unpassende VAE-Ausgaben untersuchen

Graue, weiße, verfärbte oder schwarze Ausgaben können aus einem unpassenden VAE, einer falschen Decode-Verbindung, VAE-Präzision, Attention-Präzision oder fehlenden Dateien für ein neues Modell entstehen. Prüfe in dieser Reihenfolge.

1. Reihenfolge der VAE-Prüfung

Schritte:

1. VAE-Verbindung prüfen

   • VAE-Ausgang des Checkpoint Loaders oder eines separaten VAE Loaders mit dem Decode-Node verbinden
   • Manche Checkpoints enthalten ein VAE, andere Modelle benötigen eine separate Datei

2. VAE, Modell und Workflow abgleichen

   • SD1.5, SDXL, FLUX und SD3.x können unterschiedliche Kombinationen aus VAE, Text-Encoder und Loader erfordern
   • Zuerst die kleinste offizielle Workflow-Vorlage oder das README-Beispiel des Modellprojekts ausführen

3. --fp16-vae prüfen

   • Laut offizieller Startup-Flags-Dokumentation kann --fp16-vae schwarze Bilder verursachen
   • Flag entfernen oder bei passender Hardware --fp32-vae / --bf16-vae testen

4. Präzisionsflags testen

   • --fp32-vae: VAE in voller Präzision, gewöhnlich mit höherem VRAM-Bedarf
   • --bf16-vae: VAE in BF16, benötigt passende Hardware und Backend-Unterstützung
   • --cpu-vae: VAE auf der CPU, gewöhnlich deutlich langsamer
   • --force-upcast-attention: testet, ob Attention Upcasting schwarze Bilder behebt; kein allgemeiner Qualitätsmodus

5. Zuletzt VRAM, Treiber und Abhängigkeiten prüfen

   • Eine VRAM-Spitze kann VAE Decode abbrechen lassen
   • GPU-Treiber gegen aktuelle Anforderungen prüfen
   • PyTorch auf Kompatibilität mit dem GPU-Backend prüfen

Typische Symptome:

Symptom	Mögliche Ursache
Grau, weiß oder verfärbt	Falsches VAE, falscher Decode-Pfad oder Workflow/Modell passen nicht
Vollständig schwarz	--fp16-vae, Attention-Präzision, VRAM-Spitze oder ungültige Modellkombination
Ladefehler	Beschädigtes VAE, falscher Pfad oder unvollständige Dateien

2. Risiko schwarzer Bilder mit fp16 VAE

Viele Anleitungen empfehlen --fp16-vae, um Ressourcen zu sparen. Die offizielle Startup-Flags-Referenz warnt jedoch ausdrücklich vor schwarzen Bildern. Modell, Hardware und Logs müssen in die Entscheidung einfließen.

VAE-Präzisionsflags:

Flag	Wirkung	Geeigneter Test
--fp16-vae	VAE läuft in FP16 und benötigt meist weniger Ressourcen	Kann schwarze Bilder erzeugen; vorsichtig einsetzen
--fp32-vae	VAE läuft in voller Präzision	Für die Diagnose schwarzer Bilder, meist mit höherem VRAM-Bedarf
--bf16-vae	VAE läuft in BF16	Benötigt passende Hardware und Backend
--cpu-vae	VAE läuft auf der CPU	Test bei knappem VRAM, meist langsamer

Attention-Präzision:

• --force-upcast-attention: prüft, ob Attention Upcasting schwarze Bilder behebt
• --dont-upcast-attention: ist mit dem vorherigen Flag unvereinbar und dient nur dem Debugging

Praktische Reihenfolge:

• „Beschleunigungsflags“ nicht ungeprüft aus einer Anleitung übernehmen, sondern Symptom und Konsolenausgabe lesen
• Bei schwarzen Bildern zuerst --fp16-vae entfernen, danach je nach Umgebung --fp32-vae oder --force-upcast-attention testen
• Namen und Standardwerte mit dem aktuellen python main.py --help bestätigen
• Die vollständige OOM- und Low-VRAM-Strecke steht in ComfyUI für 6–8 GB VRAM optimieren

3. VAE- und Modellkonflikt einordnen

Bricht ein funktionierender Workflow nach einem Modell- oder VAE-Wechsel, passen vermutlich Modell, VAE, Loader oder Vorlage nicht zusammen. Modellfamilien benötigen verschiedene Dateien und Node-Kombinationen.

Prüfung nach Modellfamilie:

Modellfamilie	VAE-Prüfung	Loader-/Workflow-Prüfung
SD1.5 Checkpoint	Integriertes oder passendes SD1.5-VAE verwenden	Mit einem SD1.5-kompatiblen Basisworkflow beginnen
SDXL Checkpoint	Integriertes oder passendes SDXL-VAE verwenden	SDXL-kompatible Vorlage und Loader verwenden
FLUX / SD3.x	VAE und Text-Encoder nach Modell-README bereitstellen	Offizielle Vorlage oder Projektdokumentation verwenden

Diagnose:

1. Modell-README, Projektseite oder offizielle Vorlage prüfen
   • Integriertes VAE, benötigte Zusatzgewichte und Loader bestätigen
2. Auswahl in jedem Loader prüfen
   • VAE im Dropdown muss zu Modell und Workflow passen
3. Mit der kleinsten offiziellen Vorlage reproduzieren
   • Eigene Nachbearbeitung entfernen und Nodes einzeln wieder verbinden

Zuordnung der Symptome:

Symptom	Wahrscheinliche Ursache
Grau, weiß oder verfärbt	VAE, Modell oder Decode-Pfad passen nicht
Ladefehler	Beschädigtes VAE, falscher Pfad oder unvollständige Dateien
Minimaler Workflow läuft, ursprünglicher nicht	Nachbearbeitung oder Custom Node verändert den Decode-Pfad

Weitere Auswahlregeln stehen in Stable-Diffusion-Modelle auswählen.

Update-Strategie: Stable, Development, Backup und Rollback

Ein ComfyUI-Update kann einen zuvor funktionierenden Workflow beschädigen. Development enthält die neuesten Commits, kann aber offene Probleme mitbringen. Stable priorisiert Stabilität und erhält manche Funktionen später. Versionsnotizen und ein Rollback-Pfad helfen mehr als weitere Sammelupdates nach dem ersten Fehler.

1. Vor Stable oder Development sichern

Checkliste vor dem Update:

1. Aktuellen ComfyUI-Commit notieren

   • Git: git rev-parse HEAD
   • Portable oder Desktop: Version und Update-Kanal notieren

2. Python und PyTorch notieren

   • Python: python --version
   • PyTorch: python -c "import torch; print(torch.__version__)"
   • Auf NVIDIA-Systemen den Treiber mit nvidia-smi notieren

3. Wichtige Custom-Node-Versionen notieren

   • Node-Liste aus Manager exportieren oder speichern
   • Commit-Hashes produktionskritischer Nodes notieren

4. Workflows und Konfiguration sichern

   • Wichtige Workflow-JSONs in ein separates Verzeichnis exportieren
   • extra_model_paths.yaml, Desktop-Extra-Models-Konfiguration und wichtige Nutzerdaten sichern

Stable oder Development:

Versionstyp	Eigenschaften	Geeignet für
Stable / Release	Stabilisierte Version, kann bei Funktionen zurückliegen	Produktion und langfristige Umgebungen
Development / Latest	Neueste Commits und frühere neue Funktionen	Tests neuer Modelle, Funktionen und Node-Kompatibilität
Fixierter Commit	Bekannter fester Zustand ohne automatische spätere Korrekturen	Temporäres Rollback, Regressionssuche und Reproduktion

Strategie nach Installation:

Installation	Strategie
Desktop	Standardmäßig stabiler Kanal; bei Bedarf im aktuellen Verwaltungsbereich anderen Kanal wählen
Portable	update_comfyui_stable.bat folgt Stable, update_comfyui.bat Development
Manual Git	git pull ausführen, dann requirements.txt in ComfyUIs Umgebung aktualisieren; Commit-Wechsel für Rollback

Versionsabhängiger Hinweis: Skriptnamen und Desktop-Einstellungen in der aktuellen Update-Dokumentation bestätigen.

2. Nach einem Update-Fehler zurückrollen

Ermittle zuerst, ob Core, ein einzelner Custom Node oder die Python-Umgebung verändert wurde.

Änderung einordnen:

1. Nur ComfyUI Core wurde aktualisiert

   • Mit --disable-all-custom-nodes testen, ob der Core startet
   • Prüfen, ob Custom Nodes kompatible Updates benötigen

2. Nur ein Custom Node wurde aktualisiert

   • Node auf die vorherige Version zurücksetzen
   • Oder deaktivieren und ComfyUI erneut testen

3. Abhängigkeiten wurden aktualisiert

   • Python-, PyTorch- und kritische Paketversionen erneut prüfen
   • update_comfyui_and_python_dependencies.bat in Portable installiert alle Abhängigkeiten neu; laut offizieller Dokumentation kann dies Konflikte verursachen und Nodes mit festen Paketversionen beschädigen

Git-Rollback:

# Letzte Commits anzeigen
git log --oneline

# Zu einem bekannten funktionierenden Commit wechseln
git checkout <commit-hash>

# Abhängigkeiten nur in der passenden ComfyUI-Umgebung aktualisieren
pip install -r requirements.txt

Rollback-Wege in Portable und Desktop können sich ändern. Stelle bevorzugt das Backup vor dem Update wieder her und folge der aktuellen Dokumentation. Eine sofortige Deinstallation entfernt Versions- und Konfigurationsdaten, die für die Diagnose gebraucht werden.

Daten für ein Custom-Node-Issue:

• Vollständiger Fehler und Reproduktionsschritte
• Versionen von ComfyUI, Python, PyTorch und GPU-Treiber
• Ergebnis des Tests mit --disable-all-custom-nodes
• Core- oder Node-Versionen vor und nach dem Update

Nächste Themen

Ist die Umgebung wieder stabil, gehe mit dem passenden ComfyUI-Thema weiter:

1. Geteilten Workflow reproduzieren

   • Workflow importieren, Nodes und Modelle ergänzen und Loader verbinden
   • Siehe ComfyUI-Workflows reproduzierbar machen

2. VRAM-Verbrauch senken

   • Von OOM oder VRAM-Spitzen zu --lowvram, VAE und Modellquantisierung wechseln
   • Siehe ComfyUI für 6–8 GB VRAM optimieren

3. Upscaling und Inpainting

   • Workflows mit FaceDetailer, Impact Pack und anderen Nachbearbeitungs-Nodes wiederherstellen
   • Siehe ComfyUI-Upscaling und Inpainting

4. Videos erzeugen

   • Video-Workflows, Video-VAEs und Probleme beim letzten Exportschritt behandeln
   • Siehe ComfyUI-Videos erstellen

5. Per API automatisieren

   • API format, /prompt, node_errors und Queue-Verwaltung verwenden
   • Siehe ComfyUI API für automatisierte Bildserien

6. Modelle und VAEs auswählen

   • Checkpoints, VAEs, LoRAs und Loader-Konfigurationen vergleichen
   • Siehe Stable-Diffusion-Modelle auswählen