Multi-Cloud-GPU-Orchestrierung: Integration spezialisierter Clouds mit TrueFoundry

Die Rechenverfügbarkeit ist der primäre Engpass für das Training von LLMs und die Skalierung von Inferenzen mit hohem Durchsatz. Wenn Sie versucht haben, eine Bereitstellung durchzuführen Amazon EC2 P5-Instanzen Bei Azure ND H100 v5-VMs sind Sie in letzter Zeit wahrscheinlich auf InsuffizientInstanceCapacity-Fehler gestoßen oder es wurde Ihnen mitgeteilt, dass Sie eine mehrjährige private Preisvereinbarung benötigen.

Diese Knappheit macht spezialisierte GPU-Anbieter wie CoreWeave, Lambda Labs und FluidStack zu brauchbaren Alternativen. Diese „Neo-Clouds“ bieten NVIDIA H100s und A100 oft zu niedrigeren On-Demand-Tarifen als die großen Drei.

Das Problem? Führen Sie AWS für Ihre Amazon S3 Ein Data Lake beim manuellen Hochfahren von Bare-Metal-Nodes in Lambda Labs führt zu fragmentierten Workflows. Wir lösen dieses Problem, indem wir spezialisierte Clouds als Standard behandeln Kubernetes Cluster innerhalb einer einheitlichen Kontrollebene.

Die Architektur: Bring Your Own Cluster (BYOC)

TrueFoundry verwendet eine Split-Plane-Architektur. Die Steuerungsebene übernimmt die Arbeitsplanung und die Versuchsverfolgung, während die Rechenebene in Ihrer Umgebung bleibt. Da die meisten spezialisierten Clouds eine verwaltete Kubernetes Service oder Erlaube dir die Bereitstellung K3s, wir fügen sie über einen Standardagenten hinzu.

1. Die Rechenebene: Stellen Sie einen Cluster auf dem Anbieter bereit (z. B. einen CoreWeave-Namespace oder eine Lambda-GPU-Instance).
2. Der Agent: Du installierst den TrueFoundry Agent über Helme.
3. Die Integration: Der Cluster schließt sich Ihrem Dashboard an Amazon EKS oder Azure AKS.

Wir abstrahieren die Speicherung und den Eingang. Unabhängig davon, ob der Anbieter Vast Data oder lokales NVMe-RAID verwendet, ordnen wir es einem zu Anhaltender Volumenanspruch. Das hält deine Docker Container, die anbieterübergreifend portabel sind.

Abbildung 1: Hybridtopologie, die AWS für Datenpersistenz und spezialisierte Clouds für GPU-intensive Workloads nutzt.

Technische Vorteile des Hybridmodells

1. Kostenmanagement und Failover

Die H100-Preise auf Abruf variieren erheblich. Wir verwenden TrueFoundry, um priorisierte Warteschlangen einzurichten. Sie können zunächst günstige, unterbrechbare Kapazitäten in speziellen Clouds ins Visier nehmen. Wenn der Anbieter die Instance verhindert oder die Kapazität verschwindet, kann der Scheduler automatisch einen Failover auf eine reservierte Instanz durchführen Amazon EC2 Instanz.

2. Minderung der Infrastrukturabhängigkeit

Wenn Sie sich auf proprietäre KI-Plattformen verlassen, sind Sie oft an den Speicher und das IAM-Ökosystem einer bestimmten Cloud gebunden. Wir verpacken Schulungsjobs als Standardcontainer. TrueFoundry kümmert sich um Kubernetes CSI-Treiber für S3-Montage und konfiguriert den NVIDIA-Container-Toolkit Umgebungsvariablen automatisch. Sie verschieben einen Job von AWS nach CoreWeave, indem Sie den cluster_name in Ihrer Bereitstellungsspezifikation aktualisieren.

3. Zentralisierte Beobachtbarkeit

Multi-Cloud-Setups unterbrechen normalerweise die Protokollierung. Wir aggregieren Prometheus Metriken und Grafana Dashboards in allen Clustern. Wenn ein Trainingsjob auf einem Lambda Labs-Knoten gestartet wird, werden die GPU-Auslastung und die Systemprotokolle in derselben Benutzeroberfläche angezeigt, die Sie für Ihre EKS-Produktionsumgebung verwenden.

Arbeitsablauf: Lambda Labs-Kapazität hinzufügen

Folgen Sie diesem Lebenszyklus, um spezielle Kapazitäten hinzuzufügen:

• Bereitstellung: Erstellen Sie Ihre GPU-Knoten in der Provider-Konsole.
• Verbinden: Wählen Sie in TrueFoundry „Vorhandenen Cluster verbinden“ aus.
• Agenten bereitstellen: Bash-Befehle

helm repo add truefoundry https://truefoundry.github.io/infra-charts/
helm install tfy-agent truefoundry/tfy-agent \
  --set tenantName=my-org \
  --set clusterName=lambda-h100-pool \
  --set apiKey=<YOUR_API_KEY>

• Toleranzen: Oft spezialisierte Anbieter GPU-Knoten verderben. Sie konfigurieren den TrueFoundry-Workspace so, dass die erforderlichen Toleranzen auf alle Jobs angewendet werden, die auf diesen Cluster abzielen.

Vergleich von Infrastrukturmodellen

Unterm Strich

Für wachstumsstarke Entwicklungsteams ist es keine praktikable Strategie mehr, sich für LLM-Computing auf eine einzige Cloud zu verlassen. Indem Sie die Workload-Definition vom Ausführungsort entkoppeln, können Sie GPUs wie eine Handelsware behandeln. Leiten Sie Ihre intensiven Schulungen aus Effizienzgründen an spezialisierte Clouds weiter, während Ihre Kerndaten und -dienste in Ihrer primären Hyperscale-Region bleiben.

‍