Kubermatic AI lar flere team dele én modellinstans på samme GPU-er

Hvert team sin egen modell-deployment, hver deployment sin egen reserverte GPU-pool. Noen team med høyt GPU-behov står i kø for ledig kapasitet, mens grafikkortene som er reservert for andre team går på tomgang fordi etterspørselen deres er lavere akkurat nå. Det er situasjonen Kubermatic beskriver som utgangspunkt for den nye plattformen Kubermatic AI, presentert på selskapets egen konferanse ContainerDays og omtalt av heise online 3. september. I ytterste konsekvens kan reell GPU-utnyttelse falle helt ned mot 5 prosent i slike oppsett, ifølge selskapet.

«We are observing companies making GPUs the most expensive unused inventory in the tech industry» — Sebastian Scheele, medgründer og daglig leder i Kubermatic

Prinsippet er «roll out once, deploy many times»: fem separate deployments for fem team slås sammen til én delt modellinstans, som flere leietakere bruker samtidig uten at tilganger, kvoter eller budsjetter blandes. Hvert team får sin egen API-nøkkel, sine kvoter, sine budsjetter og sine styringsregler, og leietakerne holdes isolert fra hverandre. Plattformen legger seg oppå GPU-er og Kubernetes-klynger du allerede har, enten de står på egne servere, i kanten, i skyen eller i et suverenitetsmiljø, og gjenbruker Kubermatics eksisterende deler: KKP for livssyklus på tvers av klynger, KDP som selvbetjeningslag, KubeOne, lastbalansereren KubeLB og hemmelighetshåndteringen KubeSG. Selve modellserveringen går på de Kubernetes-native rammeverkene KServe og llm-d.

For deg som bygger agenter er gatewayen det interessante. KubeLB ruter både LLM-trafikk og MCP-trafikk gjennom Kubernetes Gateway API, slik at OpenAI, Anthropic, Google, Mistral og lokalt driftede modeller kan ligge bak ett endepunkt, og KDP kommer med en innebygd ekstern MCP-server som lar KDP-miljøer styres fra en KI-assistent.

Kubermatic legger samtidig ikke fram tall på faktisk GPU-utnyttelse etter konsolidering, ingen kostnad per token og ingen publisert migreringsvei fra eksisterende oppsett. Gevinsten avhenger av hvor mange duplikate deployments du faktisk har.

Hva bør du gjøre?

1. Tell dine egne modell-deployments før du bestiller flere GPU-er. Kjører to team samme modell i hver sin namespace, er det den duplikasjonen som koster, ikke mangel på maskinvare.
2. Sjekk hvilken serveringsbackend du står på. Konsolidering forutsetter i praksis KServe eller llm-d, eller at du kobler på via KubeLB-gateway.
3. Test MCP-ruting gjennom én gateway før du sprer nøkler til flere leverandører i hver applikasjon. Kvoter og budsjetter per team er lettere å håndheve i ett rutingpunkt enn i ti kodebaser.