--- title: "LLM Inference Plattformen und Modellbereitstellung | SKAFFON" description: "LLM Inference auf Kubernetes: vLLM, TensorRT-LLM, NIM und KServe im Vergleich, Metriken, Autoscaling und Zugriffskontrolle. Mit Metrik-Aktions-Tabelle." url: https://skaffon.de/ki-infrastruktur/llm-inference/ --- 1. [Startseite](/) 2. [KI-Infrastruktur](/ki-infrastruktur/) 3. LLM Inference Plattformen und Modellbereitstellung KI-Infrastruktur · Modelle als Dienst # LLM Inference Plattformen und Modellbereitstellung Ein Modell läuft schnell. Ein Dienst, der viele Nutzer mit definierter Antwortzeit bedient, zugriffsgeschützt und messbar ist, braucht Engine-Wahl, Metriken, Autoscaling und Zugriffskontrolle auf Kubernetes mit GPUs. [Projekt anfragen](/projekt-anfragen/) [Zur Metrik-Tabelle](/ki-infrastruktur/llm-inference/#was-vllm-metriken-ihnen-sagen) - Engine-Wahl nach Lasttest, nicht nach Datenblatt - Alarme aus dokumentierten vLLM-Metriken - Zugriff pro Team, Rate-Limit, Audit-Log Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 ![Hand hält ein Smartphone mit Messkurven vor einem Netzwerkschrank mit gelben und blauen Glasfaser- und Patchkabeln](/_astro/hand-smartphone-messkurven-netzwerkschrank.CToP7GS3_Zpj85Y.jpg) Ausgangslage ## Unter Last zeigt sich, ob ein Modell ein Dienst ist Ein Modell lokal zu starten ist einfach. Schwierig wird es bei Last: Viele Anfragen konkurrieren um GPU-Speicher, lange Prompts verdrängen kurze, die erste Antwort kommt spät, und Autoscaling hilft nur begrenzt, weil ein neuer Pod erst Image und Modellgewichte laden muss, bevor er Anfragen annehmen kann. Hinzu kommen Fragen, die ein reiner Modellstart nicht beantwortet: Wer darf welches Modell nutzen, wie wird abgerechnet oder begrenzt, was passiert bei Ausfall einer GPU? SKAFFON baut die Plattform, die darauf Antworten hat. Die Seite richtet sich an Plattformverantwortliche und CTOs, die ein Modell für viele gleichzeitige Nutzer mit definierter Antwortzeit betreiben wollen. Wo diese Seite beginnt Modellwahl, Datengrenzen und GPU-Speicher-Dimensionierung stehen auf [Private LLMs](/ki-infrastruktur/private-llm/). Die GPU-Schicht darunter beschreibt [GPU Kubernetes](/ki-infrastruktur/gpu-kubernetes/). Architektur ## Der Weg einer Anfrage bis zur GPU und zurück in die Metriken Zugriffsschicht und Serving-Layer stehen vor den Inference-Pods; die Metriken der Engine steuern den Autoscaler. Engine-Wahl ## vLLM, TensorRT-LLM, NIM oder KServe: was jede Option leistet und kostet Die Engine bestimmt Durchsatz, Funktionsumfang und Lizenzlage. Ein Serving-Layer wie KServe ersetzt sie nicht, sondern verwaltet sie. __Inference-Optionen im Vergleich nach Herstellerdokumentation__ | Option | Rolle | Stärken laut Dokumentation | Zu beachten | | -------------------------------------------------------------------------------------------------------- | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [vLLM](https://docs.vllm.ai/en/latest/) | Open-Source-Inference-Engine | OpenAI-kompatible Schnittstellen (Completions, Chat Completions, Embeddings u. a.), Prometheus-Endpunkt /metrics, automatisches Prefix Caching, Tensor- und Pipeline-Parallelität | Tensor-Parallel-Größe muss zur Modellarchitektur passen (Zahl der Attention-Heads teilbar durch die Größe) | | [TensorRT-LLM](https://nvidia.github.io/TensorRT-LLM/overview.html) | NVIDIA-Bibliothek für optimierte Inference | In-Flight-Batching, Paged-KV-Cache, Quantisierung (FP8 ab H100, FP4 auf B200) | Auf NVIDIA-GPUs ausgerichtet; Integration mit Triton Inference Server und Dynamo laut Projekt vorgesehen | | [NVIDIA NIM](https://docs.nvidia.com/nim/large-language-models/2.0.9/deployment/air-gap-deployment.html) | Vorgefertigte Modell-Container | Schneller Start, dokumentierte Air-Gap-Bereitstellung | Produktiver Einsatz verlangt laut [Produktdokumentation](https://docs.api.nvidia.com/nim/docs/product) eine NVIDIA-AI-Enterprise-Lizenz; verfügbar sind die Modelle, die NVIDIA als NIM anbietet | | [KServe](https://kserve.github.io/website/docs/model-serving/generative-inference/overview) | Serving-Layer auf Kubernetes | Modelle als Kubernetes-Ressourcen; Hugging-Face-Runtime mit vLLM-Engine; OpenAI-kompatible Routen unter dem Präfix openai (Chat Completions, Completions, Embeddings, Rerank) | Verwaltet Engines, ersetzt sie nicht | NVIDIA, NIM, TensorRT und weitere genannte Namen sind Marken ihrer Inhaber. Entscheidungsregel ## Womit Sie anfangen, und was der Lasttest entscheidet Beginnen Sie mit vLLM unter KServe, wenn Sie offene Modelle betreiben und keine Lizenzkosten tragen wollen. NIM kommt in Frage, wenn die Lizenz ohnehin vorhanden ist und der Katalog Ihre Modelle abdeckt. TensorRT-LLM lohnt, wenn Messungen auf Ihrer Zielhardware den Mehraufwand rechtfertigen. Diese Aussage ist eine Entscheidungsregel, kein Leistungsversprechen: Welche Engine auf Ihrer Hardware schneller ist, entscheidet der Lasttest mit Ihrem Lastprofil. Für sehr große Modelle und Verteilung über mehrere Knoten kennt KServe die Ressource [LLMInferenceService](https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-overview), die auf llm-d aufbaut und laut Dokumentation unter anderem getrennte Prefill-Workloads, einen Scheduler zur Endpunktwahl und verteilte Inferenz mit LeaderWorkerSet bereitstellt. Das Beispiel der Dokumentation nutzt die API-Version `v1alpha1`; ob die Ressource für Ihren Einsatz ausreichend gereift ist, prüfen wir zum Projektzeitpunkt gegen die aktuelle Version. ![Person wertet Diagramme auf einem Laptop an einem runden Besprechungstisch aus, daneben ausgedruckte Auswertungen](/_astro/wertet-diagramme-laptop-runden.CmylJC3l_ZLTGDn.jpg) Durchsatz und Latenz ## Zwei Ziele im Konflikt, zwei Hebel ohne Modelländerung Durchsatz (Anfragen oder Token pro Sekunde über alle Nutzer) und Latenz (Wartezeit des einzelnen Nutzers) stehen im Konflikt. Engines erhöhen den Durchsatz, indem sie Anfragen gemeinsam verarbeiten; TensorRT-LLM beschreibt dies als In-Flight-Batching, bei dem Kontext- und Generierungsphase zusammen bearbeitet werden. Der Preis ist Latenz für den Einzelnen, sobald die GPU voll ist. - ### Prefix Caching Speichert laut [vLLM-Dokumentation](https://docs.vllm.ai/en/latest/design/prefix%5Fcaching.html) KV-Cache-Blöcke bereits verarbeiteter Anfragen und nutzt sie wieder, wenn eine neue Anfrage mit demselben Präfix beginnt, etwa einem gemeinsamen System-Prompt; das ändert laut Dokumentation die Ausgaben nicht. In mandantenfähigen Umgebungen lässt sich die Wiederverwendung über einen `cache_salt` auf Anfragen mit demselben Salt begrenzen. - ### Gleichzeitigkeit und Kontextlänge begrenzen Beide bestimmen den KV-Cache-Bedarf; die Rechenkette steht auf [Private LLMs](/ki-infrastruktur/private-llm/). Betrieb ## Was vLLM-Metriken Ihnen sagen und was Sie dann tun vLLM stellt unter `/metrics` Prometheus-Metriken bereit. Die Tabelle ordnet dokumentierte [Metriken](https://docs.vllm.ai/en/latest/design/metrics.html) einem Symptom und dem naheliegenden Hebel zu. Sie ist die Arbeitsgrundlage für Alarme und für die Lastprüfung im PoC. __Metrik, Symptom und Hebel für den Betrieb von vLLM__ | Metrik | Bedeutung | Symptom | Hebel | | -------------------------------------------------------- | ------------------------------- | ----------------------------------------------------- | --------------------------------------------------------------------------------- | | vllm:num\_requests\_waiting | Anfragen warten auf Einplanung | Dauerhaft über null: Dienst ausgelastet | Skalieren, Gleichzeitigkeit begrenzen, kleineres Modell oder Quantisierung prüfen | | vllm:num\_requests\_running | Aktuell bearbeitete Anfragen | Steigt mit Last bis zur Obergrenze | Mit Warteschlange zusammen lesen | | vllm:kv\_cache\_usage\_perc | Anteil belegter KV-Cache-Blöcke | Nahe der Obergrenze: Speicher ist der Engpass | Kontextlänge oder Gleichzeitigkeit senken, mehr GPU-Speicher, Parallelität prüfen | | vllm:time\_to\_first\_token\_seconds | Zeit bis zum ersten Token | Steigt bei langen Prompts oder voller Warteschlange | Prefix Caching nutzen, Prompts kürzen, Kapazität erhöhen | | vllm:inter\_token\_latency\_seconds | Abstand zwischen Token | Schleppende Ausgabe bei hoher Last | Gleichzeitigkeit je GPU senken, Hardware prüfen | | vllm:e2e\_request\_latency\_seconds | Gesamtdauer der Anfrage | Verletzt das Antwortzeitziel | Aufschlüsseln in Warte-, Prefill- und Decode-Zeit | | vllm:prefix\_cache\_hits und vllm:prefix\_cache\_queries | Trefferquote des Prefix Cache | Niedrig trotz gemeinsamer System-Prompts | Prompt-Aufbau so ändern, dass der gemeinsame Teil vorn steht | | vllm:request\_success\_total | Beendete Anfragen nach Grund | Anstieg abgebrochener oder längenbegrenzter Antworten | Limits und Clients prüfen | ## Zwei Alarmregeln als Ausgangspunkt Beispiel in der Prometheus-Syntax. Die Schwellen sind **angenommene Beispielwerte** und keine Empfehlung; sie werden aus Ihren Antwortzeitzielen und dem Lasttest abgeleitet. ``` # Beispiel: Warteschlange bleibt länger als 5 Minuten nicht leer max_over_time(vllm:num_requests_waiting[5m]) > 0 # Beispiel: p95 der Zeit bis zum ersten Token überschreitet das (hier angenommene) Ziel von 2 Sekunden histogram_quantile(0.95, sum by (le) (rate(vllm:time_to_first_token_seconds_bucket[5m]))) > 2 ``` Autoscaling ## Warum CPU kein Signal für LLM-Dienste ist, und drei Grenzen des Skalierens Der Kubernetes-HorizontalPodAutoscaler kann laut [Dokumentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) Metriken aus den Schnittstellen `custom.metrics.k8s.io` und `external.metrics.k8s.io` nutzen, nicht nur CPU. Für LLM-Dienste ist CPU ein schlechtes Signal; sinnvoller sind Warteschlangenlänge oder KV-Cache-Auslastung. - ### Startdauer Ein neuer Pod braucht Zeit für Image und Gewichte. Autoscaling gleicht Lastanstieg über Minuten aus, nicht über Sekunden. Wie lange der Start dauert, messen wir auf Ihrer Plattform; es hängt von Modellgröße und Speicheranbindung ab. Ein Mindestbestand an Replikas und ein zwischengespeicherter Modellspeicher verkürzen den Anlauf. - ### GPU-Knappheit Zusätzliche Pods starten nur, wenn GPUs frei sind; Quotas und Queues auf der [GPU-Plattform](/ki-infrastruktur/gpu-kubernetes/) entscheiden, wer bei Engpass Vorrang hat. - ### Abwärtsskalierung Zu schnelles Verkleinern erzeugt Pendeln; der HPA bietet dafür konfigurierbares Verhalten mit Stabilisierungsfenster. ## Vor jedem Endpunkt steht eine Zugriffsschicht Authentifizierung über Ihre Identity-Lösung oder [Keycloak](https://www.keycloak.org/), pro Team begrenzte Zugriffe, Ratenbegrenzung und Audit-Log. Modelle werden als eigene Ressourcen versioniert; ein Modellwechsel läuft als geplanter Rollout mit Rückweg. [Absicherung: LLM Security](/cybersecurity/llm-security/) Projektablauf ## Vom Lastprofil zur Produktivsetzung in fünf Schritten 1. 01 ### Anforderungen und Lastprofil festhalten Antwortzeitziele definieren und das erwartete Lastprofil gemeinsam festhalten. 2. 02 ### Engine-Auswahl Nach der Matrix, Vergleichstest auf Zielhardware. 3. 03 ### Plattformaufbau Serving-Layer, Zugriffsschicht, Monitoring nach der Metrik-Tabelle. 4. 04 ### Lasttest Mit Ihrem Lastprofil; daraus Kapazitätsplan und Autoscaling-Einstellungen. 5. 05 ### Produktivsetzung Mit Alarmen und Rollout-Prozess; auf Wunsch mit Betrieb durch SKAFFON. ## Was wir von Ihnen für die Auslegung brauchen - Aufgabe und Lastprofil: gleichzeitige Nutzer, Länge von Prompts und Antworten, Spitzen und Tagesgang - Ziele für Antwortzeit: Zeit bis zum ersten Token, Geschwindigkeit der Ausgabe, Gesamtdauer - Modelle und Lizenzen, Bedarf an mehreren Modellen oder Versionen - Vorhandene GPU-Plattform, Identity-Lösung, API-Gateway - Datenklassen, Protokollierungsvorgaben, Standort ## Was Sie nach dem Projekt in der Hand haben: sechs Ergebnisse Leistungswerte messen wir auf Ihrer Hardware und mit Ihrem Lastprofil. Den Umfang des Angebots bestimmen Zahl der Modelle, Lastprofil und Antwortzeitziele, Hardware, Integration (Identity, Gateway, Abrechnung oder Begrenzung je Team), Standort und Air-Gap-Vorgaben und der Betriebsumfang. - ### Architektur Mit begründeter Engine-Wahl. - ### Kubernetes-Ressourcen als Code Versioniert und nachvollziehbar. - ### Dashboards und Alarmregeln Nach der Metrik-Tabelle. - ### Lasttest-Protokoll Mit Ihren Messwerten. - ### Autoscaling-Konzept Auf Ihr Lastprofil abgestimmt. - ### Zugriffskonzept und Runbooks Für den laufenden Betrieb. ## Wann sich eine eigene Inference-Plattform nicht lohnt ### Das spricht dafür - Viele gleichzeitige Nutzer mit definierter Antwortzeit - Mehrere Modelle oder Versionen, Zugriff pro Team ### Das spricht dagegen - Sie wollen nur einen Cloud-Modell-API-Schlüssel nutzen und betreiben nichts selbst. - Ihre Last ist gering und gleichmäßig: Dann genügt oft ein einzelner Server ohne Autoscaling, und die Beratung auf der Seite [Private LLMs](/ki-infrastruktur/private-llm/) reicht. - Sie erwarten zugesagte Token-Raten ohne Test auf Ihrer Hardware. ## Was neben dem Serving noch ansteht Überblick: [GPU- und KI-Infrastruktur](/ki-infrastruktur/). - ### [GPU-Cluster](/ki-infrastruktur/gpu-cluster/) Hardware für Inference und Training. Weiter - ### [MLOps und KI-Plattformen](/ki-infrastruktur/ki-plattform-mlops/) Einbettung in Modell-Lebenszyklus und Pipelines. Weiter - ### [Technische KI-Beratung](/ki-infrastruktur/ki-beratung/) Beratung zu Grundsatzfragen. Weiter ## Modelle, Lastprofil und Antwortzeitziele beschreiben Schicken Sie uns Ihre Eckdaten, wir antworten mit einem Vorschlag für Engine, Plattform und Lasttest. [Projekt anfragen](/projekt-anfragen/)