vLLM auf dem eigenen Rechner einrichten, und sehen, was es sendet

Für vLLM brauchen Sie Linux (oder WSL unter Windows), eine NVIDIA-Grafikkarte mit Compute Capability 7.5 oder neuer und Python 3.10 bis 3.13. Dann 2 Befehle: uv pip install vllm --torch-backend=auto und vllm serve. Der Server antwortet auf Port 8000 an jeder Netzwerkschnittstelle, nicht nur auf Ihrem eigenen Rechner: Ergänzen Sie --host 127.0.0.1.

Genau dieser letzte Punkt unterscheidet vLLM. Von den 5 Programmen, die wir vergleichen, ist es das einzige, das ab Werk auf allen Schnittstellen lauscht; Ollama, LM Studio, llama.cpp und MLX starten auf 127.0.0.1. Außerdem startet es ohne Schlüssel, mit CORS offen für jede Website und mit eingeschalteter Nutzungsstatistik. Nichts davon ist schwer zu ändern, und diese Seite geht es der Reihe nach durch, mit der aktuellen stabilen Version 0.30.0, veröffentlicht am 22. September 2026. Jeder Befehl und jede Voreinstellung hier wurde am 28. September 2026 am Code von 0.30.0 geprüft, so wie er als Tag in seinem öffentlichen Repository steht.

Was vLLM ist, und für wen es gedacht ist

vLLM ist eine Inferenz-Engine, gebaut, um Sprachmodelle vielen Menschen gleichzeitig bereitzustellen. Zu Hause ist es auf einem Linux-Server mit NVIDIA-GPUs, und dort ergeben seine Voreinstellungen Sinn: ein Dienst, den andere Rechner über das Netz erreichen, der den Großteil der Grafikkarte für sich reserviert und der seinen Entwicklern meldet, wie er benutzt wird. Es ist quelloffen, unter der Lizenz Apache 2.0. Das Programm-Datenblatt vLLM: was es nach Hause sendet und ob prüfbar ordnet es am professionellen Ende der 5 Programme ein, und diese Anleitung ist die praktische Seite dieses Datenblatts.

Alles steckt in 1 ausführbaren Datei, vllm. Die Unterbefehle, die Sie benutzen werden, sind vllm serve, der den OpenAI-kompatiblen Server startet, sowie vllm chat und vllm complete, Konsolen-Clients, die mit diesem Server sprechen. Dazu kommen vllm bench, vllm collect-env, vllm run-batch und vllm launch, die diese Seite nicht braucht.

Was es nicht ist, denn jedes davon wird gern angenommen:

• Keine Desktop-App. Es gibt kein Fenster. vllm chat ist ein Text-Client, der einen bereits laufenden Server voraussetzt.
• Ab Werk kein Programm für GGUF. Die Unterstützung für GGUF ist in ein separates Plugin umgezogen, und der Abschnitt zu den Modellen erklärt, was das für die Größen bedeutet.
• Kein Programm für die GPU des Mac. Auf Apple Silicon läuft vLLM selbst auf der CPU. Haben Sie einen Mac, nutzt MLX auf dem Mac mit mlx-lm einrichten, und sehen, was es sendet die GPU direkt.
• Kein Modellwechsler. Der Server hält 1 Modell zur Zeit. Um es zu wechseln, starten Sie den Server mit einem anderen Namen neu.

Wollen Sie einfach ein Modell, mit dem Sie auf Ihrem eigenen Rechner chatten, führen Ollama lokal einrichten, prüfen, ob es läuft, und sehen, was es sendet und LM Studio und seinen lokalen Server einrichten, und sehen, was es sendet mit weniger Entscheidungen ans Ziel. vLLM ist für den Fall gedacht, dass Sie ein Modell bereitstellen wollen.

Was Sie brauchen: Linux, eine NVIDIA-Grafikkarte mit Compute Capability 7.5, Python 3.10 bis 3.13

Voraussetzung	Was das in der Praxis bedeutet
Linux	Die fertigen Pakete auf PyPI sind ausschließlich Linux-Wheels, für x86_64 (314,9 MB) und aarch64 (310,0 MB). Windows geht über WSL
NVIDIA-GPU, Compute Capability 7.5 oder neuer	T4 und die RTX-20-Serie aufwärts. Die RTX-30-Serie hat 8.6, die RTX-40-Serie 8.9. Die GTX-10-Serie liegt unter der Grenze. Das Paket auf PyPI ist für CUDA 13.0 gebaut; ein Build für CUDA 12.9 hängt an der Version auf GitHub
Python 3.10 bis 3.13	Die Dokumentation verlangt 3.10 bis 3.13; die Paket-Metadaten akzeptieren 3.10 bis ausschließlich 3.15. Nehmen Sie 3.12: Es liegt in beiden Bereichen, und die AMD-Wheels und das Mac-Wheel sind dafür gebaut
Eine frische Umgebung	vLLM 0.30.0 legt sein eigenes PyTorch fest, torch==2.13.0, dazu die passenden torchaudio und torchvision; deshalb empfiehlt seine Dokumentation eine neue Umgebung

Voraussetzungen laut der Installationsanleitung von vLLM zum Git-Tag v0.30.0, den PyPI-Metadaten von vllm 0.30.0 und der Tabelle der Compute Capability von NVIDIA, gelesen am 28. September 2026.

Windows. vLLM läuft nicht nativ unter Windows. Seine Dokumentation verweist auf das Windows-Subsystem für Linux, und in WSL folgen Sie den Linux-Schritten dieser Seite.

Mac. vLLM unterstützt Apple Silicon auf der CPU, als experimentelle Unterstützung: FP32 und FP16, macOS Sonoma oder neuer, Xcode 15.4 und seine Command Line Tools. PyPI hat kein macOS-Wheel, und die Dokumentation beschreibt den Bau aus dem Quellcode. Die Version 0.30.0 auf GitHub hängt außerdem ein fertiges macOS-arm64-CPU-Wheel für Python 3.12 an, 29,0 MB; das haben wir nicht getestet. Die GPU des Mac ist ein anderes Projekt: vLLM verweist auf vLLM-Metal, ein von der Community gepflegtes Plugin, das darunter MLX nutzt und Modelle von mlx-community lädt. Diese Seite behandelt es nicht.

AMD. vLLM unterstützt AMD-GPUs mit ROCm 6.3 oder neuer, und für 0.30.0 ist das fertige Wheel unter https://wheels.vllm.ai/rocm/ für ROCm 7.2.3 gebaut und braucht glibc 2.39 oder neuer. Die ROCm-Wheels gibt es nur für Python 3.12, und genau an diesem Schritt hängt alles: Mit jedem anderen Python fällt der Installer stillschweigend auf das CUDA-Wheel von PyPI zurück, das dann auf der AMD-Karte mit libcudart.so: cannot open shared object file scheitert. Die Liste der unterstützten Hardware umfasst MI200, MI300 und MI350, die Radeon RX 7900 (gfx1100/1101) und RX 9000 (gfx1200/1201) sowie Ryzen AI MAX und AI 300 (gfx1151/1150, ROCm 7.0.2 oder neuer).

Nur CPU. Auf einem x86-Linux-Rechner ohne passende GPU läuft vLLM auf dem Prozessor. AVX512 wird empfohlen; mit AVX2 bekommen Sie einen eingeschränkten Funktionsumfang. Die Version 0.30.0 hängt ein CPU-Wheel für x86_64 (147,4 MB) und eines für aarch64 (68,3 MB) an; beide brauchen glibc 2.39 oder neuer.

Welche Rechner aus unserem Katalog es ausführen können

Unser Katalog umfasst 16 Rechner. Gemessen an den eigenen Voraussetzungen von vLLM fallen sie in 4 Gruppen:

Rechner	Compute Capability	Wie vLLM darauf läuft
PC mit RTX 4060 8 GB	8.9	CUDA, unter Linux oder WSL
PC mit RTX 3060 12 GB	8.6	CUDA, unter Linux oder WSL
PC mit RTX 4070 12 GB	8.9	CUDA, unter Linux oder WSL
Workstation mit RTX 4090 24 GB	8.9	CUDA, unter Linux oder WSL
Server mit 2× RTX 3090 (48 GB)	8.6	CUDA über beide Karten mit --tensor-parallel-size 2
Die 8 Macs, vom Mac mit M4 und 16 GB bis zum Mac Studio mit M5 Ultra und 512 GB	—	Nur CPU, experimentell. Die GPU nur über das Plugin vLLM-Metal
Büro-Notebook mit 16 GB und die CPU-Seite des Mini-PCs mit NPU und 32 GB	—	CPU unter Linux. Ist der Prozessor des Mini-PCs ein Ryzen AI 300 oder Ryzen AI MAX, steht seine integrierte GPU auf der ROCm-Liste von vLLM weiter oben. Das Haupt-Repository von vLLM hat kein Backend für die NPU
Xiaomi AI Cube, 80 GB	—	Nicht prüfbar: ein Technikprototyp, dessen Prozessor nicht gegen die Voraussetzungen von vLLM dokumentiert ist

Compute Capability laut der Tabelle von NVIDIA, gelesen am 28. September 2026. Wege laut der Installationsanleitung von vLLM zum Git-Tag v0.30.0.

Die 5 NVIDIA-Rechner sind der Fall, für den vLLM gebaut ist. Auf den übrigen läuft es, wenn überhaupt, auf dem Prozessor.

vLLM installieren und prüfen, welche Version Sie bekommen haben

Die Dokumentation von vLLM empfiehlt uv und eine neue Umgebung. Mit Python 3.12:

uv venv --python 3.12
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm --version

--torch-backend=auto schaut nach, welchen NVIDIA-Treiber Sie installiert haben, und wählt den passenden PyTorch-Index. --torch-backend=cu129 oder cu130 verlangt ausdrücklich eine bestimmte Variante. Mit einfachem pip lautet die Zeile schlicht:

pip install vllm

Das vllm-Wheel selbst wiegt 314,9 MB und bringt PyTorch 2.13.0, torchaudio 2.11.0, torchvision 0.28.0 und FlashInfer mit: Der gesamte Download ist größer als das Wheel, und gemessen haben wir ihn nicht. vllm --version sollte 0.30.0 ausgeben.

Legen Sie die Version fest. vLLM bewegt sich schnell: 32 stabile Versionen in den 12 Monaten bis zum 28. September 2026, und die letzten 3 kamen jeweils 15, 14 und 13 Tage nach der vorherigen (0.28.0 am 26. August, 0.29.0 am 9. September, 0.30.0 am 22. September). Um genau die Version zu installieren, die diese Seite beschreibt:

uv pip install vllm==0.30.0 --torch-backend=auto

Der Weg über Docker. Das offizielle Image ist vllm/vllm-openai. Das Image-Tag v0.30.0 wurde am 22. September 2026 veröffentlicht und wiegt komprimiert 8,1 GiB für amd64 und 9,0 GiB für arm64:

docker run --rm --runtime nvidia --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 127.0.0.1:8000:8000 \
  --ipc=host \
  vllm/vllm-openai:v0.30.0 \
  --model Qwen/Qwen3-0.6B

Das ist der Befehl von vLLM selbst, mit einem festen Tag statt latest, mit 127.0.0.1 vor dem Port, damit Docker ihn nur auf Ihrem Rechner veröffentlicht, und mit --rm; die Zeile mit HF_TOKEN fehlt, weil Qwen/Qwen3-0.6B öffentlich ist. Das Volume teilt Ihren Hugging-Face-Cache mit dem Container, damit Modelle nicht doppelt heruntergeladen werden. Das Image läuft ab Werk als root; es enthält außerdem einen eingebauten Benutzer vllm mit UID 2000, und die Docker-Seite der Dokumentation von vLLM zeigt, wie Sie zu ihm wechseln.

Das erste Modell: vllm serve auf Port 8000

vllm serve

Ohne Modellnamen lädt vLLM Qwen/Qwen3-0.6B: 751.632.384 Parameter in BF16, 1,41 GiB Download von Hugging Face, ein Kontext von bis zu 40.960 Tokens und die Lizenz Apache 2.0. Um das Modell zu wählen, geben Sie seinen Namen auf Hugging Face an:

vllm serve Qwen/Qwen3-0.6B --max-model-len 8192

Warum die zweite Option dasteht, erklärt der Abschnitt zum Speicher. Sobald das Log zeigt, dass der Server läuft, 2 Prüfungen aus einem anderen Terminal:

curl http://127.0.0.1:8000/v1/models
curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "Qwen/Qwen3-0.6B", "messages": [{"role": "user", "content": "How tall is Mt Everest?"}]}'

Die erste listet das geladene Modell; die zweite liefert eine Antwort im Format von OpenAI. Die Hauptrouten sind POST /v1/chat/completions, POST /v1/completions und GET /v1/models, dazu GET /health und GET /version. Für einen OpenAI-Client ist die Basis-URL http://127.0.0.1:8000/v1. Für einen schnellen Chat im Terminal:

vllm chat

Er verbindet sich mit http://localhost:8000/v1, sofern Sie ihm keine andere --url geben. Der Server führt kein Protokoll Ihrer Anfragen.

Speicher: warum vLLM 92 % der Grafikkarte belegt, und –max-model-len

vLLM lädt nicht einfach ein Modell und belässt es dabei. Beim Start reserviert es einen festen Anteil der Grafikkarte, ab Werk 0,92 ihres gesamten Speichers, für das Modell, seinen Speicher zum Rechnen und den Cache, der Ihre Gespräche hält (den KV-Cache). Aus der Art, wie der Code von 0.30.0 das umsetzt, folgen 2 Dinge.

Es zählt den freien Speicher, nicht den gesamten. Sind beim Start weniger als 92 % der Grafikkarte frei, verweigert vLLM den Start mit Free memory on device … on startup is less than desired GPU memory utilization (0.92, X GiB). Decrease GPU memory utilization or reduce GPU memory used by other processes. Auf einer Karte mit 8 GB heißt das 7,36 GiB frei. Steuert dieselbe Karte auch Ihren Desktop, müssen der Desktop und der CUDA-Kontext, den vLLM für sich selbst öffnet, zusammen in etwa 0,64 GiB passen, sonst scheitert die Prüfung, bevor überhaupt ein Modell lädt. Die Abhilfe ist die, die die Meldung selbst nennt:

vllm serve --gpu-memory-utilization 0.85

Der Wert ist eine Grenze pro Prozess: 2 vLLM-Server auf 1 Karte brauchen etwa 0,5 pro Server. Im CPU-Backend reserviert dieselbe Option trotz ihres Namens Arbeitsspeicher des Systems.

Der Kontext steht ab Werk auf dem Maximum des Modells. --max-model-len wird aus der Konfiguration des Modells übernommen, sofern Sie es nicht setzen, und vLLM verweigert den Start, wenn der KV-Cache für diese volle Länge nicht hineinpasst. Der Fehler nennt die Zahlen: To serve at least one request with the model’s max seq len (N), (X GiB KV cache is needed, which is larger than the available KV cache memory (Y GiB), gefolgt von der geschätzten maximalen Länge, die passen würde, und dem Rat, gpu_memory_utilization zu erhöhen oder max_model_len zu senken. Bleibt gar nichts übrig, lautet die Meldung No available memory for the cache blocks.

Wie groß dieser Cache wird, berechnet aus der Architektur jedes Modells mit einem KV-Cache in 16 Bit:

Modell	Maximaler Kontext	KV-Cache beim Maximum	KV-Cache mit –max-model-len 8192
qwen3-1.7b	40.960	4,38 GiB	0,875 GiB
qwen3-8b	40.960	5,63 GiB	1,125 GiB
qwen3-4b-2507	262.144	36,0 GiB	1,125 GiB

Unsere Rechnung: 2 × Schichten × KV-Heads × Head-Größe × 2 Bytes pro Token, aus den Modelldaten hinter unserem Modellfinder. Gemma 4 und gpt-oss nutzen Schichten mit gleitendem Fenster (Sliding Window), für die diese Formel nicht gilt, deshalb fehlen sie hier.

Das 4B-Modell ist das, das Sie kalt erwischt. Bei 8.192 Tokens braucht qwen3-4b-2507 1,125 GiB Cache; bei seinem Standardkontext verlangt es allein für den Cache 36,0 GiB, mehr als der gesamte Speicher jeder einzelnen Grafikkarte in unserem Katalog. Unser Modellfinder und unsere Rechner-Datenblätter rechnen alles mit 8.192 Tokens Kontext. --max-model-len 8192 (oder 8K, mit großem K: mit kleinem k bedeutet es 8.000) lässt vLLM sich so verhalten wie die Zahl auf unserer Website. Mit --max-model-len auto oder -1 nimmt vLLM so viel Kontext, wie hineinpasst.

Welche Modelle passen, und warum unsere GGUF-Größen nur ein Anhaltspunkt sind

Unsere Rechner-Datenblätter halten auf NVIDIA-Karten 0,8 GiB für das System zurück und vergleichen den Rest mit den 19 Modellen, die wir messen. vLLM zieht seine eigene Linie bei 92 %, also unterscheiden sich die 2 Budgets ein wenig:

Rechner	Unser Datenblatt lässt dem Modell	Budget von vLLM (0,92 × Speicher), für Modell, Speicher zum Rechnen und KV-Cache	Modelle, die passen (Datenblatt, 8K)	Größtes, das passt (Datenblatt)
RTX 4060 8 GB	7,20 GiB	7,36 GiB	6 von 19	granite-4.2-8b
RTX 3060 12 GB und RTX 4070 12 GB	11,20 GiB	11,04 GiB	7 von 19	gemma4-12b
RTX 4090 24 GB	23,20 GiB	22,08 GiB	15 von 19	qwen3.6-35b-a3b
2× RTX 3090 48 GB	47,20 GiB	2 × 22,08 = 44,16 GiB, mit --tensor-parallel-size 2	15 von 19	qwen3.6-35b-a3b

Werte, wie die Datenblätter sie am 28. September 2026 ausgeliefert haben, aus den Rechnerdaten vom 23. September. Das Budget von vLLM ist unsere Rechnung aus seiner Voreinstellung 0,92.

Auf der Karte mit 24 GB lässt sich vLLM 1,12 GiB weniger, als unser Datenblatt zählt; auf der Karte mit 8 GB 0,16 GiB mehr. Ein Modell, das laut Datenblatt gerade noch passt, braucht auf einer Karte mit 24 GB unter Umständen ein höheres --gpu-memory-utilization.

Der größere Unterschied ist die Datei. Unsere Größen sind GGUF-Dateien in Q4_K_M. vLLM lädt GGUF nicht von sich aus: Diese Unterstützung lebt jetzt in einem separaten Plugin, vllm-gguf-plugin, das die Dokumentation als hochgradig experimentell und wenig optimiert bezeichnet. Wenn Sie es ausprobieren wollen:

uv pip install vllm-gguf-plugin

Modelle werden dann als repo_id:quant_type benannt, zum Beispiel mit Q4_K_M. Der übliche Weg in vLLM ist eine andere Kompression: AWQ-, GPTQ- oder FP8-Dateien von Hugging Face, oder MXFP4 bei gpt-oss. Diese Größen haben wir für unsere 19 Modelle nicht gemessen, also nehmen Sie das Urteil des Modellfinders für vLLM als Anhaltspunkt, nicht als dieselbe Zahl.

Wie Sie es abschotten: 0.0.0.0, kein Schlüssel und offenes CORS

Ab Werk lauscht vllm serve auf 0.0.0.0:8000, und sein Startprotokoll gibt genau das aus. Es antwortet auf localhost und an jeder anderen Netzwerkschnittstelle des Rechners: Jeder in Ihrem Netz, oder im Internet, wenn der Port offen ist, kann es benutzen. Es prüft keinen Schlüssel. Und CORS ist für jeden Ursprung, jede Methode und jeden Header offen, also kann eine Webseite, die Sie in Ihrem Browser öffnen, Anfragen daran schicken und die Antworten lesen.

Was es schließt:

export VLLM_API_KEY="ein-langer-zufallsstring"
vllm serve Qwen/Qwen3-0.6B --host 127.0.0.1 --max-model-len 8192

• --host 127.0.0.1 hält andere Rechner draußen. Braucht einer den Server, erreicht er ihn über einen SSH-Tunnel (ssh -L 8000:127.0.0.1:8000 benutzer@ihr-server).
• --api-key oder die Variable VLLM_API_KEY sorgt dafür, dass Clients den Schlüssel als Bearer-Token mitschicken müssen. Die Variable hält den Schlüssel aus der Befehlszeile heraus, wo jeder Benutzer des Rechners ihn in der Prozessliste lesen kann.
• --allowed-origins '["http://localhost:3000"]', eine JSON-Liste, benennt die Seiten, die ihn aufrufen dürfen, statt der Voreinstellung *.

Was der Schlüssel nicht abdeckt. Der Schlüssel schützt nur Routen unter 4 Präfixen: /v1, /v2, /inference und /cohere. Alles andere am selben Port antwortet ohne ihn: /health, /version, /tokenize, /metrics (Prometheus, immer eingehängt) und /invocations, das dieselben Inferenzfunktionen erreicht wie /v1. Ohne Schlüssel antworten auch die interaktiven API-Seiten /docs und /redoc und das Schema unter /openapi.json, außer Sie starten mit --disable-fastapi-docs. Die Sicherheitsseite von vLLM nennt außerdem /pause, das die Generierung anhält, und /update_weights; im Code von 0.30.0 werden sie nur eingehängt, wenn VLLM_SERVER_DEV_MODE=1 gesetzt ist, also lassen Sie diese Variable ungesetzt. Die Sicherheitsseite von vLLM sagt es unverblümt: Do not rely exclusively on --api-key, also: Verlassen Sie sich nicht allein auf --api-key. Ihre Empfehlung für alles, was andere erreichen können, ist ein Reverse Proxy vor vLLM, der nur die Routen durchlässt, die Sie freigeben wollen.

Ein zweiter Dienst, der lauscht. vLLM nutzt torch.distributed von PyTorch, und wenn es das über TCP einrichtet, wie über mehrere Rechner hinweg oder auf AMD-Karten mit dem All-Reduce von AITER, lauscht der TCPStore von PyTorch ab Werk auf allen Netzwerkschnittstellen. Auf 1 Rechner mit NVIDIA-Karten nutzt der Code von 0.30.0 stattdessen eine Datei. Die eigene Empfehlung von vLLM ist eine Firewall, die jede eingehende Verbindung außer dem Port des API-Servers blockiert. --host 127.0.0.1 schließt die API; die Firewall-Regel deckt ab, was die eigenen Optionen von vLLM nicht erreichen.

Was vLLM von sich aus sendet, und wie Sie es abschalten

Die Nutzungsstatistik ist ab Werk eingeschaltet und geht an https://stats.vllm.ai. Im Code von 0.30.0 verlässt sie den Rechner in 2 Formen:

• 1 vollständiger Bericht beim Start der Engine, aus einem eigenen Thread: eine zufällige Lauf-ID; Anzahl, Modell und Speicher der GPUs; die CUDA-Version; der Cloud-Anbieter, falls es einen erkennt; die Prozessorarchitektur und die Kennung des Betriebssystems; der gesamte Arbeitsspeicher; Kernzahl, Marke, Familie, Modell und Stepping des Prozessors; die vLLM-Version; die Architektur des Modells, nicht sein Name; die Kontextlänge; 5 Umgebungsvariablen von vLLM; und Startparameter wie Datentyp, gpu_memory_utilization, Quantisierung, Parallelisierung, max_model_len und max_num_seqs.
• Ein Herzschlag alle 10 Minuten, solange der Server läuft, nur mit der Lauf-ID und einem Zeitstempel. Das sind 144 Herzschläge am Tag.

Netzwerkfehler werden stillschweigend ignoriert. Zum Vergleich: Die Anleitung zu Ollama zählt bei geöffneter Desktop-App 30 Aufrufe am Tag.

Sie können nachlesen, was gesendet wurde. Jeder Bericht wird außerdem an eine Datei auf Ihrer Platte angehängt:

tail ~/.config/vllm/usage_stats.json

4 Wege schalten sie ab, und jeder allein genügt:

export VLLM_NO_USAGE_STATS=1
export DO_NOT_TRACK=1
export VLLM_DO_NOT_TRACK=1
mkdir -p ~/.config/vllm && touch ~/.config/vllm/do_not_track

Der Wert muss genau 1 sein. Der Code vergleicht den Text mit "1", also lässt DO_NOT_TRACK=true die Statistik eingeschaltet. In Docker übergeben Sie ihn mit -e VLLM_NO_USAGE_STATS=1.

Hugging Face. Der übrige Datenverkehr ist der Modell-Download. vLLM gibt sich bei Hugging Face als vllm zu erkennen und holt jedes Modell, das Sie nennen und das noch nicht im Cache liegt. Sind Ihre Modelle heruntergeladen:

export HF_HUB_OFFLINE=1

Damit geht kein Aufruf an Hugging Face, und ein fehlendes Modell scheitert mit einem Fehler, statt heruntergeladen zu werden. vLLM hat keine Update-Prüfung und kein Konto.

Was auf der Platte bleibt. Modelle landen im Hugging-Face-Cache in ~/.cache/huggingface, den HF_HOME verschiebt. Die eigenen Dateien von vLLM liegen in ~/.config/vllm (die Statistikdatei und der Schalter do_not_track) und in seinem Cache-Ordner, ~/.cache/vllm. Chats gibt es keine: Der Server behält keine Kopie Ihrer Anfragen.

Die Reihenfolge, die Ihnen ein funktionierendes und abgeschottetes vLLM hinterlässt:

1. Die Karte prüfen: NVIDIA mit Compute Capability 7.5 oder neuer, unter Linux oder WSL.
2. Mit uv eine Umgebung mit Python 3.12 anlegen, vllm==0.30.0 mit --torch-backend=auto installieren und mit vllm --version bestätigen.
3. VLLM_NO_USAGE_STATS=1 vor dem ersten vllm serve setzen, damit nicht einmal der Startbericht hinausgeht.
4. Mit --host 127.0.0.1, --max-model-len 8192 und einem Schlüssel in VLLM_API_KEY starten.
5. Steuert die Karte auch Ihren Bildschirm, --gpu-memory-utilization senken, bis es startet.
6. Sobald das Modell heruntergeladen ist, HF_HUB_OFFLINE=1 setzen.

Die 5 Programme werden genau hierin verglichen unter 5 Programme für lokale KI: Telemetrie, Aufrufe, Audit.