0521 968 7740Mo–Fr, 8–17 Uhr
GPU-Auslastung allein erklärt noch keine langsame LLM-Inferenz. Entscheidend sind das Verhältnis aus Modellgröße und KV-Cache, die Länge der Requests sowie das Verhalten des Schedulers unter paralleler Last. Im vLLM-Inference-Training baust du deshalb zuerst eine messbare Baseline auf. Du startest den OpenAI-kompatiblen API-Server mit vllm serve, sendest wiederholbare Request-Profile und erfasst den Durchsatz, die Zeit bis zum ersten Token und die Latenz zwischen ausgegebenen Tokens. Danach veränderst du jeweils einen Parameter. Du untersuchst die GPU-Speicherauslastung, begrenzt Kontextlängen und passt die Anzahl gleichzeitig verarbeiteter Sequenzen an. Quantisierte Modellvarianten testest du auf ihrer vorgesehenen Hardware, damit Speichergewinn, Modellkompatibilität und Antwortverhalten gemeinsam bewertet werden. Continuous Batching wird anhand konkurrierender Requests sichtbar. Für Multi-GPU-Systeme verteilst du das Modell mit Tensor Parallelism oder Pipeline Parallelism. Die Messungen zeigen, welche Strategie zum Modell und zur vorhandenen Verbindung zwischen den GPUs passt. API-Übungen decken Chat Completions, Tool-Calling und Embeddings ab. Du prüfst dabei die Abhängigkeiten zwischen Modell, Chat-Template, Parser und Endpunkt. Anschließend baust du ein Container-Image, bindest den Modell-Cache ein und stellst den Dienst auf Kubernetes bereit. Readiness-Probes, GPU-Ressourcen und Replikate werden mit den gemessenen Kapazitätsgrenzen verknüpft. Prometheus-Metriken und Server-Logs ergänzen deine Lasttests. Du erhältst damit eine Vorgehensweise, mit der du vLLM-Konfigurationen vor einer Freigabe vergleichst und Überlastung früher erkennst.
