Ein GPU-Server-Rack ist nicht nur ein Schrank voller Beschleuniger. Es ist eine Bereitstellungsgrenze, an der GPU-Topologie, Netzwerk-Fabric, Speicher, Management, Stromversorgung, Kühlung und Scheduling entweder zusammenarbeiten – oder kostspielige Engpässe verursachen.
Für KI-Entwickler und ML-Infrastruktur-Ingenieure lautet die entscheidende Frage nicht: „Wie viele GPUs passen in ein Rack?“ Sondern: Kann dieses Rack das Kommunikations-, Datenpfad- und Wiederherstellungsverhalten liefern, das die Arbeitslast benötigt? Dieser Leitfaden macht aus dieser Frage eine Architektur-Checkliste und einen Abnahmeplan für die Cloud.
Was ist ein GPU-Server-Rack?
Ein GPU-Server-Rack ist ein physisches Rack oder eine vom Anbieter verwaltete Zuweisung auf Rack-Ebene, die einen oder mehrere GPU-Server sowie die Netzwerk-, Stromversorgungs-, Kühlungs- und Managementkomponenten enthält, die für ihren Betrieb erforderlich sind. Bei einer Cloud-Bereitstellung kontrollieren Sie möglicherweise nicht den Schrank selbst, sollten aber dennoch fragen, welche Teile der Topologie garantiert sind: GPUs pro Host, Interconnect innerhalb des Hosts, Fabric zwischen Hosts, Speicherpfad, Wartungsdomäne und Platzierungsrichtlinie.
Ein einzelner GPU-Server ist ein Knoten. Ein GPU-Server-Rack ist das System um mehrere Knoten herum. Ein GPU-Cluster kann sich über ein oder mehrere Racks erstrecken. Diese Unterscheidungen sind wichtig, da ein Inferenzdienst durch den GPU-Speicher und den PCIe/NVLink-Pfad eines einzelnen Hosts begrenzt sein kann, während verteiltes Training oder Inferenz im großen Maßstab durch die Netzwerk- und Speicherpfade zwischen Hosts begrenzt werden kann.
Die BasePOD-Referenzarchitektur von NVIDIA veranschaulicht den Unterschied: Sie trennt ein InfiniBand-Rechennetzwerk, eine Ethernet-Fabric für Management und Speicher sowie ein Out-of-Band-Managementnetzwerk. Ihr Design muss diese Referenzarchitektur nicht kopieren, sollte aber die entsprechenden Pfade explizit darstellen, bevor Sie Kapazität verbindlich buchen. NVIDIA DGX BasePOD-Referenzarchitektur
Architektur eines GPU-Server-Racks: die sechs abzubildenden Bereiche
Beginnen Sie mit einem Rack-Diagramm, das die physische Platzierung und die logischen Pfade zeigt. Wenn ein Anbieter nicht jede Komponente offenlegen kann, dokumentieren Sie, was garantiert wird, und testen Sie den Rest während des Abnahmezeitraums.
| Ebene | Zu dokumentieren | Warum dies die Ergebnisse verändert |
|---|---|---|
| Rechenknoten | GPU-Modell, GPU-Anzahl pro Host, CPU/RAM, lokales NVMe, Austauschdomäne | Definiert Speicherkapazität, Kapazität für hostseitige Vorverarbeitung und den Auswirkungsbereich eines Knotenausfalls. |
| Topologie innerhalb eines Knotens | PCIe-Layout, Verfügbarkeit von NVLink/NVSwitch, GPU-zu-NIC-Affinität | Bestimmt, ob GPUs auf einem Host Daten effizient austauschen können. |
| Fabric zwischen Knoten | Netzwerktyp, Anzahl und Geschwindigkeit der NICs, Switch-Ebene, Oversubscription-Richtlinie, Platzierung im selben Rack | Bestimmt das Verhalten der kollektiven Kommunikation, sobald der Job einen Server verlässt. |
| Speicherpfad | Lokaler Cache, gemeinsam genutztes Dateisystem oder Objektspeicher, Ziel für Checkpoints, Netzwerkpfad | Verhindert, dass Datenladen und Checkpointing Rechenzeit beanspruchen. |
| Management und Steuerung | BMC-/Out-of-Band-Zugriff, Inventar, Scheduler, Metriken, Änderungssteuerung | Macht ein Rack betreibbar, wenn ein Host oder Treiber ausfällt. |
| Infrastrukturelle Rahmenbedingungen | Stromzuteilung pro Rack, PDU-Redundanz, Luftstrom- oder Flüssigkühlungsdesign, Servicezugang | Begrenzt nachhaltige Dichte und Wartung – nicht nur das, was mechanisch hineinpasst. |
1. Behandeln Sie die Topologie als Eingabeparameter der Arbeitslast
Die Anzahl der GPUs ist eine unvollständige Kapazitätsbeschreibung. Prüfen Sie bei einem Host, wie GPUs miteinander und mit NICs verbunden sind. Identifizieren Sie hostübergreifend, ob ein Job auf einem Server, in einem Rack oder rackübergreifend ausgeführt wird. Dokumentieren Sie die erwartete Platzierungsregel in der Arbeitslastspezifikation, anstatt anzunehmen, dass „acht GPUs“ überall dieselbe Maschine beschreibt.
NCCL verwendet direkte Peer-to-Peer-Pfade, wenn CUDA meldet, dass die betreffenden GPUs auf den Speicher der jeweils anderen zugreifen können. NVIDIA dokumentiert nvidia-smi topo -p2p als Möglichkeit, den Peer-to-Peer-Status zu prüfen; verwenden Sie dies als Eingabe für die Validierung, nicht als Ersatz für einen Benchmark der Arbeitslast. NCCL-Leitfaden zur GPU-Fehlerbehebung
2. Trennen Sie Rechen-, Daten- und Managementdatenverkehr
Ein GPU-Server-Rack benötigt mehr als ein schnelles Trainingsnetzwerk. Managementdatenverkehr, Abrufe von Artefakten, Telemetrie, gemeinsam genutzter Speicher und Benutzerzugriff können den Arbeitslastdatenverkehr beeinträchtigen, wenn sie einen zu klein dimensionierten Pfad gemeinsam nutzen. Verwenden Sie getrennte logische oder physische Pfade, wo Ihre Architektur dies erfordert, und definieren Sie anschließend, welcher Pfad jeweils Folgendes transportiert:
- kollektive Kommunikation und GPU-Direct-Datenverkehr;
- Image-Abrufe, Modellgewichte, Datensätze und Checkpoints;
- Kubernetes-, SSH-, BMC-, Logging- und Monitoring-Datenverkehr;
- ausgehenden Datenverkehr zu APIs, Objektspeicher oder nachgelagerten Diensten.
Dies ist besonders bei Cloud-Kapazität wichtig: Fragen Sie, ob Bandbreitenangaben die Bandbreite zwischen Hosts, den Rack-Uplink, den Speicherdurchsatz oder ein Best-Effort-Aggregat beschreiben. Sie sind nicht austauschbar.
3. Planen Sie Stromversorgung und Kühlung als Kapazitätsbeschränkungen
Dimensionieren Sie ein GPU-Server-Rack nicht allein anhand von Höheneinheiten. Eine Konfiguration, die mechanisch passt, kann durch Infrastrukturstrom, PDU-Redundanz, Luftstromrichtung, Anforderungen an Flüssigkühlung, Kabelbiegeradius oder Wartungsfreiraum begrenzt sein. NVIDIA weist darauf hin, dass Rack-Layouts je nach lokal verfügbarer Maximalleistung und Kühlungsinfrastruktur variieren; verwenden Sie die aktuellen Dokumente Ihres Serveranbieters und Colocation-Anbieters für die tatsächliche Zuteilung. NVIDIA DGX SuperPOD FAQ
Fordern Sie vor der Bereitstellung eine schriftliche Antwort auf diese Fragen an:
- Wie hoch ist das dauerhafte Leistungsbudget des Racks und welche Redundanzannahme ist darin enthalten?
- Ist das Kühldesign luftgekühlt, Direct-to-Chip-Flüssigkühlung, Wärmetausch über die Rücktür oder eine Kombination?
- Welche Komponente löst zuerst Drosselung oder ein Wartungsereignis aus: der Host, die PDU, der Netzwerk-Switch oder der Gebäudekühlkreislauf?
- Kann ein Techniker einen Knoten, ein Kabel oder eine Rücktürkomponente warten, ohne benachbarte Kapazität zu beeinträchtigen?
Wenn die Bereitstellung ausschließlich in der Cloud erfolgt, übersetzen Sie dieselben Fragen in Anbieterbegriffe: Platzierung auf dedizierten Hosts, Wartungsdomäne, Richtlinie für Host-Austausch und die Frage, ob die Zuweisung nach der Bereitstellung ihre Topologie ändern kann.
4. Geben Sie dem Scheduler Rack-Bewusstsein nur dann, wenn es sinnvoll ist
Rack-Labels sind wertvoll, wenn der Workload auf Lokalität oder Fehlerdomänen angewiesen ist. Ein verteilter Trainingsjob kann eine Platzierung in einem einzelnen Rack bevorzugen, bevor er sich über mehrere Racks erstreckt. Ein hochverfügbarer Inferenzdienst kann Replikate bewusst über Racks oder Hosts verteilen. Beginnen Sie mit einer kleinen, überprüfbaren Label-Menge, etwa topology.rack, topology.host-class, topology.fabric und topology.failure-domain, und verifizieren Sie anschließend, dass die Scheduler-Platzierung diesen Labels folgt.
Für Kubernetes sollten Sie den gesamten GPU-Software-Stack anhand des unterstützten Betriebssystems, von Kubernetes, Treibern, Runtime und Bereitstellungsoption validieren – nicht nur anhand der Clusterversion. Die Support-Matrix von NVIDIA GPU Operator unterscheidet Bare Metal, VMs mit GPU-Passthrough und vGPU-Bereitstellungen und veröffentlicht Kompatibilitätsdetails für unterstützte Umgebungen. Plattformunterstützung für NVIDIA GPU Operator
So wählen Sie ein GPU-Server-Rack für Ihren Workload aus
Verwenden Sie die Workload-Anforderungen, um zu entscheiden, ob Sie einen einzelnen Host mit hoher Dichte, ein Rack oder einen Cluster mit mehreren Racks benötigen.
| Workload-Muster | Üblicherweise priorisieren | Fragen an den Anbieter oder das Plattformteam |
|---|---|---|
| Fine-Tuning oder Inferenz auf einem einzelnen Knoten | GPU-Speicher, Intra-Node-Topologie, lokaler Speicher, zuverlässiger Host-Austausch | Welche GPUs und Interconnects sind an einen Host angebunden? Können alle erforderlichen GPUs gemeinsam zugewiesen werden? |
| Verteiltes Training | Platzierung im selben Rack, Netzwerk-Fabric, NIC-Affinität, Checkpoint-Durchsatz | Was wird für die Vernetzung zwischen Hosts garantiert? Wie wird rackübergreifende Platzierung sichtbar gemacht oder vermieden? |
| Inferenz über mehrere Knoten | Tail-Latenz, Kommunikation zwischen Modell-Shards, Sicherheit bei Rollouts, Observability | Können Replikate nach Fehlerdomäne verteilt werden, während modellparallele Ranks topologiebewusst bleiben? |
| Batch- oder Rendering-Workloads | Warteschlangenverhalten, lokaler Cache, Umgang mit Unterbrechungen, Staging von Images/Daten | Welche Platzierung wird garantiert, und wie werden unterbrochene Jobs wiederhergestellt? |
| Gemeinsam genutzte interne Plattform | Isolation, Kontingente, Scheduler-Richtlinien, Kapazitätstransparenz, Änderungskontrolle | Wie werden GPU-Partitionen, Mandantengrenzen, Treiber und Upgrades verwaltet? |
Vergleichen Sie bei einer neuen Bereitstellung die Rack-Entscheidung mit einer einfacheren Alternative. Wenn die Arbeit keine Kontrolle über Topologie, Datenlokalität oder einen benutzerdefinierten Serving-Stack erfordert, kann eine verwaltete Modell-API einen geringeren Betriebsaufwand haben. Nutzen Sie diesen Vergleich zwischen GPU-Cloud und Modell-API als Teil der Entscheidung, statt ein GPU-Server-Rack als Standardantwort zu betrachten.
So bewerten Sie die Leistung eines GPU-Server-Racks
Akzeptieren Sie ein GPU-Server-Rack nicht allein auf Grundlage einer Spitzenkennzahl für Beschleuniger. Erstellen Sie einen kurzen Abnahmetest, der die wichtigsten Leistungspfade voneinander trennt.
Schritt 1: Eine Bestands- und Topologie-Basislinie erfassen
Erfassen Sie für jeden zugewiesenen Host GPU-Identität, Treiber- und CUDA-Versionen, GPU-zu-GPU-Topologie, GPU-zu-NIC-Affinität, CPU-NUMA-Layout, lokalen Speicher und Netzwerkschnittstellen. Bewahren Sie diese Aufzeichnung zusammen mit der Bereitstellungsrevision auf. Sie liefert einen Vergleichspunkt, wenn sich die Leistung nach einem Image-, Firmware-, Treiber- oder Host-Austausch ändert.
nvidia-smi -L
nvidia-smi topo -m
nvidia-smi topo -p2p p
nvidia-smi topo -p2p n
Ändern Sie Kernel-, BIOS-, IOMMU- oder PCIe-Zugriffssteuerungseinstellungen nicht anhand einer generischen Checkliste. NVIDIA dokumentiert konfigurationsabhängiges Peer-to-Peer-Verhalten auf Linux-Bare-Metal-Systemen; verwenden Sie die unterstützten Einstellungen für den Server und die Cloud-Plattform, die Sie tatsächlich betreiben. NCCL-Fehlerbehebung für Topologie und Peer-to-Peer
Schritt 2: An den relevanten Grenzen testen
Führen Sie repräsentative Tests in drei Umfängen durch:
- Einzelner Knoten, um die GPU-Sichtbarkeit und den lokalen NVLink/NVSwitch- oder PCIe-Pfad zu validieren.
- Dasselbe Rack, um die Platzierung zwischen Hosts und die lokale Fabric zu validieren.
- Rackübergreifend, um den Pfad zu verstehen, den Ihr Scheduler verwendet, wenn Kapazität erweitert wird oder ein Failover erfolgt.
Die NCCL-Testanleitung von NVIDIA verwendet ausdrücklich Ausführungen auf einzelnen Knoten, einzelnen Racks und mehreren Racks, um GPU-Sichtbarkeit, Interconnect innerhalb eines Knotens, Fabric zwischen Knoten und Platzierung zu validieren. Erfassen Sie Latenz und Bandbreite zusammen mit dem Testbefehl, dem Digest des Container-Images, der Knotenliste und den Platzierungslabels, damit ein Ergebnis reproduziert werden kann. NCCL-Validierungsanleitung
Schritt 3: Den tatsächlichen Anwendungspfad messen
Führen Sie dann die Arbeitslast aus, die Sie bereitstellen möchten. Für das Training erfassen Sie die Zeit pro Schritt, die Datenwartezeit, die Zeit für kollektive Kommunikation, die Checkpoint-Zeit und das Wiederherstellungsverhalten. Für Inferenz erfassen Sie die Zeit bis zum ersten Token, den Ausgabedurchsatz, die Tail-Latenz, die Warteschlangenverzögerung, das Cache-Verhalten sowie Fehler- oder Neustartraten. Behalten Sie beim Vergleich von Platzierungen dasselbe Modell, Batch-/Nebenläufigkeitsprofil, dieselbe Kontextlänge und denselben Cache-Zustand bei.
So unterscheiden Sie ein GPU-Problem von einem Daten-, Netzwerk-, Scheduler- oder Konfigurationsproblem.
Schritt 4: Einen geplanten Ausfall testen
Ein betriebsbereites GPU-Server-Rack benötigt einen Wiederherstellungspfad. Überprüfen Sie vor dem Produktionsverkehr, was passiert, wenn ein Worker entleert wird, ein Knoten nicht verfügbar wird, ein Job präemptiert wird oder ein Checkpoint an anderer Stelle fortgesetzt werden muss. Bestätigen Sie, dass persistente Daten von austauschbarer Rechenkapazität getrennt sind und dass Anmeldedaten, Images und Observability auch im Ersatzpfad weiterhin funktionieren.
Ein GPU-Server-Rack in der Cloud bereitstellen: eine praktische Abfolge
Die Cloud-Bereitstellung verändert die Kontrollgrenze, nicht die Engineering-Arbeit. Sie müssen weiterhin die Annahmen zu Hardware und Platzierung sichtbar machen.
- Den Arbeitslastvertrag erstellen. Legen Sie Modellgröße, GPU-Anzahl, Speicherbedarf, Latenz- oder Durchsatz-SLO, Netzwerksensitivität, Datenquelle, Checkpoint-Speicherort, Verfügbarkeitsziel und Budgetleitplanke fest.
- Die Topologiegrenze wählen. Entscheiden Sie, ob der Job innerhalb eines Hosts, eines Racks oder eines definierten Multi-Rack-Fabrics bleiben muss. Behandeln Sie dies als Anforderung in der Provider-Anfrage, nicht als informelle Präferenz.
- Eine Zuweisungsübersicht anfordern. Fordern Sie Host-Klasse, GPU-Anzahl, GPU-Interconnect, NICs, Netzwerk-Fabric, Speicheroptionen, Platzierungsgarantie, Wartungsrichtlinie und alle Topologiemetadaten an, die Ihrem Scheduler bereitgestellt werden.
- Den Softwarevertrag fixieren. Dokumentieren Sie Betriebssystem, Kernel, NVIDIA-Treiber, CUDA, Container-Laufzeit, Kubernetes-Version, GPU-Operator-Version, Framework-Image und Application-Image-Digest. Validieren Sie die Kombination vor dem Rollout anhand der unterstützten Matrix.
- Ein enges Abnahmefenster schaffen. Führen Sie Inventar-, Topologie-, Kommunikations-, Speicher-, Anwendungs- und Wiederherstellungstests für denselben Knoten, dasselbe Rack und rackübergreifende Verbindungen durch, bevor Sie dauerhaften Traffic verlagern.
- Jede Schicht instrumentieren. Erstellen Sie separate Alerts für GPU-Zustand, Fabric-Fehler, Speicherwartezeit, Scheduler-Wartezeit, thermische Ereignisse oder Drosselung sowie Anwendungs-SLOs. Eine einzelne Auslastungsmetrik kann einen Incident auf Rack-Ebene nicht erklären.
- Ausstiegs- und Wiederherstellungsoptionen beibehalten. Pflegen Sie Image-Definitionen, Infrastrukturkonfiguration, Speicherorte persistenter Daten, Checkpoints und einen Rollback-Plan unabhängig von einer bestimmten Zuweisung.
Für die hostbezogenen Teile dieser Abfolge siehe den Leitfaden zur GPU-Server-Bereitstellung. Für die Perspektive auf Multi-Node-Control-Plane und Fabric siehe den Leitfaden zur GPU-Cluster-Architektur.
Checkliste zur Abnahme eines GPU-Server-Racks
Verwenden Sie diese Checkliste, bevor Sie ein neues GPU-Server-Rack, eine dedizierte Cloud-Zuweisung oder eine Colocation-Implementierung abnehmen.
- [ ] Der Arbeitslastvertrag benennt eine Topologiegrenze: ein Host, dasselbe Rack oder Multi-Rack.
- [ ] Die Zuweisungsübersicht identifiziert GPU-Anzahl pro Host, Accelerator-Interconnect, NICs, Netzwerk-Fabric und Speicherpfad.
- [ ] Für Stromversorgung, Kühlung, PDU-Redundanz, Anforderungen an Luftstrom oder Flüssigkeitskühlung und Servicefreiraum gibt es einen Verantwortlichen.
- [ ] GPU-, Treiber-, CUDA-, Kernel-, Container-Laufzeit- und Orchestrierungsversionen sind dokumentiert.
- [ ] Der Scheduler stellt Platzierungs- oder Fehlerdomänen-Labels bereit und berücksichtigt sie, sofern die Arbeitslast sie benötigt.
- [ ] Inventar- und
nvidia-smi-Topologieausgaben werden für jede Host-Klasse gespeichert. - [ ] Kommunikationstests decken Platzierungen auf einem einzelnen Knoten, im selben Rack und rackübergreifend ab, die der Produktions-Scheduler erzeugen kann.
- [ ] Der Anwendungstest verwendet eine repräsentative Datenquelle und ein repräsentatives Arbeitslastprofil.
- [ ] Checkpoint-, Host-Drain-, Ersatz- und Rollback-Pfade werden getestet.
- [ ] Die Kostenberichterstattung trennt produktive GPU-Zeit von Leerlauf-, Wiederholungs-, Daten- und Supportkosten, ohne dieselbe Zeit doppelt zu zählen. Für das umfassendere Kostenmodell beginnen Sie mit diesem Leitfaden zur GPU-Miete.
Häufig gestellte Fragen
Ist ein GPU-Server-Rack dasselbe wie ein GPU-Cluster?
Nein. Ein GPU-Server-Rack beschreibt eine physische oder vom Provider verwaltete Bereitstellungsgrenze auf Rack-Ebene. Ein GPU-Cluster ist eine logische Gruppe von Knoten, die einen Teil eines Racks, ein vollständiges Rack oder mehrere Racks umfassen kann. Der Unterschied ist wichtig, wenn Netzwerke, Speicher, Fehlerdomänen und Scheduling physische Grenzen überschreiten.
Wie viele GPU-Server passen in ein GPU-Server-Rack?
Es gibt keine sinnvoll allgemeingültige Zahl. Server-Tiefe und Rack-Einheiten sind nur die erste Einschränkung. Die praktische Antwort hängt von der Leistungsaufnahme des Servers, dem Kühldesign, der PDU-Kapazität und -Redundanz, der Kabelführung, dem Servicezugang und der von der Einrichtung genehmigten Dichte ab. Validieren Sie die Antwort anhand des genauen Host-, Rack- und Rechenzentrumsdesigns, das Sie verwenden werden.
Benötigt jedes GPU-Server-Rack InfiniBand?
Nein. Das geeignete Fabric hängt von der Arbeitslast und der Topologie ab. Arbeitslasten auf einem einzelnen Host benötigen möglicherweise überhaupt kein leistungsfähiges Inter-Node-Fabric. Verteilte Arbeitslasten sollten auf dem Netzwerkpfad getestet werden, den sie tatsächlich nutzen werden, einschließlich Platzierungen im selben Rack und rackübergreifend. Vermeiden Sie es, ein Fabric allein anhand einer Marketing-Spezifikation auszuwählen.
Was sollte ich testen, bevor ich Cloud-GPU-Rack-Kapazität abnehme?
Testen Sie die Ihnen zugewiesene Kapazität: Hardwareinventar, Topologie, GPU-zu-NIC-Affinität, Verhalten von lokalem und gemeinsam genutztem Speicher, Kommunikation innerhalb eines einzelnen Knotens, Kommunikation innerhalb desselben Racks, rackübergreifende Kommunikation, falls sie in der Produktion möglich ist, repräsentatives Anwendungsverhalten und Wiederherstellung nach einem geplanten Ausfall.
Wann sollte ich den Betrieb eines GPU-Server-Racks vermeiden?
Vermeiden Sie den Betrieb auf Rack-Ebene, wenn Ihr Workload die dadurch bereitgestellte Kontrolle nicht benötigt. Wenn eine verwaltete Modell-API die Anforderungen an Modell, Latenz, Verfügbarkeit, Datenschutz und Kosten erfüllen kann, kann sie den Aufwand für Hardware, Fabric, Treiber, Scheduler und Kapazitätsmanagement eliminieren. Stellen Sie diesen Vergleich bewusst an, bevor Sie sich für ein GPU-Server-Rack entscheiden.
Das Rack auf den Workload abstimmen
Ein GPU-Server-Rack ist erfolgreich, wenn sein physisches Design und seine Cloud-Zuweisung zu den Kommunikations-, Daten- und Wiederherstellungspfaden des Workloads passen. Machen Sie die Topologie explizit, trennen Sie die Datenverkehrsklassen, die sich gegenseitig beeinträchtigen können, validieren Sie die Leistung auf Ebene einzelner Knoten, innerhalb desselben Racks und rackübergreifend, und akzeptieren Sie Kapazität erst, nachdem die reale Anwendung und ein Ausfallpfad getestet wurden.
Wenn Kontrolle auf Rack-Ebene nicht erforderlich ist, vergleichen Sie einen Modell-API-Ansatz, bevor Sie die Betriebsbelastung übernehmen. Wenn sie erforderlich ist, nutzen Sie diesen Leitfaden zusammen mit dem GPU-Server-Leitfaden, dem Leitfaden zur GPU-Cluster-Architektur und der Checkliste für GPU-Cloud-Kosten, um Kapazität in eine überprüfbare Bereitstellung zu überführen.
