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

Oracle Cloud Infrastructure (OCI) verfolgt bei KI-Rechenleistung einen anderen Ansatz als die VM-zentrierten Hyperscaler. Die differenzierende Ebene ist Bare-Metal: Die GPU-Shapes von OCI – wie BM.GPU.H100.8 – laufen ohne Hypervisor-Overhead und verbinden sich über NVIDIA ConnectX SmartNICs mittels eines benutzerdefinierten RDMA over Converged Ethernet (RoCE v2) Clusternetzwerks.

Diese Leistungsgrenze bringt bei der Verwaltung von Cloud-Infrastruktur auf Bare-Metal betriebliche Anforderungen mit sich. Bare-Metal bedeutet, dass Sie nun für die Ebene verantwortlich sind, die normalerweise von VMs abstrahiert wird: GPU-Treiber und der OFED-Stack, Scheduling innerhalb der Topologie-Beschränkungen des Clusternetzwerks, Identitätsföderation über OCI IAM sowie die Auswahl zwischen verschiedenen Speicherpfaden für Modellgewichte. Nichts davon ist exotisch, aber es ist ein erheblicher Kubernetes-Aufwand, der bei verwalteten VM-Angeboten nicht anfällt.

Die Rolle von TrueFoundry in diesem Stack ist die Kubernetes-native Betriebsebene. Die Compute Plane ist Ihr eigenes Oracle Cloud Infrastructure Kubernetes Engine (OKE) Cluster, das auf OCI Bare-Metal läuft. Die Plattform bündelt eine Reihe von Open-Source- und CNCF-zugehörigen Komponenten (ArgoCD, Argo Workflows, NVIDIA GPU Operator, Prometheus, KEDA, Istio und andere) in einer verwalteten Bereitstellung, fügt eine einheitliche Benutzeroberfläche sowie einen GitOps-Workflow hinzu und bietet Observability für Dienste, Jobs und GPU-Auslastung. Sie ersetzt nicht die OCI-Primitive – sie baut auf ihnen auf.

Dieser Beitrag erläutert die Architektur, die Sie erhalten, wenn Sie TrueFoundry auf OCI Bare-Metal ausführen: die Trennung von Control Plane und Compute Plane, wie RDMA-Training in Kubernetes integriert wird, wie Workload-Identität funktioniert und die praktischen Muster für das Laden von Modellgewichten in großem Maßstab.

Bereitstellungsmodell: Control Plane und Compute Plane

TrueFoundry verwendet eine Split-Plane-Architektur. Die Control Plane (von TrueFoundry verwaltet oder selbst gehostet) enthält Metadaten, RBAC, den API-Server und den Speicher für Bereitstellungs-Manifeste. Die Compute Plane besteht aus einem oder mehreren Kubernetes-Clustern in Ihrer eigenen Cloud-Umgebung – in diesem Fall ein OKE-Cluster auf OCI Bare-Metal. Workloads, Modellgewichte und Kundendaten verbleiben in Ihrer Tenancy.

Die Verbindung zwischen beiden ist der tfy-agent, der auf dem Compute-Plane-Cluster läuft und ein ausgehendes WebSocket zur Control Plane öffnet. Der Agent ruft Bereitstellungs-Manifeste ab und sendet Kubernetes-Ressourcen-Updates zurück. Da die Verbindung ausgehend ist, müssen Sie keine eingehenden Ports in Ihrer VCN öffnen oder den Cluster-API-Server dem öffentlichen Internet aussetzen.

Wenn TrueFoundry eine Compute Plane einrichtet, installiert und verwaltet der Agent eine Reihe von Open-Source-Add-ons über ArgoCD:

• ArgoCD für die Anwendungsbereitstellung im GitOps-Stil
• Argo Workflows für die Jobs-Funktion (Trainingsläufe, Batch-Pipelines)
• Argo Rollouts für Canary- und Blue-Green-Deployments
• Prometheus / kube-prometheus-stack für Metriken, die Autoscaling und Observability ermöglichen
• KEDA für ereignisgesteuertes Autoscaling
• Istio als primärer Ingress-Controller und für das Traffic-Management
• NVIDIA GPU Operator für den Lebenszyklus von GPU-Treibern, DCGM-basierte Gesundheitsprüfungen und GPU-Node-Labels via Node Feature Discovery (die OCI-spezifischen RDMA-Topologie-Labels werden separat durch die eigene Node-Bereitstellung von OCI bereitgestellt – siehe Abschnitt „Netzwerk“ weiter unten)
• Victoria Logs + Vector (optional) für die Log-Aggregation

Sie können auch Ihre eigenen bestehenden Instanzen dieser Dienste einbinden – TrueFoundry dokumentiert die Konfiguration, die für die Koexistenz mit einer bestehenden ArgoCD-, Prometheus- oder Istio-Installation erforderlich ist.

Bare-Metal-Netzwerk: RDMA auf OKE

Das Cluster-Netzwerk von OCI ist die differenzierte Netzwerkschicht, die groß angelegtes verteiltes Training erst praktikabel macht. Oracle hat interne Messungen veröffentlicht, die eine Latenz im einstelligen Mikrosekundenbereich in diesem Fabric zeigen – bis zu 2 Mikrosekunden bei Single-Rack-Clustern und typischerweise 2,5 bis 9 Mikrosekunden bei Multi-Rack-Superclustern – unter Verwendung von RoCE v2 über NVIDIA ConnectX SmartNICs. Die tatsächlichen Werte in der Produktion hängen von der Cluster-Topologie, der Nachrichtengröße und der Auslastung ab; Oracles Dokumentation zu den First Principles behandelt das zugrunde liegende Design.

Damit RDMA effektiv genutzt werden kann, müssen zwei Voraussetzungen erfüllt sein:

• Die Knoten müssen sich im selben OCI-Clusternetzwerk befinden. OCI stellt Topologie-Labels auf OKE-Knoten bereit – oci.oraclecloud.com/rdma.local_block_id,network_block_idsowiehpc_island_id – und Oracles oci-hpc-oke-Quickstart zeigt, wie diese mit der topologiebewussten Planung von Kueue für eine optimale NCCL-Leistung verwendet werden. Für eng gekoppelte Trainingsvorgänge sollten Sie die Pods bevorzugt innerhalb desselben Local Block platzieren.
• Der Trainings-Pod muss auf die RDMA-Geräte zugreifen können. Auf den H100-Knoten von OCI stellt der Mellanox/NVIDIA-Treiber RDMA-Geräte unter /dev/infiniband/ bereit (die Pfadbenennung spiegelt die zugrunde liegende IB-Verbs-API wider, obwohl der Transport über RoCE v2 via Ethernet erfolgt).

Das Standard-Pod-Muster aus dem Quickstart von Oracle sieht wie folgt aus:

spec:
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet
  containers:
  - name: trainer
    securityContext:
      privileged: true
      capabilities:
        add: ["IPC_LOCK"]
    volumeMounts:
    - { mountPath: /dev/infiniband, name: devinf }
    - { mountPath: /dev/shm, name: shm }
  volumes:
  - { name: devinf, hostPath: { path: /dev/infiniband }}
  - { name: shm, emptyDir: { medium: Memory, sizeLimit: 32Gi }}

Diese erweiterten Berechtigungen – privileged: true,IPC_LOCK, Host-Netzwerk – sind spezifisch für HPC/RDMA-Workloads. Isolieren Sie diese Pods in der Produktion in dedizierte GPU-Namespaces mit Zulassungsrichtlinien (z. B. Pod Security Admission auf privilegiert auf Namespace-Ebene, eingeschränkt an anderer Stelle; oder eine OPA/Kyverno-Richtlinie, die auf einem Label basiert), damit nicht zusammengehörige Workloads nicht denselben Kontext erben können.

‍

‍

Die Rolle von TrueFoundry besteht hier darin, das Ausführen dieser Training-Pods zu einem normalen Deployment-Workflow zu machen – Sie erstellen die Workload, die Plattform leitet sie durch Argo Workflows, Prometheus erfasst GPU-Metriken vom DCGM Exporter, der mit dem GPU Operator ausgeliefert wird, und ArgoCD versioniert die Manifeste. Workload-spezifische Signale wie NCCL-Zähler werden nur erfasst, wenn die Anwendung sie bereitstellt. Die RDMA-spezifischen Komponenten (hostPath-Mounts, IPC_LOCK, Topologie-Affinität) werden in Ihrer Job-Spezifikation gemäß dem oben genannten Standardmuster konfiguriert; die Plattform ersetzt diese Felder nicht, sondern stellt bereit, was auch immer Sie angeben.

Speziell für verteiltes Training über mehrere Knoten hinweg installieren Sie in der Regel einen Operator über dessen Helm-Chart auf dem Cluster – MPI Operator für MPIJob-basierte Ausführungen (PyTorch DDP, DeepSpeed, NCCL), Kubeflow Training Operator für PyTorchJob/TFJob oder KubeRay für Ray-basiertes Training. TrueFoundry bündelt diese standardmäßig nicht. Sobald sie installiert sind, stellt die Plattform MPIJob/PyTorchJob/RayJob-Ressourcen wie jede andere Kubernetes-Workload bereit, mit demselben GitOps- und Observability-Ansatz. Verteiltes Training mit RDMA auf OCI ist derzeit kein natives TrueFoundry-Feature – es handelt sich um ein Implementierungsmuster, das auf den veröffentlichten Referenzmanifesten von Oracle basiert, wobei die Plattform den umgebenden operativen Stack verwaltet und nicht die RDMA-spezifische Orchestrierung.

Identitätsföderation: OKE Workload Identity

Für unterstützte Clustertypen empfiehlt OCI mittlerweile OKE Workload Identity anstelle der Verteilung langlebiger API-Schlüssel an Pods. Der Mechanismus funktioniert ähnlich wie AWS IRSA oder GKE Workload Identity: Ein Kubernetes-ServiceAccount wird einer OCI-IAM-Richtlinie zugeordnet, und das OCI-SDK tauscht das projizierte ServiceAccount-Token des Pods zum Zeitpunkt des Aufrufs gegen ein kurzlebiges OCI-Zugriffstoken aus. Es befinden sich keine statischen Anmeldeinformationen im Pod.

Zwei wichtige Einschränkungen aus Oracles Dokumentation:

• Workload Identity funktioniert nur auf Erweiterte OKE-Cluster, keine Basis-Cluster.
• Die Authentifizierung über Workload Identity wird nur durch OCI-SDKs unterstützt (Java, Python, Go usw.) – nicht durch die OCI-CLI oder die Konsole.

Auf Kubernetes-Seite sind Workloads an ServiceAccounts mit Namespace-Gültigkeitsbereich gebunden, und die Plattform kann deren Erstellung als Teil des Deployment-Prozesses automatisieren. Die OCI-Seite – die IAM-Richtlinie mit der request.principal.type='workload' Regel sowie den Selektoren für Cluster/Namespace/ServiceAccount – wird gemäß der Standard-Workload-Identity-Einrichtung von Oracle konfiguriert. Sobald beide Seiten eingerichtet sind, erhalten Deployments, die OCI-Zugriff benötigen, transparent über das SDK kurzlebige Token.

Speicher und Laden von Modellen

OCI Bare Metal bietet Ihnen verschiedene Speicheroptionen, um Modellgewichte in den VRAM zu laden. Jede hat ihre Vor- und Nachteile, und die Volume-Abstraktionen von TrueFoundry (PVCs, Volume Mounts, Init-Container) funktionieren mit allen – das richtige Muster hängt von Ihrer Workload ab:

• Lokaler NVMe-Speicher. BM.GPU.H100.8 wird mit 16 NVMe-SSDs (jeweils 3,84 TB, insgesamt ca. 61 TB lokal) ausgeliefert. Für Workloads, bei denen jeder Knoten seine eigene Kopie der Gewichte aus einem Checkpoint-Cache lädt, ist lokaler NVMe-Speicher die schnellste Option – da das Netzwerk auf dem kritischen Pfad nicht beansprucht wird.
• OCI File Storage Service (FSS) mit High-Performance Mount Targets. FSS HPMT bietet RWX-Dateispeicher (ReadWriteMany) mit hohem Durchsatz, der gleichzeitig auf vielen Bare-Metal-Knoten eingebunden werden kann. Dies ist die ideale Lösung für die Volume-Abstraktion von TrueFoundry, die auf Kubernetes RWX PersistentVolumes basiert. Gut geeignet für gemeinsam genutzte Modellgewichte, Datensätze und die Speicherung von Checkpoints während des Trainings. Oracle bietet zudem einen vollständig verwalteten Lustre-Dateiservice für Fälle mit sehr hohem Durchsatz.
• OCI Block Volume (Multi-Attach). Ein einzelnes Block-Volume kann schreibgeschützt für bis zu 32 Instanzen innerhalb derselben Availability Domain eingebunden werden. Die Leistung gilt pro Volume (geteilt über alle eingebundenen Instanzen), und für Bare-Metal-Instanzen wird iSCSI mit Multipath für die Anbindung verwendet. Nützlich, wenn Sie ein unveränderliches Modell-Artefakt haben, das jeder Knoten in einem Job wie eine lokale, schreibgeschützte Festplatte einbinden soll, ohne den Umweg über eine Dateisystemschicht zu gehen.
• OCI Object Storage. Laden Sie Gewichte beim Start des Pods aus dem Object Storage in den lokalen NVMe-Speicher oder Arbeitsspeicher. Dies ist das einfachste Muster und funktioniert hervorragend mit den Init-Container-Hooks von TrueFoundry. Jeder Pod erhält eine unabhängige Bandbreite, was oft besser ist, als das IOPS-Budget eines einzelnen Volumes auf viele Lesezugriffe aufzuteilen.

Das richtige Muster hängt vom jeweiligen Workload ab. Für die meisten Trainingsläufe ist die Kombination aus lokalem NVMe-Speicher (für kurzlebige, hochperformante Daten) und FSS (für gemeinsam genutzte Checkpoints und Gewichte) das Standard-Setup für die Produktion. Die Multi-Attach-Funktion von Block Volumes ist eine Option für spezifische Fälle, in denen ein einzelnes, unveränderliches Artefakt für viele Lesezugriffe wie eine lokale Festplatte erscheinen muss.

Betriebliche Überlegungen

Der Betrieb von Bare-Metal-GPU-Workloads auf nativen OCI-Grundlagen ist machbar – Oracle stellt einen Terraform-basierten HPC-Stack sowie den oci-hpc-oke Quickstart bereit –, erfordert jedoch, dass Sie sich um eine beträchtliche Kubernetes-Betriebsschicht kümmern. Die folgende Tabelle beschreibt, was TrueFoundry zusätzlich bietet.

Das Muster ist konsistent: OCI stellt die Bare-Metal-Compute- und Netzwerk-Grundlagen bereit; TrueFoundry liefert die darüber liegende Kubernetes-Betriebsschicht.

Fazit

TrueFoundry auf OCI ist eine Kubernetes-native Plattform, die auf dem Bare-Metal-Stack von Oracle läuft. Die Compute-Ebene ist Ihr OKE-Cluster, die Workloads nutzen das RoCE v2-Cluster-Netzwerk von OCI sowie Workload Identity über Standard-Kubernetes-Muster, und die Plattform bündelt die Open-Source- und CNCF-konforme Betriebsschicht – GitOps, Observability, Autoscaling, GPU-Operator – in einer verwalteten Bereitstellung. Das Ergebnis ist ein geringerer Plattform-Engineering-Aufwand für den Betrieb von Bare-Metal-GPU-Workloads, wobei die OCI-spezifische Konfiguration transparent bleibt, anstatt verborgen zu werden.

Ein praktischer Evaluierungspfad ist eine Referenzbereitstellung auf einem kleinen OKE-Cluster – typischerweise ein oder zwei BM.GPU-Shapes plus ein CPU-Pool für die Plattform-Add-ons –, um die Architektur zu validieren, bevor eine Skalierung auf ein vollständiges Supercluster erfolgt.

‍