Orchestrierung von Bare-Metal-KI: TrueFoundry-Integration mit Oracle Cloud Infrastructure

Bereitstellung verteilter Trainingsjobs oder Inferenz mit hohem Durchsatz für Oracle Cloud-Infrastruktur (OCI) erfordert einen spezifischen architektonischen Ansatz. OCI bietet Bare-Metal-GPU-Instanzen ohne Hypervisor-Overhead und Direkter Speicherzugriff per Fernzugriff (RDMA) Cluster-Netzwerke über konvergentes Ethernet.

Eine Bare-Metal-Infrastruktur maximiert zwar die Leistung, erfordert jedoch ein fortschrittliches Betriebsmanagement. Sie müssen Netzwerkschnittstellen konfigurieren, NVIDIA-Treiber auf niedriger Ebene verwalten und Knotenausfälle manuell behandeln, ohne die Abstraktionsebene der verwalteten Virtualisierung nutzen zu müssen. TrueFoundry fungiert als Infrastruktur-Overlay innerhalb Ihrer OCI-Tenancy. Es übersetzt Workloads auf hoher Ebene für maschinelles Lernen in exakte Bare-Metal-Ausführungsbefehle. Im Folgenden wird die technische Integration zwischen TrueFoundry und OCI detailliert beschrieben, wobei der Schwerpunkt auf Kubernetes-Orchestrierung, RDMA-Netzwerken und Workload-Identität liegt.

Bereitstellungsmodell: Control Plane vs. Compute Plane

TrueFoundry verwendet eine Split-Plane-Architektur. Die Control Plane verwaltet RBAC, Metadaten und Routing. Die Compute Plane führt die Modellgewichtungen aus und verarbeitet die Kundendaten. In einer OCI-Umgebung führen Sie Compute Plane aus Oracle Cloud Infrastructure Kubernetes Engine (OKE).

Die Control Plane hostet den API-Server und die Planungslogik. Der TrueFoundry Agent wird auf Ihrem OKE-Cluster ausgeführt. Der Agent initiiert eine reine Ausgangsverbindung gRPC oder WebSocket-Stream, um nach Bereitstellungsmanifesten abzufragen. Durch dieses Design entfällt die Anforderung an standardmäßige eingehende Ports im Virtual Cloud Network (VCN), sodass Ihre Ausführungsumgebung privat bleibt.

Abbildung 1: Die Split-Plane-Architektur isoliert die Datenverarbeitung innerhalb des Kunden-VCN.

Netzwerk: Abstraktion von RoCE v2 und RDMA

Das Training großer Sprachmodelle erfordert eine enorme Bandbreite von Knoten zu Knoten. OCI bietet ein spezialisiertes Cluster-Netzwerk, das eine Latenz von nur zwei Mikrosekunden erreichen kann, indem es den Betriebssystem-Kernel umgeht mit RDMA über konvergentes Ethernet v2 (RoCE v2). Um diese Hardware nutzen zu können, müssen Sie Workloads auf Bare-Metal-Knoten innerhalb derselben Fault Domain planen und sie so konfigurieren, dass sie direkt auf die Mellanox ConnectX SmartNICs zugreifen.

TrueFoundry automatisiert diese Planungseinschränkungen. Wenn Sie einen verteilten Schulungsauftrag einreichen mit PyTorch DDP oder Tiefe Geschwindigkeit, der TrueFoundry-Controller übersetzt Ihre Anfrage in eine Kubernetes-MPIJob. Der Controller wendet strenge Knotenaffinitätsregeln an, um sicherzustellen, dass alle Pods im angegebenen Bare-Metal-Cluster-Netzwerk landen. Anschließend fügt er die erforderlichen Host-Pfad-Volumes und privilegierten Sicherheitskontexte ein, sodass der Container nativ auf die InfiniBand-Geräte zugreift. Sie müssen keine benutzerdefinierten Kubernetes-Manifeste schreiben.

Abb. 2: RDMA-Netzwerkfluss, der die Kernel-Bypass-Umgehung für die GPU-Kommunikation zwischen Knoten detailliert beschreibt.

Identitätsverbund und Sicherheit

OCI implementiert Workload Identity, um statische Anmeldeinformationen oder Benutzerprinzipal-API-Schlüssel im Anwendungscode zu ersetzen.

Wenn eine TrueFoundry-Bereitstellung Zugriff auf OCI Object Storage benötigt, um Modellgewichte zu laden, stellt die Plattform ein Kubernetes-Dienstkonto bereit, das an einen OCI Identitäts- und Zugriffsmanagement (IAM) politik. Der OKE-Metadatenserver fängt die Authentifizierungsanforderung ab, validiert das Kubernetes-Token und gibt ein kurzlebiges OCI-Zugriffstoken an den Pod aus. Ihr Anwendungscode verwendet das Standard-OCI-SDK über diesen injizierten Token-Mechanismus. Wir beschränken den Explosionsradius eines kompromittierten Pods auf die spezifischen IAM-Richtlinien, die diesem isolierten Servicekonto zugeordnet sind.

‍

Abb. 3: Die OKE Workload Identity-Authentifizierungssequenz.

Rechenoptimierung: Block Volume Multi-Attach

OCI bietet Bare-Metal-Hardwareoptionen wie den BM.GPU.H100.8 über vorhersehbare Berechnungsmodelle. Da es sich um physische Maschinen handelt, unterscheidet sich die Bereitstellungslogik grundlegend von virtualisierten Umgebungen. TrueFoundry lässt sich direkt in die integrieren OKE Cluster Autoscaler um diese Knoten zu verwalten, wobei Bare-Metal-Hardware als elastische Kapazität behandelt wird.

Das gleichzeitige Laden eines 100-GB-Modells in den VRAM über 64 GPUs belastet den Standard-Netzwerkspeicher und verzögert die Bereitstellungsbereitschaft. TrueFoundry umgeht dies durch folgende Funktionen OCI-Blockvolumen Multi-Attach-Funktionen. Die Plattform mountet ein einzelnes Block-Volume mit hohem IOPS, das die Modellgewichte für mehrere Bare-Metal-Instances gleichzeitig in einer schreibgeschützten Konfiguration enthält. Diese Architektur minimiert den Netzwerkengpass, der entsteht, wenn bei jedem Pod-Start Lasten aus dem Objektspeicher abgerufen werden, was die Bereitstellungszeiten für große Modelle erheblich verkürzen kann.

Betriebsvergleich: Natives OCI und TrueFoundry Overlay

In der folgenden Tabelle werden die betrieblichen Unterschiede zwischen der Verwaltung von rohen OCI-Bare-Metal-Primitiven und der Verwendung des TrueFoundry-Overlays beschrieben.

‍

Fazit

Die Zusammenarbeit zwischen TrueFoundry und Oracle Cloud Infrastructure zielt darauf ab, die Betriebsimpedanz von Bare-Metal-Computing zu beseitigen. TrueFoundry automatisiert die Komplexität von Kubernetes-Orchestrierung, RoCE v2 RDMA-Netzwerken, Workload Identity Federation und leistungsstarkem Block Volume Multi-Attach und stellt sicher, dass Ihre Data-Science- und Engineering-Teams die Rohgeschwindigkeit der Bare-Metal-GPUs von OCI maximieren können. Dieses Infrastruktur-Overlay ermöglicht es Ihnen, Ihren Fokus wieder vollständig auf das Erstellen, Trainieren und Bereitstellen umfangreicher KI-Modelle zu verlagern, ohne umfangreiche technische Ressourcen für die Verwaltung von Cloud-Primitiven auf niedriger Ebene aufzuwenden.

‍