Warum der Cloud-Router zum Flaschenhals wird
Bei KI-Clustern denken die meisten zuerst an GPU-Kapazität, VRAM oder Modellgröße. Doch in der Praxis ist die Netzwerk-Infrastruktur – insbesondere der Cloud-Router – oft der limitierende Faktor für API-Inferenz. Ein Router, der nicht für hochfrequente, latenz-sensitive Kommunikation ausgelegt ist, erzeugt genau die Engpässe, die du mit zusätzlichen GPUs nicht beheben kannst.
Was einen Cloud-Router für KI-Cluster auszeichnet
Ein klassischer Router priorisiert nach IP-Adressen und Ports. Ein KI-Cluster benötigt jedoch eine Latenz-optimierte Weiterleitung und intelligentes Traffic-Shaping für synchrone Inferenz-Requests. Die entscheidenden Spezifikationen sind:
- Durchsatz: Mindestens 100 Gbit/s pro Node, besser 400 Gbit/s für Multi-Node-Cluster.
- Packet-PPS: Hohe Packets-per-Second-Werte (über 50 Mpps), da Inferenz-Requests viele kleine Pakete erzeugen.
- Buffer-Speicher: Ausreichend On-Chip-Buffer, um Burst-Traffic abzufedern ohne Tail-Latenz.
- Anycast-Unterstützung: Für globale API-Endpunkte und geringere DNS-Latenz.
VRAM-Anforderungen und Routing-Entscheidungen
Die Routing-Strategie hängt stark vom VRAM-Bedarf deiner Modelle ab. Ein 70B-Parameter-Modell mit 16-Bit-Gewichten benötigt mindestens 140 GB VRAM (z. B. 2× H100 80GB). Das bedeutet: Dein Router muss Requests an den richtigen GPU-Pod weiterleiten, ohne dass die GPU-Auslastung über 85 % steigt. Eine praktische Faustregel:
- VRAM-Auslastung < 70 %: Round-Robin-Routing
- VRAM-Auslastung 70–85 %: Least-Connected-Routing
- VRAM-Auslastung > 85 %: Requests an Warteschlange oder sekundären Cluster
Nutze dazu ein Service-Mesh oder einen Application-Load-Balancer, der GPU-Metriken exponiert – nicht nur CPU- und RAM-Werte.
CLI-Befehle, die du kennen solltest
Die meisten Cloud-Router (z. B. auf Basis von FRRouting oder Bird) lassen sich über die CLI optimieren. Ein Beispiel für BGP-Anycast-Routing:
router bgp 65000
neighbor 10.0.0.1 remote-as 65001
address-family ipv4 unicast
network 192.168.10.0/24 route-map INFERENCE_LOW_LATENCY
exit-address-family
route-map INFERENCE_LOW_LATENCY permit 10
set local-preference 150
Zusätzlich solltest du die TCP-Stack-Parameter anpassen:
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
Damit reduzierst du die Queue-Latenz erheblich, besonders bei bursty Inferenz-Requests.
Technische Fallstricke bei Kubernetes-Clustern
Wenn du Kubernetes verwendest, ist kube-proxy oft der Flaschenhals. Setze stattdessen auf eBPF-basiertes Routing (z. B. Cilium). Das ersetzt iptables-Regeln durch effizientere eBPF-Programme im Kernel:
cilium install --set routing-mode=native --set auto-direct-node-routes=true
Wichtig: Aktiviere Socket-Load-Balancing, damit die Verbindung auf dem gleichen Node bleibt, wenn möglich. Das spart Latenz und reduziert den Router-Durchsatz erheblich.
Monitoring: So erkennst du Engpässe frühzeitig
Setze nicht nur auf klassisches Ping-Monitoring. Überwache gezielt:
- Inflight-Requests pro Router-Node – nicht nur Requests pro Sekunde.
- 99. Perzentil Latenz zwischen Client und GPU-Pod.
- TCP-Retransmissionen (Anzeiger für verlorene Packete durch Router-Queue-Overflow).
- GPU-Cache-Misses – wenn der Router Requests an einen Pod sendet, der das Modell nicht im Cache hat.
Ein effektives Toolset dafür ist prometheus zusammen mit grafana. Ein einfacher Check für die Queue-Last im Router:
watch -n 1 'ss -s | grep -E "TCP|UDP"'
Empfehlungen für die Praxis
Für ein typisches KI-Cluster mit 8–16 GPUs empfehle ich:
- Software-Router: VPP (Vector Packet Processing) auf einem dedizierten Node mit 2× 100G NICs – kostengünstig und extrem performant.
- Hardware-Router: NVIDIA Spectrum-2/3 oder Arista 7800R-Serie, wenn du über 100 Gbit/s pro Pod skalierst.
- VPN-interne Ratenbegrenzung: Nicht vergessen, pro API-Token ein
rate-limitzu setzen, um Fan-out-Bursts zu vermeiden.
Denke daran: Ein Router, der nur für klassisches Web-Traffic gebaut ist, wird dein KI-Cluster ausbremsen. Investiere in einen Router, der Latenz-Metriken direkt an dein Monitoring liefert – dann bleiben deine API-Inferenzen schnell und deine GPU-Ressourcen werden effizient genutzt.
