Pexon Consulting | 10 Min. Lesezeit | 30.08.2026
TL;DR
Kubernetes ist 2026 nötig für KI-Workloads, aber nicht hinreichend. Inferenz, Training und agentische Lasten brauchen unterschiedliche Scheduler, GPUs und Nachweise. Wer denselben Pool ohne Schnitt betreibt, kauft Leerlauf und Ausfälle. Der Text trennt die drei Lasttypen und zeigt, was der Betrieb darunter leisten muss. Stand August 2026.
Das Problem: „wir machen KI auf Kubernetes“ ist kein Zielbild
Ein Cluster, ein GPU-Pool, ein Namespace „ai“: das ist die Folie, nicht der Betrieb. Inferenz will niedrige Wartezeit und stehende Replicas. Training will lange Jobs, Checkpoints und Fair-Share. Agenten wollen Sandbox, Identity und Werkzeugzugriff, oft sekundenweise, mit Seitenkanälen in interne Systeme.
Microsoft hat auf der Build-Linie 2025/2026 denselben Satz in die Architekturdecks geschrieben: Kubernetes ist die gemeinsame Steuerungsebene, die Workloads selbst sind nicht austauschbar. Wer das ignoriert, sieht es an drei Symptomen. GPU-Nodes stehen nachts voll, obwohl niemand inferenziert. Ein Trainingsjob räumt den Chat-Endpunkt weg. Ein Agent-Pod mit Cluster-Admin „zum Debuggen“ überlebt den PoC.
Dieser Text ist die Nabe zwischen Tool-Blogs und dem Betriebs-Hub. Den Jahresrückblick zu Distributionen, DRA und Gateway API haben wir separat geschrieben. Hier stehen Lasttypen.
Drei Lasttypen, drei Verträge mit dem Cluster
Die Zeilen sind absichtlich grob. Ein Embedding-Batch ist Inferenz mit anderer SLO. Ein Eval-Lauf ist Training ohne Modellupdate. Trotzdem: sobald zwei Zeilen denselben nvidia.com/gpu-Pool ohne Quota teilen, gewinnt der lauteste Job.
# Orientierungsbeispiel: Pools im Git, nicht "Namespace ai"
gpuPools:
inferenz:
taint: "workload=inferenz:NoSchedule"
sharing: mig
training:
taint: "workload=training:NoSchedule"
sharing: none
agenten:
runtime: kata
gpu: "0" # Werkzeuge auf CPU, Modelle über das GatewayOhne diese Trennung ist Karpenter nur ein teurer Lüfter: er skaliert den Mischbetrieb hoch, statt die falsche Mischung zu verbieten.
Warum Kubernetes nötig bleibt
Ohne Kubernetes verdoppelt ihr für jeden Lasttyp die Plattform: VM-Images, Secrets, Ingress, Observability. Der gemeinsame Nenner ist sinnvoll: GitOps, NetworkPolicy, ResourceQuota, ein Identity-Anschluss, GPU-Operator auf den Knoten.
Nötig heißt nicht fertig. Device Plugin oder DRA müssen zur Hardware passen. Ein Gateway muss Keys und Budgets kennen, sonst wird Inferenz zur Schatten-API. Agenten brauchen eine Runtime, die Syscalls begrenzt. Training braucht eine Queue, die den Chat nicht erwürgt.
Die Production-Gap ist immer dieselbe Form: PoC antwortet, Betrieb und Nachweis tun es nicht. Beim Lasttyp wechselt nur das Artefakt. Inferenz: Modellstand. Training: Checkpoint und Daten. Agent: Tool-Permission und Session.
Agentische Last ist kein „kleineres LLM“
Ein Agent, der Jira, Git und interne HTTP-APIs anfasst, ist eine Integrationsfläche. Die GPU-Frage ist oft zweitrangig, weil das Modell über das vorhandene Gateway läuft. Die Cluster-Frage ist Isolation: Container-Escape, seitliche Bewegung, langlebige Tokens.
Kata Containers oder vergleichbare Sandbox-Runtimes, kurze Identitäten, Policy vor dem Tool. Das ist ein anderer Blog-Strang (Keyless Identity, Agent-Sandbox), aber derselbe Hub: die Plattform unter dem Produkt. Wer Agenten in denselben Namespace wie vLLM legt, „weil beides KI ist“, vermischt Vertrauensgrenzen.
Was ihr nicht in denselben Cluster-Schnitt packen sollt
- Chat-Inferenz und Mehr-Tage-Training auf denselben ungeteilten GPUs ohne Quota.
- Agent-Tool-Pods mit denselben ServiceAccounts wie das Serving.
- Dev-Time-Slicing auf Karten, die Kundenantworten erzeugen.
- Ein Alert „GPU Util 0“ ohne Lasttyp: nachts darf Training-Idle anders aussehen als toter Chat.
- Ein SLA für „den KI-Cluster“, das TTFT und Job-Completion in denselben Satz zwingt.
Diese Liste ist der Filter vor jedem Chart. Tools kommen danach: Operator, vLLM, Kueue, Kata.
Was Pexon konkret macht
Wir betreiben die Plattform unter den drei Lasttypen auf eurem Cluster: GPU-Pools, Inferenz-Pfad, Gateway, Isolation wo Agenten Werkzeuge anfassen. Training als Data-Science-Job bleibt bei euch. Wir halten die Karten, die Queues und den Nachweis, nicht das Modellziel. GPU-Scheduling auf Kubernetes: Queue vor der Karte
Einstieg: AI-Readiness-Scan 990 EUR, ein Tag, fünf Seiten. Betrieb ab 5.000 EUR im Monat, Spanne bis 10.000, Servicezeit Mo-Fr 08:00-18:00 MEZ. Kein Hyperscaler-Wiederverkauf, keine 24/7-Fantasie.
Was das nicht ist
Kein Kernel-Deep-Dive, kein zweites Kubernetes-2026, keine Tool-Liste mit zwölf Scannern. Es ist die Lasttyp-Karte, bevor ihr Charts mischt. Modellwahl und Prompt-Qualität gehören in euer Produkt, nicht in diesen Betriebsschnitt.
Häufig gestellte Fragen
Reicht ein Kubernetes-Cluster für alle AI Workloads?
Ein Cluster ja, ein ungeschnittener GPU-Pool nein. Namespaces, Taints und Quotas sind die Mindestschnitte. Inferenz und Training auf derselben Karte ohne Regel ist der teuerste Default.
AI Workloads Kubernetes: Inferenz oder Agenten zuerst?
Zuerst die Last, die Kunden sehen: fast immer Inferenz plus Gateway. Agenten danach, mit Isolation. Training nur, wenn ein Data-Team Retraining wirklich fährt.
Was kostet der Betrieb, wenn drei Lasttypen anliegen?
Mehr Pools heißen mehr Nodes oder strengere Sharing-Regeln, nicht automatisch dreimal Preis. Pexon-Betrieb der Plattform: 5.000-10.000 EUR im Monat plus eure GPUs. Der Scan klärt, ob ihr drei Pools braucht oder zwei.
Brauchen Agenten eigene GPUs?
Selten. Sie brauchen Sandbox, Identity und ein Gateway zum Modell. Eigene Karten nur, wenn ihr lokal inferenziert und die Last den Chat-Pool gefährdet.
Ist Kubernetes 2026 ohne GPU-Operator für KI-Workloads haltbar?
Nur als kurzer Versuch auf einem festen Node. Sobald Nodes skalieren oder Teams teilen, fehlt die Treiber- und Device-Schicht. Dann ist der Operator Teil des Lasttyp-Schnitts, nicht ein Extra.
Nächster Schritt
Drei Lasttypen, ein Pool, unklare Zuständigkeit: die Tabelle oben gegen euren Cluster legen. Lücken bei Schnitt, Gateway oder Nachweis? Dann den KI-Plattform-Betrieb (AI-Readiness-Scan, 990 EUR). Kubernetes als gemeinsame Ebene nutzen, die Workloads trotzdem trennen.
