Viele OpenAI-SDK-Apps können durch Base-URL-Wechsel angebunden werden.
vLLM ist mehr als ein Modell-Loader; Continuous Batching, KV-Cache-Management und OpenAI-kompatible Endpoints zielen auf effizientes Serving vieler Requests. Relevant sind Throughput und p95-Latenz unter Concurrency statt Single-User-token/s.
`docker run` nicht blind kopieren, ohne Modelllizenz, Tokenizer/Chat-Template und Quantization-Format zu prüfen. „Server läuft“ beweist kein korrektes Antwortformat.
Der offizielle vLLM-Server bietet OpenAI-kompatible Endpoints wie Chat/Completions und kann mit `vllm/vllm-openai` laufen. Auch wenn Gewichte in VRAM passen, Headroom für KV Cache und Concurrency lassen.
Der offizielle vLLM-Server bietet OpenAI-kompatible Endpoints wie Chat/Completions und kann mit `vllm/vllm-openai` laufen. Auch wenn Gewichte in VRAM passen, Headroom für KV Cache und Concurrency lassen.
vLLM OpenAI-kompatiblen Server auf GPU-Host deployen: Docker, Model Cache, Tensor Parallelism, Endpoint-Tests, Concurrency, Prefix Cache und echte Benchmarks.
Viele OpenAI-SDK-Apps können durch Base-URL-Wechsel angebunden werden.
Zielt auf effiziente Planung paralleler Requests auf der GPU.
Langer Kontext und Concurrency verbrauchen VRAM zusätzlich zu Modellgewichten.
Tensor Parallelism kann Modelle über GPUs sharden; Interconnect-Bottlenecks messen.
Gewichte, Quantization-Overhead, CUDA/Runtime, KV Cache und Fragmentierung teilen VRAM. 100% Auslastungsziel erhöht OOM-Risiko.
| Budget | Treiber |
|---|---|
| Weights | Parameter × Bits |
| KV Cache | Kontext × Concurrency × Modellarchitektur |
| Runtime | CUDA/Kernels/Graphs |
| Headroom | Peak/Fragmentierung |
Wenn `nvidia-smi` auf dem Host fehlschlägt, nicht zuerst im Container debuggen. Driver/CUDA-Kompatibilität auf Host-Ebene klären.
nvidia-sminvidia-smi --query-gpu=name,memory.total,driver_version,pstate --format=csvdocker info | grep -i runtimedocker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smiGroßes Modell bei jedem Deploy neu herunterzuladen erhöht Downtime, Bandbreite und Startzeit. Model Cache persistent mounten.
mkdir -p /srv/vllm-cachedocker run --rm --gpus all -p 8000:8000 -v /srv/vllm-cache:/root/.cache/huggingface vllm/vllm-openai:latest --model MODEL_ID --host 0.0.0.0 --port 8000Server kann ready aussehen, während Tokenizer-/Chat-Template-Fehler erst beim ersten Chat-Request auftreten. Smoke-Test ins Deployment-Gate aufnehmen.
curl -s http://127.0.0.1:8000/v1/models | jq .curl -s http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"MODEL_ID","messages":[{"role":"user","content":"Say only READY"}],"max_tokens":8}' | jq .Zwei GPUs erhöhen Gesamt-VRAM, garantieren aber nicht 2× Performance. Collective Communication und PCIe/NVLink-Bandbreite bestimmen Skalierung.
nvidia-smi topo -mnvidia-smi nvlink --status 2>/dev/null || trueWorkloads mit wiederholten langen System-/RAG-Prefixes profitieren ggf. stärker; Random-Prompt-Benchmarks zeigen das nicht unbedingt.
Bei 1, 2, 4, 8, 16 parallelen Requests TTFT, Output-tok/s, p95-Latenz und Fehlerquote messen. Entscheidend ist maximale Concurrency innerhalb SLA.
| Concurrency | TTFT p95 | Output tok/s | Fehler % |
|---|---|---|---|
| 1 | — | — | — |
| 2 | — | — | — |
| 4 | — | — | — |
| 8 | — | — | — |
| 16 | — | — | — |
Single-/Multi-GPU-vLLM-Benchmark auf Eka Sunucu nach Modell, Kontext und Concurrent-Request-Ziel planen.
Primärdokumentation und technische Referenzen dieses Leitfadens.
Mit passenden Infrastruktur- und Implementierungsleitfäden fortfahren.
vLLM API
OpenAI-kompatible Endpoints erlauben vielen SDKs/Apps die Anbindung per Base URL/Modellname; verwendete Endpoint-Funktionen separat prüfen.
Nein. KV Cache, Runtime und Concurrency brauchen zusätzlich VRAM. Kontextlänge und parallele Nutzer einplanen.
Keine Garantie. Skalierung hängt von Tensor-Parallel-Kommunikation, Modellgröße, Batch und GPU-Interconnect ab.
Offizielle Doku zeigt `vllm/vllm-openai` für OpenAI-kompatibles Serving.