Eine private LLM-Plattform auf Kubernetes: der Stack Schicht für Schicht und die Hardware darunter

Der Stack, Schicht für Schicht

Eine private LLM-Plattform auf Kubernetes ist ein Stack aus Schichten, jede mit einer Aufgabe. Die Tabelle führt sie mit den im September 2026 aktuellen Versionen auf.

Release Notes und Release-Historien von NVIDIA, vLLM, KServe, der Gateway API Inference Extension, llm-d und Kubeflow, abgerufen am 24. September 2026.

GPU-Nodes und der GPU Operator

Der GPU Operator installiert, was ein GPU-Node braucht, jeden Teil als Container. Release 26.7.1, am 23. September 2026 das neueste in NVIDIAs Release Notes, bringt Device-Plugin und GPU Feature Discovery v0.20.1, DCGM Exporter v4.6.1-4.8.4 und MIG Manager v0.15.1 mit; der Operator ist Open Source unter Apache 2.0, und seine Seite zur Plattformunterstützung führt Kubernetes von Version 1.33 bis Version 1.37 unter Ubuntu 24.04 auf. Seine Supportliste nennt die Server Editions der RTX PRO 6000 und RTX PRO 4500, die H200 NVL, die L40S und die L4. Für die RTX PRO 4000 oder 5000 oder für die Workstation Edition und die Max-Q der RTX PRO 6000 haben wir keinen Eintrag gefunden.

GPU Feature Discovery versieht jeden Node mit einem Label für sein GPU-Modell, sodass das Deployment des Sprachmodells über nvidia.com/gpu.product Nodes mit RTX PRO 6000 oder H200 NVL auswählen kann. Ein Replikat, das mehrere GPUs umfasst, braucht ganze Karten, denn NCCL wird mit MIG nicht unterstützt. Karten für kleine Modelle lassen sich aufteilen: Der MIG Manager akzeptiert ein Layout je Gerät, sodass eine Karte eines Nodes MIG nutzen kann, während die anderen ganz bleiben, und die Strategie mixed meldet jedes Profil als eigene Ressource, etwa nvidia.com/mig-1g.24gb. Time-Slicing hat keine Speicher- oder Fehlerisolierung und eignet sich für die Entwicklung, nicht für einen produktiven Endpunkt. Unser Leitfaden zum GPU-Sharing behandelt die Details.

Serving: vLLM, KServe oder NIM

Ein vLLM-Server „stellt jeweils ein Modell bereit“, jedes Modell wird also zu einem eigenen Deployment. Die Kubernetes-Seite von vLLM zeigt die einfache Form: das Image vllm/vllm-openai, Gewichte auf einem PersistentVolumeClaim, Probes auf /health an Port 8000 und ein /dev/shm im Arbeitsspeicher, weil vLLM „für Inferenz mit Tensor-Parallelismus auf den gemeinsam genutzten Speicher des Hosts zugreifen muss“. Sie nennt 13 weitere Wege, vLLM bereitzustellen, darunter KServe und llm-d; unser Vergleich der Engines behandelt die Engines.

KServe 0.20.0, erschienen am 6. August 2026, verpackt das in einen InferenceService. Mit dem Modellformat huggingface nutzt seine Runtime standardmäßig vLLM und „fällt automatisch auf das Standard-Backend von Hugging Face zurück“, wenn vLLM ein Modell nicht unterstützt. Ein storageUri wie hf:// oder pvc:// benennt die Gewichte, und die OpenAI-Routen liegen unter /openai/v1/. Für LLMs verweist die Installationsanleitung von KServe inzwischen auf den LLMInferenceService, noch in einer Alpha-API-Version, der eine Route der Gateway API, Scheduling nach Treffern im Prefix-Cache und nach Last, die Disaggregation von Prefill- und Decode-Phase sowie Multi-Node-Serving hinzufügt. Kubeflow ergänzt Pipelines, Training, Notebooks und eine Model Registry; seine Community Distribution 26.03.1, das Patch-Release vom 15. Juni 2026, enthält KServe 0.18.0, zwei Minor-Releases hinter 0.20.0.

NVIDIA NIM ist die Option aus NVIDIA AI Enterprise, und NIM for LLMs 2.0.12, das NVIDIA inzwischen „NIM for Large Language Models and Vision Language Models“ nennt, „baut auf vLLM auf“: Der frühere Multi-Backend-Container „wird durch einen dedizierten vLLM-Container ersetzt“. Der NIM Operator, in Version 3.1.2 vom 12. August 2026, setzt GPU Operator 24.3.0 oder neuer voraus; unter seinen Ressourcen lädt NIMCache Modelle von NVIDIA NGC oder Hugging Face auf Netzwerkspeicher herunter, und NIMService legt das Deployment, den Service und, wenn aktiviert, einen Autoscaler an. NVIDIAs Bedingungen sehen kostenlosen Zugang über das Developer Program für Forschung, Entwicklung und Tests auf bis zu 16 GPUs vor und im Produktivbetrieb eine Lizenz für AI Enterprise je GPU; die H200 NVL bringt sie für fünf Jahre mit, die RTX PRO 6000 Server Edition und die L4 nicht. Unsere Seite zu NVIDIA AI Enterprise behandelt die Lizenz.

Routing, Zugang und Sicherheit

Routing. Die Gateway API Inference Extension, ein Kubernetes-Projekt, dessen Release v1.6.2 am 17. September 2026 erschienen ist, definiert den InferencePool, seit v1.0.0 stabil unter inference.networking.k8s.io/v1: eine Menge von Modellserver-Pods hinter einem Endpoint Picker, der vllm:num_requests_waiting, vllm:num_requests_running, vllm:kv_cache_usage_perc und die auf jedem Replikat genutzten LoRA-Adapter ausliest und jede Anfrage an das am besten geeignete Replikat schickt; ein einfacher Service ignoriert diese Signale. Seit v1.6.0 vom August 2026 liefert das Projekt selbst nur noch einen schlanken Endpoint Picker, „für Konformitätstests konzipiert“: Sein vollständiger Endpoint Picker ist in das Projekt llm-d umgezogen, und für den Produktivbetrieb verweist die Dokumentation auf llm-d-router oder einen eigenen Endpoint Picker. Der LLMInferenceService von KServe stellt einen solchen Scheduler selbst bereit. Das Gateway muss die Extension implementieren; das Projekt nennt Istio, Agentgateway und NGINX Gateway Fabric unter den Implementierungen.

Zugang. In der Dokumentation der Extension haben wir nichts zur Zugriffskontrolle gefunden. Schlüssel je Team, Rate Limits und das Protokoll der Anfragen und Antworten kommen aus den Policies des Gateways oder von einem OpenAI-kompatiblen Proxy, und dieser Weg muss der einzige Zugang sein. Die Option --api-key von vLLM schützt nur Pfade unter /v1, /v2, /inference und /cohere; /pause und /abort_requests antworten ohne den Schlüssel, und die Sicherheitsseite von vLLM rät davon ab, sich allein auf ihn zu verlassen. Die Protokollierung von Anfragen und Antworten und der Schutz vor Prompt Injection gehören zur Leistung KI/ML-Integration, geliefert vom Team unseres Engineering-Partners Vixen.UNO.

Isolierung. Pods nehmen alle eingehenden Verbindungen an, bis eine Network Policy sie auswählt, und die Kubernetes-Dokumentation warnt: „Das Anlegen einer NetworkPolicy-Ressource ohne einen Controller, der sie umsetzt, hat keine Wirkung.“ Setzen Sie ein Netzwerk-Plugin ein, das Policies durchsetzt, und lassen Sie nur das Gateway, den Endpoint Picker und Prometheus den Serving-Port erreichen, denn vLLM stellt /metrics auf demselben Port bereit wie seine API. vLLM nennt den Verkehr zwischen den Nodes eines Multi-Node-Deployments „standardmäßig unsicher“ und schreibt, dass er in einem isolierten Netz laufen muss. Kubernetes speichert Secrets, etwa den Schlüssel für Hugging Face oder NGC, standardmäßig unverschlüsselt in etcd; aktivieren Sie also die Verschlüsselung im Ruhezustand. Pinnen Sie Images per Digest: Das Beispiel von vLLM nutzt das Tag latest, von dem Kubernetes im Produktivbetrieb abrät, und --trust-remote-code, das „Remote-Code (z. B. von HuggingFace)“ vertraut; lassen Sie es weg, sofern das Modell es nicht braucht.

Modell-Storage: wie die Gewichte in den Pod kommen

Dokumentation von KServe 0.20, Dokumentation des NVIDIA NIM Operators und Kubernetes-Dokumentation zu den Zugriffsmodi von Volumes, abgerufen am 24. September 2026.

Das Netzwerk setzt die Untergrenze für jeden Download. Llama 3.3 70B in FP8 umfasst 68 GiB, also 584 Gbit: nach unserer Rechnung mindestens 23 Sekunden bei einer Leitungsrate von 25 Gbit/s und 5,8 Sekunden bei 100 Gbit/s, bevor irgendetwas in den GPU-Speicher geladen wird. Jedes Replikat, das auf einem anderen Node startet, braucht diese Zeit erneut; lokale Kopien werden also wichtig, sobald das Autoscaling Replikate verschiebt.

RAG-Dienste neben dem Modell

Das Retrieval fügt ein Embedding-Modell, einen Reranker, eine Vektordatenbank und Ingestion-Jobs hinzu. vLLM stellt Embedding- und Reranking-Modelle mit seinem Pooling-Runner (--runner pooling) unter /v1/embeddings und /v1/rerank bereit, die Hugging-Face-Runtime von KServe unter /openai/v1/, und NVIDIAs Embedding-NIMs aus NeMo Retriever „stellen eine API bereit, die mit dem API-Standard von OpenAI kompatibel ist“, mit einem Reranking-NIM daneben. Die Routen /rerank und /score von vLLM ohne das Präfix /v1 deckt sein API-Schlüssel nicht ab.

Nach unserer Rechnung aus Modelldaten von Hugging Face hat Qwen3-Embedding-8B (7,57 Milliarden Parameter) 15,1 GB Gewichte in BF16, Qwen3-Reranker-8B 16,4 GB und Qwen3-Embedding-0.6B 1,2 GB. Der Vektorindex wird im Arbeitsspeicher dimensioniert: Als 32-Bit-Gleitkommazahlen belegen eine Million Chunks mit 4.096 Dimensionen 16,4 GB an Rohvektoren, noch ohne jede Indexstruktur, und 4,1 GB bei 1.024. Die Ingestion muss die Zugriffsrechte jedes Dokuments in den Index übernehmen, damit das Retrieval nach Nutzer filtert, das erste Problem, das unser RAG-Leitfaden angeht; Kubeflow Pipelines kann die Ingestion als Graph aus Containern ausführen.

Metriken und Autoscaling

vLLM exportiert Prometheus-Metriken unter /metrics, darunter vllm:time_to_first_token_seconds, vllm:inter_token_latency_seconds, vllm:num_requests_running, vllm:num_requests_waiting und vllm:kv_cache_usage_perc, wobei 1 einen vollen Cache bedeutet. DCGM Exporter liefert zusätzlich GPU-Metriken auf Port 9400, je Karte und je MIG-Instanz. Unser Monitoring-Leitfaden erklärt, warum die GPU-Auslastung täuscht, was sie auch für das Autoscaling ausschließt.

Der Prometheus-Scaler von KEDA nimmt eine Abfrage, einen threshold und einen activationThreshold entgegen; KEDA legt einen Horizontal Pod Autoscaler an, skaliert selbst von null auf eins und überlässt den Bereich von eins bis N dem Autoscaler. Mit dem Standard-Metriktyp von KEDA, AverageValue, wird das Ergebnis der Abfrage vor dem Vergleich durch die Zahl der Replikate geteilt; eine über die Replikate eines Modells summierte Abfrage verlangt also ein Replikat für jeweils so viele Anfragen, wie der Schwellenwert angibt. Die Warteschlange allein ist eine schlechte Zielgröße: Sie fällt auf null, sobald die Kapazität reicht, und der Autoscaler verkleinert das Deployment dann, bis sich wieder eine Warteschlange bildet. Offene Anfragen, also laufende plus wartende, sind stabiler, solange der Schwellenwert unter der Zahl der Anfragen bleibt, die ein Replikat gleichzeitig verarbeiten kann; bei einem höheren Schwellenwert stauen sich Anfragen, bevor ein Replikat hinzukommt. Das eigene Beispiel von KServe skaliert nach vllm:num_requests_running. Ohne KEDA braucht ein HPA einen Adapter für benutzerdefinierte oder externe Metriken; so oder so beträgt sein Standard-Stabilisierungsfenster für das Herunterskalieren 300 Sekunden.

On-Premise fügt ein Autoscaler Pods hinzu, keine GPUs: Ein neues Replikat startet nur dort, wo eine Karte des passenden Typs frei ist, und bedient erst Anfragen, wenn seine Gewichte angekommen und geladen sind, und nach dem Herunterskalieren auf null wartet die nächste Anfrage auf all das.

Welche Hardware welche Schicht trägt

Verbleibender KV-Cache = 0,9 × vom Treiber gemeldeter Speicher (95,6 GiB auf der RTX PRO 6000, 140,4 GiB auf der H200 NVL), abzüglich etwa 3 GiB Overhead, abzüglich der Gewichte; das ist das Budget unseres Leitfadens zu Nutzern je Karte (vLLM 0.30.0 selbst nutzt standardmäßig 0,92); übrige Größen nach unserer Rechnung aus Modelldaten von Hugging Face; MIG-Profile aus NVIDIAs MIG-Benutzerhandbuch.

Die Referenzkonfigurationen auf unserer Seite zu KI-Servern lassen sich darauf abbilden. Die beiden Karten RTX PRO 6000 Server Edition des Private-KI-Starters können auf einer Karte ein Modell der 70B-Klasse in FP8 und, nach der Regel in der Anmerkung, 12 Sitzungen zu 8.192 Token mit je 1,25 GiB in einem FP8-KV-Cache halten und die andere Karte in vier Instanzen vom Typ 1g.24gb aufteilen, für den Embedder, den Reranker und bis zu zwei weitere kleine Modelle. Die vier Karten des Inferenz-Knotens bedienen mehrere Modelle oder ein größeres Modell über mehrere Karten hinweg, wobei vLLM ohne NVLink Pipeline- statt Tensor-Parallelismus empfiehlt. Auf der H200 NVL des Trainings-Knotens fasst eine MIG-Instanz vom Typ 1g.18gb, laut NVIDIAs Produktseite 16,5 GB, den 0,6B-Embedder, aber nicht den 8B-Embedder, dessen 15,1 GB Gewichte kaum etwas für den Laufzeitspeicher und den Cache von vLLM übrig ließen; und solange diese Karte MIG nutzt, kann sie nicht an einem Training mit NCCL teilnehmen. Die L4 mit 72 W und halber Bauhöhe ergänzt eine GPU für kleine Modelle ohne MIG; die RTX PRO 4000 hat ebenfalls 24 GB, doch in der Supportliste des GPU Operators haben wir keinen Eintrag für sie gefunden.

Was wir liefern

Eurokommerz liefert die GPUs und Server unter diesen Schichten mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung: RTX PRO 6000 Server Edition und H200 NVL für das Sprachmodell, L4 für kleine Modelle und nach Auftrag gebaute KI-Server auf Basis der Referenzkonfigurationen, auf Wunsch mit installiertem Betriebssystem, Treibern, CUDA und einer Container-Runtime; NVIDIA-AI-Enterprise-Lizenzen für NIM kommen auf dieselbe Rechnung. Die Plattform darüber ist KI/ML-Integration, geliefert vom Team unseres Engineering-Partners Vixen.UNO: eine Kubernetes-basierte Plattform mit KServe und Kubeflow, private Modelle mit vLLM, Ollama oder NVIDIA AI Enterprise, RAG-Assistenten, die die Zugriffsrechte jedes Nutzers beachten, und die Protokollierung von Anfragen und Antworten. Sie läuft auf Ihren Servern oder in den Tier-3-Rechenzentren von Baltneta in Litauen, dem Rechenzentrumspartner von Vixen.UNO, und Vertragspartner ist Eurokommerz.

FAQ