Deshalb reicht es nicht aus, den Kaufpreis einer GPU mit einem Stundentarif zu vergleichen. Das Ergebnis hängt von der Utilization, der Nutzungsdauer, den Kosten der gesamten Serverplattform und den tatsächlichen Kosten für die Ausführung von ML-Workloads ab.
Kauf, Dedicated GPU oder Cloud
Bei der Auswahl einer GPU-Infrastruktur vergleichen ML-Teams in der Regel drei grundlegende Optionen:
- Eigener GPU-Server. Er erfordert Anfangsinvestitionen, die Hardware bleibt jedoch im Besitz des Unternehmens. Neben den GPUs müssen CPU, RAM, Storage, Netzwerkkomponenten, Stromversorgung und die übrigen Komponenten der Plattform angeschafft werden.
- Dedicated GPU Server. Der komplette Server wird für einen bestimmten Zeitraum gemietet. Das Team erhält dedizierte physische Beschleuniger, ohne diese selbst kaufen zu müssen, bezahlt den Server jedoch unabhängig von der tatsächlichen Auslastung.
- Cloud GPU. Cloud-Ressourcen lassen sich in der Regel für kürzere Zeiträume bereitstellen und nach Abschluss einer Aufgabe wieder abschalten. Das ist bei variabler Last praktisch, bei dauerhafter Nutzung können die laufenden Kosten jedoch höher ausfallen.
Eigene und Dedicated GPUs eignen sich wirtschaftlich daher eher für stabile Lasten. Der wesentliche Vorteil der Cloud besteht dagegen darin, Ressourcen nicht dauerhaft bezahlen zu müssen, wenn sie nur zeitweise benötigt werden.
Die entscheidende Kennzahl ist die Utilization
Die Utilization zeigt, welchen Anteil der verfügbaren Zeit eine GPU tatsächlich vom Team genutzt wird.
Vereinfacht:
Utilization = genutzte GPU-Stunden / verfügbare GPU-Stunden × 100 %
Eine dauerhaft verfügbare GPU bietet ungefähr 730 Stunden pro Monat. Beanspruchen ML-Workloads davon 300 Stunden, beträgt die Utilization rund 41 %.
Bei einem eigenen Server bedeutet eine geringe Auslastung, dass sich die Investition auf weniger produktiv genutzte GPU-Stunden verteilt. Ein ähnliches Problem besteht bei der monatlichen Miete eines Dedicated GPU Servers: Der Server wird auch während Leerlaufzeiten bezahlt.
Die Cloud funktioniert anders. Wird eine Instanz nach Abschluss der jeweiligen Aufgabe abgeschaltet, kann das Unternehmen nur für den Zeitraum bezahlen, in dem die Ressourcen tatsächlich benötigt werden. Je weniger vorhersehbar die Last ist, desto größer ist daher der wirtschaftliche Vorteil dieses Modells.
Was eine eigene GPU tatsächlich kostet
In die Berechnung darf nicht nur der Preis des Beschleunigers einfließen. Entscheidend sind die Kosten des gesamten einsatzfähigen Systems.
Zum TCO können gehören:
- GPU und Serverplattform;
- CPU, RAM und NVMe Storage;
- Netzwerkausrüstung;
- Stromversorgung und Kühlung;
- Unterbringung im eigenen Serverraum oder per Colocation;
- Strom und Connectivity;
- Wartung und Reparaturen.
Bei Multi-GPU-Systemen sind zusätzlich die PCIe-Topologie und High-Speed-Verbindungen zwischen den Beschleunigern relevant. Die Kosten für vier GPUs entsprechen daher nicht einfach dem Preis eines einzelnen Beschleunigers multipliziert mit vier.
Eine vereinfachte Berechnung sieht so aus:
TCO own = Hardware + Unterbringung + Strom + Betrieb − Restwert
Die verschiedenen Optionen sollten über denselben Zeitraum verglichen werden, beispielsweise über 12, 24 oder 36 Monate.
Wie sich der Break-even-Point bestimmen lässt
Für Cloud GPUs lässt sich der grundlegende Break-even-Point mit folgender Formel abschätzen:
Break-even GPU hours = TCO des eigenen Systems / effektive Kosten einer gemieteten GPU-Stunde
Angenommen, der TCO eines eigenen Servers beträgt über drei Jahre 30.000 €, während eine vergleichbare gemietete Ressource durchschnittlich 3 € pro Stunde kostet.
Dann gilt:
30.000 € / 3 € = 10.000 GPU-Stunden
Nutzt das Team über drei Jahre deutlich mehr Rechenleistung als diese 10.000 GPU-Stunden, wird der Kauf wirtschaftlich interessanter. Liegt die Nutzung darunter, kann die Miete günstiger sein.
Eine solche Berechnung liefert jedoch nur einen ersten Richtwert. Storage, Network Traffic und andere kostenpflichtige Services können die Cloud-Kosten erhöhen. Bei einem eigenen Server müssen dagegen Wartungskosten und mögliche Ausfallzeiten berücksichtigt werden.
Besser die Kosten pro Workload als pro GPU-Stunde berechnen
Der Preis einer einzelnen Stunde eignet sich besonders schlecht für den Vergleich von Beschleunigern mit unterschiedlicher Performance.
Angenommen, GPU A kostet 2 € pro Stunde und benötigt 20 Stunden für einen Training Job. Die Gesamtkosten betragen 40 €. GPU B kostet 3 € pro Stunde, erledigt dieselbe Aufgabe jedoch in 10 Stunden. Damit kostet der Workload nur 30 €.
Für ML-Infrastruktur ist es deshalb sinnvoll, zusätzlich die Cost per Workload zu berechnen: beispielsweise die Kosten für das Training eines Modells, die Verarbeitung einer bestimmten Datenmenge oder die Ausführung einer festgelegten Anzahl von Inference Requests.
Dadurch lassen sich unterschiedliche GPU-Generationen vergleichen, ohne die Entscheidung ausschließlich anhand des Stundentarifs zu treffen.
Training und Inference erfordern unterschiedliche Ansätze
Training erzeugt häufig eine ungleichmäßige Last. GPUs werden während eines Experiments intensiv genutzt und können anschließend ungenutzt bleiben, während das Team die Ergebnisse analysiert oder Daten vorbereitet. In einem solchen Szenario ermöglicht die Cloud, Ressourcen nur für einzelne Jobs zu mieten.
Bei Production Inference ist die Last häufig stabiler. Wenn ein Modell rund um die Uhr Anfragen verarbeitet und für eine dauerhaft hohe GPU-Auslastung sorgt, erhalten ein eigener Server oder ein Dedicated Server einen wirtschaftlichen Vorteil.
Entscheidend ist jedoch nicht die Bezeichnung der Aufgabe, sondern das tatsächliche Nutzungsprofil. Auch Inference mit starken Schwankungen im Tagesverlauf kann von der Skalierbarkeit der Cloud profitieren, während kontinuierliches Training besser zur eigenen Infrastruktur passen kann.
Auch die technologische Alterung von GPUs beeinflusst die Amortisation
Die physische Lebensdauer einer GPU kann deutlich länger sein als der Zeitraum, in dem sie für ML-Workloads die optimale Lösung darstellt. Neue Modelle können mehr VRAM erfordern oder auf Beschleunigern der nächsten Generation wesentlich effizienter arbeiten.
Beim Kauf trägt der Eigentümer dieses Risiko. Benötigt das Team nach zwei Jahren eine andere Konfiguration, muss die vorhandene Hardware für weniger anspruchsvolle Aufgaben weiterverwendet, verkauft oder früher als geplant ersetzt werden.
Bei gemieteter Infrastruktur lässt sich einfacher auf eine andere GPU-Klasse wechseln, ohne eigene Hardware verkaufen zu müssen. Je schneller sich die Anforderungen der Projekte ändern, desto vorsichtiger sollte daher mit langen Amortisationszeiträumen für die Hardware gerechnet werden.
Wann GPUs kaufen und wann mieten?
Der Kauf wird zu einer attraktiven Option, wenn GPUs regelmäßig und intensiv genutzt werden, die Last über mehrere Jahre vorhersehbar ist und die aktuelle Plattform über ausreichende Reserven bei Performance und VRAM verfügt. Gleichzeitig muss das Unternehmen bereit sein, CAPEX zu tragen und die Hardware zu betreiben.
Die Miete eines Dedicated GPU Servers eignet sich für konstante Lasten, wenn das Team dedizierte physische Beschleuniger nutzen möchte, ohne in deren Anschaffung zu investieren. Der Nachteil: Der Server wird unabhängig von der tatsächlichen Auslastung bezahlt.
Cloud GPUs sind bei unregelmäßigen Training Jobs, Experimenten, temporären Projekten und einem zeitweisen Bedarf an einer großen Zahl von Beschleunigern sinnvoller. Die höheren Kosten pro GPU-Stunde können in solchen Fällen dadurch ausgeglichen werden, dass keine langfristigen Leerlaufzeiten bezahlt werden müssen.
Je stabiler die Last ist, desto interessanter werden damit eigene oder langfristig gemietete Infrastrukturen. Je stärker die Last schwankt, desto größer wird der wirtschaftliche Wert der Cloud.
Das Hybridmodell
Es ist nicht notwendig, für alle ML-Workloads dasselbe Infrastrukturmodell zu wählen.
Eine stabile Grundlast kann auf eigenen GPUs oder Dedicated GPU Servers ausgeführt werden, während die Cloud für Lastspitzen und die temporäre Erweiterung der Rechenressourcen genutzt wird.
So kann beispielsweise die permanente Inference auf dedizierter Infrastruktur laufen, während das Team für das Training eines neuen Modells vorübergehend zusätzliche GPUs mietet. Dadurch muss keine Hardware für eine maximale Last angeschafft werden, die nur wenige Male pro Jahr auftritt.
So berechnen Sie die Amortisation für Ihr ML-Team
Für einen praktischen Vergleich genügen einige Schritte:
- GPU-Stunden erfassen und die durchschnittliche Auslastung bestimmen.
- Konstante und periodische Last voneinander trennen.
- Den TCO eines eigenen Servers für den gewählten Zeitraum berechnen.
- Die Kosten derselben Workloads auf Dedicated GPUs und Cloud GPUs berechnen.
- Nicht nur GPU-Hours, sondern auch Cost per Workload vergleichen.
- Mehrere Utilization-Szenarien prüfen und die Wahrscheinlichkeit eines Hardwarewechsels berücksichtigen.
Als Ergebnis erhält das Team keinen universellen Break-even-Point, sondern einen Bereich. Ab einer bestimmten Zahl von GPU-Stunden wird der Kauf günstiger als die Cloud. Sinkt die Utilization, kann sich der wirtschaftliche Vorteil wieder zugunsten der Miete verschieben.
GPU kaufen oder mieten: Die Auslastung entscheidet
Der Kauf von GPUs amortisiert sich, wenn die Beschleuniger über einen längeren Zeitraum ausreichend intensiv genutzt werden und die Einsparungen gegenüber der Miete die Anschaffungs- und Betriebskosten übersteigen.
Die Cloud bietet einen anderen wirtschaftlichen Vorteil: Ressourcen, die nur zeitweise benötigt werden, müssen nicht dauerhaft vorgehalten werden. Dedicated GPUs nehmen eine Zwischenposition ein: dauerhaft verfügbare physische Ressourcen ohne anfängliche Investitionen in die Hardware.
Die Berechnung für ein ML-Team sollte daher entlang folgender Kette erfolgen: GPU-Hours → Utilization → Cost per Workload → TCO → Nutzungsdauer und Risiko der technologischen Alterung. Dieser Ansatz zeigt nicht nur, welche GPU am günstigsten ist, sondern welches Infrastrukturmodell wirtschaftlich am besten zur tatsächlichen Last passt.