GPU-Cluster-Architektur: Compute, Netzwerk, Storage und Control Plane

GPU-Cluster-Architektur ist die Form des gesamten Systems, nicht nur die Anzahl der GPUs. Ein Produktionscluster muss Compute-Nodes, Hochgeschwindigkeitsnetzwerk, Storage, einen Scheduler, Zugriffskontrollen, Telemetrie und Recovery-Pfade koordinieren, bevor er teure Beschleuniger in nützliche Trainingsläufe oder zuverlässige Inferenz verwandeln kann.

Die praktische Frage ist einfach: Kann Ihr Team Daten schnell genug verschieben, Jobs planen, Ausfälle beheben und Kosten messen, um die GPUs ausgelastet zu halten? Wenn nicht, kann ein Cluster mit besseren Karten wirtschaftlich schlechter abschneiden als ein kleinerer verwalteter GPU-Service oder eine Model-API.

Dieser Leitfaden gibt KI-Plattformteams ein Arbeitsmodell für gpu cluster architecture: Was in die Compute-Schicht gehört, was das Netzwerk nachweisen muss, wie Storage und Checkpointing passen, wie Kubernetes oder Slurm zur Control Plane wird und was vor dem Mieten oder Kaufen von Multi-Node-Kapazität zu testen ist.

Flatkeys praktische Regel lautet, mit der Workload-Grenze zu beginnen. Wenn das Produkt nur Model-Outputs benötigt, benchmarken Sie zuerst einen GPU-Cloud-vs-Model-API-Pfad. Wenn Sie benutzerdefinierte Gewichte, Platzierungskontrolle, langlaufendes Training oder private Serving-Infrastruktur benötigen, dann entwerfen Sie den GPU-Cluster rund um die Anforderungen der Workload an Compute, Netzwerk, Storage und Control Plane.

GPU-Cluster-Architektur Kurzantwort

Ein nützlicher GPU-Cluster hat vier Ebenen:

Eine multi-node gpu cluster architecture ist erfolgreich, wenn diese Ebenen gemeinsam entworfen werden. Compute ohne Fabric ist isolierte Kapazität. Fabric ohne Storage beseitigt nur Flaschenhälse. Kubernetes ohne Quoten, Telemetrie und Runbooks ist nur ein Startmechanismus.

GPU-Cluster-Architekturdiagramm

Nutzen Sie dieses Diagramm als Prüfraster, bevor Sie Provider vergleichen oder ein Rack-Design freigeben.

                  users / CI / product traffic / API clients
                                  |
                                  v
        +------------------------------------------------------+
        | control plane                                        |
        | Kubernetes or Slurm scheduler, queues, quotas,       |
        | secrets, registry access, policy, telemetry, billing |
        +------------------------------------------------------+
              |                    |                    |
              v                    v                    v
   +-------------------+   +-------------------+   +-------------------+
   | gpu compute node  |   | gpu compute node  |   | gpu compute node  |
   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |   | GPUs, CPU, RAM,   |
   | local NVMe, NICs  |   | local NVMe, NICs  |   | local NVMe, NICs  |
   +-------------------+   +-------------------+   +-------------------+
              \                  |                  /
               \                 |                 /
                v                v                v
        +------------------------------------------------------+
        | high-speed fabric                                   |
        | NVLink/NVSwitch inside node; InfiniBand, RoCE, EFA, |
        | or Ethernet across nodes; placement and routing     |
        +------------------------------------------------------+
                                  |
                                  v
        +------------------------------------------------------+
        | storage and data path                               |
        | object store, shared filesystem, local scratch,      |
        | model cache, checkpoints, snapshots, backups        |
        +------------------------------------------------------+

Für ein kubernetes gpu cluster architecture diagram fügen Sie die Kubernetes-spezifischen Objekte rund um die Control Plane hinzu:

cluster admins -> node images -> GPU Operator / device plugin -> GPU nodes
app teams      -> namespace -> quota -> job queue -> Pod / Job / RayJob
finance        -> labels -> usage export -> cost per job / team / model
security       -> secrets -> image policy -> network policy -> audit logs

Das Diagramm ist bewusst schlicht gehalten. Das Ziel ist nicht, jeden Dienst darzustellen. Das Ziel ist, fehlende Verantwortlichkeiten zu erkennen, bevor der Cluster zu einer Produktionsabhängigkeit wird.

Mit der Workload beginnen, nicht mit dem Rack

Bevor Sie sich für Kubernetes, Slurm, eine Cloud-Reservierung oder einen Bare-Metal-Anbieter entscheiden, erstellen Sie ein einseitiges Workload-Briefing.

Wenn Sie diese Tabelle nicht ausfüllen können, unterzeichnen Sie noch keinen langfristigen Kapazitätsvertrag. Mieten Sie stattdessen einen kleineren Anteil, führen Sie Benchmarks aus und machen Sie aus den Logs das Beschaffungsbriefing. Der GPU-Cluster-Mietleitfaden liefert die Checkliste für die Käuferseite, sobald die Architekturform klar ist.

Compute-Ebene: GPU-Nodes sind nicht austauschbar

Die Compute-Ebene definiert, was ein Job tatsächlich nutzen kann. Eine vollständige Compute-Spezifikation umfasst mehr als nur "8x H100" oder "B200 cluster".

Fragen Sie nach:

• GPU-Modell, Speicherkapazität und PCIe versus SXM, wo relevant.
• GPUs pro Node und der Topologie innerhalb des Nodes.
• CPU-Modell, CPU-Anzahl, Systemspeicher und NUMA-Layout.
• Lokale NVMe-Kapazität und erwarteter Durchsatz.
• NIC-Anzahl, NIC-Geschwindigkeit und ob GPU-Direct-Pfade unterstützt werden.
• Treiberversion, CUDA, Container-Runtime und Lebenszyklus des OS-Images.
• MIG-, vGPU-, Time-Slicing- oder Full-GPU-Zuweisungsrichtlinie.
• Node-Homogenität und Austauschrichtlinie.

Die Topologie innerhalb des Nodes ist wichtig, weil acht GPUs in einem Server nicht dasselbe sind wie acht einzelne GPU-Nodes. Das Node-Design bestimmt den Speicherdruck, CPU-Engpässe, die Geschwindigkeit des lokalen Stagings und wie teuer die Kommunikation zwischen den Nodes wird.

Die Dokumentation des NVIDIA Kubernetes GPU Operator ist hier nützlich, weil sie zeigt, wie Treiber, das NVIDIA Container Toolkit, der Device-Plugin, DCGM-Telemetrie und verwandte Komponenten als Cluster-Stack verwaltet werden können, statt als einmaliges Node-Setup. Die Dokumentation des Kubernetes Device Plugin erklärt den allgemeinen Erweiterungspunkt, der verwendet wird, um Vendor-Geräte als planbare Ressourcen bereitzustellen.

Netzwerk-Ebene: Beweisen Sie das Fabric mit einem Benchmark

Multi-Node-Training und Serving mit hohem Durchsatz hängen vom Netzwerk ab. Eine Cluster-Spezifikation sollte das Fabric und den Abnahmetest angeben, nicht nur die Bandbreiten-Schlagzeile.

Fragen Sie nach:

• Details zu Intra-Node NVLink oder NVSwitch.
• Cross-Node-Design mit InfiniBand, RoCE, EFA oder Ethernet.
• NIC-Anzahl und Geschwindigkeit pro Node.
• Placement-Garantie und Failure-Domain.
• Oversubscription-Verhältnis.
• GPUDirect-RDMA-Unterstützung, wo relevant.
• Container- und Host-Networking-Modell.
• Observability für Fabric-Fehler, Retransmits, Congestion und Node-Ausfälle.

Verwenden Sie vor Vertragsbeginn einen Abnahmetest:

network acceptance test:
  run NCCL all_reduce across every rented node
  record bandwidth, latency, node IDs, GPU model, driver, CUDA, NCCL version
  repeat after installing the production container image
  save logs and compare them with the provider's quoted topology

NVIDIA NCCL und NCCL-Tests sind Standardreferenzen, um das Verhalten kollektiver Kommunikation in verteilten GPU-Workloads zu validieren. Es geht nicht darum, einer einzigen Benchmark-Zahl hinterherzulaufen. Es geht darum, nicht passende Nodes, schlechte Platzierung, Fabric-Congestion oder Drift zwischen Treiber und Container zu erkennen, bevor ein kompletter Trainingslauf fehlschlägt.

Für Inference sollte der Netzwerktest den echten Traffic-Pfad einbeziehen: Request-Ingress, Kommunikation zwischen Modell-Shards, KV-Cache-Verhalten, wo relevant, Storage-Abrufe und Egress. Ein Trainings-Fabric, das isoliert stark aussieht, kann trotzdem schlechte Benutzerlatenz erzeugen, wenn der Serving-Stack zu viele Netzwerkgrenzen überschreitet.

Storage-Ebene: Daten, Gewichte und Checkpoints aus dem kritischen Pfad heraushalten

Storage ist der Bereich, in dem viele GPU-Cluster-Architekturpläne teuer werden. Das GPU-Angebot ist sichtbar. Der Datenpfad bleibt oft verborgen, bis der erste Produktionslauf startet.

Entwerfen Sie Storage um vier Flüsse herum:

Beim Training sind Checkpoint-Durchsatz und Restore-Zeit Architekturthemen, keine Backup-Details. Bei Inference beeinflussen das Laden der Modellgewichte, das lokale Cache-Warm-up und das Verhalten persistenter Volumes die Bereitstellungszeit und die Failover-Zeit.

NVIDIAs GPUDirect-Storage-Dokumentation ist eine nützliche Quelle, wenn die Architektur einen direkten Datenpfad zwischen lokalem oder entferntem Storage und GPU-Speicher erfordert. Nicht jeder Cluster braucht GPUDirect Storage, aber Teams, die große Datensätze oder Checkpoints verschieben, sollten ausdrücklich entscheiden, ob der Storage-Stack gewöhnlich, optimiert oder ein akzeptierter Engpass ist.

Control Plane: Kubernetes, Slurm oder beides?

Die Control Plane macht aus Hardware eine Plattform. Sie entscheidet, wer was ausführen kann, wann Jobs starten, wie Fehler erneut versucht werden und wie Teams die Nutzung verstehen.

Kubernetes GPU-Cluster-Architektur

Kubernetes eignet sich für GPU-Plattformen, die Service-Deployment, Multi-Tenant-Namespaces, container-native Workflows, API-gesteuerte Automatisierung, Richtlinien und Integration mit Cloud-nativer Observability benötigen. Eine produktive kubernetes gpu cluster architecture umfasst in der Regel:

• Node-Images und Bootstrap-Automatisierung.
• GPU Operator oder herstellerspezifisches Treiber-/Device-Plugin-Management.
• Device Plugin oder Dynamic Resource Allocation zur GPU-Bereitstellung.
• Namespaces, RBAC, Secrets, Image-Pull-Policy und Network Policy.
• Jobs, Deployments, RayJob, Training-Operatoren oder Inferenzservices.
• Kueue oder eine andere Queueing-Schicht, wenn Batch-Fairness wichtig ist.
• Quotas nach Team, Projekt, Umgebung oder Kunde.
• DCGM, Prometheus, Logs, Traces und Billing-Labels.
• Admission Controls für Images, privilegierte Workloads, Host-Mounts und GPU-Sharing.

Kubernetes-Device-Plugins stellen GPUs als erweiterte Ressourcen bereit. Die Kubernetes Dynamic Resource Allocation ergänzt ein umfangreicheres, auf Claims basierendes Ressourcenmodell für Geräte und andere spezialisierte Ressourcen. Kueue fügt Konzepte für das Job-Queueing wie Workloads, Queues, Cohorts und Resource Flavors für Batch- und AI/ML-Scheduling hinzu. Zusammen können diese Tools einen GPU-Pool in eine verwaltete Plattform verwandeln statt in eine Sammlung von per SSH zugänglichen Maschinen.

Slurm GPU-Cluster-Architektur

Slurm eignet sich für viele HPC-orientierte und Forschungsumgebungen, weil es um Queues, Partitionen, Accounting, Reservations und Batch-Jobs herum aufgebaut ist. Die GRES-Dokumentation von Slurm behandelt GPU-Ressourcen und wie Jobs sie anfordern.

Slurm ist oft eine starke Wahl, wenn:

• Benutzer Batch-Training-Jobs einreichen.
• Queue-Richtlinien zentral sind.
• Teams bereits HPC-Betriebserfahrung haben.
• Die Workload weniger serviceorientiert ist.
• MPI, NCCL-Tests und Batch-Accounting vertraute operative Grundbausteine sind.

Manche Organisationen betreiben beides: Slurm für Forschung und große Trainings-Queues, Kubernetes für Inferenzservices und Plattform-APIs. Das kann funktionieren, aber nur, wenn Identität, Datenzugriff, Observability und Kostenverteilung systemübergreifend geplant werden.

Observability und Kostenkontrollen gehören ins erste Design

Fügen Sie Telemetrie nicht erst hinzu, nachdem der Cluster live ist. Die Fragen, die für Engineering und Finance wichtig sind, sind vorhersehbar:

• Welche Jobs haben welche GPUs genutzt?
• Welcher Namespace, welches Team, welcher Kunde, welches Modell oder welches Experiment hat die Kosten verursacht?
• Wie hoch war die tatsächlich nützliche Auslastung, nicht nur die zugewiesene GPU-Zeit?
• Wie viel Zeit wurde in der Queue verbracht?
• Welche Fehler haben die meisten GPU-Stunden verbrannt?
• Welcher Storage- oder Netzwerkengpass hat zu untätigen GPUs geführt?
• Wie hoch waren die Kosten pro abgeschlossenem Lauf oder akzeptierter Ausgabe?

Die Mindest-Telemetrie sollte Folgendes umfassen:

• GPU-Auslastung, Speicherauslastung, Leistung, Temperatur und ECC-Ereignisse.
• Pro-Job Laufzeit, Queue-Zeit, Retry-Anzahl, Exit-Grund und Eigentümer.
• Gesundheit des Netzwerk-Fabrics und Benchmark-Historie.
• Storage-Durchsatz, Latenz, Checkpoint-Zeit und Restore-Zeit.
• Scheduler-Zuweisungsereignisse und Quota-Ablehnungen.
• Billing-Labels oder Usage-Exports, die an Geschäftseinheiten gekoppelt sind.

Das Modell-/API-Baseline von Flatkey ist hier wichtig. Wenn eine verwaltete Modell-API dieselbe akzeptierte Ausgabe mit klareren Stückkosten und geringerem Betriebsaufwand liefert, muss der Cluster diese Baseline nach Abzug von Leerlaufzeit, Retries, Storage und Arbeitsaufwand übertreffen.

Sicherheit, Isolierung und Zugriffskonzept

GPU-Cluster beginnen oft als Engineering-Projekte und werden zu gemeinsamer Infrastruktur. Behandeln Sie das Zugriffskonzept als Teil der Architektur.

Definieren Sie:

• Authentifizierung und Identitätsquelle.
• Isolation nach Namespace, Projekt oder Konto.
• SSH-Richtlinie, falls vorhanden.
• Container-Image-Registry, Signierung und Scanning.
• Secrets-Management.
• Network-Egress-Policy.
• Datenlöschung und Cleanup nach Jobs.
• Aufbewahrung von Audit-Logs.
• Break-Glass-Zugriff.
• Vendor-Support-Zugriff und Remote-Hands-Workflow.

Bei Multi-Tenant-Clustern muss entschieden werden, ob GPU-Sharing erlaubt ist. Eine vollständige GPU-Zuweisung ist einfacher. MIG, vGPU oder Time-Slicing können die Auslastung verbessern, verändern aber auch Isolierung, Telemetrie, Scheduling und Leistungserwartungen.

Cluster-Sizing: die Architektur in Zahlen übersetzen

Das Sizing sollte durch die nützliche Einheit bestimmt werden:

required_gpu_capacity =
  target_work_completed_per_month
  / useful_work_per_gpu_month_after_failures_idle_and_retries

Dann unter Druck testen:

Für ein Kostenmodell verknüpfen Sie diesen Artikel mit Ihrem GPU-Cluster-TCO-Arbeitsblatt:

effective_cluster_unit_cost =
  (compute + network + storage + support + operations + idle + retries)
  / accepted workload units

Der Nenner sollte zum Produkt passen: abgeschlossene Trainingsläufe, akzeptierte Inferenz-Tokens, erzeugte Medienjobs, Suchindex-Updates oder Kundenanfragen.

Checkliste für die Architekturprüfung

Verwenden Sie diese Checkliste, bevor Sie ein multi node gpu cluster architecture diagram oder ein Anbieterangebot freigeben.

Offizielle Referenzen, die Sie offen halten sollten

Verwenden Sie die offiziellen Dokumentationen als Quellenprüfung während der Architekturprüfung:

Betrachten Sie diese als Architekturreferenzen, nicht als Ersatz für Abnahmetests auf dem genauen Cluster, den Sie betreiben werden.

Wann ein GPU-Cluster die falsche Architektur ist

Erstellen oder reservieren Sie keinen Cluster nur, weil die GPU-Stundenpreise attraktiv aussehen. Ein direkter GPU-Cluster kann die falsche Architektur sein, wenn:

• Das Produkt nur Modell-Ausgaben benötigt.
• Sich der Modellmix wöchentlich ändert.
• Das Team keine Treiber, Scheduler, Storage, Netzwerke und Incidents betreiben kann.
• Die Workload spitzenartig und mit niedriger Auslastung ist.
• Datenbewegung das Compute dominiert.
• Die Beschaffung eine Dreijahresverpflichtung möchte, bevor Benchmark-Nachweise vorliegen.
• Finance die Clusterkosten nicht den akzeptierten Ausgaben zuordnen kann.

Vergleichen Sie in diesen Fällen zuerst Cloud-GPU-Mietpreise, Serverless GPU oder eine Modell-API. Die richtige Architektur ist diejenige, die zuverlässige akzeptierte Ausgaben zu den niedrigsten gesamten Betriebskosten liefert, nicht die mit dem größten Beschleunigerbestand. Für einen Marktüberblick auf Anbieterebene nutzen Sie den GPU-Cloud-Vergleich, bevor Sie Angebote anfordern.

Fazit

Eine starke GPU-Cluster-Architektur ist ein Systemdesign: Compute-Knoten, die zur Workload passen, ein Netzwerk-Fabric, das durch Benchmarks bewiesen ist, Storage, der die GPUs nicht ausbremst, und eine Control Plane, die Nutzung planen, absichern, überwachen und verrechnen kann.

Für kleine Experimente beginnen Sie mit Miete oder verwalteten APIs. Für ernsthaftes Multi-Node-Training oder Private Inference verwenden Sie das obenstehende Diagramm und die Checkliste, bevor Sie sich für einen Anbieter, ein Rack oder eine Reservierung festlegen. Der teure Fehler ist nicht, Kubernetes statt Slurm oder H100 statt H200 zu wählen. Der teure Fehler besteht darin, GPU-Kapazität zu kaufen, bevor die Architektur bewiesen hat, dass sie diese Kapazität in nützliche Arbeit umsetzen kann.