|
03.09.2026
17:05 Uhr
|
Die Kubernetes-native KI-Plattform Kubermatic AI soll GPU-Ressourcen konsolidieren und Modelle als geteilten Dienst über Teams hinweg bereitstellen.
Die Kubernetes-native Plattform Kubermatic AI soll vorhandene GPU-Ressourcen in Unternehmen bündeln und als geteilte KI-Dienste bereitstellen. Das Hamburger Unternehmen Kubermatic hat die neue Plattform im Rahmen seiner alljährlichen Veranstaltung ContainerDays jetzt vorgestellt. Statt für jedes Team eine eigene Modellinstanz zu betreiben, verfolgt Kubermatic AI den Ansatz, ein Modell einmal auszurollen und es anschließend abgesichert über mehrere Mandanten hinweg zu nutzen. Laut Ankündigung zielt Kubermatic mit seiner neuen Plattform auf Betreiber interner KI-Plattformen, Neoclouds und Anbieter souveräner KI-Umgebungen ab.
Mehr zu Agentic AI, digitaler Souveränität und weiteren Themen finden interessierte Developer, Software-Architekten, DevOps- und Platform-Engineering-Teams auf der CLC-Konferenz vom 11. bis 12. November 2026 in Mannheim.
☞ Sichern Sie sich jetzt die Tickets zum Frühbucherpreis. ☜
Kubermatic AI reagiert laut Hersteller auf ein Kostenproblem, das in vielen Rechenzentren schlummert. Obwohl GPUs inzwischen zu den teuersten Infrastrukturkomponenten zählen, bleibt ihre Auslastung oft niedrig. Ursache dafür sei die in vielen Unternehmen gängige Praxis, für jedes Team eine separate Modellbereitstellung inklusive eines dafür reservierten GPU-Pools aufzusetzen. Dies führt immer wieder zu Situationen, in denen einige Teams mit höherem GPU-Bedarf auf freie Kapazitäten warten müssen, während die für andere Teams reservierten GPUs – aufgrund eines gerade geringeren Bedarfs – im Leerlauf verbleiben. In Extremfällen könne die tatsächliche GPU-Nutzung in solchen Konstellationen auf bis zu 5 Prozent sinken, was Kubermatic-Mitgründer und CEO Sebastian Scheele zu der drastischen Einschätzung kommen lässt: „Wir beobachten, wie Unternehmen GPUs zum teuersten ungenutzten Inventar in der Tech-Branche machen“.
Kubermatic AI setzt als Plattformschicht auf bereits vorhandenen GPUs und Kubernetes-Clustern auf – On-Premises, an der Edge, in der Cloud sowie in hybriden und souveränen Umgebungen. Der Ansatz folgt dem Grundprinzip: „einmal ausrollen, vielfach bereitstellen“. Aus fünf separaten Bereitstellungen für fünf Teams wird demnach eine gemeinsam genutzte Modellinstanz. Jedes Team erhält dabei einen eigenen API-Schlüssel, eigene Kontingente, separate Budgets sowie eigene Governance-Richtlinien. Die Mandanten bleiben trotz geteilter Modellinstanz voneinander isoliert.
Technisch baut Kubermatic AI auf dem bestehenden Portfolio des Anbieters auf. Dazu gehören die Kubermatic Kubernetes Platform (KKP) für das Multi-Cluster-Lifecycle-Management, die Kubermatic Developer Platform (KDP) als Self-Service-Ebene, das Lifecycle-Werkzeug KubeOne, der Load Balancer KubeLB mit KI-fähigem Networking sowie das Secrets-Management KubeSG. Für das eigentliche Model Serving greift die Plattform auf die Kubernetes-nativen Frameworks KServe und llm-d zurück.
Im Kern setzt die Plattform enterprisestaugliche Multi-Tenancy um, durch die mehrere Mandanten dieselben bereitgestellten Modelle nutzen können, ohne dass sich Zugriffe, Kontingente oder Budgets vermischen. Konkrete Kubernetes-Mechanismen wie Namespaces, Network Policies oder Admission Controller nennt Kubermatic in der Ankündigung zwar nicht im Detail, sie lassen sich aber aus der Architektur der zugrundeliegenden Komponenten ableiten. So stellt KKP in Version 2.31 GPU-Projektkontingente und mandantenbezogene Identity Provider pro Cluster bereit. KubeLB routet LLM- und MCP-Verkehr über die Kubernetes Gateway API, während das advanced AI-Networking Anfragen dabei anhand der tatsächlichen GPU-Auslastung und der Inferenzanforderungen verteilen soll.
Kubermatic AI setzt auf bestehender Infrastruktur auf und soll damit zur Konsolidierung beitragen: Wer bislang identische Modell-Deployments in einzelnen Namespaces oder Clustern betreibt, kann diese zu einer gemeinsamen Instanz zusammenführen und definiert darüber tenant-spezifische Kontingente und Richtlinien. Detaillierte Migrationspfade hat Kubermatic bislang nicht öffentlich vorgelegt, in der Praxis dürften bestehende Stacks aber entweder in ein kompatibles Serving-Backend wie KServe oder llm-d überführt oder über KubeLB-Gateways angebunden werden.
Die neue Plattform kann sowohl selbst gehostete Open-Source-Modelle als auch externe Closed-Source-Anbieter einbinden. Über das Agentgateway von KubeLB lässt sich LLM-Verkehr etwa zu OpenAI, Anthropic, Google oder Mistral ebenso routen wie zu lokal betriebenen Modellen. Mehrere Provider und MCP-Server lassen sich hinter einem einzigen Endpunkt verwalten. Dank Support für das Model Context Protocol (MCP), das KI-Assistenten und Werkzeuge standardisiert anbindet, lassen sich mit Kubermatic AI auch agentenbasierte Arbeitsabläufe einrichten. KDP stellt dazu einen eingebauten Remote-MCP-Server bereit, sodass sich KDP-Umgebungen per KI-Assistent steuern lassen – ohne dass sich Teams in eine neue Oberfläche einarbeiten müssen.
Ein weiterer Baustein des neuen Angebots ist die Kubernetes AI Conformance: KKP ist offiziell AI-konform für Kubernetes 1.34. Das standardisierte Blueprint soll Modelle zwischen konformen Clustern portabel machen, ohne dass Code neu geschrieben werden muss. Für Unternehmen im deutschsprachigen Raum kann das vor allem im Hinblick auf Vendor-Lock-in und Datensouveränität relevant sein, da sich Workloads zwischen Private Cloud, Public Cloud und Sovereign Cloud verschieben lassen. Kubermatic flankiert den Ansatz darüber hinaus mit integrierter Transparenz und Compliance-Unterstützung für Rahmenwerke wie SOC 2 und PCI-DSS. Das Unternehmen betont zudem die offene Basis: Die Plattform läuft mit Standard-Kubernetes-Werkzeugen und ohne vertragliche Bindung an einen einzelnen Anbieter.
Wie viel die Konsolidierung in der Praxis konkret bringt, hängt sicherlich vom individuellen Setup ab. Kennzahlen zu GPU-Auslastung in Prozent oder Kosten pro Token nennt Kubermatic bislang nicht. Die KubeLB-Insights aus Version 1.5 versprechen aber eine flottenweite Sicht auf Backends und Datenverkehr. Der wichtigste Hebel bleibt laut Anbieter das Zusammenführen mehrerer Modellbereitstellungen über Teamgrenzen hinweg – mit dem Ziel, teure Hardware auszulasten, statt neue GPUs anzuschaffen.
(map)