Kubermatic AI: Teure GPUs besser nutzen – auch Team-übergreifend

Was geschehen ist – die Kernmeldung ausführlich

Das Hamburger Unternehmen Kubermatic hat im Rahmen seiner jährlichen Veranstaltung, den ContainerDays, eine neue technologische Lösung vorgestellt: Kubermatic AI. Dabei handelt es sich um eine Kubernetes-native Plattform, die darauf ausgelegt ist, die oft ineffiziente Nutzung von Grafikprozessoren (GPUs) in modernen Unternehmensumgebungen zu adressieren. Die Kernidee der Plattform besteht darin, GPU-Ressourcen zu konsolidieren und KI-Modelle als geteilte Dienste über verschiedene Teams hinweg bereitzustellen. Anstatt für jede Abteilung oder jedes Projekt eine eigene, isolierte Modellinstanz samt dediziertem GPU-Pool zu betreiben, ermöglicht Kubermatic AI eine zentrale Bereitstellung. Ein einmal ausgerolltes Modell kann somit sicher von mehreren Mandanten genutzt werden. Diese Strategie richtet sich insbesondere an Betreiber interner KI-Plattformen, Anbieter von Neoclouds sowie an Organisationen, die Wert auf souveräne KI-Umgebungen legen. Das Ziel ist es, die Auslastung der teuren Hardware signifikant zu erhöhen und das Problem ungenutzter Kapazitäten zu lösen, die in vielen Rechenzentren derzeit ungenutzt brachliegen.

Die Einzelheiten – Zahlen, Namen und technische Komponenten

Die technische Basis von Kubermatic AI stützt sich auf das bestehende Portfolio des Unternehmens. Dazu gehören die Kubermatic Kubernetes Platform (KKP) für das Multi-Cluster-Lifecycle-Management, die Kubermatic Developer Platform (KDP) als Self-Service-Ebene sowie das Lifecycle-Werkzeug KubeOne. Ergänzt wird dies durch den Load Balancer KubeLB, der über KI-fähiges Networking verfügt, und das Secrets-Management KubeSG. Für das eigentliche Model Serving nutzt die Plattform die Kubernetes-nativen Frameworks KServe und llm-d. CEO und Mitgründer Sebastian Scheele bezeichnete die aktuelle Situation in der Branche drastisch: Unternehmen würden GPUs zum teuersten ungenutzten Inventar machen, wobei die Auslastung in Extremfällen auf lediglich 5 Prozent sinken könne. Die Plattform ermöglicht es, dass jedes Team trotz der gemeinsamen Nutzung eines Modells eigene API-Schlüssel, separate Budgets, individuelle Kontingente und spezifische Governance-Richtlinien erhält. Die technische Umsetzung der Mandantentrennung erfolgt über Mechanismen wie Namespaces, Network Policies und Admission Controller. Zudem bietet KKP in der Version 2.31 spezifische GPU-Projektkontingente an, während KubeLB den Datenverkehr über die Kubernetes Gateway API steuert und Anfragen basierend auf der Inferenzlast verteilt.

Hintergrund – Die Entstehung des Problems

Die Notwendigkeit für eine solche Plattform erwuchs aus einer weit verbreiteten Praxis in der IT-Infrastruktur vieler Unternehmen. In der Vergangenheit war es üblich, für jedes Team, das KI-Modelle einsetzt, eine eigene, separate Modellbereitstellung aufzusetzen. Dies erforderte zwangsläufig die Reservierung eines eigenen GPU-Pools für jede dieser Einheiten. In der Praxis führte dies jedoch zu einem gravierenden Ungleichgewicht: Während einige Teams mit hohem Bedarf auf freie Kapazitäten warten mussten, verblieben die GPUs anderer Teams, die gerade weniger Anfragen zu verarbeiten hatten, im Leerlauf. Da GPUs zu den kostenintensivsten Infrastrukturkomponenten in modernen Rechenzentren zählen, stellte dieser Zustand eine erhebliche finanzielle Belastung dar. Die Ineffizienz der bisherigen Vorgehensweise war somit der primäre Treiber für die Entwicklung von Kubermatic AI. Das Unternehmen reagiert damit auf ein Kostenproblem, das in vielen Rechenzentren schlummert und durch die zunehmende Verbreitung von KI-Workloads immer deutlicher zutage tritt. Die Lösung zielt darauf ab, diese isolierten Silos aufzubrechen und eine effizientere, zentralisierte Nutzung der vorhandenen Hardware zu ermöglichen.

Die Beteiligten – Wer entscheidet und wer profitiert

Das Unternehmen Kubermatic, mit Sitz in Hamburg, agiert hier als Anbieter und Entwickler der Plattform. CEO Sebastian Scheele ist dabei die zentrale Stimme, die die strategische Ausrichtung und die Problemanalyse des Unternehmens nach außen kommuniziert. Die Zielgruppe der neuen Lösung umfasst primär Betreiber interner KI-Plattformen, Anbieter von sogenannten Neoclouds sowie Organisationen, die souveräne KI-Umgebungen betreiben. Diese Akteure sind direkt von den hohen Kosten für GPU-Infrastruktur betroffen und suchen nach Wegen, ihre Betriebskosten zu optimieren. Darüber hinaus adressiert das Angebot Developer, Software-Architekten sowie DevOps- und Platform-Engineering-Teams. Diese Gruppen sind es, die in der Praxis mit der Verwaltung von Kubernetes-Clustern und der Bereitstellung von KI-Modellen betraut sind. Auch wenn keine weiteren externen Partner oder Kunden namentlich genannt wurden, ist die Plattform explizit für Unternehmen konzipiert, die ihre Infrastruktur auf Kubernetes-Basis standardisiert haben und eine effizientere Verwaltung ihrer KI-Workloads anstreben, ohne dabei an einen einzelnen Cloud-Anbieter gebunden zu sein.

Einordnung – Was das bedeutet

Den Berichten zufolge ist die Einführung von Kubermatic AI als Antwort auf die zunehmende Komplexität und die hohen Kosten bei der Bereitstellung von KI-Modellen zu verstehen. Einzuordnen ist das so: Die Plattform versucht, die Flexibilität von Kubernetes mit der Notwendigkeit einer effizienten Hardware-Auslastung zu verbinden. Durch den Ansatz, Modelle als geteilten Dienst bereitzustellen, vollzieht das Unternehmen einen Schritt weg von der isolierten Infrastruktur hin zu einer mandantenfähigen Architektur. Dies ist besonders relevant für Unternehmen, die ihre Datensouveränität wahren wollen, da die Plattform sowohl selbst gehostete Open-Source-Modelle als auch externe Closed-Source-Anbieter integrieren kann. Die Unterstützung des Model Context Protocol (MCP) ist dabei ein wichtiger technischer Aspekt, da sie eine standardisierte Anbindung von KI-Assistenten und Werkzeugen ermöglicht. Einzuordnen ist zudem, dass die Plattform auf Transparenz und Compliance setzt, etwa durch die Unterstützung von Rahmenwerken wie SOC 2 und PCI-DSS. Dies unterstreicht den Anspruch, eine enterprisestaugliche Lösung zu bieten, die über reine Experimentierumgebungen hinausgeht und den Anforderungen großer Organisationen gerecht wird.

Offene Fragen – Was der Quelltext nicht beantwortet

Obwohl Kubermatic AI eine Reihe von technischen Funktionen bietet, lässt der Quelltext einige Fragen unbeantwortet. So fehlen beispielsweise konkrete Details zu den Migrationspfaden für Unternehmen, die bereits bestehende Modellbereitstellungen in einzelnen Namespaces oder Clustern betreiben. Es wird zwar angedeutet, dass diese in kompatible Serving-Backends wie KServe oder llm-d überführt oder über KubeLB-Gateways angebunden werden könnten, doch konkrete Anleitungen oder automatisierte Werkzeuge für diesen Prozess werden nicht explizit beschrieben. Auch fehlen spezifische Kennzahlen zur erzielbaren Effizienzsteigerung. Zwar wird das Problem der niedrigen Auslastung benannt, doch liefert der Anbieter bislang keine konkreten Daten zu einer durchschnittlichen prozentualen Verbesserung der GPU-Auslastung oder zu den potenziellen Kosteneinsparungen pro Token. Zudem bleibt offen, wie komplex die Konfiguration der mandantenbezogenen Identity Provider in der Praxis tatsächlich ist und welche spezifischen Anforderungen an die zugrundeliegende Infrastruktur gestellt werden, um eine reibungslose Zusammenarbeit zwischen verschiedenen Teams ohne gegenseitige Beeinträchtigung zu gewährleisten.

Wie es weitergeht – Ankündigungen und Termine

Im Hinblick auf die weitere Entwicklung und Wissensvermittlung weist das Unternehmen auf die CLC-Konferenz hin, die vom 11. bis 12. November 2026 in Mannheim stattfinden wird. Dort sollen Themen wie Agentic AI, digitale Souveränität und Platform Engineering vertieft werden, was für die Zielgruppe von Kubermatic AI von hoher Relevanz ist. Hinsichtlich der Plattform selbst ist die Version 2.31 der Kubermatic Kubernetes Platform (KKP) bereits ein wichtiger Meilenstein, da sie die notwendigen GPU-Projektkontingente und mandantenbezogenen Identity Provider bereitstellt. Auch die KubeLB-Insights in der Version 1.5 werden als Werkzeug genannt, um eine flottenweite Sicht auf Backends und Datenverkehr zu ermöglichen. Da die Plattform auf Standard-Kubernetes-Werkzeugen basiert, ist davon auszugehen, dass Kubermatic die Entwicklung im Einklang mit der Kubernetes-Roadmap fortsetzen wird, insbesondere im Hinblick auf die AI Conformance für zukünftige Kubernetes-Versionen. Weitere spezifische Termine für Updates oder neue Funktionen wurden im Quelltext nicht genannt, jedoch unterstreicht die offizielle AI-Konformität für Kubernetes 1.34 den Anspruch auf langfristige Kompatibilität und Standardisierung.