GPU-Cloud-Bursting über Bare Metal, Public und souveräne Clouds

Open-Source Cozystack (CNCF-Projekt, von Ænix initiiert) → Ænix Public Cloud, Private Cloud und AI Platform → Ænix baut, betreibt und migriert sie.

Cloud Bursting bedeutet, stetige Workloads auf eigener Kapazität zu betreiben und Lastspitzen nur bei Bedarf in externe Clouds auszulagern. Für GPU-Arbeit heißt das: Eigenes Bare Metal bildet die Grundlast, und Inferenz- oder Training-Jobs bursten bei Spitzen in Public-Hyperscaler oder eine souveräne Cloud — danach wird die Zusatzkapazität wieder abgebaut. Ænix liefert das als Engineering-Projekt auf Cozystack und Cluster API, nicht als Funktion auf Knopfdruck: Eine einzige Cluster API umfasst Bare Metal, Hyperscaler und souveräne Cloud, mit anteiligem GPU-Sharing (HAMi), Autoscaling und einem WireGuard-Mesh. Das passt zu AI/ML-Teams, Forschungseinrichtungen und Plattformbetreibern, die elastische GPU-Kapazität ohne Hyperscaler-Lock-in brauchen — und hat in einem realen akademischen Projekt die GPU-Kosten in der souveränen Cloud um rund das Fünffache gesenkt.

Auf einen Blick

  • Was es ist Grundlast-GPU-Workloads auf eigener Kapazität betreiben und Spitzen bei Bedarf in externe Clouds bursten
  • Control Plane Eine Cluster API über Bare Metal, Public-Hyperscaler und souveräne Cloud
  • GPU-Effizienz Anteiliges GPU-Sharing (HAMi) — mehrere Jobs teilen sich eine physische Karte
  • Wirtschaftlichkeit Rund 5x günstigere GPU in einer souveränen Cloud gegenüber dem vorherigen Hyperscaler-Setup (akademischer Multi-Cloud-Fall)
  • Plattform Cozystack — CNCF-Sandbox-Projekt, Apache 2.0 (keine Lizenzkosten pro GPU oder CPU); geliefert als Projekt, nicht als Funktion auf Knopfdruck
  • Konnektivität WireGuard-Mesh verbindet Standorte und Clouds zu einem Pod- und Service-Netzwerk
  • Isolation Hosted Control Planes pro Tenant (Kamaji) für sichere Mandantenfähigkeit

Quelle: Cluster-API-Dokumentation, Cozystack, Fallstudie akademische Multi-Cloud-GPU

Die Grundlast besitzen, nur die Spitzen mieten. Mit Cloud Bursting betreiben Sie stetige GPU-Workloads auf Hardware, die Sie selbst kontrollieren, und lagern Inferenz- oder Training-Spitzen bei Bedarf in Public- oder souveräne Clouds aus — danach wird die Zusatzkapazität wieder abgebaut. Ænix baut das auf einer einzigen Kubernetes-Plattform, damit Ihre Teams elastische GPU-Kapazität erhalten: ohne Hyperscaler-Lock-in, ohne intransparente Abrechnung und ohne vollständige Migration.

Bursting liefern wir als Projekt auf Cozystack und Cluster API, zugeschnitten auf Ihre Burst-Targets; es ist keine Funktion, die Sie in einem Proof of Concept einfach einschalten.

Passt zu: Ænix AI Platform — mandantenfähiges GPU-Scheduling und anteiliges Sharing (HAMi) für Inferenz und Fine-Tuning; Angebot per RFP. Für die elastische Self-Service-Cloud darunter kombinieren Sie sie mit der Public Cloud Platform. Rechnen Sie die Zahlen mit den ROI- und TCO-Rechnern durch oder sehen Sie sich das Webinar zum Aufbau einer eigenen GPU-Cloud an (Englisch). Für Verantwortliche von ML-Plattformen: der Leitfaden für Leiter AI/ML.


Was Sie bekommen

GPU-Cloud-Bursting auf Cozystack ist ein elastischer GPU-Pool, verteilt über die Infrastruktur, die Sie bereits haben, und die Clouds, die Sie erreichen wollen.

  • Bursting in Public- und souveräne Clouds. Grundlast-Workloads laufen auf eigenem Bare Metal. Bei Lastspitzen kommt Kapazität bei einem Public-Hyperscaler, in einer souveränen Cloud oder in beiden hinzu — und wird danach wieder freigegeben. Eine souveräne Cloud kann ein vollwertiges Burst-Target sein, wenn eine Aufsichtsbehörde die GPU-Verarbeitung an eine Rechtsordnung bindet oder wenn ihre GPUs schlicht günstiger sind.
  • Anteiliges GPU-Sharing. Mit HAMi auf dem NVIDIA GPU Operator teilen sich mehrere Jobs eine physische Karte. Ein Notebook, ein kleiner Inferenz-Endpoint und ein Batch-Job laufen gemeinsam auf einer GPU, statt jeweils ein ganzes Gerät zu belegen.
  • Eine Cluster API. Bare Metal, Hyperscaler und souveräne Cloud liegen hinter einer einzigen Cluster API. Teams fordern GPUs überall auf dieselbe Weise an; die Plattform entscheidet, wo sie landen.
  • Autoscaling, das GPUs berücksichtigt. Der Cluster Autoscaler fügt GPU-Nodes hinzu, wenn sich Pods nicht einplanen lassen, und entfernt sie, sobald die Spitze vorbei ist — Sie zahlen für Spitzenkapazität nur, solange die Spitze dauert.
  • Ein verschlüsseltes Mesh über alle Standorte. Ein WireGuard-Mesh verbindet jeden Standort und jede Cloud zu einem Pod- und Service-Netzwerk; neue Nodes registrieren sich beim Hochfahren selbst.
  • Isolation pro Tenant. Jeder Tenant erhält eine eigene Hosted Control Plane, sodass beliebiger Nutzercode und mandantenübergreifendes GPU-Sharing die Plattform nicht gefährden.

Für wen ist das gedacht?

Für AI/ML-Teams mit stark schwankendem Trainings- und Inferenzbedarf, für Forschungseinrichtungen und Universitäten mit gemeinsam genutzten GPUs für Lehre und Experimente sowie für Plattformbetreiber, die GPU-as-a-Service anbieten wollen, ohne einen Hyperscaler weiterzuverkaufen. Ist Ihr GPU-Bedarf gleichmäßig und planbar, brauchen Sie womöglich kein Bursting — dann dimensionieren Sie für die Grundlast und belassen es dabei. Schwankt er stark, liegt im Bursting der wirtschaftliche Hebel.


So funktioniert es

Das Muster setzt sich aus Standardbausteinen von Kubernetes zusammen, die wir durchgängig aufbauen und betreiben.

Eigene Bare-Metal-GPUs
GrundlastAnteiliges Sharing (HAMi)
vereint durch
Cozystack / Ænix
Eine Cluster APICluster Autoscaler
burstet Spitzen in
Public und souveräne Cloud
Elastische GPUs, kein Lock-in
  • Cluster Autoscaler erkennt GPU-Pods, die sich nicht einplanen lassen, und stellt Nodes auf dem passenden Ziel bereit — Bare Metal, Hyperscaler oder souveräne Cloud — über die Cluster API, den deklarativen Kubernetes-Standard für den Lebenszyklus von Clustern und Maschinen. Ist die Warteschlange abgearbeitet, werden die Nodes wieder entfernt.
  • Cilium und ein WireGuard-Mesh (Kilo) liefern das CNI und ein verschlüsseltes Overlay über Clouds hinweg. Frisch autoskalierte Nodes melden sich selbst im Mesh an und erreichen gemeinsamen Storage ohne manuelle Schritte — das Kubernetes-Netzwerkmodell behandelt sie, als wären sie lokal.
  • NVIDIA GPU Operator übernimmt Treiberinstallation und Geräteerkennung auf jedem Node, und HAMi ergänzt Time-Slicing, sodass eine Karte mehrere Pods bedient; auf MIG-fähigen Karten stellt der Operator zudem MIG-Partitionen als einplanbare Ressourcen bereit.
  • Talos Linux und Kamaji bilden die Basis: ein unveränderliches, per API verwaltetes Betriebssystem für die Nodes und Hosted Control Planes für Tenant-Cluster, sodass jeder Tenant von vornherein isoliert ist.

Es sind dieselben offenen, an der CNCF ausgerichteten Bausteine, auf die sich das Cloud-Native-Ökosystem verständigt hat — keine proprietäre Orchestrierungsschicht, kein Control-Plane-Aufschlag pro GPU.


Vergleichen Sie noch? Preise & Plattformen ansehen →

Die Wirtschaftlichkeit

GPUs sind die knappe, teure Ressource, und ihre Preise stehen unter Druck: Sie schwanken stark und sind in kurzen Zeiträumen deutlich gestiegen. Die Grundlast zu besitzen und nur die Spitzen zu bursten — statt GPUs rund um die Uhr bei einem Hyperscaler zu mieten — ist genau der Punkt, an dem sich dieser Druck auffangen lässt.

In der Fallstudie zur akademischen Multi-Cloud hat ein europäischer SaaS-Anbieter für akademisches Computing sein Backend und die Nutzer-Workloads von einem Public-Hyperscaler auf eigenes Bare Metal mit Cozystack verlagert, eine einzige Cluster API über Bare Metal, einen Hyperscaler und eine souveräne OpenStack-Cloud beibehalten und GPU-Kapazität bei Bedarf per Bursting hinzugenommen. GPUs in der souveränen Cloud waren rund 5x günstiger als im vorherigen Hyperscaler-Setup — bei intaktem anteiligem Sharing und intakter Isolation pro Tenant und ohne Ausfallzeit für Tausende aktive Nutzer.

Wie viel Sie sparen, hängt von Ihrem Mix aus Grundlast, Spitzen und Burst-Target ab. Modellieren Sie ihn mit den ROI- und TCO-Rechnern, bevor Sie sich auf Hardware oder einen Vertrag für ein Burst-Target festlegen.


Ænix hat Cozystack entwickelt und pflegt es gemeinsam mit Maintainern anderer Unternehmen — ein CNCF-Sandbox-Projekt (der Antrag auf CNCF Incubation befindet sich in der Due-Diligence-Prüfung) unter Apache 2.0, seit September 2026 im Programm CNCF Kubernetes AI Conformance. Ænix verkauft auf dieser Engine drei Plattformen: Public Cloud, Private Cloud und AI.

Häufig gestellte Fragen

Was ist Cloud Bursting?

Cloud Bursting ist ein hybrides Muster: Eine Anwendung läuft als Grundlast auf privater oder eigener Infrastruktur und weicht in eine externe Cloud aus, sobald die Nachfrage die lokale Kapazität übersteigt. Bei GPU-Workloads tragen Sie so die Kosten der Grundlast selbst und bezahlen zusätzliche GPUs nur während der Spitzen; danach wird die Kapazität wieder freigegeben.

Wie funktioniert GPU-Bursting auf Kubernetes?

Der Kubernetes Cluster Autoscaler erkennt GPU-Pods, die sich nicht einplanen lassen, und fügt Nodes dort hinzu, wo sie gebraucht werden — auf Bare Metal, beim Hyperscaler oder in der souveränen Cloud, alles hinter einer Cluster API. Ein CNI und ein WireGuard-Mesh binden die neuen Nodes in ein gemeinsames Netzwerk ein, der GPU Operator macht ihre GPUs einplanbar, und nach der Spitze werden die zusätzlichen Nodes wieder abgebaut.

Kann ich in eine souveräne Cloud bursten?

Ja. Eine souveräne oder regionale Cloud kann wie jedes andere Ziel als Burst-Target dienen. Das ist wichtig, wenn eine Aufsichtsbehörde die GPU-Verarbeitung an eine Rechtsordnung bindet oder wenn souveräne GPU-Kapazität schlicht günstiger ist. In unserem akademischen Multi-Cloud-Projekt haben wir eine souveräne OpenStack-Cloud als Burst-Target ergänzt und dort Tenant-Cluster aus einem einzigen Manifest betrieben.

Warum ist das günstiger als ein Hyperscaler?

Sie besitzen die Grundlast, statt sie rund um die Uhr zu mieten, teilen physische GPUs per anteiligem Scheduling zwischen Jobs und bursten in die jeweils günstigste Kapazität — auch in souveräne Clouds. Im akademischen Projekt war GPU-Kapazität in der souveränen Cloud rund 5x günstiger als im vorherigen Hyperscaler-Setup. Rechnen Sie Ihre eigenen Zahlen mit den ROI- und TCO-Rechnern durch.

Was bedeutet GPU-as-a-Service in diesem Zusammenhang?

GPU-as-a-Service heißt hier: Ihre eigene Plattform stellt Teams GPUs als elastische Self-Service-Ressource bereit — einen Bruchteil einer Karte oder einen ganzen Node anfordern, eingeplant bekommen, nach Gebrauch freigeben —, statt einen Managed-GPU-Service bei einem Hyperscaler einzukaufen. Control Plane, Wirtschaftlichkeit und Datenresidenz bleiben bei Ihnen.

Muss ich meine bestehende Hardware oder Cloud aufgeben?

Nein. Cloud Bursting ergänzt, was vorhanden ist. Eigenes Bare Metal bleibt die Grundlast, bestehender Storage (etwa ein externes Ceph) bleibt, wo er ist, und Public- oder souveräne Clouds werden als Burst-Targets angebunden. Nichts erzwingt eine vollständige Migration — Sie erweitern Kapazität dort und dann, wo Sie sie brauchen.

Bereit für ein Gespräch?

Buchen Sie einen 30-minütigen Discovery-Call — unverbindlich. Wir klären den Fit, die passende Plattform und die nächsten Schritte.