KI-Training vs. Inferenz: Unterschiedliche Netzwerkanforderungen und Architekturstrategien

Einführung

Obwohl KI-Training und -Inferenz beide GPUs und Beschleuniger nutzen, unterscheiden sich ihre Netzwerkanforderungen grundlegend. Das Training erfordert enorme Bandbreite für die Gradientensynchronisation über Tausende von GPUs hinweg, während bei der Inferenz geringe Latenz, hoher Durchsatz und Kosteneffizienz Priorität haben. Das Verständnis dieser unterschiedlichen Anforderungen ist entscheidend für die Entwicklung einer optimierten Infrastruktur. Dieser Artikel analysiert die Netzwerkeigenschaften der jeweiligen Arbeitslasten und untersucht optimale Architekturstrategien.

Merkmale der Arbeitsbelastung: Eine grundlegende Kluft

Trainingsbelastung

Das Training beinhaltet die iterative Aktualisierung der Modellparameter auf Basis von Trainingsdatensätzen, die über verteilte GPUs verarbeitet werden:

Kommunikationsmuster:

• All-Reduce-Operationen: Jede GPU tauscht Gradienten mit allen anderen GPUs aus.
• Bulk Synchronous Parallel (BSP): synchronisierte Barrieren zwischen Trainingsschritten
• Kollektive Kommunikation dominiert (70-80 % des Netzwerkverkehrs).

Verkehrsmerkmale:

• Große, vorhersehbare Datenübertragungen (Hunderte von GB pro All-Reduce-Vorgang)
• Synchronisierte Bursts auf allen GPUs gleichzeitig
• Elefantenströme: langlebige Verbindungen mit hohem Volumen
• Deterministische Muster, die sich in jeder Trainingsiteration wiederholen

Leistungskennzahlen:

• Bandbreitenauslastung: 80-95 % während des Trainings aufrechterhalten.
• Dauer: Stunden bis Wochen ununterbrochenen Betriebs
• Latenztoleranz: 100–500 µs akzeptabel für Gradientensynchronisation
• Jitterempfindlichkeit: hoch (beeinträchtigt Konvergenz und Trainingsstabilität)

Inferenz-Workloads

Inferenzprozesse verarbeiten einzelne Benutzeranfragen oder kleine Datenmengen, um Vorhersagen zu generieren:

Kommunikationsmuster:

• Anfrage-Antwort-Verfahren: Der Client sendet die Eingabe, das Modell liefert die Vorhersage.
• Asynchrone, unabhängige Anfragen ohne GPU-übergreifende Koordination
• Punkt-zu-Punkt-Kommunikation (Load Balancer → GPU → Client)

Verkehrsmerkmale:

• Kleine Anfragen variabler Größe (KB- bis MB-Bereich)
• Schwankender, unvorhersehbarer Datenverkehr, der durch das Nutzerverhalten verursacht wird
• Mäuseflüsse: kurzlebige Verbindungen mit geringem Volumen
• Hohe Anfragerate (Tausende bis Millionen Anfragen pro Sekunde)

Leistungskennzahlen:

• Bandbreitenauslastung: 10-40% (deutlich geringer als beim Training)
• Dauer: Millisekunden pro Anfrage
• Latenz ist entscheidend: unter 10 ms End-to-End-Latenz für Echtzeitanwendungen
• Tail-Latenz (P99): muss für ein optimales Nutzererlebnis streng kontrolliert werden.

Vergleich der Netzwerkanforderungen

Dimension	Ausbildung	Schlussfolgerung	Verhältnis
Bandbreite pro GPU	400-800 Gbit/s	10-100 Gbit/s	8-80x
Latenz (P50)	200-500 μs	1-5 ms	—
Latenz (P99)	1-2 ms akzeptabel	<10 ms kritisch	—
Jittertoleranz	Niedrig (beeinträchtigt die Konvergenz)	Sehr niedrig (beeinträchtigt die Benutzererfahrung)	—
Durchsatzpriorität	Massendatenverschiebung	Anfragerate (QPS)	—
Verkehrsvorhersagbarkeit	Hochgradig vorhersehbar	Sehr variabel	—
Nutzungsmuster	Anhaltend 80-95%	Ausbruchsartig 10-40%	—

Architektur des Schulungsnetzwerks

Gestaltungsprinzipien

• Maximale Bandbreite für die Bisektion: Nicht-blockierende Architektur zur Vermeidung von Gradientensynchronisationsengpässen
• Durchmesser minimieren: Weniger Hops reduzieren die Gesamtlatenz.
• RDMA-Optimierung: Datentransfer ohne Kopien für maximale Effizienz
• Adaptives Routing: Verteilung des Datenverkehrs auf mehrere Pfade zur Vermeidung von Hotspots.

Empfohlene Topologie

Fettbaum oder 2-stufiges Dorn-Blatt (CLOS)

• Volle Bandbreitenbegrenzung (1:1 Überbuchung oder besser)
• Jeder Blattschalter ist mit jedem Hauptschalter verbunden.
• 2-3 Hop-Latenz zwischen zwei beliebigen GPUs
• Skaliert auf über 10.000 GPUs mit vorhersehbarer Leistung

Protokollstapel

InfiniBand (bevorzugt) oder RoCE v2

• InfiniBand: Natives RDMA, adaptives Routing, Staukontrolle
• RoCE v2: RDMA über Ethernet, geringere Kosten, breiteres Ökosystem
• Beide unterstützen GPUDirect RDMA für direkte GPU-zu-GPU-Datenübertragungen.

Schlüsseltechnologien

• NCCL (NVIDIA Collective Communications Library): Optimierte All-Reduce-Algorithmen
• GPUDirect RDMA: CPU-Umgehung für GPU-zu-Netzwerk-Datenübertragungen
• Prioritätsflusssteuerung (PFC): Paketverluste bei Überlastung verhindern
• ECN (Explizite Staumeldung): Proaktives Staumanagement

Bandbreitenzuweisung

Für ein DGX H100-System mit 8 GPUs:

• 8 x 400 Gbit/s InfiniBand-Netzwerkkarten = 3,2 Tbit/s Gesamt
• Jeder GPU stehen dedizierte 400 Gbit/s für die Kommunikation zwischen den Knoten zur Verfügung.
• Innerhalb eines Knotens: NVLink bietet eine GPU-zu-GPU-Bandbreite von 900 GB/s.

Beispiel: Metas KI-Forschungs-Supercluster (RSC)

• Umfang: 16.000 NVIDIA A100 GPUs
• Netzwerk: NVIDIA Quantum-2 InfiniBand mit 400 Gbit/s pro GPU
• Topologie: 5-stufige CLOS mit 25,6 Tbit/s Bisektionsbandbreite
• Leistung: Über 90 % GPU-Auslastung bei GPT-skalierten Modellen

Inferenznetzwerkarchitektur

Gestaltungsprinzipien

• Latenz optimieren: Hops und Warteschlangenverzögerung minimieren
• Überzeichnung akzeptabel: Blatt-zu-Dornen-Verhältnis 4:1 oder sogar 10:1
• Edge-Optimierung: Inferenz in der Nähe der Nutzer platzieren (CDN-ähnliche Verteilung)
• Elastische Skalierung: Automatische Anpassung der GPU-Kapazität an die Anforderungslast

Empfohlene Topologie

2-stufige Blattstruktur mit Überzeichnung

• Überbuchungsverhältnis von 4:1 bis 10:1 (kostenoptimiert)
• Blattschalter am Netzwerkrand für Zugriff mit geringer Latenz
• Spine ermöglicht die Verbindung zwischen den Racks.
• Skaliert horizontal durch Hinzufügen von Blattschaltern

Protokollstapel

TCP/IP mit HTTP/2 oder gRPC

• Standard-Ethernet (kein RDMA erforderlich)
• HTTP/2 für das Multiplexen mehrerer Anfragen über eine einzelne Verbindung
• gRPC für effiziente Binärserialisierung
• TLS zur Verschlüsselung (verursacht eine Latenz von ca. 1 ms, ist aber aus Sicherheitsgründen erforderlich)

Schlüsseltechnologien

• Lastverteilung: Verteilung der Anfragen auf den GPU-Pool (NGINX, Envoy, AWS ALB)
• Anfragebündelung: Mehrere Anfragen werden zusammengefasst, um die GPU-Auslastung zu verbessern.
• Modell-Caching: Häufig verwendete Modelle im GPU-Speicher halten, um Nachladeverzögerungen zu vermeiden
• Verbindungspooling: Wiederverwendung von TCP-Verbindungen zur Reduzierung des Handshake-Overheads.

Bandbreitenzuweisung

Für einen Inferenzserver mit 8x A100 GPUs:

• 2 x 100-Gbit/s-Ethernet-Netzwerkkarten (gebündelt) = 200 Gbit/s Gesamt
• Durchschnittlich 25 Gbit/s pro GPU (gegenüber 400 Gbit/s beim Training)
• Ausreichend für mehr als 10.000 Anfragen pro Sekunde bei typischen Batchgrößen

Beispiel: OpenAI ChatGPT-Inferenzinfrastruktur

• Umfang: Geschätzte 10.000+ GPUs (A100/H100-Mix)
• Netzwerk: Standard-Ethernet mit intelligentem Lastausgleich
• Topologie: Geografisch verteilte Edge-Cluster für geringe Latenz
• Leistung: Antwortzeiten im Subsekundenbereich für die meisten Anfragen

Hybridarchitekturen: Training + Inferenz

Viele Organisationen betreiben beide Workloads auf gemeinsam genutzter Infrastruktur. Wichtige Strategien:

Strategie 1: Separate Cluster

Ansatz: Dedizierter Trainingscluster (hohe Bandbreite) + dedizierter Inferenzcluster (latenzoptimiert)

Vorteile:

• Optimale Leistung für jede Arbeitslast
• Keine Ressourcenkonflikte
• Vereinfachte Kapazitätsplanung

Nachteile:

• Höhere Kapitalkosten (doppelte Infrastruktur)
• Geringere Gesamtauslastung der GPUs (Trainingscluster sind zwischen den Jobs im Leerlauf)

Ideal für: Große Organisationen mit kontinuierlichem Schulungsbedarf und hohem Datenaufkommen

Strategie 2: Zeitlich aufgeteilter gemeinsam genutzter Cluster

Vorgehensweise: Dieselben GPUs für das Training (außerhalb der Spitzenzeiten) und die Inferenz (Spitzenzeiten) verwenden.

Vorteile:

• Höhere GPU-Auslastung (80-90% gegenüber 50-60% bei dedizierten Grafikkarten)
• Niedrigere Kapitalkosten

Nachteile:

• Komplexe Orchestrierung erforderlich
• Aufwand für das Laden/Entladen des Modells (Minuten)
• Risiko, dass Schulungsaufträge die SLAs für Inferenz beeinträchtigen

Ideal für: Mittelgroße Installationen mit vorhersehbaren Verkehrsmustern

Strategie 3: Mehrstufiges Netzwerk (Schienenoptimiert)

Vorgehensweise: Getrennte physikalische Netzwerke für das Training (InfiniBand mit hoher Bandbreite) und die Inferenz (Standard-Ethernet)

Vorteile:

• Die Trennung der Arbeitslast verhindert Störungen
• Kostenoptimiert (teure Stoffe nur dort, wo sie nötig sind)
• Flexible Ressourcenzuweisung

Nachteile:

• Erhöhte Komplexität der Verkabelung und der Schalter
• Erfordert Server mit zwei Netzwerkkarten.

Ideal für: Hyperscale-Bereitstellungen mit gemischten Arbeitslasten

Kostenanalyse: Trainings- vs. Inferenznetzwerke

Vergleich eines Clusters mit 1024 GPUs

Komponente	Training (400G IB)	Inferenz (100G Eth)
NICs	8 Mio. $ (8x 400 GB IB/GPU)	500.000 US-Dollar (2x 100G Ethernet/GPU)
Schalter	4,8 Mio. USD (nicht blockierend)	1,2 Mio. USD (4:1 Überzeichnung)
Optik	2 Millionen US-Dollar	200.000 US-Dollar
Gesamtnetzwerk	14,8 Mio. US-Dollar	1,9 Mio. US-Dollar
% der GPU-Kosten	49%	6%

Trainingsnetzwerke sind aufgrund des Bandbreitenbedarfs 7-8 Mal teurer als Inferenznetzwerke.

Techniken zur Leistungsoptimierung

Für Schulungszwecke

• Gradientenkomprimierung: Reduzierung des gesamten Datenvolumens um den Faktor 10-100 (FP16-, INT8-Quantisierung)
• Hierarchisches All-Reduce: NVLink-Verbindung innerhalb eines Knotens, InfiniBand-Verbindung zwischen Knoten nutzen
• Pipeline-Parallelität: Überlappende Kommunikation mit Berechnung
• ZeRO Optimizer: Partitionierung der Optimierungszustände zur Reduzierung von Speicher- und Kommunikationsaufwand

Zum Schluss

• Anfragebündelung: Zusammenfassung von 8–32 Anfragen zur Verbesserung der GPU-Auslastung
• Modellquantisierung: INT8/INT4 reduziert die Modellgröße und die Übertragungszeit.
• KV-Cache-Optimierung: Wiederverwendung des Aufmerksamkeitscaches für mehrstufige Konversationen
• Spekulative Dekodierung: Reduzierung der Latenz bei autoregressiver Generierung

Überwachung und Beobachtbarkeit

Trainingskennzahlen

• Latenz vollständig reduzieren (P50, P99, P99,9)
• Netzwerkbandbreitenauslastung pro GPU
• Paketverlustrate (sollte bei PFC 0 sein)
• GPU-Auslastung (Ziel: 90%+)

Inferenzmetriken

• Anfragelatenz (P50, P95, P99)
• Anfragen pro Sekunde (QPS)
• GPU-Speicherauslastung
• Warteschlangenlänge und Wartezeit

Zukunftstrends

Ausbildung

• 800G/1,6T InfiniBand: Unterstützung von Modellen mit Billionen von Parametern
• Optische Leitungsvermittlung: Rekonfigurierbare Topologien für dynamische Arbeitslasten
• Netzwerkinterne Datenverarbeitung: Auslagerung der All-Reduce-Prozesse auf SmartNICs/DPUs

Schlussfolgerung

• Edge-Inferenz: Modelle auf 5G-Basisstationen für eine Latenz von unter 1 ms bereitstellen
• Serverlose Inferenz: Automatische Skalierung von 0 auf Tausende von GPUs in Sekundenschnelle
• Modellkomprimierung: Destillation und Beschneidung reduzieren die Anforderungen an die Netzwerkübertragung

Abschluss

Training und Inferenz stellen die beiden Extreme des Spektrums der Netzwerkanforderungen dar. Training erfordert maximale Bandbreite bei moderater Latenztoleranz, während Inferenz geringe Latenz bei moderatem Bandbreitenbedarf priorisiert. Das Verständnis dieser Unterschiede ist für eine kosteneffiziente Infrastrukturplanung unerlässlich.

Wichtigste Erkenntnisse:

• Trainingsnetzwerke kosten pro GPU 7-8 Mal mehr, sind aber für ein effizientes verteiltes Training unerlässlich.
• Inferenznetzwerke können Standard-Ethernet mit Überbelegung nutzen, um die Kosten zu senken.
• Hybridarchitekturen erfordern eine sorgfältige Trennung der Arbeitslasten, um Interferenzen zu vermeiden.
• Netzwerkoptimierung (Komprimierung, Batchverarbeitung) kann die Leistung beider Arbeitslasten drastisch verbessern.

Da KI-Modelle immer skalierbarer werden, bleibt das Netzwerk ein entscheidender Wettbewerbsvorteil – Organisationen, die ihre Infrastruktur an die Workload-Charakteristika anpassen, werden überlegene Leistung und Wirtschaftlichkeit erzielen.