Geteilte GPU auf Kubernetes: Was Sie tatsächlich bekommen

September 2026 • Product

Die meisten Inferenzdienste nutzen nur einen Teil einer GPU, und eine ganze Karte ist oft mehr, als ein Notebook, ein Batch-Scoring-Job oder ein kleines Modell braucht. Eine Karte zwischen Workloads zu teilen klingt einfach, aber Kubernetes tut das standardmäßig nicht, und die verschiedenen Wege dazu geben sehr unterschiedliche Versprechen ab. Dieser Artikel erklärt diese Versprechen, was ein geteilter Slice auf Kube-DC garantiert und was nicht, und was wir beim Betrieb eines echten LLM darauf gelernt haben.

Kubernetes vergibt standardmäßig ganze GPUs

Das Standard-Device-Plugin-Modell von Kubernetes meldet GPUs als ganze Zahlen an den Scheduler. Eine Anforderung von nvidia.com/gpu: 1 bedeutet die gesamte Karte, und alle anderen Pods warten. Der Scheduler kennt kein Speicherkontingent, daher braucht das Teilen einer Karte zusätzliche Technik, und es gibt drei gängige Ansätze.

HAMi, ein Projekt der Cloud Native Computing Foundation, funktioniert, indem es in jeden Container eine Bibliothek lädt, die CUDA-Aufrufe abfängt. Der Container sieht nur seinen Speicher-Slice, eine Zuweisung, die den Slice überschreiten würde, liefert einen Out-of-Memory-Fehler, und Kernel-Starts werden in Richtung des angeforderten Rechenanteils gedrosselt. Die eigene Dokumentation von HAMi ist bei den Grenzen sorgfältig: Anwendungen, die die CUDA-Bibliothek umgehen, etwa Docker-in-Docker oder direkte Treiberaufrufe, werden nicht erfasst, und die Isolierung ist im Vergleich zu MIG nach bestem Bemühen.

Was ein geteilter Slice auf Kube-DC garantiert

Die GPU-Pakete von Kube-DC nutzen Software-Slicing auf NVIDIA-V100-Karten, und die Plattformdokumentation nennt die Garantien präzise. Ein Slice ist ein fester Bruchteil eines GPU-Modells; Sie fordern das Produkt an, statt Speicher und Rechenleistung frei einzustellen. Auf einer V100 mit 32 GB bieten unsere Pakete 25 % (8 GiB), 50 % (16 GiB) und 100 % (32 GiB).

• Der Speicher-Slice wird durchgesetzt. Im Container meldet nvidia-smi die Größe des Slice, nicht der physischen Karte, und der Slice ist eine harte Obergrenze.
• Der Rechenanteil beruht auf Kooperation. Die Plattform steuert jede Workload im stabilen Zustand in Richtung ihres Anteils, aber beim Start und auf manchen CUDA-Bibliothekspfaden kann er kurzzeitig überschritten werden. Es ist keine garantierte Leistung.
• Kontingent ist ein Anspruch, keine Reservierung. Ein Kontingent reserviert keinen physischen Slice. Sind alle kompatiblen GPUs belegt, wartet eine gültige Workload im Status Pending, bis ein Slice frei wird.
• Slices sind für Container. Geteilte Kapazität kann nicht an eine virtuelle Maschine angebunden werden.

Wie die Nutzung aussieht

Seit Kubernetes 1.34 sind die Dynamic-Resource-Allocation-(DRA)-APIs in resource.k8s.io/v1 allgemein verfügbar, und Kube-DC nutzt sie: Eine Workload verweist auf ein ResourceClaimTemplate, das auf die DeviceClass Ihres Produkts zeigt, und die Plattform validiert die Anforderung, wenn Sie sie anwenden. Ihr Projektkontingent zeigt, wie viele Slices jedes Produkts Sie gleichzeitig halten dürfen:

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

Sobald Ihr Pod läuft, bestätigen Sie den Slice aus dem Container heraus. Beim 8-GiB-Produkt beträgt der Speicher insgesamt 8192 MiB, obwohl die Karte 32 GB hat:

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

Das vollständige, kopier- und anpassbare Manifest steht in der Kube-DC-Dokumentation, und wir geben es hier bewusst nicht wieder, da es dem veröffentlichten Vertrag der Plattform exakt entsprechen muss. In unserem eigenen Test scheiterten deshalb zwei Versuche, bevor der dritte gelang:

• Eine einfache nvidia.com/gpu-Anforderung auf einem rohen Pod wurde von einer Admission-Policy abgelehnt, da geteilte GPU-Kapazität nur über das Claim-basierte Muster angeboten wird.
• Ein handgeschriebenes DRA-Claim-Template wurde von einer zweiten Admission-Policy abgelehnt, da Labels, Namen und feste Kapazitätswerte der dokumentierten Form folgen müssen.
• Das dokumentierte Manifest wurde akzeptiert, dann startete der Pod aus einem unabhängigen Grund nicht: Das gemeinsame CPU-Kontingent des Projekts war durch einen Managed Cluster und eine virtuelle Maschine fast vollständig ausgeschöpft. Ein GPU-Pod braucht weiterhin CPU und Arbeitsspeicher aus Ihrem Paket – prüfen Sie diese Reserve daher, bevor Sie bereitstellen.

Ein LLM auf einem Slice betreiben: Was wir gelernt haben

In unserem End-to-End-Test vom August 2026 haben wir Ollama auf einem 8-GiB-Slice betrieben und llama3.2:3b bereitgestellt und dann einen KI-Agenten damit verbunden – zuerst von einer virtuellen Maschine im selben Projekt und dann von einem Server außerhalb des Rechenzentrums. Die Ollama-Logs zeigten die Karte als Tesla V100 mit Compute Capability 7.0 und insgesamt 8,0 GiB, genau der Slice. Vier Details haben uns Zeit gekostet, und jedes gilt für jeden, der ein Modell auf einem Slice betreibt.

1. Prüfen Sie, ob Ihre Software die GPU-Generation noch unterstützt

Die V100 ist eine Karte der Volta-Generation, und aktuelle GPU-Software hat begonnen, weiterzuziehen. In unserem Test übersprang das neueste Ollama-Image die GPU, weil sein CUDA-Build die Compute Capability 7.0 nicht enthielt. Das Festnageln auf ollama/ollama:0.24.0 behob es. Das deckt sich mit den Upstream-Berichten: Ein Ollama-Issue beschreibt, dass v0.30.0 auf einer Tesla V100 mit dem Fehler „device kernel image is invalid“ scheitert, während v0.24.0 und früher funktionierten, und ein Maintainer führte später einen solchen Fehler auf komprimierte CUDA-Kernel zurück, die NVIDIA-Treiber 550 oder neuer erfordern. Pinnen Sie Ihre Image-Version und testen Sie Upgrades bewusst.

2. Das Speicherlimit des Pods ist vom GPU-Slice getrennt

Unser erstes Laden des Modells wurde mit Exit-Code 137 (OOMKilled) beendet. Ursache war das eigene Speicherlimit des Containers von 512 MiB, das für den Host-seitigen Overhead von Ollama viel zu klein ist und nichts mit dem GPU-Speicher zu tun hatte. Dimensionieren Sie Request und Limit für den Arbeitsspeicher des Containers unabhängig vom festen Slice. Wir verwendeten 2 GiB und 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. Das Standard-Kontextfenster kann den Prompt eines Agenten stillschweigend abschneiden

Der von uns angebundene Agent sendet einen System-Prompt und Tool-Definitionen von etwa 14.700 Tokens. Das Ollama-Server-Log zeigte, dass die Eingabe auf sein Limit von 4.096 Tokens gekürzt wurde, was verworrene, unzuverlässige Antworten erzeugte, die wie ein Problem der Modellqualität aussahen. Das Erhöhen der Kontextlänge mit der obigen Variable behob die Ursache. Denken Sie daran, dass ein längerer Kontext mehr vom Speicher Ihres Slice nutzt – dimensionieren Sie Modell und Kontext daher gemeinsam.

4. Modelle leben im Pod, sofern Sie ihnen kein Volume geben

Beim standardmäßigen temporären Speicher löschte jeder Neustart des Pods, auch einer durch das Ändern einer Umgebungsvariable ausgelöster, die abgerufenen Modelle. Legen Sie das Modellverzeichnis für alles, was über eine Demo hinausgeht, auf ein persistentes Volume. Beachten Sie außerdem, dass Mandantenrollen auf Kube-DC kubectl exec nicht nutzen können, daher haben wir Modelle mit einmaligen Jobs abgerufen, die die HTTP-API von Ollama aufrufen.

Wann ein geteilter Slice das richtige Werkzeug ist

Die Kube-DC-Dokumentation nennt den passenden Einsatz: Modellinferenz, Notebooks, kleine Trainingsläufe und Batch-Scoring, bei denen ein Job GPU-Beschleunigung braucht, aber keine ganze Karte. Schlecht passt es, wenn Sie eine harte Isolierungsgrenze, garantierten Durchsatz oder ein Modell benötigen, das größer ist als der Slice, und Arbeit, die eine ganze Karte braucht, gehört auf dedizierte Hardware. Weil Slices in eine Warteschlange kommen, wenn die Karte ausgelastet ist, eignet es sich auch eher für Workloads, die auf Kapazität warten können, als für latenzkritische Dienste mit strikten Fristen.

So bewerten Sie jedes Angebot mit geteilter GPU

• Wird das Speicherlimit durchgesetzt, oder ist es eine Empfehlung? Time-Slicing setzt keines durch.
• Ist der Rechenanteil garantiert, kooperativ oder unbegrenzt, und was passiert bei Konkurrenz?
• Ist das Kontingent eine Reservierung, oder kann Ihre Workload im Status Pending warten, wenn die Karte ausgelastet ist?
• Welches GPU-Modell ist es, und unterstützt die Software, die Sie betreiben wollen, diese Generation noch?
• Können Sie eine ganze Karte oder eine dedizierte VM bekommen, wenn Sie einem Slice entwachsen, und wie sieht die Isolierung dort aus?
• Welche CPU, welchen Arbeitsspeicher und welchen Speicher erhalten Sie zusätzlich zur GPU, und werden sie mit dem Rest Ihrer Workloads gepoolt?

Quellen

• 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

Weiterführende Lektüre

• Managed vs. Self-Hosted Kubernetes: Die technische Realität
• So bewerten Sie einen Managed-Kubernetes-Anbieter in Europa

Probieren Sie es auf Kube-DC aus

Unsere GPU-Pakete ergänzen einen Kube-DC-Pool um einen Anteil einer geteilten NVIDIA V100: 25 %, 50 % oder 100 % der Karte, mit durchgesetztem Speicher-Slice. Dazu erhalten Sie dedizierte vCPU, Ceph-basierten NVMe-Speicher, eine dedizierte öffentliche IPv4, S3-kompatiblen Objektspeicher und Ihre eigenen vom Mandanten administrierten Kubernetes-Cluster, mit 24/7-Support per E-Mail und Ticket und einem Lösungsziel von 4 Stunden. Wir haben ein echtes LLM und einen KI-Agenten damit durchgängig betrieben, und jeder Schritt in diesem Artikel lässt sich wiederholen.