GPU-Cluster · Sizing, Aufbau, Abnahme, Betrieb
NVIDIA GPU-Cluster planen, aufbauen und betreiben
Sie entscheiden, was der Cluster können muss und wo er stehen soll. Wir dimensionieren, bauen die Kubernetes-Plattform, weisen die Leistung auf Ihrer Hardware nach und betreiben sie auf Wunsch rund um die Uhr.
- NVIDIA-GPUs, Kubernetes mit GPU Operator
- Abnahme mit Ihrem Testplan
- Betrieb auf Wunsch rund um die Uhr (24/7)
01Planung vor Bestellung
Warum Fehler bei GPU-Clustern erst nach der Lieferung auffallen
Ein GPU-Cluster ist keine größere Variante eines Serverclusters. Drei Eigenschaften machen Planungsfehler teuer:
- Speicher begrenzt, was läuft. Ein Modell muss samt Zwischenspeichern in den GPU-Speicher passen; fehlt er, hilft mehr Rechenleistung nicht.
- Kommunikation begrenzt die Skalierung. Sobald ein Workload mehrere GPUs oder Server nutzt, bestimmen Interconnect und Netzwerk, ob zusätzliche GPUs Leistung bringen oder nur warten.
- Die Hardware ist teuer und hat Lieferzeiten. Eine falsche Beschaffung lässt sich selten korrigieren; die Planung muss vor der Bestellung stehen.
02Standort
Eigenes Rechenzentrum oder europäische Cloud: Wo der Cluster stehen soll
Die Architektur ist an jedem Standort dieselbe: GPU-Knoten, Kubernetes mit GPU Operator, Serving, Beobachtbarkeit, Zugriffskontrolle (die Schichten im Überblick auf der Seite GPU- und KI-Infrastruktur). Unterschiede liegen im Standort.
| Kriterium | Eigenes Rechenzentrum / Colocation | Europäische Cloud-Infrastruktur |
|---|---|---|
| Datenkontrolle | maximal, physischer Zugriff bei Ihnen | vertraglich und technisch zu sichern; Anbieter- und Vertragsbedingungen prüfen |
| Verfügbarkeit der GPUs | von Lieferzeiten der Hardware abhängig | abhängig von Kapazität des Anbieters, kurzfristig oft schneller |
| Kostenstruktur | Investition plus Betrieb; wirtschaftlich bei dauerhaft hoher Auslastung | laufende Kosten, flexibel bei schwankender oder noch unklarer Last |
| Netzwerk-Interconnect | frei wählbar (z. B. RDMA-fähig) | durch Angebot des Anbieters begrenzt; vorab klären |
| Betriebsaufwand | Strom, Kühlung, Hardware-Tausch bei Ihnen oder Dienstleister | Hardware-Betrieb beim Anbieter, Plattformbetrieb bei Ihnen oder uns |
| Air-Gap möglich | ja | nur mit entsprechendem Angebot, meist eingeschränkt |
Die Tabelle enthält keine Messwerte und keine Preise. Sie zeigt die Kriterien, anhand derer wir die Entscheidung mit Ihnen treffen. Zur Einordnung des Cloud-Teils siehe Souveräne Cloud, zur Virtualisierungsbasis Proxmox.
03
Beispielarchitektur: vom GPU-Server bis zum Gateway
GPU-Server mit NVLink, getrenntes Compute- und Management/Storage-Netz, Storage-Cluster, Kubernetes mit GPU Operator und Zugang über ein Gateway mit Identity.
04Sizing
Was wir für ein belastbares GPU-Sizing von Ihnen brauchen
Offene Eingaben werden im Assessment als Annahmen dokumentiert, nicht stillschweigend gefüllt. Wie sich Modellgröße in GPU-Speicher übersetzt, zeigt das Rechenbeispiel bei den privaten LLMs.
GPU-Klasse. Typische Datenzentrums-GPUs unterscheiden sich in Speicher und Anbindung: Laut NVIDIA hat die H100 80 GB (SXM) bzw. 94 GB (NVL), die A100 bis zu 80 GB und die L40S 48 GB GDDR6 ohne NVLink. Welche Klasse passt, entscheidet der Workload.
- Workload-Profil: Inference, Fine-Tuning, Training oder Mischbetrieb, Modellgrößen, gewünschte Parallelität
- Datenklassen und Standortvorgaben, auch ein möglicher Air-Gap-Bedarf
- Stand der Infrastruktur: Rechenzentrum, Strom- und Kühlreserven, Netzwerk, Kubernetes und Identity
- Betriebsmodell nach der Übergabe
05Netzwerk und Storage
Wo ein GPU-Cluster seine Leistung verliert oder hält
-
Im Server: NVLink
Innerhalb eines Servers übernimmt NVLink die GPU-zu-GPU-Kommunikation, sofern die GPU es unterstützt.
-
Zwischen Servern: RDMA
Je nach Workload kommen RDMA-fähige Netze (InfiniBand oder RoCE) in Frage. Die NVIDIA-Dokumentation beschreibt, wie GPUDirect RDMA mit dem GPU Operator und dem Network Operator zusammenspielt.
-
Storage
Durchsatz für Modellgewichte und Datensätze, Checkpoints und Zugriffstrennung.
06Projektablauf
Vom Anforderungsdokument zur unterschriebenen Abnahme
Fünf Schritte, jeder mit einem greifbaren Ergebnis.
- 01
Assessment
Workloads, Daten, StandortErgebnis ist ein Anforderungsdokument mit dokumentierten Annahmen.
- 02
Zielarchitektur und Sizing
Hardware und NetzwerkHardware- und Netzwerkvorschlag mit Begründung und Alternativen.
- 03
Aufbau oder Bereitstellung
Plattform als CodeBetriebssystem-Basis, Kubernetes, NVIDIA GPU Operator (Treiber, Container Toolkit, Device Plugin, DCGM), Netzwerk-Operatoren und GPU-Scheduling, alles als Infrastructure as Code nachvollziehbar, etwa mit OpenTofu, und integriert in Identity, Monitoring und Backup. Die Kubernetes-Schicht entspricht unserer Kubernetes-Beratung.
- 04
Abnahme
Ihr Testplan, Ihre MesswerteFunktions- und Leistungstests auf Ihrer Hardware mit einem vorab vereinbarten Testplan: GPU-Erkennung und -Gesundheit, Interconnect-Messungen zwischen Knoten, Serving- oder Trainingsläufe mit Ihren Modellen. Die Messwerte gehören Ihnen; SKAFFON veröffentlicht hier keine Benchmark-Zahlen, weil ein Cluster-Ergebnis nur für genau diese Hardware und Konfiguration gilt. Abweichungen werden behoben.
- 05
Übergabe oder Betrieb
Runbooks, Schulung oder SKAFFONRunbooks, Schulung Ihres Teams oder Betrieb durch SKAFFON.
07Lieferumfang
Was bei der Übergabe auf Ihrem Tisch liegt
Wie stark Zahl und Art der Workloads, Clustergröße, RDMA-Bedarf, Zahl der Umgebungen und das gewünschte Support-Fenster den Aufwand treiben, klärt das Assessment; daraus entsteht ein Angebot mit klarem Umfang und Preismodell.
- Zielarchitektur mit Sizing-Begründung
- Infrastructure-as-Code-Repository
- Abnahmeprotokoll mit Ihren Messwerten
- Betriebs- und Notfall-Runbooks
- Monitoring-Dashboards
08Betrieb
Wer nachts reagiert, wenn eine GPU ausfällt
Überwachung mit DCGM-Exporter und Prometheus, Update- und Patchprozess für Treiber und Kubernetes, Kapazitätsberichte, Runbooks. Betrieb und Support bieten wir rund um die Uhr (24/7) an; die Reaktionszeiten je Prioritätsstufe stehen im Servicelevel-Modell unter Managed Services. Den Umfang eines GPU-Betriebs legen wir im Vertrag fest.
09
GPU-Sharing zwischen Mandanten ist eine Risikoentscheidung
GPU-Knoten laufen im selben Sicherheitsmodell wie der Rest Ihrer Plattform: Mandantentrennung über Namespaces und Netzwerkrichtlinien, Zugriff über Ihre Identity-Lösung, Secrets außerhalb von Images, Protokollierung.
GPU-Sharing zwischen Mandanten (zum Beispiel über MIG, das die A100 laut NVIDIA bis zu sieben Instanzen unterstützt) ist eine bewusste Entscheidung mit eigener Risikoabwägung. Die Absicherung der Plattform beschreiben wir im Bereich Cybersecurity.
10
Cluster, Miete oder einzelne GPU: Was zu Ihrem Vorhaben passt
Ein Cluster mit SKAFFON passt, wenn
- Sie Workload-Profil und Standortvorstellung beschreiben können
- Sie Plattform, Abnahme und Betrieb aus einer Hand brauchen
Ein anderer Weg ist kürzer, wenn
- Sie stundenweise gemietete GPU-Kapazität suchen: SKAFFON ist kein GPU-Vermieter.
- Sie nur Hardware beschaffen wollen, ohne Plattform und Betrieb: dafür ist ein Systemhaus der kürzere Weg.
- Ihr Workload auf einer einzelnen GPU läuft: ein Cluster ist dann überdimensioniert, die Fragen klärt eher die Beratung.
Beschreiben Sie Workload und Standort, wir kommen mit einem Sizing zurück
Sind zuerst die Grundsatzfragen offen, beginnt es mit der technischen KI-Beratung; die Einordnung der Bausteine steht unter GPU- und KI-Infrastruktur. NVIDIA, H100, A100, L40S, CUDA und weitere genannte Namen sind Marken ihrer Inhaber.