vLLM bietet einen OpenAI-kompatiblen Online-Serving-Server für hohen Throughput. Production-Sizing bedeutet mehr als Modellgewichte in VRAM zu laden; KV Cache, Context, Concurrency, TP/DP und API-CPU zählen.
Aktuelle vLLM-Doku zeigt OpenAI-kompatible APIs über `vllm serve`. Sie warnt außerdem, dass `--api-key` nicht automatisch jeden Endpoint schützt; Production braucht zusätzliche Proxy-/Firewall-Kontrollen.
In vLLM V1 übernimmt der API-Server Input/Streaming, Engine Core Scheduler/KV Cache und GPU Worker die Model-Forward-Passes.
Tensor Parallel verteilt ein Modell über GPUs; Data Parallel repliziert Modellinstanzen für unabhängige Request-Batches.
Offizielle Security-Hinweise sagen: Nicht jeder Endpoint ist durch den eingebauten API Key geschützt. vLLM hinter Private Network/Reverse Proxy mit TLS, Rate Limit und Auth betreiben.
Modellnamen an eigenes Deployment anpassen.
nvidia-smicurl -s http://127.0.0.1:8000/v1/modelscurl -s http://127.0.0.1:8000/healthps aux | grep '[v]llm'ss -lntp | grep ':8000'KV Cache, Context, Batch/Concurrency, Multimodal Inputs und Runtime Overhead erhöhen VRAM. GPU nicht nur nach Model-Dateigröße wählen.
Ja. Über OpenAI-kompatiblen Server und angepasste Base URL.
Nein. Nicht alle Endpoints sind geschützt; zusätzliche Proxy-/Firewall-/Auth-Schicht nötig.
Wenn das Modell nicht in eine GPU passt oder über mehrere GPUs verteilt werden soll.
Teilen Sie Modell, Precision/Quantization, Context, Concurrency und Ziel-Token/s; GPU/VRAM und TP/DP planen.