Eine interne Daten- und KI-Plattform, GPUs inklusive

GPU-Pools, Quotas und ein Scheduler für Pods und VMs

KI-/ML-Plattform GPU-Pools · Quotas Pods + VMs, ein Scheduler Data Lakes · GitOps In Einführung

Eine interne Plattform für zwei Dinge, die große Organisationen sonst zweimal bauen: Daten — Analytik, Lakes und Marts, Modelltraining — und KI/ML-Services von der Entwicklung über das Training bis zum Serving. Darunter liegt KI-taugliche Infrastruktur: GPU-Ressourcenpools mit Time-Slicing und Quotas je Tenant, ein einziger Scheduler, der Pods und virtuelle Maschinen platziert, und Verbrauchsmetriken, die fein genug sind, um Teams zu verrechnen und zu sehen, wohin Kapazität tatsächlich geht. Das Projekt ist in Einführung: GPU-Unterstützung läuft, das MVP der KI-Services ist weitgehend fertig.

Ein Scheduler

für Pods und virtuelle Maschinen, mit Metriken hinter Billing und Analyse

Je Tenant

GPU-Pools, Time-Slicing und Quotas je Team und je Projekt

Phase 2 · 70%

MVP der KI-Services in einer zweimonatigen Phase; GPU-Support bereits fertig

Über das Projekt

Der Kunde baut eine interne Plattform, die Datenmanagement und KI/ML-Arbeit für die gesamte Organisation abdeckt, statt jede Funktion ihren eigenen Stack ansammeln zu lassen. Auf der Datenseite: Analytik, Data Lakes und Data Marts, Modelltraining. Auf der KI/ML-Seite: Modelle betreiben, entwickeln und trainieren, als Service für andere Teams.

Beides wird üblicherweise als getrennte Programme geführt — und verbringt danach Jahre damit, sich Datensätze zuzukopieren. Hier teilen sie sich von Anfang an Infrastruktur, Mandantenfähigkeit und Quotas.

Ziele

Eine interne Plattform für Datenmanagement und KI/ML-Services statt zweier Betriebsmodelle über einem Bestand.
GPU-Kapazität, die zwischen Teams geteilt werden kann, ohne jemanden auszuhungern und ohne Karten brachliegen zu lassen.
Verbrauch genau genug messen, um intern zu verrechnen und Kapazitätsentscheidungen auf Belege zu stützen.
Mandantenfähigkeit stark genug, dass Teams auf gemeinsamer Hardware isoliert arbeiten.
Automatisierung des GPU-Lifecycles von der Bereitstellung bis zur Außerbetriebnahme.

Lösung

KI-taugliche Infrastruktur: GPUs für Kubernetes und für VMs.

GPU-Infrastrukturschicht — GPU-Ressourcenpools, Time-Slicing, Quotas je Tenant und je Projekt.
Ein Scheduler — ein Planer für Pods und virtuelle Maschinen, mit Auslastungsmetriken, die Leistungsverrechnung und tiefe Analyse speisen.
Daten und Pipelines — S3-kompatibler Speicher, Datenbanken und Modell-Artefakte, Pipelines GitOps-artig automatisiert.

Vollständiges GPU-Lifecycle-Management. Automatisiertes GPU-Provisioning, Passthrough in VMs und in Kubernetes sowie Treiberverwaltung — zusammengeführt statt pro Fall geskriptet:

Voller Autopilot für NVIDIA-Karten; GPU-Passthrough für andere Hersteller.
Automatische Treiberinstallation und GPU-Ressourcenverwaltung in Kubernetes.
Lifecycle- und Ressourcenmanagement, Autoscaling und Provisioning auf Abruf.
Sicherheit und Mandantenfähigkeit, Außerbetriebnahme und Rolling Upgrades.

Was die Plattform heute kann

Monitoring — Auslastung, Last und die ungenutzte Kapazität, die vorher niemand erfasst hat.
Provisioning — schnelle Zuteilung von GPU oder vGPU an ein ML-Projekt.
Mandantenfähigkeit — isolierte Arbeitsbereiche je Team.
Billing und Quotas — Limits, Tarife, Verbrauchserfassung.
Dynamische Zuteilung — GPUs gehen bei Freigabe zurück in den Pool, statt reserviert zu bleiben.
Inventar — jede Karte, ihr Standort und ihr Zustand in einem Register.

Roadmap

Phase 1 — fertig. GPU-Unterstützung. Autopilot für NVIDIA, Passthrough für andere Hersteller, Monitoring und Ressourcenerfassung. Das ist die Infrastrukturschicht.
Phase 2 — zwei Monate, rund 70% erledigt. Erstes MVP der KI-Services. KI-Services im Plattform-Dashboard, Unterstützung für GPUs anderer Hersteller, verbreitete selbst gehostete Modelle.
Phase 3 — drei Monate. Erweiterte Services. Bessere Orchestrierung der KI-Services, Enterprise-Werkzeugsatz für GPUs, MIG-Unterstützung.
Phase 4 — Ausbau. Feinabstimmung der KI-Plattform und Automatisierung für Nicht-NVIDIA-GPUs.

Warum dieser Fall zählt

Daten und KI auf einer Plattform

Gleicher Speicher, gleiche Mandantenfähigkeit, gleiche Quotas. Kein zweites Betriebsmodell und keine Kopie jedes Datensatzes zwischen zwei Stacks.

Pods und VMs, ein Scheduler

Erst das macht Leistungsverrechnung möglich: Zwei Scheduler, die beide die Karten für ihr Eigentum halten, liefern keine Zahl, die jemand unterschreibt.

Brachliegende GPUs sind eine messbare Größe

Auslastung, Last und ungenutzte Kapazität je Tenant — und frei werdende Karten gehen zurück in den Pool statt gebucht zu bleiben.

Eine Roadmap mit einer fertigen Phase

GPU-Unterstützung läuft; die KI-Service-Schicht entsteht darauf. Veröffentlicht während der Umsetzung, nicht im Rückblick.

Diese Case Study beschreibt ein laufendes Projekt und erscheint anonymisiert (Tier-3-Evidenz): Der Kunde wird über sein Profil beschrieben, nicht über seinen Namen. Eine Kundenreferenz ist unter NDA auf Anfrage möglich — sprechen Sie mit dem Ænix-Vertrieb.

Ænix ist das Team hinter Cozystack — einem CNCF-Projekt (heute Sandbox, Incubating erwartet im Spätsommer 2026), Apache 2.0. Ænix kommerzialisiert es als Ænix Platform in drei Plattformen — Provider und Enterprise — mit den Modulen AI Platform und Developer Self-Service.

Häufig gestellte Fragen

Warum eine Plattform für Daten und KI zugleich?

Weil es zweimal dasselbe Infrastrukturproblem ist. Analytik, Data Lakes und Marts, Modelltraining und Model Serving brauchen alle Objektspeicher, Datenbanken, Scheduling, Quotas und Pipelines. Sie zu trennen bedeutet zwei Betriebsmodelle, zwei Kapazitätsplanungen und eine Kopie jedes Datensatzes dazwischen.

Wie werden GPUs zwischen Teams geteilt?

GPUs liegen in Ressourcen-Pools mit Time-Slicing, Quotas gelten je Tenant und je Projekt. Frei werdende Kapazität wird dynamisch umverteilt, statt hinter demjenigen brachzuliegen, der sie gebucht hat. Jedes Team sieht einen isolierten Bereich, und die Plattform führt ein Inventar über jede Karte, ihren Ort und ihren Zustand.

Konkurrieren virtuelle Maschinen und Container um dieselben GPUs?

Sie teilen sich einen Scheduler. Pods und VMs werden vom selben Planer platziert, mit denselben Verbrauchsmetriken dahinter — und genau das macht Leistungsverrechnung und belastbare Auslastungsanalyse erst möglich. Was zwei getrennte Scheduler jeweils für ihr Eigentum halten, lässt sich weder abrechnen noch auswerten.

Gilt das nur für NVIDIA?

Die vollständige Automatisierung — Provisioning, Treiberverwaltung, Lifecycle — steht für NVIDIA. Karten anderer Hersteller werden heute über GPU-Passthrough unterstützt; ihre Automatisierung steht auf der Roadmap.

In welchem Stand ist das Projekt?

In der Einführung. Die GPU-Unterstützung ist fertig: automatisiertes Provisioning, Passthrough, Monitoring und Verbrauchserfassung. Das MVP der KI-Services steht bei rund siebzig Prozent einer zweimonatigen Phase. Erweiterte Services, bessere Orchestrierung und MIG-Unterstützung folgen in einer dreimonatigen Phase danach.