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.
- Engine-Wahl nach Lasttest, nicht nach Datenblatt
- Alarme aus dokumentierten vLLM-Metriken
- Zugriff pro Team, Rate-Limit, Audit-Log
01Ausgangslage
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.
02Architektur
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.
03Engine-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.
| Option | Rolle | Stärken laut Dokumentation | Zu beachten |
|---|---|---|---|
| vLLM | 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 | 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 | Vorgefertigte Modell-Container | Schneller Start, dokumentierte Air-Gap-Bereitstellung | Produktiver Einsatz verlangt laut Produktdokumentation eine NVIDIA-AI-Enterprise-Lizenz; verfügbar sind die Modelle, die NVIDIA als NIM anbietet |
| KServe | 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.
04Entscheidungsregel
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, 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.
05Durchsatz 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 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_saltauf Anfragen mit demselben Salt begrenzen. -
Gleichzeitigkeit und Kontextlänge begrenzen
Beide bestimmen den KV-Cache-Bedarf; die Rechenkette steht auf Private LLMs.
06Betrieb
Was vLLM-Metriken Ihnen sagen und was Sie dann tun
vLLM stellt unter /metrics Prometheus-Metriken bereit. Die Tabelle ordnet dokumentierte Metriken einem Symptom und dem naheliegenden Hebel zu. Sie ist die Arbeitsgrundlage für Alarme und für die Lastprüfung im PoC.
| 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 |
07
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
08Autoscaling
Warum CPU kein Signal für LLM-Dienste ist, und drei Grenzen des Skalierens
Der Kubernetes-HorizontalPodAutoscaler kann laut Dokumentation 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 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, 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 Security09Projektablauf
Vom Lastprofil zur Produktivsetzung in fünf Schritten
- 01
Anforderungen und Lastprofil festhalten
Antwortzeitziele definieren und das erwartete Lastprofil gemeinsam festhalten.
- 02
Engine-Auswahl
Nach der Matrix, Vergleichstest auf Zielhardware.
- 03
Plattformaufbau
Serving-Layer, Zugriffsschicht, Monitoring nach der Metrik-Tabelle.
- 04
Lasttest
Mit Ihrem Lastprofil; daraus Kapazitätsplan und Autoscaling-Einstellungen.
- 05
Produktivsetzung
Mit Alarmen und Rollout-Prozess; auf Wunsch mit Betrieb durch SKAFFON.
10
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
11
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.
12
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 reicht.
- Sie erwarten zugesagte Token-Raten ohne Test auf Ihrer Hardware.
13
Was neben dem Serving noch ansteht
Überblick: GPU- und KI-Infrastruktur.
-
GPU-Cluster
Hardware für Inference und Training.
-
MLOps und KI-Plattformen
Einbettung in Modell-Lebenszyklus und Pipelines.
-
Technische KI-Beratung
Beratung zu Grundsatzfragen.
Modelle, Lastprofil und Antwortzeitziele beschreiben
Schicken Sie uns Ihre Eckdaten, wir antworten mit einem Vorschlag für Engine, Plattform und Lasttest.