Gedeelde GPU op Kubernetes: wat u werkelijk krijgt

September 2026 • Product

De meeste inferentiediensten gebruiken slechts een deel van een GPU, en een complete kaart is vaak meer dan een notebook, een batch-scoringtaak of een klein model nodig heeft. Eén kaart delen tussen workloads klinkt eenvoudig, maar Kubernetes doet dat standaard niet, en de verschillende manieren om het te doen beloven heel verschillende dingen. Dit artikel legt die beloften uit, wat een gedeelde slice op Kube-DC wel en niet garandeert, en wat we leerden door een echte LLM erop te draaien.

Kubernetes deelt standaard hele GPU's uit

Het standaard device-pluginmodel van Kubernetes meldt GPU's aan de scheduler als hele getallen. Een aanvraag van nvidia.com/gpu: 1 betekent de volledige kaart, en alle andere pods wachten. De scheduler kent geen geheugenquotum, dus voor het delen van een kaart is extra machinerie nodig, en er zijn drie gangbare aanpakken.

HAMi, een project van de Cloud Native Computing Foundation, werkt door in elke container een bibliotheek te laden die CUDA-aanroepen onderschept. De container ziet alleen zijn slice geheugen, een toewijzing die de slice zou overschrijden geeft een out-of-memoryfout terug, en kernel-launches worden afgeremd richting het gevraagde rekenaandeel. De eigen documentatie van HAMi is voorzichtig over de grenzen: applicaties die de CUDA-bibliotheek omzeilen, zoals Docker-in-Docker of directe driveraanroepen, worden niet gedekt, en de isolatie is best-effort in vergelijking met MIG.

Wat een gedeelde slice op Kube-DC garandeert

De GPU-pakketten van Kube-DC gebruiken softwarematige slicing op NVIDIA V100-kaarten, en de platformdocumentatie beschrijft de garanties precies. Een slice is een vaste fractie van één GPU-model; u vraagt het product aan in plaats van geheugen en rekenkracht vrij af te stellen. Op een V100 van 32 GB bieden onze pakketten 25% (8 GiB), 50% (16 GiB) en 100% (32 GiB).

• De geheugenslice wordt afgedwongen. In de container meldt nvidia-smi de grootte van de slice, niet van de fysieke kaart, en de slice is een harde limiet.
• Het rekenaandeel is coöperatief. Het platform stuurt elke workload in de stabiele toestand richting zijn aandeel, maar bij het opstarten en op sommige CUDA-bibliotheekpaden kan het kortstondig worden overschreden. Het is geen gegarandeerde prestatie.
• Quotum is een recht, geen reservering. Een quotum reserveert geen fysieke slice. Wanneer alle compatibele GPU's bezet zijn, wacht een geldige workload in de status Pending tot er een slice vrijkomt.
• Slices zijn voor containers. Gedeelde capaciteit kan niet aan een virtuele machine worden gekoppeld.

Hoe het gebruik eruitziet

Sinds Kubernetes 1.34 zijn de Dynamic Resource Allocation (DRA)-API's in resource.k8s.io/v1 algemeen beschikbaar, en Kube-DC gebruikt ze: een workload verwijst naar een ResourceClaimTemplate dat naar de DeviceClass van uw product wijst, en het platform valideert de aanvraag wanneer u die toepast. Uw projectquotum laat zien hoeveel slices van elk product u tegelijk mag houden:

kubectl get resourcequota -n <project-namespace> -o yaml | grep deviceclass

Zodra uw pod draait, controleert u de slice vanuit de container. Bij het product van 8 GiB is het totale geheugen 8192 MiB, ook al heeft de kaart 32 GB:

nvidia-smi --query-gpu=name,memory.total --format=csv,noheader
# Tesla V100-PCIE-32GB, 8192 MiB

Het volledige manifest om te kopiëren en aan te passen staat in de Kube-DC-documentatie, en we geven het hier bewust niet weer, omdat het exact moet overeenkomen met het gepubliceerde contract van het platform. In onze eigen test mislukten twee pogingen om die reden voordat de derde slaagde:

• Een gewone nvidia.com/gpu-aanvraag op een kale pod werd geweigerd door een admissionbeleid, omdat gedeelde GPU-capaciteit alleen wordt aangeboden via het op claims gebaseerde patroon.
• Een met de hand geschreven DRA-claimtemplate werd geweigerd door een tweede admissionbeleid, omdat de labels, namen en vaste capaciteitswaarden de gedocumenteerde vorm moeten volgen.
• Het gedocumenteerde manifest werd geaccepteerd, waarna de pod om een niet-gerelateerde reden niet startte: het gepoolde CPU-quotum van het project was bijna volledig in gebruik door een beheerd cluster en een virtuele machine. Een GPU-pod heeft nog steeds CPU en geheugen uit uw pakket nodig, dus controleer die ruimte voordat u deployt.

Een LLM draaien op een slice: wat we leerden

In onze end-to-endtest van augustus 2026 draaiden we Ollama op een slice van 8 GiB en serveerden we llama3.2:3b, waarna we er een AI-agent op aansloten, eerst vanaf een virtuele machine in hetzelfde project en daarna vanaf een server buiten het datacenter. De Ollama-logs toonden de kaart als een Tesla V100 met compute capability 7.0 en een totaal van 8,0 GiB, precies de slice. Vier details kostten ons tijd, en elk ervan geldt voor iedereen die een model op een slice draait.

1. Controleer of uw software de GPU-generatie nog ondersteunt

De V100 is een kaart van de Volta-generatie, en actuele GPU-software is begonnen door te schuiven. In onze test sloeg de nieuwste Ollama-image de GPU over, omdat de CUDA-build compute capability 7.0 niet bevatte. Het vastzetten van ollama/ollama:0.24.0 loste het op. Dit komt overeen met de upstream-meldingen: een Ollama-issue beschrijft dat v0.30.0 faalt op een Tesla V100 met de fout "device kernel image is invalid", terwijl v0.24.0 en eerder werkten, en een maintainer schreef een vergelijkbare fout later toe aan gecomprimeerde CUDA-kernels waarvoor NVIDIA-driver 550 of nieuwer nodig is. Zet uw imageversie vast en test upgrades bewust.

2. De geheugenlimiet van de pod staat los van de GPU-slice

Onze eerste modelload werd beëindigd met exitcode 137 (OOMKilled). De oorzaak was de eigen geheugenlimiet van de container van 512 MiB, veel te klein voor de overhead van Ollama aan de hostkant, en had niets met GPU-geheugen te maken. Dimensioneer de RAM-request en -limiet van de container onafhankelijk van de vaste slice. Wij gebruikten 2 GiB en 4 GiB:

containers:
- name: ollama
  image: ollama/ollama:0.24.0
  env:
  - name: OLLAMA_CONTEXT_LENGTH
    value: "16384"
  resources:
    requests:
      memory: 2Gi
    limits:
      memory: 4Gi

3. Het standaard contextvenster kan de prompt van een agent stilzwijgend afkappen

De agent die we aansloten stuurt een systeemprompt en toolbeschrijvingen van ongeveer 14.700 tokens. Het Ollama-serverlog toonde dat de invoer werd afgekapt op de limiet van 4.096 tokens, wat rommelige, onbetrouwbare antwoorden opleverde die op een probleem met de modelkwaliteit leken. Het verhogen van de contextlengte met de bovenstaande variabele verhielp de oorzaak. Bedenk dat een langere context meer van het geheugen van uw slice gebruikt, dus dimensioneer model en context samen.

4. Modellen leven in de pod, tenzij u ze een volume geeft

Met de standaard tijdelijke opslag wiste elke herstart van de pod, ook een veroorzaakt door het wijzigen van een omgevingsvariabele, de opgehaalde modellen. Zet de modelmap voor alles wat meer is dan een demo op een persistent volume. Let er ook op dat tenantrollen op Kube-DC kubectl exec niet kunnen gebruiken, dus we haalden modellen op met eenmalige Jobs die de HTTP-API van Ollama aanroepen.

Wanneer een gedeelde slice het juiste gereedschap is

De Kube-DC-documentatie benoemt de toepassing: modelinferentie, notebooks, kleine trainingen en batchscoring, waar een taak GPU-versnelling nodig heeft maar geen hele kaart. Het past slecht als u een harde isolatiegrens, gegarandeerde doorvoer of een model groter dan de slice nodig hebt, en werk voor een hele kaart hoort op dedicated hardware. Omdat slices in de wachtrij komen te staan als de kaart bezet is, past het ook beter bij workloads die op capaciteit kunnen wachten dan bij latentiegevoelige diensten met strikte deadlines.

Hoe u elk aanbod voor gedeelde GPU beoordeelt

• Wordt de geheugenlimiet afgedwongen, of is het een suggestie? Time-slicing dwingt niets af.
• Is het rekenaandeel gegarandeerd, coöperatief of onbeperkt, en wat gebeurt er bij contentie?
• Is quotum een reservering, of kan uw workload in Pending wachten wanneer de kaart bezet is?
• Welk GPU-model is het, en ondersteunt de software die u wilt draaien die generatie nog?
• Kunt u een hele kaart of een dedicated VM krijgen als een slice te klein wordt, en hoe ziet de isolatie er daar uit?
• Welke CPU, geheugen en opslag krijgt u naast de GPU, en worden die gedeeld met de rest van uw workloads?

Bronnen

• Kube-DC: shared GPU workloads
• Kube-DC platform datasheet
• HAMi: GPU virtualization principles
• HAMi: FAQ (HAMi vGPU compared with MIG)
• NVIDIA GPU Operator: time-slicing GPUs in Kubernetes
• Kubernetes v1.34: DRA has graduated to GA
• Kubernetes: Dynamic Resource Allocation
• Ollama issue 16449: v0.30.0 fails on Tesla V100

Gerelateerd

• Beheerd vs. zelf gehost Kubernetes: de technische realiteit
• Hoe u een beheerde Kubernetes-aanbieder in Europa beoordeelt

Probeer het op Kube-DC

Onze GPU-pakketten voegen een slice van een gedeelde NVIDIA V100 toe aan een Kube-DC-pool: 25%, 50% of 100% van de kaart, met de geheugenslice afgedwongen. Daarnaast krijgt u dedicated vCPU, op Ceph gebaseerde NVMe-opslag, een dedicated publiek IPv4-adres, S3-compatibele objectopslag en uw eigen door de tenant beheerde Kubernetes-clusters, met 24/7 support via e-mail en tickets en een oplostijddoel van 4 uur. We hebben er een echte LLM en een AI-agent end-to-end op gedraaid, en elke stap in dit artikel kunt u herhalen.