GPU-Beschleuniger für Server: Auswahl ohne Engpässe
Eine GPU mit hoher Rechenleistung verliert ihren Nutzen, sobald die Plattform ihre Daten nicht schnell genug liefert oder mehrere Beschleuniger untereinander zu langsam kommunizieren. PCIe Gen 5 x16 erreicht maximal 128 GB/s bidirektional.

PCIe Gen 4 x16 bleibt bei 64 GB/s. NVLink der vierten Generation erreicht bei NVIDIA H100 und H200 bis zu 900 GB/s zwischen GPUs.
Diese Differenz bestimmt die Architektur. Nicht die Zahl der Tensor-Kerne. Nicht allein die Größe des Grafikspeichers.
Die GPU-Beschleuniger-Server-Auswahlkriterien beginnen deshalb nicht bei der Karte. Sie beginnen bei CPU-Lanes, Topologie, Leistungsbudget und thermischer Verlustleistung. Erst danach folgt die konkrete GPU.
Die Architektur-Falle: PCIe-Bandbreite und Lane-Sharing
PCIe ist in vielen Servern nicht nur ein Steckplatzstandard. Es ist der gemeinsame Transportweg für GPUs, NVMe-SSDs, Netzwerkkarten, RAID-Controller und weitere Erweiterungskarten. Wird dieser Weg falsch geplant, arbeitet eine physisch mit x16 bestückte GPU effektiv nur noch mit x8-Anbindung.
Bei PCIe Gen 5 halbiert sich die verfügbare bidirektionale Bandbreite damit von 128 GB/s auf 64 GB/s. Bei Gen 4 sinkt sie von 64 GB/s auf 32 GB/s. Für lokale Inferenz mit vorab geladenem Modell ist das nicht zwingend kritisch. Für Trainingsjobs, häufige Host-Device-Transfers, Datenvorverarbeitung auf der CPU oder GPU-Direct-Storage-nahe Workloads wird es zum messbaren Engpass.
Die Ursache liegt oft nicht in der GPU, sondern im Mainboard-Layout. Ein Slot kann mechanisch x16 ausgeführt sein, elektrisch aber nur acht Lanes erhalten. Ebenso häufig teilt sich ein Steckplatz die Lanes mit einem M.2- oder U.2/U.3-Anschluss. Das Handbuch formuliert dies meist knapp: Bei Belegung von Slot A wird Slot B von x16 auf x8 reduziert. In einem KI-Server ist dieser Satz Teil der Performance-Spezifikation.
Die Kontrolle erfolgt in einer festen Reihenfolge:
1. CPU-Lane-Budget erfassen. Die Zahl der vom Prozessor bereitgestellten PCIe-Lanes ist maßgeblich. Moderne AMD-EPYC- und Intel-Xeon-Plattformen stellen typischerweise 128 oder mehr Lanes bereit. Entscheidend ist die Zahl nutzbarer Lanes pro Sockel und deren Generation.
2. Mainboard-Bifurkation prüfen. Ein x16-Port kann je nach Plattform in x8/x8 oder x4/x4/x4/x4 aufgeteilt werden. Das ist für NVMe-Riser sinnvoll, kann aber eine GPU-Anbindung ungewollt reduzieren.
3. Slot-Zuordnung dokumentieren. Jede GPU benötigt einen festen physischen Steckplatz, eine elektrische Lane-Breite und eine CPU-Zuordnung. Diese Zuordnung gehört in die Rack-Dokumentation, nicht nur in das BIOS-Handbuch.
4. NVMe und Netzwerk einplanen. Vier NVMe-SSDs mit je vier Lanes belegen bereits 16 Lanes. Eine 100-GbE-Netzwerkkarte beansprucht in der Regel ebenfalls eine hochbreitbandige PCIe-Anbindung. Ohne Lane-Plan entsteht Lane-Sharing fast zwangsläufig.
5. Den Ist-Zustand messen. Firmware, Riser, Kontaktprobleme oder BIOS-Einstellungen können die Link-Breite und Link-Geschwindigkeit begrenzen. Eine GPU, die als Gen 5 x8 statt Gen 5 x16 läuft, liefert keine theoretische Ausrede, sondern einen reduzierten Datentransport.
Ein freier x16-Steckplatz ist keine Zusage für eine x16-Anbindung.
Die typische Fehlplanung betrifft Systeme mit zwei bis vier GPUs, lokalen NVMe-Datensätzen und schneller Netzwerkanbindung. Der Server wird nach Anzahl der Steckplätze gekauft. Die Lane-Topologie wird später betrachtet. Das kehrt die technische Reihenfolge um.
NVLink und PCIe: Zwei Transportwege mit unterschiedlicher Aufgabe
PCIe verbindet GPU und Host-System. Es verbindet auch GPUs untereinander, wenn keine direkte Hochgeschwindigkeitsverbindung vorhanden ist. NVLink ist dagegen für die GPU-zu-GPU-Kommunikation konzipiert. Diese Trennung ist bei der KI-Server-GPU-Auswahl zentral.
Eine H100 oder H200 mit NVLink der vierten Generation erreicht bis zu 900 GB/s bidirektionale GPU-zu-GPU-Bandbreite. PCIe Gen 5 x16 erreicht maximal 128 GB/s bidirektional. Der Unterschied beträgt damit ungefähr den Faktor sieben. Bei Blackwell GB200 steigt die angegebene NVLink-Bandbreite pro GPU auf bis zu 1,8 TB/s.
Diese Zahlen sind nicht universell in höhere Anwendungsleistung übersetzbar. Sie definieren aber die Obergrenze des Interconnects. Je stärker ein Workload Tensoren, Aktivierungen oder Modellzustände zwischen GPUs austauscht, desto höher ist die Relevanz.
| Parameter | PCIe Gen 4 x16 | PCIe Gen 5 x16 | NVLink 4 bei H100/H200 |
|---|---|---|---|
| Bidirektionale Bandbreite | bis 64 GB/s | bis 128 GB/s | bis 900 GB/s |
| Primäre Aufgabe | Host- und Erweiterungsanbindung | Host- und Erweiterungsanbindung | Direkte GPU-Kommunikation |
| Abhängigkeit von CPU-Lanes | hoch | hoch | ergänzend zu PCIe |
| Eignung für stark gekoppeltes Multi-GPU-Training | begrenzt | begrenzt bis mittel | hoch |
| Verfügbarkeit bei NVIDIA L40S | vorhanden | plattformabhängig | nicht unterstützt |
Die NVIDIA L40S zeigt die Konsequenz klar. Sie basiert auf der Ada-Lovelace-Architektur, verfügt über 48 GB GDDR6 mit ECC und ist mit 350 Watt spezifiziert. Für Visualisierung, Rendering, Inferenz und viele Einzel-GPU-Aufgaben ist das ein belastbares Profil. NVLink unterstützt sie jedoch nicht. Mehrere L40S können daher nicht mit einer NVLink-Fabric verbunden werden.
Das ist keine pauschale Einschränkung der Karte. Es ist eine Architekturgrenze. Bei voneinander unabhängigen Inferenzanfragen kann eine L40S-Flotte effizient arbeiten. Bei großen verteilten Trainingsläufen mit intensiver Synchronisation entsteht die Kommunikation über PCIe. Dann sinkt die Skalierung deutlich früher als bei einer SXM-Plattform mit NVLink.
Die Entscheidung folgt dem Datenfluss:
- Einzel-GPU-Inferenz: Grafikspeicher, Speicherbandbreite, Leistungsaufnahme und verfügbare PCIe-Anbindung dominieren. NVLink ist meist kein Pflichtmerkmal.
- Mehrere unabhängige Inferenzinstanzen: Mehrere PCIe-GPUs sind technisch sinnvoll, sofern CPU-Lanes und Netzwerkanbindung ausreichend dimensioniert sind.
- Rendering und virtuelle Workstations: GPU-Dichte, Kühlung, Display- oder Virtualisierungsfunktionen und Grafikspeicher stehen im Vordergrund. Direkte GPU-Kommunikation ist nachrangig.
- Verteiltes KI-Training: NVLink und die interne GPU-Topologie werden zu Kernparametern. PCIe bleibt notwendig, ist aber nicht der geeignete Ersatz für einen Hochgeschwindigkeits-Interconnect.
- Große Modelle mit Modellparallelisierung: Die GPU-zu-GPU-Kommunikation kann die Rechenleistung begrenzen. Eine höhere Zahl langsamer gekoppelter GPUs ist dann keine lineare Skalierung.
Wenn die GPUs mehr Daten austauschen als der Host zuliefern muss, entscheidet der Interconnect über die Auslastung.
SXM und PCIe: Die TDP ist eine Plattformentscheidung
Server-GPUs unterscheiden sich nicht nur bei Rechenleistung und Speicher. Das Formfaktor-Konzept definiert Stromversorgung, Kühlung, Servicefähigkeit und maximale Dichte.
Die PCIe-Variante der NVIDIA H100 ist auf etwa 350 bis 400 Watt ausgelegt. Die H100 im SXM-Formfaktor kann bis zu 700 Watt konfigurierbare Leistungsaufnahme erreichen. Diese Differenz ist kein Detail der Produktliste. Sie trennt zwei Plattformklassen.
Eine PCIe-GPU sitzt in einem Standard-Erweiterungsslot. Sie lässt sich in geeigneten Servern mit Riser-Konzept integrieren. Die Kühlung erfolgt typischerweise über einen gerichteten Hochdruck-Luftstrom. Die thermische Verlustleistung muss aus dem Gehäuse abgeführt werden, ohne dass Netzwerkkarten, RAM-Bänke oder benachbarte GPUs in die thermische Drosselung geraten.
SXM-Beschleuniger sind stärker in das Systemdesign eingebunden. Die GPU-Module, die NVLink-Anbindung, Kühlkörper und Spannungsversorgung sind Teil einer abgestimmten Plattform. Das ermöglicht hohe Leistungsbudgets und dichte Multi-GPU-Konfigurationen. Es reduziert gleichzeitig die Austauschbarkeit auf Komponentenebene. Ein SXM-System ist kein universeller 19-Zoll-Server mit nachgerüsteten Karten.
Die thermische Rechnung ist direkt:
- Vier GPUs mit je 350 Watt erzeugen bereits 1.400 Watt Verlustleistung allein auf Beschleunigerebene.
- Acht SXM-GPUs mit je bis zu 700 Watt erreichen bis zu 5.600 Watt GPU-Leistungsaufnahme.
- Hinzu kommen CPUs, DDR5-Speicher, NVMe-Laufwerke, Netzwerkkarten, Spannungswandler und Lüfter.
Die elektrische Aufnahme des Gesamtsystems liegt damit deutlich über der Summe der GPU-TDPs. Netzteile dürfen nicht nach Dauerlast auf Kante dimensioniert werden. Reserve ist erforderlich, weil GPU-Lasten keine gleichförmige Kurve bilden. Sie ändern sich innerhalb von Millisekunden.
Auch die Luftführung ist nicht austauschbar. Eine 350-Watt-Karte in einem Gehäuse mit unzureichendem statischem Druck erreicht schnell höhere Hotspot-Temperaturen. Die Lüfterdrehzahl steigt. Der Geräuschpegel steigt. Die GPU reduziert bei thermischen Grenzen ihre Taktfrequenz. Die Folge ist keine vollständige Störung, sondern ein schleichender Verlust beim Durchsatz. Genau deshalb bleibt das Problem im Betrieb oft zu lange unentdeckt.
Die erforderlichen Plattformdaten sind vor der Beschaffung festzuhalten:
| Prüfpunkt | PCIe-GPU-Server | SXM-Mehrfach-GPU-System |
|---|---|---|
| GPU-Leistungsbereich | typischerweise bis 350–400 W bei H100 PCIe | bis 700 W pro H100 SXM möglich |
| Kühlkonzept | gerichtete Luftkühlung über Riser und Karten | integriertes Hochleistungs-Kühlkonzept |
| GPU-Interconnect | PCIe, modellabhängig weitere Optionen | NVLink als Plattformbestandteil |
| Austauschbarkeit | vergleichsweise hoch | systemgebunden |
| Rackbarbeit | abhängig von Gehäuse, Luftstrom und Kartenabstand | hohe Leistungsdichte, hohe Infrastrukturanforderung |
| Hauptrisiko | Lane-Sharing und thermische Drosselung | Strom-, Kühl- und Rackkapazität |
CPU-Anbindung und Skalierung: 128 Lanes sind kein Luxus
Eine GPU beschleunigt Berechnungen. Die CPU orchestriert Datenpfade, Speicherverwaltung, Netzwerkverkehr, Storage-Zugriffe und Teile der Vorverarbeitung. Ist die CPU-Plattform zu klein gewählt, bleibt die GPU-Auslastung trotz hoher theoretischer Beschleunigerleistung ungleichmäßig.
Server-CPUs wie AMD EPYC oder Intel Xeon stellen typischerweise 128 oder mehr PCIe-Lanes bereit. Das schafft Spielraum für mehrere GPUs, NVMe-Speicher und Netzwerkkarten ohne aggressives Lane-Sharing. Die Angabe allein genügt jedoch nicht. Bei Zwei-Sockel-Systemen kommt die NUMA-Topologie hinzu.
Eine GPU, die an CPU 0 angebunden ist, arbeitet am effizientesten mit Arbeitsspeicher und Netzwerkkarte derselben NUMA-Domäne. Greift sie permanent auf Ressourcen zu, die an CPU 1 hängen, durchläuft der Datenverkehr den Sockel-Interconnect. Die zusätzliche Latenz und der reduzierte effektive Durchsatz sind bei datenintensiven Pipelines relevant.
Die saubere Zuordnung lautet daher:
1. GPU und zugehörige NIC möglichst an dieselbe CPU-Domäne anbinden.
2. Lokalen NVMe-Speicher für den Datenpfad derselben GPU-Domäne vorsehen.
3. CPU-Kerne und Arbeitsspeicher pro Beschleuniger planen, nicht nur pro Server.
4. BIOS- und Firmware-Versionen vor der Inbetriebnahme vereinheitlichen.
5. Link-Breite, Link-Generation, NUMA-Zuordnung und Fehlerzähler unter Last erfassen.
Der letzte Punkt wird häufig ausgelassen. Ein Server bootet auch mit ungünstiger Topologie. Frameworks starten auch mit reduzierter PCIe-Verbindung. Der Fehler zeigt sich erst in geringer GPU-Auslastung, verlängerten Datenladezeiten oder ungleichmäßigem Skalierungsverhalten zwischen zwei baugleichen Knoten.
Firmware gehört in diesen Zusammenhang. BIOS, BMC, GPU-Firmware, PCIe-Switch-Firmware und Netzwerkkarten-Firmware beeinflussen Kompatibilität und Link-Training. Ein gemischter Firmwarestand ist kein Wartungsdetail. Er erschwert jede Ursachenanalyse, sobald ein Link mit falscher Generation oder reduzierter Breite trainiert.
Stromversorgung unter Last: Millisekunden entscheiden
KI-Beschleuniger erzeugen schnelle Lastwechsel. Zwischen niedriger Auslastung und hoher Rechenlast liegen teilweise Millisekunden. Netzteile und USV-Anlagen müssen diese Übergänge stabil abfangen.
Die Dauerleistung einer USV beschreibt nur einen Teil der Eignung. Hohe C-Raten und thermische Belastung der Batteriesysteme werden bei schnellen Leistungsanstiegen relevant. Besonders Lithium-Ionen-USV-Systeme müssen für das konkrete Lastprofil bewertet werden. Eine Anlage, die für eine gleichmäßige Serverlast dimensioniert wurde, ist nicht automatisch für einen dichten GPU-Cluster geeignet.
Das betrifft drei Ebenen:
- Server-Netzteile: Redundanz schützt vor dem Ausfall eines Netzteils. Sie ersetzt keine Leistungsreserve. Bei N+1-Auslegung muss das verbleibende Netzteilset die reale Spitzenlast tragen können.
- Rack-Stromkreis: Die Leistungsaufnahme pro Rack bestimmt Absicherung, Phasenverteilung und Kabeldimensionierung. Ein einzelnes Hochdichte-GPU-System kann die bisherige Rackplanung entwerten.
- USV und Einspeisung: Die Anlage muss schnelle Lastwechsel ohne Spannungseinbruch abfangen. Die thermische Auslegung der USV bleibt Teil der Gesamtplanung.
Eine Messung nur am Stromzähler des Racks ist zu grob. Erforderlich sind zeitlich hochaufgelöste Leistungsdaten während typischer Trainings-, Inferenz- und Initialisierungsphasen. Besonders kritisch sind Startphasen, Modellladevorgänge und Lastwechsel zwischen Batches. Hier entstehen die Spitzen, nicht im gemittelten Tagesverbrauch.
Die zweite Messgröße ist Temperatur. GPU-Temperatur allein reicht nicht. Relevant sind auch Einlasstemperatur, Ablufttemperatur, Lüfterdrehzahl, Netzteiltemperatur und eventuelle Drosselungsereignisse. Erst diese Kombination zeigt, ob die berechnete Leistungsdichte im realen Rack stabil betrieben werden kann.
Die Auswahl beginnt mit der Datenbewegung
Die richtige Server-GPU ist kein isoliertes Bauteil. Sie ist Teil eines Datenpfads aus CPU, PCIe-Fabric, Arbeitsspeicher, NVMe, Netzwerk, Stromversorgung und Kühlung.
Für Inferenz und visuelle Beschleunigung kann eine PCIe-GPU wie die L40S mit 48 GB ECC-GDDR6 und 350 Watt eine zweckmäßige Plattform bilden. Die Einschränkung ist klar: keine NVLink-Kopplung. Für eng gekoppelte Trainingslasten mit mehreren GPUs verschiebt sich die Anforderung auf SXM-Systeme mit NVLink, ausreichender Rackleistung und einem dafür vorgesehenen Kühlkonzept.
Die Beschaffung ist abgeschlossen, wenn die GPU zum Workload passt. Die Architektur ist erst abgeschlossen, wenn jede GPU ihre volle PCIe-Anbindung erhält, ihre lokale NUMA-Domäne kennt, unter Last nicht drosselt und die Stromversorgung Lastwechsel beherrscht.
| Auswahlparameter | PCIe-basierter GPU-Server | NVLink-/SXM-basierter GPU-Server |
|---|---|---|
| Geeigneter Schwerpunkt | Inferenz, Rendering, getrennte GPU-Workloads | Verteiltes Training, Modellparallelisierung, eng gekoppelte GPU-Lasten |
| Host-Anbindung | PCIe Gen 4 oder Gen 5, bevorzugt x16 pro GPU | PCIe für Host- und Peripherieanbindung |
| GPU-zu-GPU-Transport | PCIe, maximal 128 GB/s bei Gen 5 x16 | NVLink bis 900 GB/s bei H100/H200 |
| CPU-Anforderung | ausreichende Lane-Zahl, saubere Slot-Zuordnung | hohe Lane-Zahl plus abgestimmte Plattformtopologie |
| Typische Leistungsaufnahme pro GPU | etwa 350 bis 400 W bei H100 PCIe | bis zu 700 W bei H100 SXM |
| Kritischer Planungsfehler | x16-Slot mit nur x8 elektrischer Anbindung | unterschätzte Rack-, Kühl- und USV-Kapazität |
| Technische Priorität | PCIe-Lanes, Luftstrom, NUMA-Zuordnung | NVLink-Topologie, Leistungsdichte, Infrastrukturreserve |