ComfyUI auf dem Remote-Mac prüfen: Checkliste 2026

Die offizielle ComfyUI-Projektseite nennt für Apple Silicon die Chipgenerationen M1, M2, M3 und M4 als unterstützte Installationsbasis. Das ist jedoch nur der Startpunkt: Wenn Sie ComfyUI auf dem Remote-Mac abnehmen, prüfen Sie die Umgebung in dieser Reihenfolge: Basis-System, PyTorch, ComfyUI-Start, Modellpfade, ComfyUI Nodes, fester Workflow, Neustart und Remote-Sicherheit. Eine sichtbare Benutzeroberfläche allein reicht nicht aus. (github.com)

Symptom: ComfyUI öffnet sich, aber ein gemeinsamer Workflow findet Modelle nicht, Nodes fehlen oder die Umgebung funktioniert nach einem Neustart nicht mehr.
Schnellste Lösung: Arbeiten Sie mit einem festen Test-Workflow, sichern Sie Versions- und Startprotokolle und akzeptieren Sie die Übergabe erst, wenn derselbe Ablauf vor und nach dem Neustart erfolgreich läuft.

Zuletzt aktualisiert am 10.08.2026; die technischen Angaben wurden anhand der offiziellen ComfyUI-Dokumentation, des ComfyUI-Repositorys und der PyTorch-MPS-Dokumentation geprüft.

Für wen diese Abnahme-Checkliste gedacht ist

Diese Anleitung richtet sich an Sie, wenn Sie einen Remote-Mac für ComfyUI mieten oder eine bereits eingerichtete Umgebung übernehmen und Fehler unmittelbar bei der Übergabe erkennen möchten.

Sie ist außerdem für Teamadministratoren gedacht, die gemeinsame Arbeitsabläufe mit festen Nodes und reproduzierbaren Abhängigkeiten pflegen, sowie für Creator, die ComfyUI regelmäßig zwischen lokalen und entfernten Apple-Silicon-Systemen übertragen.

Die Abnahme beginnt vor dem ersten Login

Bevor Sie ein Terminal öffnen, müssen die Liefergrenzen klar sein. Viele spätere Fehler entstehen nicht durch ComfyUI selbst, sondern durch unvollständige Übergabeinformationen: Ein Modell wurde nicht mitgeliefert, ein gemeinsames Verzeichnis ist nur lesbar oder der Remote-Zugriff erlaubt zwar eine grafische Sitzung, aber keinen stabilen Terminalzugang.

Fordern Sie deshalb vor dem Test eine schriftliche Übergabe mit folgenden Punkten an:

• installierte macOS-Version;
• exakt angezeigte Chipbezeichnung und Architektur;
• verfügbarer Speicherplatz für Modelle, Zwischendateien und Ergebnisse;
• Benutzername und Rollen des verwendeten macOS-Kontos;
• verwendeter Remote-Zugang, etwa Bildschirmfreigabe, SSH oder eine browserbasierte Sitzung;
• Speicherort der ComfyUI-Installation;
• Speicherort von Checkpoints, VAE-Dateien, LoRAs und weiteren Modellen;
• Liste der vorgesehenen ComfyUI Nodes;
• ComfyUI-Version, Python-Version und PyTorch-Version;
• vereinbarte Arbeitsabläufe für die Abnahme;
• Zuständigkeit für Updates, Backups und spätere Fehlerbehebung.

Die Konfiguration darf nicht aus dem Namen des Chips abgeleitet werden. „Apple Silicon“ sagt noch nicht, wie viel Arbeitsspeicher frei ist, welche macOS-Version installiert wurde oder ob die verwendete PyTorch-Installation den MPS-Backend tatsächlich nutzen kann. Prüfen Sie die Werte auf dem System selbst und dokumentieren Sie sie als Übergabebeleg.

Ein zusätzlicher Prüfpunkt ist die Rechtevergabe. Ein Konto, das ComfyUI starten kann, muss nicht automatisch in jedes Modellverzeichnis schreiben dürfen. Umgekehrt ist ein weitreichendes Administratorkonto für ein gemeinsam genutztes Kreativsystem aus Sicht von Datenschutz und DSGVO nicht immer sinnvoll. Klären Sie, ob der Nutzer nur Modelle laden, auch Nodes installieren oder zusätzlich Systempakete aktualisieren darf.

Wenn Sie die Hardware oder den Mietzeitraum noch auswählen, sollten Sie zunächst die Anforderungen des Workflows notieren und erst danach die Bestellung konfigurieren. Die verfügbaren Angaben und den vorgesehenen Ablauf können Sie in der Konfigurationshilfe für Ihre Bestellung abgleichen.

Erste Prüfung: Apple Silicon, macOS und Remote-Zugriff

Melden Sie sich zunächst über den vorgesehenen Zugang an und prüfen Sie, ob der Zugriff auch ohne lokale Hilfe funktioniert. Für eine wiederholbare Umgebung reicht es nicht, dass ein Anbieter einmalig eine Sitzung geöffnet hat. Sie müssen den Prozess selbst nachvollziehen können.

Öffnen Sie das Terminal und erfassen Sie mindestens:

uname -m
sw_vers
system_profiler SPHardwareDataType
df -h
whoami

uname -m sollte die tatsächlich verwendete Architektur zeigen. Bei einem nativen Apple-Silicon-Prozess erwarten Sie in der Regel arm64; entscheidend ist aber die Ausgabe des Systems, nicht die Produktbezeichnung in einer E-Mail. sw_vers dokumentiert die macOS-Version. df -h zeigt, ob der für Modelle vorgesehene Speicherpfad tatsächlich nutzbaren freien Platz besitzt.

Prüfen Sie anschließend, ob Sie den ComfyUI-Prozess starten, stoppen und seine Logs lesen können. Bei einer Teamumgebung gehört auch dazu, dass Sie die vorgesehenen Verzeichnisse erreichen, ohne private Dateien anderer Nutzer einzusehen. Für einen laufenden Dienst sollten Sie außerdem klären, wie der Port geschützt wird und ob der Zugriff nur über eine gesicherte Verbindung erfolgt.

Die offizielle ComfyUI-Dokumentation beschreibt Apple-Silicon-Systeme mit M1 bis M4 als Installationsziel und verweist für die Beschleunigung auf PyTorch mit Metal-Unterstützung. Die Dokumentation liefert jedoch keine pauschale Garantie für jeden Custom Node. Deshalb muss die tatsächliche Umgebung geprüft werden.

Basis-Check mit Beleg und Fehleraktion

Zweiter Schritt: Python und PyTorch sauber nachweisen

Nach dem Systemcheck prüfen Sie die Laufzeitumgebung. Der häufigste Denkfehler besteht darin, ein Paket im globalen Python zu installieren und anschließend anzunehmen, ComfyUI verwende automatisch genau diese Version. Die ComfyUI-Dokumentation warnt ausdrücklich davor, Abhängigkeiten im falschen Python-Umfeld zu installieren. (docs.comfy.org)

Wechseln Sie in das ComfyUI-Verzeichnis und erfassen Sie:

which python
python --version
python -c "import torch; print(torch.__version__)"
python -c "import torch; print(torch.backends.mps.is_available())"
python -c "import torch; print(torch.backends.mps.is_built())"
git --version

Falls das System mehrere Python-Installationen enthält, sollten Sie zusätzlich den Pfad von python und pip vergleichen:

which pip
python -m pip --version

Verwenden Sie für Installationen möglichst python -m pip, damit eindeutig ist, welchem Python die Pakete zugeordnet werden. Bei einer isolierten virtuellen Umgebung sollte der aktive Pfad erkennbar sein. Wenn pip auf eine andere Python-Installation zeigt als der ComfyUI-Startbefehl, ist die Umgebung nicht abnahmefähig, selbst wenn der erste Start funktioniert.

PyTorch stellt für macOS das MPS-Backend bereit. Die offizielle Dokumentation unterscheidet dabei zwischen einem installierten PyTorch-Build mit MPS-Unterstützung und einem Gerät beziehungsweise Betriebssystem, auf dem MPS tatsächlich verfügbar ist. Als Beispiel nennt sie für die Verfügbarkeit eine MPS-fähige Umgebung und macOS 14.0 oder neuer. Prüfen Sie daher sowohl torch.backends.mps.is_built() als auch torch.backends.mps.is_available(), statt nur die PyTorch-Version abzulesen. (docs.pytorch.org)

Speichern Sie die Ausgabe in einer Datei:

{
  date
  uname -m
  sw_vers
  python --version
  python -m pip --version
  python -c "import torch; print(torch.__version__); print(torch.backends.mps.is_built()); print(torch.backends.mps.is_available())"
  git --version
} | tee abnahme-umgebung.txt

Eine funktionierende MPS-Abfrage beweist noch nicht, dass jeder Workflow auf dem Backend läuft. Einige Nodes oder Modellkomponenten können eigene Voraussetzungen haben. Genau deshalb folgt nach dem Basischeck ein echter ComfyUI-Lauf mit Modellen und Ausgabe.

Dritter Schritt: ComfyUI starten und den Startlog sichern

Starten Sie ComfyUI nicht nur über ein grafisches Symbol, sondern mindestens einmal aus dem Terminal. So sehen Sie Importfehler, fehlende Pakete und Warnungen, die in der Oberfläche nicht sichtbar sind.

Ein typischer manueller Start sieht so aus:

cd /Pfad/zu/ComfyUI
python main.py 2>&1 | tee startlog-abnahme.txt

Die offizielle Apple-Silicon-Anleitung des ComfyUI-Repositorys nennt python main.py als Startbefehl nach Installation von PyTorch, ComfyUI-Abhängigkeiten und den Modellverzeichnissen. Für Ihre Abnahme ist der wichtige Punkt nicht der konkrete Befehl, sondern der Nachweis, dass der verwendete Startweg dokumentiert und wiederholbar ist.

Prüfen Sie nach dem Start:

• Wird die Oberfläche ohne leere oder beschädigte Bereiche geladen?
• Gibt es im Terminal ImportError, ModuleNotFoundError oder Hinweise auf inkompatible Pakete?
• Werden die vorgesehenen nativen Nodes angezeigt?
• Lässt sich ein einfacher Testgraph ausführen?
• Wird eine Ausgabedatei im erwarteten Ordner erzeugt?
• Bleibt der Prozess während eines Durchlaufs stabil?

Führen Sie zusätzlich eine kurze Stop-and-Start-Prüfung aus. Beenden Sie ComfyUI kontrolliert, starten Sie es erneut und vergleichen Sie den zweiten Startlog mit dem ersten. Ein Fehler, der erst nach dem zweiten Start erscheint, ist für gemeinsam genutzte Umgebungen besonders relevant.

Vierter Schritt: Modellpfade, Schreibrechte und Neustartverhalten prüfen

Modelle sind keine Nebensache. Checkpoints, VAE-Dateien, LoRAs, ControlNets und Upscaler sind eigenständige Abhängigkeiten eines Workflows. Die offizielle Modelldokumentation beschreibt ComfyUI/models/ als üblichen Ablageort und weist darauf hin, dass unterschiedliche Modelle und Custom Nodes eigene Pfade oder Loader verwenden können. (docs.comfy.org)

Prüfen Sie mindestens diese Verzeichnisse, soweit sie im geplanten Workflow vorkommen:

ComfyUI/models/checkpoints
ComfyUI/models/vae
ComfyUI/models/loras
ComfyUI/models/controlnet
ComfyUI/models/upscale_models

Die Verzeichnisnamen müssen zur konkreten Installation und zum Workflow passen. Legen Sie keine zusätzlichen Ordner an, nur weil sie in einer allgemeinen Anleitung genannt werden. Entscheidend ist, ob der Loader im festen Test-Workflow die erwartete Datei sieht.

Für jeden benötigten Modelltyp prüfen Sie:

1. Ist der Pfad vorhanden?
2. Ist die Datei lesbar?
3. Wird sie im passenden Loader angezeigt?
4. Kann ComfyUI sie laden?
5. Kann der Prozess in den vorgesehenen Ausgabeordner schreiben?
6. Bleibt der Pfad nach einem Neustart erhalten?

Wenn mehrere ComfyUI-Instanzen dieselbe Modellbibliothek verwenden sollen, kann extra_model_paths.yaml eingesetzt werden. Die offizielle Dokumentation beschreibt diese Datei als Möglichkeit, zusätzliche Modellpfade zu registrieren und eine Modellbibliothek gemeinsam zu nutzen. Das ist praktisch, erhöht aber die Anforderungen an Dateirechte, Pfadstabilität und Datenschutz. (docs.comfy.org)

Hinweis aus der Praxis: Ein Modell, das vor dem Neustart im Dropdown erscheint, ist noch kein Beweis für eine stabile Konfiguration. Prüfen Sie, ob der Pfad aus einer festen Konfigurationsdatei kommt oder nur durch eine temporäre Sitzung, einen gemounteten Ordner oder einen manuellen Dateiscan verfügbar war.

Wie bleibt der Modellpfad nach einem Neustart erhalten?
Dokumentieren Sie den absoluten Pfad, prüfen Sie die verwendete Konfigurationsdatei und führen Sie den Loader-Test nach dem Neustart erneut aus. Bei einem externen oder gemeinsam genutzten Verzeichnis müssen Sie außerdem testen, ob der Mount oder die Netzwerkverbindung beim Start bereits verfügbar ist. Wenn der Pfad erst später eingebunden wird, kann ComfyUI beim ersten Start leer wirken, obwohl die Konfiguration grundsätzlich korrekt ist.

Fünfter Schritt: ComfyUI Nodes einzeln und reproduzierbar installieren

Installieren Sie nicht alle Nodes auf einmal. Dieser Punkt entscheidet häufig darüber, ob Sie einen Fehler in wenigen Minuten eingrenzen oder eine unklare, vermischte Python-Umgebung zurücksetzen müssen.

Die offiziellen Installationshinweise unterscheiden zwischen ComfyUI Manager, Git-Installation und ZIP-Download. Bei einer Git-Installation bleiben Versionsinformationen verfügbar; bei einem ZIP-Download fehlt diese Versionshistorie. Für eine gemeinsam verwaltete Umgebung ist deshalb ein Commit, Tag oder Release pro Node wertvoller als die bloße Aussage „aktuell installiert“. (docs.comfy.org)

Gehen Sie in dieser Reihenfolge vor:

1. Erstellen Sie eine Liste der Nodes, die der feste Workflow tatsächlich benötigt.
2. Prüfen Sie für jeden Node die README, unterstützte Plattformen, Python-Voraussetzungen und benötigten Modelle.
3. Installieren Sie eine kleine Gruppe funktional zusammengehöriger Nodes.
4. Speichern Sie Repository, Branch, Tag oder Commit.
5. Installieren Sie die Abhängigkeiten im ComfyUI-Python-Umfeld.
6. Starten Sie ComfyUI neu.
7. Führen Sie einen minimalen Test mit genau dieser Gruppe aus.
8. Sichern Sie den Startlog und die sichtbaren Node-Namen.
9. Erst danach installieren Sie die nächste Gruppe.

Die Installationsschritte für Custom Nodes bestehen grundsätzlich darin, den Code in ComfyUI/custom_nodes abzulegen und anschließend die erforderlichen Python-Abhängigkeiten zu installieren. Verwenden Sie dabei nicht versehentlich das System-Python, sondern das Python der ComfyUI-Umgebung.

Abhängigkeiten können sich gegenseitig überschreiben. Die offizielle Dokumentation führt als Beispiel einen Node mit einer festgelegten Version open_clip_torch==2.26.1 und einen anderen mit einer Mindestanforderung open_clip_torch>=2.29.0 an. Solche widersprüchlichen Vorgaben sind kein Apple-Silicon-spezifischer Fehler, werden in einer gemeinsam genutzten Umgebung aber schnell zum Betriebsproblem.

Was sollten Sie nach der Installation eines Custom Nodes prüfen?
Prüfen Sie zuerst, ob der Node ohne Importfehler registriert wird. Danach laden Sie einen Minimalgraphen, der seine Kernfunktion verwendet, und kontrollieren den Startlog auf Warnungen. Zusätzlich müssen Sie testen, ob ein Neustart die Registrierung erhält. Ein Node, der nur nach manueller Aktualisierung oder einem einmaligen Manager-Lauf sichtbar ist, ist noch nicht zuverlässig eingerichtet.

Sechster Schritt: Den festen ComfyUI-Workflow ausführen

Jetzt kommt die eigentliche Abnahme. Verwenden Sie einen Workflow, der mindestens diese Funktionen enthält:

• Laden eines Checkpoints;
• Laden eines VAE oder einer vorgesehenen Modellkomponente;
• optional Laden eines LoRA oder ControlNet, wenn der Teamprozess dies benötigt;
• Textkodierung;
• Sampling;
• Dekodierung;
• Speichern des Ergebnisses.

Der Workflow sollte als JSON exportiert und zusammen mit einer kurzen Abnahmeanweisung gespeichert werden. Dokumentieren Sie außerdem, welche Modelle ausgewählt werden, welche Eingabedatei verwendet wird und in welchem Ordner das Ergebnis erscheinen muss.

Ein praktischer Testfall sieht beispielsweise so aus: Ein Team erhält einen vorbereiteten Workflow für Produktbilder. Beim ersten Öffnen fehlen zwei Nodes. Statt wahllos weitere Erweiterungen zu installieren, vergleichen Sie die Node-Namen mit der Node-Liste, prüfen die Repository-Versionen und installieren nur die tatsächlich erforderlichen Komponenten. Danach führen Sie den Minimalgraphen aus. Erst wenn dieser funktioniert, testen Sie den vollständigen Produktbild-Workflow.

Was tun Sie, wenn der ComfyUI-Arbeitsablauf Nodes vermisst?
Unterscheiden Sie zunächst zwischen einem fehlenden nativen Node und einem fehlenden Custom Node. Ein nativer Node kann durch eine nicht passende ComfyUI-Version fehlen; ein Custom Node fehlt, wenn die Erweiterung nicht installiert oder nicht korrekt geladen wurde. Installieren Sie nicht automatisch mehrere ähnlich benannte Pakete, sondern vergleichen Sie Workflow-Metadaten, Node-Typ und die vom Autor dokumentierte Installation.

Wenn der Node installiert ist, aber weiterhin fehlt, prüfen Sie:

• wurde ComfyUI nach der Installation neu gestartet?
• wurde die Abhängigkeit im richtigen Python installiert?
• steht im Startlog ein Importfehler?
• verwendet der Workflow einen alten Node-Namen?
• benötigt die Erweiterung eine bestimmte ComfyUI-Frontend-Version?
• wurde der Node durch eine inkompatible Abhängigkeit deaktiviert?

Die offizielle Troubleshooting-Anleitung empfiehlt bei Custom-Node-Problemen eine schrittweise Eingrenzung und gegebenenfalls eine binäre Suche. Dabei aktivieren Sie nicht alle Nodes gleichzeitig, sondern testen Gruppen, bis die fehlerhafte Erweiterung eingegrenzt ist. (docs.comfy.org)

Siebter Schritt: Neustart, Zugriff und gemeinsame Nutzung abnehmen

Ein System ist erst dann übergabefähig, wenn es den kontrollierten Neustart übersteht. Beenden Sie ComfyUI, schließen Sie die Remote-Sitzung und starten Sie anschließend den vereinbarten Dienst oder das System erneut. Danach führen Sie denselben festen Workflow noch einmal aus.

Kontrollieren Sie dabei:

• Sind alle Modelle wieder sichtbar?
• Sind alle erwarteten ComfyUI Nodes registriert?
• Wird der Workflow ohne manuelle Nachinstallation geladen?
• Bleibt der Ausgabeordner beschreibbar?
• Sind die Startparameter unverändert?
• Ist der Remote-Port weiterhin geschützt?
• Sind API-Schlüssel oder Zugangsdaten nicht im Workflow oder Log gespeichert?
• Können Teammitglieder nur auf die vorgesehenen gemeinsamen Ordner zugreifen?

Für einen Remote-Mac ist die Zugriffssicherheit Teil der technischen Abnahme. Vermeiden Sie öffentlich erreichbare, ungeschützte Verwaltungsoberflächen. Verwenden Sie eine abgesicherte Zugangslösung, getrennte Konten und möglichst keine gemeinsam verwendeten Passwörter. Prüfen Sie außerdem, ob sensible Modell- oder Kundendaten in temporären Ordnern, Logs oder Vorschauen liegen bleiben.

Die allgemeine ComfyUI-Fehlerdokumentation weist darauf hin, dass sich die lokale Anmeldung anders verhalten kann als der Zugriff über LAN oder Remote-Verbindungen und dass für entfernten Zugriff zusätzliche Authentifizierung erforderlich sein kann. Das sollte vor der Übergabe getestet werden, nicht erst beim ersten Teammitglied außerhalb des lokalen Systems. (docs.comfy.org)

Die abnahmefähige Checkliste

• [ ] macOS-Version und Chiparchitektur direkt auf dem System dokumentiert
• [ ] Freier Speicher und tatsächliche Modellpfade geprüft
• [ ] Benutzerkonto, Gruppenrechte und gemeinsame Ordner kontrolliert
• [ ] Remote-Zugang selbstständig getestet
• [ ] Python- und pip-Pfad im ComfyUI-Umfeld erfasst
• [ ] PyTorch-Version, MPS-Build und MPS-Verfügbarkeit dokumentiert
• [ ] Git-Version und ComfyUI-Version gespeichert
• [ ] ComfyUI aus dem Terminal gestartet
• [ ] Startlog ohne ungeklärte Importfehler gesichert
• [ ] Checkpoints, VAE, LoRAs und weitere benötigte Modelle geladen
• [ ] Schreibtest im Ausgabeordner erfolgreich durchgeführt
• [ ] extra_model_paths.yaml geprüft, falls externe Pfade verwendet werden
• [ ] ComfyUI Nodes einzeln oder in kleinen Gruppen installiert
• [ ] Commit, Tag oder Release jedes Nodes dokumentiert
• [ ] Nach jeder Installationsgruppe ein Neustart durchgeführt
• [ ] Minimaltest pro Node-Gruppe erfolgreich
• [ ] Fester Workflow als JSON gespeichert
• [ ] Workflow mit Laden, Sampling und Speichern ausgeführt
• [ ] Ausgabe und Logs archiviert
• [ ] Neustart- und Wiederholungstest erfolgreich
• [ ] Ports, Zugangsdaten, API-Schlüssel und Dateirechte geprüft

Wann ein Remote-Mac nicht die passende Lösung ist

Ein Remote-Mac ist nicht automatisch die beste Wahl für jeden Betrieb. Wenn Sie dauerhaft sehr hohe Lasten fahren, spezielle lokale Geräte anschließen müssen oder eine GPU-Funktion benötigen, die auf Apple Silicon und MPS nicht vollständig unterstützt wird, kann ein eigener Arbeitsplatz oder eine andere Hardwareklasse geeigneter sein. Auch häufige Änderungen an Systempaketen können gegen eine gemietete, gemeinsam verwaltete Umgebung sprechen.

Für viele Teams liegen die Nachteile einer lokalen oder improvisierten Lösung jedoch an anderer Stelle: Hardware muss selbst beschafft und gewartet werden, der Zugriff von mehreren Personen ist schwerer zu standardisieren, und Modell- sowie Node-Versionen werden schnell unterschiedlich. Eine Cloud-Sitzung ohne feste Pfade kann zusätzlich bei Neustarts, Zugriffsschutz und Datenhaltung problematisch werden. Ein gemieteter Macstripe-Remote-Mac ist dann sinnvoll, wenn Sie eine zeitlich begrenzte ComfyUI-Umgebung benötigen, die vor dem Einsatz anhand von Modellpfaden, Nodes, Workflow und Neustart überprüft werden kann.

Wenn Sie die Übergabe vorbereiten, halten Sie deshalb nicht nur den gewünschten Chip fest. Übergeben Sie die vollständige Node-Liste, den Modellpfad, den festen Workflow, den benötigten Mietzeitraum und die Anforderungen an den Remote-Zugriff. Bei offenen Punkten können Sie die technischen Hinweise im Hilfezentrum prüfen oder die konkrete Umgebung über die Kontaktseite von Macstripe abstimmen. Entscheidend ist, dass Sie die Abnahme mit einem reproduzierbaren Test beenden: derselbe Workflow, dieselben Dateien und ein erfolgreicher Lauf nach dem Neustart.

Weiterführende Lektüre

• Remote-Mac-Bereitstellung: Pfade, Dauerbetrieb und systematische Fehlerprüfung
• Unified Memory auf Apple Silicon: Speicherplanung für lokale KI-Workloads