Lokale KI-Infrastruktur
Modellspeicher und GPU-Bedarf
Wie viel Speicher braucht dieses Modell, und passt es auf diese GPUs?
Modell, Kontext und GPU-Setup planen, bevor du etwas herunterlädst oder kaufst.
1 · Modell
Qwen3-8B
Qwen
Model Card auf Hugging Face(öffnet in neuem Tab)config.json(öffnet in neuem Tab)
- Parameter
- 8,19 Mrd.
- Schichten
- 36
- Heads
- 32 Query, 8 KV
- Head-Dimension
- 128
- Maximaler Kontext
- 40.960 Tokens
- KV cache pro Token, 16 Bit
- 144 KiB/token
- Hidden Size
- 4.096
- Vokabular
- 151.936
Werte am 30. Oktober 2026 aus der config.json auf Hugging Face gelesen.
Diese Werte stammen von Hugging Face und sind schreibgeschützt. Wähle Werte anpassen, um sie zu ändern.
2 · Präzision
Wie viele Bits jeden Parameter speichern.
›Veröffentlichte Quantisierungen
Gilt nur für quantisierte Formate.
Getrennt von den Gewichten einstellbar. FP8 halbiert den Cache.
3 · Workload
Tokens pro Sequenz, Prompt und generierter Text zusammen.
Anfragen, die zur selben Zeit verarbeitet werden, der Batch.
4 · Hardware
RTX PRO 6000 Blackwell Server Edition
NVIDIA · Blackwell
Speicher
96 GB
GDDR7 · als 96 GiB gezählt
Bandbreite
1.597 GB/s
Max. Leistung
300 to 600 W
Konfigurierbar.
Die Balken vergleichen jeden Wert mit der größten GPU im Katalog.
- NVLink
- Keine
- MIG-Instanzen
- 4
- NVLink-Gruppe
- Keine, nur PCIe
- GPUs pro Server
- bis zu 8
So wird sie in Server eingebaut
- The Server Edition lists no NVLink. NVIDIA-Certified RTX PRO servers hold up to 8 GPUs. NVIDIA RTX PRO 6000 Blackwell Server Edition(öffnet in neuem Tab)
Diese GPU unterteilen
MIG
Unterteilt in 4 Speicher-Slices und 4 Compute-Slices, bis zu 4 Instanzen auf einer GPU. Die Profile:
- 1g.24gb
- 2g.48gb
- 4g.96gb
Wo eine Instanz beginnen darf:Abgeleitet
vGPU for Compute
10 Typen mit 8 bis 96 GB Framebuffer, bis zu 12 vGPUs auf einer GPU. Es braucht eine Lizenz für NVIDIA AI Enterprise und einen Hypervisor.
Teilen ohne Unterteilen
Time-slicing funktioniert auf jeder GPU, ohne Isolation von Speicher oder Fehlern zwischen den Replicas. MPS teilt eine ganze GPU, keine MIG-Instanz.
Zahlenformate
Dokumente bei NVIDIA
›Spezifikationen und Quellen
- Speicher
- 96 GB[1]
- Typ
- GDDR7[1]
- Bandbreite
- 1.597 GB/s[1]
- Max. Leistung
- 300 to 600 W[2]Konfigurierbar.
- NVLink
- 0[3]Nicht unterstützt.
- MIG-Instanzen
- 4[4]
- FP4
- 4.000 TFLOPS[1]NVIDIA nennt nicht, ob dense oder sparse.
- FP8
- 2.000 TFLOPS[1]NVIDIA nennt nicht, ob dense oder sparse.
- FP16 / BF16
- 1.000 TFLOPS[1]NVIDIA nennt nicht, ob dense oder sparse.
- TF32
- 234 TFLOPS[1]NVIDIA nennt nicht, ob dense oder sparse.
Zahlenformate: FP4, FP8, FP16, BF16, TF32, FP32
Tensor-Werte sind Spitzenwerte aus Datenblättern und keine Leistung in der Anwendung.
Quellen
Quellen werden geladen
GPUs insgesamt. Das Modell verteilt sich per Tensor parallelism, Pipeline-Stufen und Replicas auf sie, wie das Layout unten festlegt.
1 Server mit je 8 GPUs, der letzte mit 1
So wird die GPU genutzt
Unterteile jede GPU in Slices oder teile sie unter Replicas, statt mehr GPUs zu nutzen. Slices und Teil-GPUs führen Replicas des Modells aus und lassen sich nicht zu einer Tensor-parallel-Gruppe verbinden.
›Deployment-Layout
Wie sich die GPUs das Modell teilen. Speicher pro GPU, Platz für den KV cache und GPU-Anzahl ergeben sich daraus, so wie vLLM sie aufteilt.
Pipeline-Stufen
Teilt die Schichten in Abschnitte auf verschiedenen GPUs auf. Zwischen den Stufen fließen wenig Daten, daher passt es zu GPUs ohne schnelle Verbindung und zu Servern, die nur über ein Netzwerk verbunden sind.
Replicas
Unabhängige Kopien des Modells, jede mit eigenem KV cache. Die Sequenzen werden auf die Kopien verteilt. Ein Mixture-of-Experts-Modell verteilt seine Experten über alle Replicas.
Tensor-parallel-Größe: 1, die GPUs geteilt durch Pipeline-Stufen und Replicas.
GPUs pro Server
Tensor parallelism bleibt innerhalb eines Servers. Darüber hinaus werden die GPUs zu Pipeline-Stufen.
Decode-context-parallel-Größe
Teilt den KV cache jeder Sequenz tokenweise auf die GPUs des Tensor-Parallel-Verbunds auf. Es kommen keine GPUs hinzu, und das Decoding wird langsamer.
Nur für Mixture-of-Experts-Modelle.
Runtime-Annahmen›3 GiB Overhead pro GPU, 90 % nutzbar, 10 % Reserve
Speicher für CUDA-Kontext, Aktivierungen und Graphs, in der gewählten Einheit. Eine Heuristik.
Anteil des GPU-Speichers, den die Serving-Engine nutzen darf. Der Standard von vLLM ist 92 Prozent.
Anteil des nutzbaren Speichers, der frei bleiben soll, damit es bequem passt.
Dieses Modell hat keine Sliding-Window-Schichten.
Passt mit Reserve
Braucht 22,76 GiB pro GPU. 63,64 GiB der 86,4 GiB nutzbaren bleiben frei, mehr als die gewünschte Reserve von 10 %.
Benötigter Speicher pro GPU
22,76 GiB
von 86,4 GiB nutzbar
Restspeicher pro GPU
63,64 GiB
73,66 % des nutzbaren Speichers sind frei
Rohgröße der Gewichte
15,26 GiB
Parameter × nominale Bits
Geschätzter Gesamtspeicher
22,76 GiB
GPU-Speicher gesamt
96 GiB
Speicher einer GPU
Speicher auf jeder GPU
GPU-Speicher 96 GiB
- Gewichte im Speicher15,26 GiB67,04 %
- KV cache4,5 GiB19,77 %
- Runtime-Overhead3 GiB13,18 %
Speicherbudget
| Posten | Speicher |
|---|---|
| Rohgröße der GewichteParameter × nominale Bits | 15,26 GiB |
| Gewichte im Speicher | 15,26 GiB |
| Runtime-Overhead | 3 GiB |
| Modell mit Runtime-Overhead | 18,26 GiB |
| KV cache | 4,5 GiB |
| Gesamt | 22,76 GiB |
Platz für den KV cache
Nach den Gewichten und dem Overhead bleibt Platz für 496.206 Tokens im KV cache, genug für 60,57 Sequenzen von je 8.192 Tokens.
vLLM gibt diesen Wert beim Start als Kapazität des KV cache aus. Die echte Kapazität ist etwas niedriger: Der Cache liegt in Blöcken.
GPU-Anzahl
Speicherminimum
1
TP 1
26,34 % des nutzbaren Speichers, 63,64 GiB frei pro GPU
Die kleinste GPU-Anzahl, deren Speicher bei beliebiger Aufteilung für das Modell reicht. Das Layout wird von vLLM womöglich nicht akzeptiert.
Kleinste gültige Aufteilung
1
TP 1
26,34 % des nutzbaren Speichers, 63,64 GiB frei pro GPU
Die wenigsten GPUs in einem Layout, das vLLM akzeptiert: Tensor parallelism innerhalb eines Servers, Pipeline-Stufen darüber hinaus.
Empfohlen
1
TP 1
26,34 % des nutzbaren Speichers, 63,64 GiB frei pro GPU
Eine gültige Aufteilung, die zusätzlich deine Reserve einhält.
Jede GPU muss ihren eigenen Anteil halten, daher ist der Speicher mehrerer GPUs kein gemeinsamer Pool. Mehr als acht GPUs bedeuten meist mehrere Server.
Speicher pro GPU nach GPU-Anzahl
Jeder Balken ist eine GPU-Anzahl, mit dem Layout, das die Empfehlung von vLLM dafür bevorzugt. Die Linie ist der nutzbare Speicher. Wähle einen Balken, um diese Anzahl zu verwenden.
- Nutzbar 86,4 GiB
- Grenze der Reserve
- Gewichte im Speicher
- KV cache
- Runtime-Overhead
- Stern: empfohlen
- Raute: kleinste gültige Aufteilung
- Kreis: Speicherminimum
- Umrandet: aktiv
- Abgeblasst, gestrichelt: vLLM würde mit diesem Layout nicht starten
›Als Tabelle anzeigen
| GPUs | Layout | Pro GPU | Passt? |
|---|---|---|---|
| 1 | TP 1 | 22,76 GiB | Passt mit ReserveSpeicherminimum, kleinste gültige Aufteilung, empfohlen, aktiv |
| 2 | TP 2 | 12,88 GiB | Passt mit Reserve |
| 3 | TP 3vLLM würde mit diesem Layout nicht starten | 9,77 GiB | Passt mit Reserve |
| 4 | TP 4 | 7,94 GiB | Passt mit Reserve |
| 5 | TP 5vLLM würde mit diesem Layout nicht starten | 7,18 GiB | Passt mit Reserve |
| 6 | TP 3 × PP 2vLLM würde mit diesem Layout nicht starten | 6,39 GiB | Passt mit Reserve |
| 7 | TP 7vLLM würde mit diesem Layout nicht starten | 6,3 GiB | Passt mit Reserve |
| 8 | TP 8 | 5,47 GiB | Passt mit Reserve |
| 9 | TP 1 × PP 9 | 6,1 GiB | Passt mit Reserve |
| 10 | TP 2 × PP 5 | 5,27 GiB | Passt mit Reserve |
| 11 | TP 1 × PP 11 | 5,61 GiB | Passt mit Reserve |
| 12 | TP 4 × PP 3 | 4,74 GiB | Passt mit Reserve |
| 13 | TP 1 × PP 13 | 5,13 GiB | Passt mit Reserve |
| 14 | TP 2 × PP 7 | 4,79 GiB | Passt mit Reserve |
| 15 | TP 1 × PP 15 | 5,13 GiB | Passt mit Reserve |
| 16 | TP 8 × PP 2 | 4,23 GiB | Passt mit Reserve |
Was bei anderem Kontext und anderer Gleichzeitigkeit passt
Jede Zelle ist der Speicher, den eine GPU bei diesem Kontext und dieser Zahl von Sequenzen braucht, auf den eingestellten GPUs und im eingestellten Layout. Wähle eine Zelle, um sie zu verwenden.
Sequenzen ↓Kontext, in Tokens →
| 2K | 4K | 8K | 16K | 32K | 40KModell-Max. | |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 4 | ||||||
| 16 | ||||||
| 64 | ||||||
| 128 | ||||||
| 256 | ||||||
| 512 | ||||||
| 1024 |
- Haken: passt mit Reserve
- Dreieck: passt, ohne die gewünschte Reserve
- Kreuz: passt nicht
- Umrandet: aktiv
Möglichkeiten, das Setup zu ändern
Spielraum nach oben
Dieses Setup passt mit Reserve. So weit ließe es sich treiben.
Der Kontext könnte bei 4 Sequenzen auf 40.960 Tokens wachsen
Danach: passt mit Reserve, 47,17 % des nutzbaren Speichers
Bis zu 52 gleichzeitige Sequenzen passen bei 8.192 Tokens
Danach: passt mit Reserve, 88,84 % des nutzbaren Speichers
Dieses Setup deployen
Diese Befehle sind für das oben dimensionierte Setup und deine Auswahl hier geschrieben und ändern sich mit beidem. Nichts wird für dich verändert: Eine Auswahl, die nicht mehr funktioniert, bleibt erhalten und wird markiert, mit Wegen, sie zu beheben.
Der Server
Ausführen mit
Runtime
Der Server, der das Modell lädt.
GPUs
Die Indizes der GPUs im Computer, wie nvidia-smi sie auflistet, durch Kommas getrennt. Das Setup nutzt 1 GPU.
GPUs identifizieren per
Ein Index hängt von der Reihenfolge ab, in der der Treiber die GPUs findet. Eine UUID ist an die Karte gebunden.
Endpoint
Der Port, auf dem der Endpoint antwortet. 8000 (Standard)
Lauscht auf
Standardmäßig ist der Endpoint nur auf diesem Computer erreichbar.
Der Endpoint antwortet nur auf Anfragen, die einen Key mitschicken. Der Key wird auf deinem Computer erzeugt und nie in einen Befehl oder Link geschrieben.
Weitere Optionen
Wo die heruntergeladenen Gewichte liegen. Ein bereits vorhandenes Verzeichnis spart den Download.
Der Standard ist das Release, für das diese Befehle geschrieben wurden. latest folgt dem neuesten.
Was laufen wird
vLLM · Docker · 1 GPU, RTX PRO 6000 Blackwell
- Repository
- Qwen/Qwen3-8BVom Rechner
- Runtime
- vLLMStandard
- Ausführen mit
- DockerStandard
- GPUs
- 1 GPU, RTX PRO 6000 BlackwellVom Rechner
- Index 0Standard
- Kontext
- 8.192 TokensVom Rechner
- Sequenzen pro Replica
- 4Berechnet
- Speicher pro GPU
- 22,76 GiB benötigt von 86,40 GiB nutzbar
- Anteil jeder GPU für die Engine
- 90 ProzentBerechnet
- Zugang
- OffenVom Rechner
- Endpoint
- 127.0.0.1:8000Standard
Einen Blick wert
Du hast einen KV cache in fp16 für bf16-Gewichte dimensioniert. Ein 16-Bit-Cache braucht in beiden Typen gleich viel Platz, und vLLM speichert ihn im eigenen Typ des Modells, sofern nichts anderes verlangt wird, daher erzwingen die Befehle fp16 nicht.
16 Schritte in 5 Phasen. Öffne einen nach dem anderen oder alle.
1Hardware prüfen
Sieh dir an, was der Computer oder Cluster bietet, bevor du etwas änderst.3 Schritte
- Schritt 1
Treiber prüfen
Stelle sicher, dass der NVIDIA-Treiber installiert und für die Software unten neu genug ist.
nvidia-smiDas solltest du sehen
- Eine Tabelle mit der Treiberversion und einer CUDA-Version von mindestens 13.0, die das Image braucht.
Hilfe und Quellen
Wenn es nicht funktioniert
- Ist die CUDA-Version niedriger, als die Software braucht, aktualisiere den Treiber und prüfe erneut.
Woher die Werte kommen
- Die gewählte GPU: RTX PRO 6000 Blackwell.
- Schritt 2
GPUs prüfen
Stelle sicher, dass der Computer die GPU mit Index 0 auflistet.
nvidia-smi -LDas solltest du sehen
- Eine Zeile pro GPU, jede mit RTX PRO 6000 Blackwell, wie der Computer es schreibt.
Hilfe und Quellen
Wenn es nicht funktioniert
- Fehlt eine gewählte GPU, steckt sie nicht in diesem Computer, oder der Treiber sieht sie nicht.
- Passen die Namen nicht zu dem, was du erwartest, sind die Indizes nicht das, was du denkst. Identifiziere die GPUs per UUID, die nicht von der Reihenfolge abhängt.
Woher die Werte kommen
- Der Rechner nutzt 1 GPU.
- Die gewählte GPU: RTX PRO 6000 Blackwell.
- Schritt 3
Prüfen, dass der Speicher frei ist
Der Rechner erwartet 22,76 GiB auf jeder GPU, von den 86,40 GiB, die die Engine nutzen darf. Prüfe, dass der Speicher von der GPU mit Index 0 frei ist.
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv -i 0Das solltest du sehen
- Fast der gesamte Speicher der GPU ist frei, mindestens 22,76 GiB auf jeder.
Zu beachten
- Andere Prozesse nutzen diese GPUs womöglich schon. Ist ihr Speicher nicht frei, stoppe sie oder wähle andere GPUs, bevor du startest.
Hilfe und Quellen
Woher die Werte kommen
- Der Rechner: 22,76 GiB benötigt von 86,40 GiB nutzbar auf jeder GPU.
2Vorbereiten
Hole dir Zugang zum Modell, installiere, was der Server braucht, und beschaffe ihn. Auch eine unterteilte GPU entsteht hier.2 brauchen Administratorrechte5 Schritte
Tools installieren
- Schritt 4
Docker prüfen
Stelle sicher, dass Docker Engine installiert ist.
docker --versionDas solltest du sehen
- Eine Docker-Version.
Hilfe und Quellen
- Schritt 5
NVIDIA Container Toolkit installieren
Braucht AdministratorrechteEs lässt Container die GPUs nutzen. Diese Befehle gelten für Ubuntu und Debian, die verlinkte Seite unten behandelt die anderen Distributionen.
Kommt nach Schritt 1
sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \ && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update export NVIDIA_CONTAINER_TOOLKIT_VERSION=1.20.1-1 sudo apt-get install -y \ nvidia-container-toolkit=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ nvidia-container-toolkit-base=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ libnvidia-container-tools=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ libnvidia-container1=${NVIDIA_CONTAINER_TOOLKIT_VERSION}Das solltest du sehen
- Die Pakete werden ohne Fehler installiert.
Hilfe und Quellen
- Schritt 6
Docker mit den GPUs verbinden
Braucht AdministratorrechteRegistriere die NVIDIA-Runtime bei Docker und starte es neu.
sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart dockerDas solltest du sehen
- Keine Fehler, und Docker kommt wieder hoch.
Zu beachten
- Ein Neustart von Docker stoppt die laufenden Container.
Hilfe und Quellen
- Schritt 7
Prüfen, dass ein Container die GPUs sieht
Führe nvidia-smi in einem Container aus, der die GPU mit Index 0 bekommt. Es sollte nichts erscheinen außer dieser GPU.
docker run --rm --runtime=nvidia --gpus '"device=0"' \ ubuntu nvidia-smiDas solltest du sehen
- Eine Tabelle mit einer GPU, der gewählten.
Hilfe und Quellen
Wenn es nicht funktioniert
- Kann Docker nicht mit den GPUs starten, ist das Toolkit nicht konfiguriert, oder die Indizes gibt es auf diesem Computer nicht.
- Passen die Namen nicht zu dem, was du erwartest, sind die Indizes nicht das, was du denkst. Identifiziere die GPUs per UUID, die nicht von der Reihenfolge abhängt.
- NVIDIA Container Toolkit: sample workload(öffnet in neuem Tab)
- NVIDIA Container Toolkit: Specialized configurations with Docker(öffnet in neuem Tab)
Woher die Werte kommen
--gpus '"device=0"'Standard Die ersten GPUs, ab 0 gezählt.
Server beziehen
- Schritt 8
Image herunterladen
Lade vllm/vllm-openai:v0.32.0 vor dem ersten Start herunter, damit der Start nur noch das Modell laden muss.
docker pull vllm/vllm-openai:v0.32.0Das solltest du sehen
- Der Download wird abgeschlossen, und die letzte Zeile nennt das Image.
Zu beachten
- Das Image ist mehrere Gigabyte groß.
3Server starten
Starte ihn mit dem dimensionierten Setup.1 Schritt
- Schritt 9
Server starten
Starte vllm-qwen3-8b mit dem dimensionierten Setup: dem Modell Qwen/Qwen3-8B, der Aufteilung auf die GPUs, dem Kontext und dem zugeteilten Speicher. Der erste Start lädt das Modell herunter und dauert ein paar Minuten.
Kommt nach Schritt 3
# config YSTVGT docker run -d --name vllm-qwen3-8b \ --runtime nvidia --gpus '"device=0"' \ --ipc=host \ -v "$HOME/.cache/huggingface":/root/.cache/huggingface \ -p 127.0.0.1:8000:8000 \ vllm/vllm-openai:v0.32.0 \ --model Qwen/Qwen3-8B \ --max-model-len 8192 --max-num-seqs 4 \ --gpu-memory-utilization 0.90Das solltest du sehen
- Eine Container-ID.
Zu beachten
- Der erste Start lädt das Modell herunter und bereitet die Kernels vor, das dauert Minuten. Vorher ist der Server nicht bereit.
Hilfe und Quellen
Wenn es nicht funktioniert
- Wenn es mit einer Out-of-memory-Meldung stoppt, braucht das Setup mehr, als die GPU fasst. Verringere Kontext oder Sequenzen, gib der Engine einen größeren Anteil der GPU oder nimm mehr GPUs. Der Rechner zeigt, um wie viel.
- Sagt vLLM, der Kontext sei länger, als der KV cache fassen kann, verringere den Kontext oder die Zahl der Sequenzen.
- Sagt vLLM, die Attention Heads ließen sich nicht durch die Tensor-parallel-Größe teilen, nimm eine Größe, die sie teilt.
- Ist der Port belegt, wähle oben in den Optionen einen anderen.
- Kann Docker nicht mit den GPUs starten, ist das Toolkit nicht konfiguriert, oder die Indizes gibt es auf diesem Computer nicht.
Woher die Werte kommen
-dStandard Wie du es ausführen willst.
--name vllm-qwen3-8bVom Rechner Das Repository des gewählten Modells.
--runtime nvidiaStandard Wie du es ausführen willst.
--gpus '"device=0"'Standard Die ersten GPUs, ab 0 gezählt.
--ipc=hostStandard Wie du es ausführen willst.
-v "$HOME/.cache/huggingface":/root/.cache/huggingfaceStandard Wo die heruntergeladenen Gewichte liegen.
-p 127.0.0.1:8000:8000Standard Der Port, auf dem der Endpoint antwortet.
--model Qwen/Qwen3-8BVom Rechner Das Repository des gewählten Modells.
--max-model-len 8192Vom Rechner Die von dir gesetzte Kontextlänge: 8.192 Tokens.
--max-num-seqs 4Berechnet 4 Sequenzen, verteilt auf 1 Replica.
--gpu-memory-utilization 0.90Berechnet Der von dir gesetzte nutzbare Anteil, 90 Prozent, aufgeteilt auf 1 Replica auf dem Gerät, abgerundet, damit die Anteile nie mehr als das Gerät ergeben.
- Das Repository des gewählten Modells.
- Die von dir gesetzte Kontextlänge: 8.192 Tokens.
- Der von dir gesetzte nutzbare Anteil, 90 Prozent, aufgeteilt auf 1 Replica auf dem Gerät, abgerundet, damit die Anteile nie mehr als das Gerät ergeben.
4Prüfen, dass es funktioniert
Warte, bis er antwortet, frage ihn etwas und vergleiche den Speicher mit dem Rechner.6 Schritte
Endpoint prüfen
- Schritt 10
Warten, bis er bereit ist
Der Server antwortet auf /health, sobald das Modell geladen ist.
timeout 900 bash -c 'until curl -fs http://127.0.0.1:8000/health >/dev/null; do sleep 5; done' && echo readyDas solltest du sehen
- Das Wort ready, nach einer Minute oder mehr, während das Modell lädt.
Hilfe und Quellen
Wenn es nicht funktioniert
- Meldet sich der Server nicht als bereit, lies die letzten Logzeilen: Das Modell lädt noch, oder der Server ist mit einem Fehler gestoppt.
- Wenn es mit einer Out-of-memory-Meldung stoppt, braucht das Setup mehr, als die GPU fasst. Verringere Kontext oder Sequenzen, gib der Engine einen größeren Anteil der GPU oder nimm mehr GPUs. Der Rechner zeigt, um wie viel.
- Schritt 11
Prüfen, dass das Modell bereitgestellt wird
Frage den Server, welche Modelle er bereitstellt.
curl -sS http://127.0.0.1:8000/v1/modelsDas solltest du sehen
- Eine Liste, in der Qwen/Qwen3-8B steht.
Hilfe und Quellen
Wenn es nicht funktioniert
- Lautet die Antwort 401, ist der Key in dieser Shell nicht der, mit dem der Server gestartet wurde.
- Schritt 12
Eine Frage stellen
Eine Anfrage über den Endpoint, den deine Anwendungen nutzen werden.
curl -sS http://127.0.0.1:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"model": "Qwen/Qwen3-8B", "messages": [{"role": "user", "content": "Say hello in five words."}], "max_tokens": 32}'Das solltest du sehen
- Eine JSON-Antwort mit einer Nachricht des Modells.
Hilfe und Quellen
Wenn es nicht funktioniert
- Lautet die Antwort 401, ist der Key in dieser Shell nicht der, mit dem der Server gestartet wurde.
- Meldet sich der Server nicht als bereit, lies die letzten Logzeilen: Das Modell lädt noch, oder der Server ist mit einem Fehler gestoppt.
System ansehen
- Schritt 13
GPUs ansehen
Sieh dir den belegten Speicher und die Auslastung von der GPU mit Index 0 an, während der Server läuft.
nvidia-smi --query-gpu=index,name,memory.used,memory.total,utilization.gpu --format=csv -i 0Das solltest du sehen
- Belegter Speicher nahe an dem, was die Engine bekommen hat.
Hilfe und Quellen
- Schritt 14
Server ansehen
Prüfe, ob vllm-qwen3-8b läuft und was es zuletzt gemeldet hat.
Kommt nach Schritt 12
docker ps --filter name=vllm-qwen3-8b --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' docker logs --tail 20 vllm-qwen3-8bDas solltest du sehen
- Der Server läuft, und seine letzten Logzeilen zeigen keine Fehler.
Hilfe und Quellen
Mit dem Rechner vergleichen
- Schritt 15
Mit dem Rechner vergleichen
Der Rechner erwartete 22,76 GiB auf jeder GPU, davon 90 Prozent der GPU für die Engine. Das eigene Log des Servers sagt, was er für die Gewichte genommen hat und was für den KV cache bleibt.
Kommt nach Schritt 12
docker logs vllm-qwen3-8b 2>&1 | grep -E 'Model loading took|Available KV cache memory|GPU KV cache size'Das solltest du sehen
- Zeilen mit dem Speicher, den die Gewichte belegt haben, dem Speicher, der für den KV cache bleibt, und wie viele Tokens der KV cache aufnehmen kann.
Hilfe und Quellen
Woher die Werte kommen
- Der Rechner: 22,76 GiB benötigt von 86,40 GiB nutzbar auf jeder GPU.
5Aufräumen
Stoppe den Server und entferne, was diese Schritte erzeugt haben.1 Schritt
- Schritt 16
Stoppen
Kann Dinge stoppen oder entfernenStoppe vllm-qwen3-8b und gib die GPUs frei.
Kommt nach Schritt 9
docker stop vllm-qwen3-8b && docker rm vllm-qwen3-8bDas solltest du sehen
- Keine Ausgabe, und die GPUs sind frei.
Zu beachten
- Der Endpoint antwortet nicht mehr.
Hilfe und Quellen
Berechnung
- Deine Eingabe
- Offizielle Spezifikation
- Berechnetes Ergebnis
- Schätzung
- Heuristik
- Annahme
›Gewichte
Rohgröße der Gewichte
Berechnetes ErgebnisRohgröße der Gewichte = Parameter × nominale Bits pro Parameter ÷ 8
= Deine Eingabe: 8,19 Mrd. Parameter × Offizielle Spezifikation: 16 bit/param ÷ 8
= 15,26 GiB
Gewichte im Speicher
Berechnetes ErgebnisGewichte im Speicher = Parameter × effektive Bits pro Parameter ÷ 8
= Deine Eingabe: 8,19 Mrd. Parameter × Offizielle Spezifikation: 16 bit/param ÷ 8
= 15,26 GiB
›KV cache
KV cache pro Token
Berechnetes ErgebnisKV cache pro Token = 2 × Schichten mit KV cache × KV Heads × Head-Dimension × Bits pro Wert im KV cache ÷ 8
= 2 × Deine Eingabe: 36 × Deine Eingabe: 8 × Deine Eingabe: 128 × Deine Eingabe: 16 bit ÷ 8
= 144 KiB/token
KV cache pro Sequenz
Berechnetes ErgebnisKV cache pro Sequenz = KV cache pro Token × Kontextlänge
= Berechnetes Ergebnis: 144 KiB/token × Deine Eingabe: 8.192 Tokens
= 1,13 GiB
KV cache
Berechnetes ErgebnisKV cache = KV cache pro Sequenz × gleichzeitige Sequenzen
= Berechnetes Ergebnis: 1,13 GiB × Deine Eingabe: 4
= 4,5 GiB
›Speicher pro GPU und gesamt
Benötigter Speicher pro GPU
SchätzungBenötigter Speicher pro GPU = Gewichte im Speicher + KV cache + Runtime-Overhead
= Berechnetes Ergebnis: 15,26 GiB + Berechnetes Ergebnis: 4,5 GiB + Heuristik: 3 GiB
= 22,76 GiB
Modell mit Runtime-Overhead
SchätzungModell mit Runtime-Overhead = Gewichte im Speicher + Runtime-Overhead
= Berechnetes Ergebnis: 15,26 GiB + Heuristik: 3 GiB
= 18,26 GiB
›Passt es auf die GPU?
Nutzbarer Speicher pro GPU
SchätzungNutzbarer Speicher pro GPU = GPU-Speicher × nutzbarer Anteil ÷ 100
= Offizielle Spezifikation: 96 GiB × Annahme: 90 % ÷ 100
= 86,4 GiB
Komfortable Grenze pro GPU
SchätzungKomfortable Grenze pro GPU = Nutzbarer Speicher pro GPU × (100 − geforderte Reserve) ÷ 100
= Schätzung: 86,4 GiB × (100 − Annahme: 10 %) ÷ 100
= 77,76 GiB
Restspeicher pro GPU
SchätzungRestspeicher pro GPU = Nutzbarer Speicher pro GPU − Benötigter Speicher pro GPU
= Schätzung: 86,4 GiB − Schätzung: 22,76 GiB
= 63,64 GiB
Auslastung des nutzbaren Speichers
SchätzungAuslastung des nutzbaren Speichers = Benötigter Speicher pro GPU ÷ Nutzbarer Speicher pro GPU × 100
= Schätzung: 22,76 GiB ÷ Schätzung: 86,4 GiB × 100
= 26,34 %
›Platz für den KV cache
Für den KV cache verbleibender Speicher pro GPU
SchätzungFür den KV cache verbleibender Speicher pro GPU = max(0, Nutzbarer Speicher pro GPU − Gewichte im Speicher − Runtime-Overhead)
= max(0, Schätzung: 86,4 GiB − Berechnetes Ergebnis: 15,26 GiB − Heuristik: 3 GiB)
= 68,14 GiB
Kapazität des KV cache
SchätzungKapazität des KV cache = floor(Für den KV cache verbleibender Speicher pro GPU ÷ KV cache pro Token)
= floor(Schätzung: 68,14 GiB ÷ Berechnetes Ergebnis: 144 KiB/token)
= 496.206 Tokens
Sequenzen dieses Kontexts, die passen
SchätzungSequenzen dieses Kontexts, die passen = Kapazität des KV cache ÷ Kontextlänge
= Schätzung: 496.206 Tokens ÷ Deine Eingabe: 8.192 Tokens
= 60,57 ×
›Bei 1 GPU Speicherminimum, kleinste gültige Aufteilung, empfohlen
Benötigter Speicher pro GPU
SchätzungBenötigter Speicher pro GPU = Gewichte im Speicher + KV cache + Runtime-Overhead
= Berechnetes Ergebnis: 15,26 GiB + Berechnetes Ergebnis: 4,5 GiB + Heuristik: 3 GiB
= 22,76 GiB
Nutzbarer Speicher pro GPU
SchätzungNutzbarer Speicher pro GPU = GPU-Speicher × nutzbarer Anteil ÷ 100
= Offizielle Spezifikation: 96 GiB × Annahme: 90 % ÷ 100
= 86,4 GiB
Komfortable Grenze pro GPU
SchätzungKomfortable Grenze pro GPU = Nutzbarer Speicher pro GPU × (100 − geforderte Reserve) ÷ 100
= Schätzung: 86,4 GiB × (100 − Annahme: 10 %) ÷ 100
= 77,76 GiB
Restspeicher pro GPU
SchätzungRestspeicher pro GPU = Nutzbarer Speicher pro GPU − Benötigter Speicher pro GPU
= Schätzung: 86,4 GiB − Schätzung: 22,76 GiB
= 63,64 GiB
Auslastung des nutzbaren Speichers
SchätzungAuslastung des nutzbaren Speichers = Benötigter Speicher pro GPU ÷ Nutzbarer Speicher pro GPU × 100
= Schätzung: 22,76 GiB ÷ Schätzung: 86,4 GiB × 100
= 26,34 %
Annahmen
- Annahme: Der KV cache liegt in Blöcken (in vLLM 16 Tokens), daher ist die echte Kapazität etwas kleiner als die angezeigte Zahl.
- Heuristik: Der Runtime-Overhead beträgt 3 GiB pro GPU für CUDA-Kontext, Aktivierungen und Graphs. Er ist eine Heuristik: vLLM hat bei einem 8B-Modell 2,57 GiB gemessen, und der Wert variiert mit Engine und Einstellungen. Ändern
- Annahme: Nur 90 % des GPU-Speichers geht an das Modell. Serving-Engines reservieren den Rest: Der Standard von vLLM ist 92 Prozent (Dokumentation von Version 0.32). Ändern
- Annahme: Ein Setup passt komfortabel, wenn mindestens 10 % des nutzbaren Speichers frei bleiben. Ändern
- Annahme: NVIDIA gibt GPU-Speicher in GB an, und die Hardware hat so viele GiB: Eine H100 80 GB hat 80 GiB, und nvidia-smi zeigt 79,6. Die wenigen Prozent, die ECC und Treiber zurückhalten, deckt der nutzbare Anteil ab.
- Annahme: Die Präzision des KV cache wird getrennt von der Präzision der Gewichte gesetzt. Die Quantisierung der Gewichte verkleinert weder den KV cache noch den Overhead. Ändern
- Annahme: Es wird angenommen, dass jede Sequenz gleichzeitig den vollen Kontext nutzt, der schlechteste Fall. Echter Traffic ist meist kürzer. Ändern
- Annahme: Es wird angenommen, dass sich mehrere GPUs das Modell per Tensor parallelism teilen, wie vLLM es tut: Gewichte und KV Heads werden aufgeteilt, und jede GPU zahlt den Runtime-Overhead.
Passt mit Reserve22,76 GiB / 86,4 GiBbenötigt / nutzbar
Warum das wichtig ist
Die Zahl auf einer Model Card sind die Gewichte. Ein laufendes Modell hält zusätzlich einen KV cache, der mit Kontext und Gleichzeitigkeit wächst, dazu Runtime-Overhead, und jede GPU muss ihren eigenen Anteil tragen: Der Speicher mehrerer GPUs ist kein gemeinsamer Pool. Nur mit den Gewichten zu planen ist der häufigste Fehler bei der Dimensionierung.
So liest du das Ergebnis
Passt mit Reserve lässt auf jeder GPU die gewünschte Reserve frei. Passt in der Theorie liegt unter dem nutzbaren Speicher, mit weniger Reserve als verlangt. Passt nicht heißt, dass einer GPU der Speicher ausgeht. Das Speicherbudget zeigt jeden Teil für alle GPUs und für eine einzelne. Die GPU-Anzahl folgt der Empfehlung von vLLM: Tensor parallelism innerhalb eines Servers, Pipeline-Stufen darüber hinaus. Mit dem Deployment-Layout teilst du die GPUs anders auf und siehst, wie viel jede Variante aufnehmen kann.
Lokale KI und Souveränität
Ein Modell auf Hardware zu betreiben, die du kontrollierst, ist ein Baustein für eine Souveränitätsentscheidung. Es macht ein Deployment nicht von selbst souverän, DSGVO-konform oder konform mit dem EU AI Act.
Diese Tools stammen aus dem Workshop KI ohne Cloud.