Wie ich Stable Diffusion mit ComfyUI auf AWS ausführe, was es kostet und wie es sich in Benchmarks schlägt

Wenn Sie die neuesten Stable Diffusion-Modelle von SDXL bis Stable Video mit ComfyUI ausführen möchten, benötigen Sie die neueste Version von ComfyUI, leistungsstarke GPUs und schnelle Laufwerke. Wenn ich für Bilder SDXL verwende, möchte ich auch nicht, dass die Generierung Minuten dauert. Ich habe eine Weile lang meinen M1 Pro MacBook mit DiffusionBee und ComfyUI genutzt. Bis zu dem Punkt, an dem mein M1 Pro ständig die Kühlerlüfter laufen ließ – etwas, das zuvor nie vorkam, selbst wenn ich anspruchsvolle Anwendungen ausführte.

Auf meinem M1 MacBook dauerte es etwa 60 bis 180 Sekunden, um ein großes 1280×720 Pixel Bild mit den Juggernaut XL- oder RealVisXL-Modellen zu generieren. Das wurde aus verschiedenen Gründen zu einem Problem. Erstens machte ich mir große Sorgen um die Lebensdauer der Mac-SSD, und zweitens blockierte die Generierung einfach den Mac, während ich ihn für andere Dinge brauchte. Ich konnte es nicht mehr ertragen. Das Einzige, was mich davon abhielt, auf AWS zu deployen, waren die potenziellen Kosten von 735 $ pro Monat für eine G5-Instanz (g5.xlarge) (Spoiler: Ich betreibe sie für nur 65 $ pro Monat). Ich hatte auch keine Ahnung, wie schnell die g5.xlarge mit RealVisXL4.0 Lightning sein würde. Die einzige Möglichkeit war, es selbst herauszufinden.

Architektur auf AWS

Wenn Sie meine Artikel regelmäßig verfolgen, wissen Sie, dass ich in diesem Jahr für meine 3. Rezertifizierung als AWS Solutions Architect Professional fällig bin. Ein Deployment ohne CloudFormation kommt für mich einfach nicht in Frage.

Mein ComfyUI-Deployment auf AWS (Wesentliche VPC-Ressourcen aus Gründen der Übersichtlichkeit weggelassen)

Das CloudFormation-Template und das Deployment erlauben es mir, den gesamten Stack zu zerstören, sollten die Kosten oder die Leistung außer Kontrolle geraten. Das Deployment selbst dauert etwa 10-15 Minuten, und die Löschung des gesamten Stacks etwa 5 Minuten. Cognito und das SSL-Zertifikat sind ebenfalls kostenlos, daher stört es mich nicht, wenn sie vorhanden sind. Die Löschung erfolgt mit einem einzigen Klick, was für meinen Anwendungsfall akzeptabel ist, da es sich nicht um einen CloudFormation-Stack handelt.

Deployment mit CloudFormation

Ich habe das folgende Template geschrieben, um die Instanz in us-east-1 zu deployen, da das die günstigste Region war, in der ich sie betreiben konnte. AWS bietet einen Beispiel-Stack namens „Cost Effective AWS Deployment Of ComfyUI“ an, den ich als Inspiration genommen habe. Ich entschied mich jedoch für eine EC2-Instanz statt Container, da ich mehr Kontrolle über die Maschine und mehr Persistenz wollte. Das AWS-Beispiel war auch ein wenig zu professionell für meinen einfachen Aufbau, der nur meinen persönlichen Anforderungen dienen soll.

AWSTemplateFormatVersion: '2010-09-09'
Description: ComfyUI worker instance
Parameters:
    AvailabilityZone:
        Description: Availability Zone
        Type: AWS::EC2::AvailabilityZone::Name
        Default: us-east-1f
        ConstraintDescription: must be a valid Availability Zone.
    BackupAvailabilityZone:
        Description: Backup Availability Zone
        Type: AWS::EC2::AvailabilityZone::Name
        Default: us-east-1a
        ConstraintDescription: must be a valid Availability Zone.
    KeyPairName:
        Description: Name of an existing EC2 KeyPair to enable SSH access to the instance
        Type: AWS::EC2::KeyPair::KeyName
        Default: ComfyUIWorkerKey
        ConstraintDescription: must be the name of an existing EC2 KeyPair.
    InstanceTypeName:
        Description: EC2 instance type name
        Type: String
        Default: g5.xlarge
    AmiImageId:
        Description: AMI image ID
        Type: String
        # USE THE LATEST YOU CAN FIND IN THE AMI CATALOG IN EC2 !!!
        # Deep Learning OSS Nvidia Driver AMI GPU PyTorch 2.2.0
        Default: ami-02e407fb981a2b5e3
    # The snapshot ID of the EBS volume for the models
    # !!! Uncomment if you want to deploy with a snapshot !!!
    # ModelVolumeSnapshotId:
    #    Description: The snapshot ID of the EBS volume for the models
    #    Type: String
    #    Default: snap-03ac8a7b13931a185
    IP1:
        Description: The first IP address for SSH and port 8188 access
        Type: String
        Default: "127.0.0.1"
    IP2:
        Description: The second IP address for SSH and port 8188 access
        Type: String
        Default: "127.0.0.1"
    LoadBalancerCertificateArn:
        Description: The ARN of the SSL certificate for the load balancer
        Type: String
        Default: arn:aws:acm:us-east-1:1234:certificate/abcdefg
    UserPoolArn:
        Description: The ARN of the Cognito User Pool
        Type: String
        Default: arn:aws:cognito-idp:us-east-1:1234:userpool/us-east-1_abcdefg
    UserPoolClientId:
        Description: The client ID of the Cognito User Pool
        Type: String
        Default: abcdefg
    UserPoolDomain:
        Description: The domain of the Cognito User Pool
        Type: String
        Default: auth.example.com
Resources:
    ComfyUIWorkerVpc:
        Type: AWS::EC2::VPC
        Properties:
            CidrBlock: 10.42.0.0/16
            EnableDnsSupport: true
            EnableDnsHostnames: true
            Tags:
            - Key: Name
              Value: ComfyUIWorkerVpc
... (Der Rest des CloudFormation-Templates wurde der Kürze halber ausgelassen) ...

Vor dem Deployment müssen Sie einen Cognito-Benutzerpool mit App (inklusive App-Secret) und das Zertifikat für den Load Balancer erstellen, über den Sie auf ComfyUI zugreifen möchten. Ich habe mir in Cognito einen einzelnen Benutzer angelegt, um mit diesen Anmeldedaten auf meine ComfyUI-Instanz zuzugreifen.

AWS Cognito Authentifizierung, ausgelöst durch den Load Balancer, um den Zugriff auf ComfyUI zu ermöglichen

Die Security Group für meine Instanz erlaubt außerdem SSH und TCP 8188 (der Port, auf dem ComfyUI läuft) von beiden meiner IP-Adressen. Ich habe Dual-WAN, daher sind es für mich zwei IP-Adressen. Der SSH-Port ist erforderlich, um ComfyUI auf der Maschine zu installieren. Sie werden auch bemerken, dass die Maschine neben dem System-Volume, das die AMI mitbringt, ein zweites Volume angeschlossen hat. Ich mounte das Volume „/dev/sda1“ unter „/opt/StableDiffusion“, damit ich meine ComfyUI-Installation, die Modelle und alles andere auf diesem Laufwerk behalten kann, wann immer ich ein neueres Image verwenden möchte. AWS veröffentlicht regelmäßig vorkonfigurierte Deep Learning-Maschinenimages (abgekürzt AMI). Ich kann einfach auf die neueste Version aktualisieren, ohne die Transferkosten für das erneute Herunterladen der Modelle alle paar Wochen zu haben, wenn AWS die Deep Learning-AMIs aktualisiert.

ComfyUIWorkerInstance:
        Type: AWS::EC2::Instance
        Properties:
            InstanceType: !Ref InstanceTypeName
            ImageId: !Ref AmiImageId
            KeyName: !Ref KeyPairName
            BlockDeviceMappings:
            - DeviceName: /dev/sda1
              Ebs:
                VolumeType: gp3
                VolumeSize: 256
                # Uncomment if you want to deploy with a snapshot!
                # SnapshotId: !Ref ModelVolumeSnapshotId
            NetworkInterfaces:
            - AssociatePublicIpAddress: true
              DeviceIndex: 0
              SubnetId: !Ref ComfyUIWorkerSubnet
              GroupSet:
              - !GetAtt ComfyUIWorkerSecurityGroup.GroupId
            Tags:
            - Key: Name
              Value: ComfyUI

Bei nachfolgenden CloudFormation-Aktualisierungen mache ich das mit dem angehängten Snapshot. Bevor ich Upgrades durchführe, die den Austausch der Instanz erfordern, erstelle ich einen Snapshot meines Volumes. Ich könnte das Volume auch löschungsgeschützt lassen und wiederverwenden. Darüber habe ich mir aber noch keine endgültigen Gedanken gemacht.

ComfyUI als Daemon ausführen

Da ich die Instanz immer anhalte, wenn ich sie nicht nutze, um Gebühren zu vermeiden, möchte ich nicht immer ComfyUI selbst starten, wenn die Instanz neu gestartet wurde. Aus diesem Grund habe ich ComfyUI als systemd-Service (auch Daemon genannt) installiert.

[Unit]
Description=ComfyUI Service  
After=network.target

[Service]
Type=simple
User=ec2-user
WorkingDirectory=/opt/StableDiffusion/ComfyUI
ExecStart=/bin/bash -c 'source activate pytorch; python3 main.py --listen --highvram'
Restart=always

[Install]
WantedBy=multi-user.target

Wenn man die obige Datei als /etc/systemd/system/comfyui.service auf der Instanz speichert und „sudo systemctl enable comfyui“ ausführt, wird sie als Service gestartet, wann immer die Instanz bootet. Ich kann den Service auch mit „sudo service comfyui status“ etc. überprüfen. Der „listen“-Parameter für ComfyUI weist es an, auf allen IP-Adressen zu lauschen.

Performance-Benchmark im Vergleich zum Mac

Die g5.xlarge-Instanz verfügt über 24 GB NVRAM auf einer NVIDIA A10G zusammen mit einem 4-Kern AMD EPYC 7R32 (@ 3,3 GHz) und 16 GB RAM. Abgesehen von der NVIDIA A10G ist die Konfiguration ziemlich ähnlich wie bei meinem Mac M1 Pro.

Ausgabe von „watch -n 1 nvidia-smi“ – Ich habe den VRAM selbst im „highvram“-Modus von ComfyUI nie ausgeschöpft

Ich erwartete, dass die G5-Instanz bessere Leistung als mein Mac hat, und angesichts der Benchmarks, die ich zuvor gesehen hatte, erwartete ich eine gute Verbesserung. Da sich bei mir eine gewisse Frustration angesammelt hatte wegen der Wartezeit, die der Mac für die Generierung benötigte, war ich begeistert, als ich die ersten Generierungen mit der A10G auf der G5-Instanz laufen ließ.

Performance-Benchmarks berechnet mit voll geladenen Modellen (Workflow-Neustart)

Meine Benchmarks sind alles andere als wissenschaftlich und spiegeln nur einige der Standard-Workflows wider, die ich normalerweise ausführe. Ich versioniere sie in einem Github-Repository, und ich empfehle Ihnen dringend, dasselbe zu tun. Mit EpicRealismXL und einem LCM LoRA verbessert sich die Generierung erheblich, aber ich war wirklich begeistert, als die G5-Instanz nur etwa 700 ms brauchte, um ein neues Bild zu generieren. Für meinen Video2Video-Workflow habe ich das LCM LoRA nicht verwendet, da ich die Qualität von RealVisXL mit einer relativ großen Anzahl von 40 Zyklen bevorzuge.

Sehr langsames Laden von Modellen mit Volumes aus Snapshots

Als ich die Instanz auf die neueste AWS Deep Learning AMI aktualisierte, um von Python 3.9 auf Python 3.10 umzusteigen, erlebte ich einen brutalen Leistungsabfall mit dem gp3-SSD-Volume, das ich aus meinem Snapshot erstellt hatte. Dieses Problem trat auf, weil das neu erstellte Volume nicht initialisiert war. Das Symptom dafür, dass das gp3-Volume nicht initialisiert war, war, dass ComfyUI etwa 6-20 Minuten brauchte, um ein Modell wie JuggernautXL zu laden.

#!/bin/bash
# Initialisiert das EBS-Volume, wenn die Instanz mit einem Snapshot gestartet wird
sudo fio --filename=/dev/sda1 --rw=read --bs=1M --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize

Nach der Ausführung des obigen Scripts (von AWS bereitgestellt; siehe „Initialize Amazon EBS volumes„) durch Lesen von 1MB-Blöcken war die Leistung wieder auf hohem Niveau und Modelle würden innerhalb weniger Sekunden (ca. 10-20 Sekunden) geladen. Das Initialisierungsskript von AWS dauerte etwa 1h 20m, bis es auf dem 256 GB großen gp3-Volume abgeschlossen war. Das ist eine ziemlich lange Zeit und ich werde in Zukunft möglicherweise darauf verzichten, Snapshots zu verwenden, und stattdessen das Volume selbst behalten. Der Snapshot ist jedoch hilfreich, sollte das Volume ausfallen.

Modelle mit 2,5 Gbit/s von HuggingFace herunterladen

Während ich mit meinen 800 Mbit/s zu Hause am oberen Ende der Internetbandbreite liege, ist das nichts im Vergleich zu AWS‘ massiver Konnektivität. Die us-east-1-Region befindet sich in einer Region namens „Data Center Alley“ (aka „Dulles Technology Corridor“) in Nord-Virginia, wo viele der Rechenzentren in Nordamerika angesiedelt sind. Diese Region bietet eine der schnellsten Übertragungsraten, da viele andere Dienste (wie HuggingFace oder Civitai) in derselben Region oder in der Nähe angesiedelt sind. HuggingFace verteilt Modelle über AWS CloudFront, was bedeutet, dass der Download von Modellen zwischen HuggingFace und meiner Instanz tatsächlich innerhalb der AWS-Rechenzentren selbst stattfindet.

Download des SVD 1.1 Modells von HuggingFace mit 305 MB/s (2,5 Gbit/s)

Angesichts des Datenübertragungsvolumens in „Data Center Alley“ sind auch die Transfers von Civitai recht schnell, da sie ihre Modelle mit Cloudflare verteilen. Die Menge an Maschinen und Systemen in Nord-Virginia stellt sicher, dass sowohl CloudFront- als auch Cloudflare-POPs die gängigsten Modelle gecacht haben. Das Herunterladen eines 8-GB-Modells dauert jetzt nur noch ein paar Sekunden.

Kostenanalyse

Der Betrieb kostet mich etwa 1,20 $ pro Stunde mit allen Ressourcen, Modell-Downloads, Upgrades und all meinen anderen Anforderungen. Wenn ich die Instanz 24/7 laufen lassen würde, würde es mich sagenhafte 864 $ pro Monat kosten. Ich starte die Instanz jedoch nur, wenn ich sie wirklich brauche, und das sind etwa 4-5 Stunden an einem Tag, an dem ich sie intensiv nutze. Meine wöchentliche Nutzung liegt bei ca. 16 Stunden und meine Kostenschätzung beträgt ca. 65 $ pro Monat.

Kostenanalyse der ersten Betriebstage (mit AWS Cost Explorer)

Das Erstellen von Snapshots und Volumes aus Snapshots wird mit ca. 0,50 $ für meine Nutzung zu Buche schlagen, und das Herumprobieren mit Instanzen ist das Gleiche. Ein Tag intensiver Nutzung, Konfiguration, Setup, Modell-Downloads etc. liegt immer noch im Dollarbereich und ist auf einem Budget machbar. Ich habe mir eine Obergrenze von 100 $ pro Monat gesetzt und achte auch darauf, den Setup-Aufwand gering zu halten, um die Kosten niedrig zu halten. Dazu gehört auch die Löschung von Snapshots, die ich nicht mehr benötige. Beachten Sie, dass auch für die gp3-EBS-Volumes Gebühren anfallen, selbst wenn die Instanz angehalten ist. Da die Instanz selbst die höchsten Kosten verursacht, ist das Herunterfahren der Instanz, wenn sie nicht mehr benötigt wird, der entscheidendste Faktor für die Kosteneinsparung.

So verwalte ich die Instanzkosten

Es gibt 3 Möglichkeiten, wie ich die Instanz starte und stoppe. Wenn ich sowieso im EC2-Dashboard bin, aus Wartungsgründen, kann ich sie dort einfach starten und stoppen. Wenn ich unterwegs bin oder sie remote mit Cognito von einer anderen Maschine aus nutze, verwende ich einfach die AWS Console iPhone-App, um die Instanz zu starten und zu stoppen. Auf meinem Mac habe ich auch ein Skript, um sie zu starten und zu stoppen.

# Zeigt den Status der Instanz an
aws ec2 describe-instances --instance-ids i-abc123 --query 'Reservations[*].Instances[*].[InstanceId,State.Name]'  --region us-east-1
# Instanz starten
aws ec2 start-instances --instance-ids i-abc123 --region us-east-1  
# Instanz stoppen
aws ec2 stop-instances --instance-ids i-abc123 --region us-east-1

Es ist ein bisschen wie „Habe ich den Herd ausgemacht?“, wenn man das Haus verlässt oder sie nicht benutzt. Im Allgemeinen nutze ich die Maschine für 2-4-stündige Sitzungen zum Generieren von Bildern oder wenn ich Artikel schreibe. Ich nehme mir Zeit dafür und schalte sie aus, wenn ich weiß, dass ich sie mindestens die nächsten 20-30 Minuten nicht brauchen werde.

Kostenkontrolle mit Prognosen

Der wichtige Teil, um die Kosten im Griff zu behalten, ist das Setzen von Abrechnungswarnungen in der Konsole, regelmäßiges Überprüfen des Verbrauchs über die Abrechnungskonsole oder innerhalb der AWS-Console-App. Wenn Sie neu bei AWS sind, stellen Sie auch sicher, dass Sie niemals den Root-Benutzer verwenden, sondern Ihren eigenen IAM-Benutzer als Admin haben und alle Benutzer MFA erzwingen, wenn sie auf Ihr AWS-Konto zugreifen.

AWS-Rechner zur Schätzung der Kosten basierend auf der wöchentlichen Nutzung on Demand

Ich empfehle jedem dringend, den AWS-Rechner zu verwenden, um die möglichen Kosten für den Betrieb der Instanz on Demand in Ihrer gewünschten Region mit Ihrem gewünschten Verbrauch zu berechnen. Der Rechner ist extrem gut und meine Ergebnisse daraus haben sich als sehr präzise im Vergleich zu dem erwiesen, was ich letztendlich hatte. Aber er ist nur so gut wie die Daten, die Sie ihm füttern. Stellen Sie sicher, dass Sie On-Demand auswählen, den korrekten Instanztyp und auch die Größe der Volumes und Snapshots angeben.

Fazit: ComfyUI im Beast-Modus

ComfyUI auf einer g5.xlarge in us-east-1 auszuführen, ist wahrscheinlich der „Beast-Modus“ für jede persönliche Nutzung. Die Leistung ist für mich atemberaubend und die Kosten sind absolut in Ordnung, wenn man eine strenge Kostenkontrolle ausübt und vorsichtig mit potenziellen Kosten umgeht. Es ist unerlässlich, alles in einem CloudFormation-Stack zu haben, um die eingesetzten Ressourcen unter Kontrolle zu halten. Ein Deployment in der Konsole wäre für mich absolut tabu, da ich die Kontrolle darüber schnell verlieren würde.

Ausführung von AnimateDiff Video2Video in ca. 5-7 Minuten für ein 6-Sekunden-Video in 720×1280

Alles in allem war das Deployment in AWS für mich die absolut richtige Entscheidung. Die Vorteile gegenüber dem lokalen Betrieb zu Hause überwiegen für mich die Nachteile. Hier ist meine Liste der Pros und Kontras des Betriebs von ComfyUI mit meinen Workflows auf AWS im Vergleich zum Betrieb auf meinem Mac zu Hause.

Pro

• Ich habe meinen Mac vor Ressourcenabbau und möglicher Beschädigung bewahrt
• Schneller, flexibler und zuverlässiger als mein lokaler Betrieb
• Möglichkeiten zum Verwerfen und Wiederherstellen, wenn ich mein ComfyUI ruiniere
• Option, sofort auf die neuesten NVIDIA-Chips umzusteigen

Contra

• Wenn man nicht vorsichtig ist, steigen die Kosten über 100 $ pro Monat
• Beschränkt auf Systeme, Treiber und GPUs, die AWS anbietet
• Nicht so einfach für Anfänger, viele potenzielle Risiken
• Nutzung unterliegt den AWS-Richtlinien – z.B. AI- und Fair-Use-Richtlinien

Wenn Sie ComfyUI mit dem beschriebenen oder einem ähnlichen Setup betreiben möchten, empfehle ich Ihnen dringend, sorgfältig einen Plan auszuarbeiten. Wenn Sie keine Erfahrung mit AWS oder keine AWS-Zertifizierung haben, müssen Sie äußerst vorsichtig sein, da die Kosten mit großen Instanzen wie den G5-Typen schnell steigen können. Es ist absolut wichtig zu verstehen, wie AWS EC2 funktioniert und was ComfyUI benötigt. Ich würde dieses Setup wahrscheinlich nicht für Anfänger oder Personen mit geringer praktischer Erfahrung mit AWS empfehlen.

Ihre eigene Infrastruktur für ComfyUI-Workflows in der Cloud aufbauen

Für Anfänger, Personen mit geringen AWS-Kenntnissen oder unzureichender Zeit für das Management des Deployments ist es wahrscheinlich besser, ein verwaltetes Angebot von Unternehmen in Betracht zu ziehen, die ComfyUI für Sie betreiben. Wenn Ihnen das Setup jedoch gefällt, empfehle ich jedem dringend, zu lernen, wie AWS funktioniert, zu verstehen, wie ComfyUI funktioniert (nicht einfach nur Tutorials zu folgen) und Ihre eigene KI-Infrastruktur auf AWS aufzubauen.