AI, AI, AI - in 2 bis10 Microsekunden KI und Cloud Native: Freund oder Feind?

Wer sich Stimmen aus manchem KI-Interessenverband anhört, gewinnt schnell den Eindruck, Bestandsrechenzentren seien reif für die Abrissbirne. Beißen sich denn die KI-Workloads mit Cloud-nativen Infrastrukturen? Was meint die Kubernetes-Gemeinde?

Die rasante Entwicklung von Künstlicher Intelligenz (KI) und Cloud-nativer IT hat neuartige Anforderungen an die Infrastruktur hervorgebracht und stellt bewährte Ansätze im Bereich des Rechenzentrumsdesigns, Software-Architekturen und Betriebspraxis schon wieder in Frage. Während Cloud-native Workloads bisher Elastizität, Zustandslosigkeit und horizontale Skalierbarkeit priorisierten, kommen KI-Workloads mit Prioritäten daher, die sich mit der Bestands-IT nicht gut vertragen.

KI-Arbeitslasten gehören am besten gleich auf KI-Infrastrukturen, logisch - im Idealfall. Das soll jetzt aber nicht bedeuten, dass sich KI-Workloads in Cloud-nativen Umgebungen per se nicht ausführen ließen. Ganz im Gegenteil! Da gibt es sogar extra Punkte für.

Die Pioniere der Cloud-nativen Containerisierung von KI-Modellen sehen in der Containerisierung von KI erhebliche Vorteile - nachdem diese erst einmal eine Reihe von Herausforderungen auf der Infrastrukturebene überwunden haben.

Strom, Hitze, Daten

KI-Workloads, insbesondere das Training großer Sprachmodelle (LLMs wie „GPT-4.x“), erfordern GPU-Cluster mit einer Leistungsdichte, die pro Rack so um die 30 bis 100 Kilowatt und mehr erreichen kann, abhängig vom GPU-Modell und der Anzahl der Chips – das ist der 2,5- bis 8-fache Energiebedarf traditioneller Cloud-nativer Arbeitslasten. In der Praxis ist somit dreiphasige Stromversorgung notwendig (208- bis 480-Volt-Systeme), um die Energie effizient zu verteilen.

Verantwortlich für diesen enormen Bedarf sind GPUs wie „Nvidia A100“ und „H100“, deren Architektur speziell auf Matrixoperationen optimiert ist. Cloud-native Microservices hingegen nutzen meist CPU-zentrierte Architekturen mit einem Energieverbrauch von lediglich 5 bis 10 kW pro Rack und skalieren horizontal, um Lastspitzen abzufangen.

Die Energie-intensive Natur der KI zeigt sich auch bei der Speicherbandbreite: Moderne KI-Cluster erreichen bis zu 140 Gigabis pro Sekunde (GB/s) pro Knoten mit „GPUDirect Storage“. Typische Cloud-native Apps liegen bei 1 bis 4 GB/s pro Node – selbst NVMe-basierte Lösungen wie „Ceph“ schaffen selten über 20 GB/s, wobei Ausnahmen, zum Beispiel bei In-Memory-Datenbanken, bis 50 GB/s erreichen können.

Die Anforderungen

KI-Fabriken setzen daher eher auf Flüssigkeitskühlung als andere Rechenzentren. Nicht weiter schlimm: Der Bruch mit luftgekühlten Konzepten und Warm-/Kaltgang-Einhausungen steht in der Regel ohnehin schon auf der Zu-Erledigen-Liste für aufkommende Modernisierungsprojekte.

Der unersättliche Hunger von KI-Anwendungen nach unstrukturierten Daten, etwa Bildern und großen Textmengen, erfordert hochperformante parallele Dateisysteme wie „Lustre“ von OpenSFS/EOFS oder „BeeGFS“ von der Thinkarq GmbH aus Kaiserslautern - Systeme, die viele aus dem universären HPC-Umfeld kennen. Diese Lösungen können pro Knoten Durchsatzraten von 10 bis 100 GB/s während des Trainings bereitstellen.

Hinzu kommen vektorbasierte Datenbanken wie „Pinecone“ oder „Milvus“, die während der Inferenzphase mit intensiven, zufälligen Lesezugriffen das Speichersystem zusätzlich belasten. Cloud-native Workloads bevorzugen hingegen typischerweise Objektspeicher wie „Minio“ und „Swiftstack“ sowie Blockspeicher, die speziell für kleine, häufige Transaktionen optimiert sind.

Der Herzschlag eines KI-Clusters

KI-Trainingscluster müssen Parametersynchronisation über Tausende von GPUs hinweg bewältigen. Das Training von GPT-4 verlangt Latenzen unterhalb von 2 Microsekunden (µs) pro Hop in der Netzwerkkommunikation. Darum sind hier latenzarme Technologien wie „RoCEv2“ (RDMA over Converged Ethernet) oder Nvidia „NVLink“ — nach Möglichkeit — Pflicht.

Die GPU Technology Conference 2025 sprengt erneut Leistungsgrenzen

Nvidia stellt DIE Infra­struktur fürs AI-Zeitalter in Aussicht

Speicherzentrierte Interconnects für KI-Beschleuniger

UALink, CXL & Co. - eine Revolte gegen NVLink von Nvidia

Frameworks für das Accelerated Computing im Vergleich

CUDA, HIP/ROCm oder Unified DNA und oneAPI auf dem Schachbrett der KI-Vorherrschaft

Dies gilt nur für intra-Rack-Kommunikation (NVLink/InfiniBand). Bei Cross-Rack-Traffic steigt die Latenz auf 5 bis 10 µs.

Cloud-native Workloads arbeiten im Gegensatz dazu fast schon asynchron. Sie setzen auf softwaredefinierte Konnektivität (SDN) und optimiertes East-West-Traffic-Management. Sie tolerieren höhere Latenzen, sodass sich Lastspitzen über Lastverteiler und Service-Meshes wie „Istio“ abfedern lassen.

Dieser Unterschied schlägt sich unmittelbar in der Verkabelung nieder: KI-Racks nutzen typischerweise Hochleistungsverbindungen mit 400 Gbit/s Infiniband oder Quantum-Leap-Kabel für die GPU-zu-GPU-Kommunikation, während Cloud-native Infrastrukturen meist mit Ethernet-Verbindungen in Spine-Leaf-Topologien mit gerade einmal 25 bis 100 Gbit/s inklusive TCP/IP-Offloading auskommen.

Also doch lieber wieder Kubernetes?

Kubernetes, die führende Orchestrierungsplattform für Cloud-native Anwendungen, gilt als der bevorzugte Weg zur Bereitstellung von containerisierten Anwendungen. In diesen portablen Paketen von Softwarelogik lassen auch KI-Modelle bündeln. Wer dies wagt, kann sie dann auf Kubernetes-Clustern ausrollen.

Gerade für KI-Modelle kann die Containerisierung beachtliche Vorteile bedeuten, da jedes Modell oft eigene, zum Teil sogar widersprüchliche Abhängigkeiten mit sich bringt. Die Isolation dieser Abhängigkeiten innerhalb von Containern erhöht die Flexibilität isolierter Modellbereitstellung. Cloud-native Werkzeuge können so eine skalierbare Implementierung von KI-Modellen ermöglichen.

Einziges Problem: Die benötigten Tools sind für die Anforderungen von KI-Arbeitslasten momentan nicht ausgelegt.

Verteiltes KI-Training großer Modelle auf cloud-nativen Kubernetes-Plattformen geht mit einem Durchsatzverlust von 20 bis 30 Prozent gegenüber reinen Bare-Metal-Umgebungen einher. Dieses Ausbremsen der „Datenzufuhr“ lässt sich hauptsächlich auf den Overhead der Netzwerkvirtualisierung zurückführen. Technologien wie „GPUDirect RDMA“ und „SR-IOV“-Passthrough wirken diesem Leistungsverlust entgegen, indem sie den Kernel-Netzwerk-Stack umgehen. Der Verlust tritt aber nur beim Training großer Modelle auf. Bei Inferenz, zum Beispiel mit „KServe“ liegt der Overhead bei weniger als 5 Prozent, wenn SR-IOV/GPUDirect genutzt wird.

Speicherzugriff ohne Umwege

Was ist RDMA - Remote Direct Memory Access?

Auf dem Server „Dell Poweredge XE9680“ verursacht „vSphere“ laut Zahlen von VMware einen Performance-Overhead von gerade einmal 2 bis 4 Prozent im Vergleich zu Bare-Metal-Systemen bei netzwerkentkoppelter Offline-Inferenz (siehe: Grafik). Dieser minimale Unterschied zeigt, dass virtualisierte Umgebungen durchaus in der Lage sein können, leistungsintensive Inferenzaufgaben effektiv zu unterstützen und das bei kaum spürbaren Einbußen beim Durchsatz, sofern sie auf das Netzwerk nicht angewiesen sind und nicht hinaus skalieren müssen.

Die eigentliche Musik spielt sich zwischen der Leistung einer Cloud-nativen Infrastruktur und einer KI-Fabrik ab. Für die Diskrepanz gibt es mehrere Gründe, nicht zuletzt die leistungsstarke Konnektivität via NVLink und Quantum-2 Infiniband.

Die NVLink-4.0-Interconnects erreichen eine Bandbreite von 900 GB/s zwischen den GPUs innerhalb eines Nodes anstelle von 64 GB/s wie im Falle von PCIe 4.0. Dieser Unterschied lässt sich auf architektonische Entscheidungen von Nvidia wie die direkte GPU-zu-GPU-Kopplung, die höheren Taktfrequenzen, kürzere Distanzen, parallele Datenleitungen und spezialisierte Protokolle zurückführen.

Während sich KServe/Kubernetes-Cluster mit RoCEv2 (200 Gbps) und einer Netzwerklatenz von 50 bis100 μs zufriedengeben (schöne Grüße an vSwitch), setzt Nvidia für die netzwerkseitige Kommunikation zwischen Nodes — den Servern und GPU-Clustern in den KI-Fabriken — auf „Quantum-2 Infiniband“ (400 Gbps) für eine Latenz von unterhalb 2μs (Bare-Metal-RDMA).

Die vergleichsweise geringe Skalierbarkeit eines KServe/Kubernetes-Clusters beschränkt automatisch die Modellgröße. KI-Fabriken setzen auf einen vollständig abgestimmten Stack („Full-Stack Co-Design“), dei den Overhead der Container-Laufzeitumgebung von Kubernetes mit spezialisierten Kerneln und anderen ähnlichen Optimierungen umgehen und die GPU-Auslastung maximieren.

Leistungsunterschiede

Die Kubernetes-Community arbeitet derzeit daran, diese Leistungsdifferenz durch Initiativen wie „Kuberay“ für elastisches Training und die Nutzung von „Nvidia Bluefield“-DPUs zur Entlastung der CPUs zu reduzieren. Wenn es nach der Kubernetes-Gemeinde geht, dürfte sich der Leistungsunterschied zwischen Kubernetes-basierten Anwendungen und spezialisierten KI-Fabriken im Laufe des kommenden Jahres auf weniger als 15 Prozent verringern. Das ist jedenfalls so die vorläufige Zielsetzung.

Obwohl KI- und Cloud-native Workloads bisher in der Tat sehr unterschiedliche Anforderungen an die Infrastruktur stellen, insbesondere in Bezug auf Leistungsdichte, Kühlung und Netzwerkarchitektur, erweist sich das Kubernetes-Ökosystem als bemerkenswert flexibel und zuvorkommend. Cloud-native Unternehmen, die KI-Arbeitslasten integrieren wollen, können den Umstieg aber schrittweise vollziehen.

Der gezielte Einsatz des Nvidia-GPU-Operators, Kubeflow-Pipelines und KServe in Verbindung mit selektiven Infrastruktur-Upgrades hilft, vorhandene Cloud-native Investitionen zu nutzen und gleichzeitig die besonderen Anforderungen von KI-Workloads mit möglichst niedrigen Kapitalausgaben zu erfüllen. Die starke Ausrichtung der Kubernetes-Community auf KI-native Abstraktionen wie Kuberay und „Volcano“ hält das Versprechen, dass Cloud-native Infrastrukturen auch dann noch tragfähig bleiben, wenn KI-Modelle in ihrer Komplexität exponentiell wachsen.

(ID:50402547)