12. November 2026 · VRAMfarm-Team
Llama 70B auf einer GPU: 4 Bit oder FP8, 48 GB oder 80 GB und echte Geschwindigkeiten
Der erste Versuch läuft meist so: eine 24-GB-Karte, ollama run llama3.3:70b und eine Antwort, die mit zwei oder drei Tokens pro Sekunde heraustropft. Kaputt ist nichts. Das 4-Bit-Modell ist 43 GB groß, also hat Ollama stillschweigend fast die Hälfte davon in den Arbeitsspeicher gelegt. Eine einzelne Karte betreibt ein 70B-Modell nur dann in Lesegeschwindigkeit, wenn das ganze Modell hineinpasst: eine 48-GB-Karte für eine Person bei normalem Kontext (etwa 12–18 Tokens pro Sekunde) oder eine 80-GB-Karte für lange Dokumente, mehrere Nutzer oder FP8-Qualität (25–50 Tokens pro Sekunde).
Alles Folgende bezieht sich auf Llama 3.3 70B, und die Werte gelten auch für andere dichte 70B-Modelle, die darauf aufbauen, etwa DeepSeek R1 Distill Llama 70B. Ein 72B-Modell wie Qwen2.5 72B ist ein paar Gigabyte größer (etwa 47 GB in Q4_K_M) und lässt auf einer 48-GB-Karte fast keinen Platz für den Cache.
Zuerst das Format wählen
Jede Laufzeitumgebung hat ihr eigenes Dateiformat, und das Format bestimmt die Größe und damit die Karte.
| Format | Größe eines 70B-Modells | Läuft in | Karten | Qualität gegenüber dem Original |
|---|---|---|---|---|
| BF16 (Original) | 141 GB | vLLM, Transformers | B200 allein oder 2 × 80 GB | Referenz |
| FP8 | ~71 GB | vLLM, SGLang | 80–96 GB: H100, RTX PRO 6000, H200 | Praktisch identisch |
| GGUF Q8_0 | ~75 GB | llama.cpp, Ollama | 80–96 GB | Praktisch identisch |
| GGUF Q5_K_M | ~50 GB | llama.cpp, Ollama | 80 GB (mit Cache zu groß für 48 GB) | Sehr nah dran |
| GGUF Q4_K_M | ~43 GB | llama.cpp, Ollama | 48 GB | Kleiner Verlust |
| AWQ oder GPTQ, 4 Bit | ~40 GB | vLLM, SGLang | 48 GB | Kleiner Verlust |
| GGUF Q2/IQ2 | 21–26 GB | llama.cpp | 24–32 GB | Deutlich schlechter |
GGUF ist das Format von llama.cpp, und auch Ollama nutzt es. Eine Datei enthält die Gewichte, und die Laufzeitumgebung kann einige Schichten auf der CPU lassen, wenn die GPU voll ist. Das ist zugleich seine Stärke und die Falle aus dem ersten Absatz. Q4_K_M ist die übliche Wahl für 70B.
AWQ und GPTQ sind 4-Bit-Formate für GPU-Server. vLLM betreibt beide mit schnellen Kernels auf jeder Karte ab der Ampere-Generation, und das deckt alles in unserem Katalog ab. Ihre Qualität ist ähnlich; wählen Sie einen Build aus einer gepflegten Quelle mit vielen Downloads.
FP8 halbiert das Original fast ohne Verlust. Die Karten berechnen es nativ ab der Ada-Generation (RTX-40-Serie, L40S) sowie auf Hopper (H100, H200) und Blackwell (RTX-50-Serie, RTX PRO 6000, B200). Ein 70B-Modell in FP8 braucht etwa 71 GB, in der Praxis heißt FP8 also eine H100 mit 80 GB, eine RTX PRO 6000 mit 96 GB oder eine H200. Die A100 kann FP8-Gewichte in vLLM laden, rechnet aber in 16 Bit: Sie spart Speicher und gewinnt kein Tempo. Blackwell-Karten berechnen außerdem NVFP4, ein 4-Bit-Format mit etwa 40 GB, das in veröffentlichten Vergleichen oft näher an der FP8-Qualität bleibt als ältere 4-Bit-Verfahren. Die Unterstützung in den Laufzeitumgebungen ist neuer; prüfen Sie also, ob Ihre vLLM-Version es aufführt.
48 GB oder 80 GB: Der Kontext entscheidet
Die Gewichte sind nur ein Teil der Rechnung. Llama 3.3 70B speichert in 16 Bit etwa 0,33 MB KV-Cache pro Token. 8.000 Tokens Unterhaltung belegen also 2,7 GB, und der volle Kontext von 128.000 Tokens belegt 43 GB, so viel wie die 4-Bit-Gewichte. Der VRAM-Ratgeber erklärt die Formel; hier sehen Sie, was sie pro Karte bedeutet.
| Konfiguration | Gewichte | Übrig für den Cache | Kontext, 16-Bit-Cache | Kontext, 8-Bit-Cache |
|---|---|---|---|---|
| 48-GB-Karte, GGUF Q4_K_M | ~43 GB | 3–4 GB | 8.000–12.000 Tokens | 16.000–24.000 |
| 48-GB-Karte, AWQ in vLLM | ~40 GB | 3–5 GB | 8.000–12.000 | 16.000–24.000 |
| 2 × 24-GB-Karten, AWQ oder Q4 | ~40–43 GB | 3–5 GB | 8.000–12.000 | 16.000–24.000 |
| 80-GB-Karte, AWQ oder Q4 | ~40–43 GB | 30–35 GB | insgesamt etwa 100.000 | die vollen 128.000 für einen Nutzer oder viele kürzere Chats |
| 80-GB-Karte, FP8 | ~71 GB | 4–8 GB | 12.000–25.000 | 25.000–50.000 |
| RTX PRO 6000 mit 96 GB, FP8 | ~71 GB | ~20 GB | ~60.000 | etwa 120.000 |
| H200 mit 141 GB, FP8 | ~71 GB | ~60 GB | 128.000 plus mehrere Nutzer | viel Reserve |
Es sind Spannen, weil sich der nutzbare Speicher der Karten um ein, zwei Gigabyte unterscheidet, jede Laufzeitumgebung eigene Puffer hält und vLLM nur den Anteil der Karte nutzt, den --gpu-memory-utilization festlegt. „Insgesamt“ ist für den Betrieb als Dienst wichtig: Der Cache wird zwischen allen geteilt, die gleichzeitig mit dem Modell sprechen. 100.000 Tokens auf einer 80-GB-Karte sind also ein langes Dokument oder etwa ein Dutzend Unterhaltungen mit je 8.000 Tokens.
Die praktische Regel: Eine 48-GB-Karte wie die L40S oder RTX A6000 reicht für eine Person, die chattet oder ein paar Seiten zusammenfassen lässt. Nehmen Sie eine 80-GB-Karte, wenn Sie lange Dokumente einfügen, ein Team bedienen oder FP8 wollen. Auch zwei 24-GB-Karten in einer Maschine fassen ein 70B-Modell in 4 Bit. Vergleichen Sie zwei RTX 3090 für 0,60 € pro Stunde mit einer RTX A6000 für 0,72 €; Maschinen mit mehreren Karten stehen im Katalog gesondert.
Ollama oder llama.cpp: ein Nutzer, wenige Schritte
Ollama ist der kürzeste Weg. Öffnen Sie auf einem leeren PyTorch-Server das Jupyter-Terminal oder verbinden Sie sich per SSH:
curl -fsSL https://ollama.com/install.sh | sh
OLLAMA_CONTEXT_LENGTH=8192 OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve > /workspace/ollama.log 2>&1 &
ollama run llama3.3:70b
Der Standard-Tag llama3.3:70b ist das Q4_K_M mit 43 GB. Die Kontextlänge sollten Sie bewusst setzen: Passt der gewünschte Kontext nicht, bricht Ollama nicht ab, sondern verschiebt Schichten auf die CPU. Prüfen Sie das mit ollama ps in einem zweiten Terminal. In der Spalte PROCESSOR muss 100% GPU stehen; etwas wie 20%/80% CPU/GPU bedeutet, dass die Geschwindigkeit gerade auf ein Fünftel bis ein Zehntel gefallen ist. Abhilfe schafft ein kürzerer Kontext oder eine größere Karte. Mit dem 8-Bit-Cache von oben passen auf eine 48-GB-Karte auch 16.000 Tokens Kontext.
llama.cpp gibt Ihnen mehr Kontrolle: genaue Quantisierungsdateien, Cache-Typen, die Aufteilung der Schichten auf zwei Karten. Es muss zuerst mit CUDA kompiliert werden; die Build-Schritte stehen im Vergleich der Laufzeitumgebungen. Danach:
pip install -U huggingface_hub
hf download bartowski/Llama-3.3-70B-Instruct-GGUF Llama-3.3-70B-Instruct-Q4_K_M.gguf --local-dir /workspace/models
./build/bin/llama-server -m /workspace/models/Llama-3.3-70B-Instruct-Q4_K_M.gguf \
-ngl 99 -c 16384 --flash-attn on -ctk q8_0 -ctv q8_0 \
--host 127.0.0.1 --port 8081
-ngl 99 legt alle Schichten auf die GPU. Port 8080 belegt auf unseren Servern Jupyter, nehmen Sie also einen anderen und öffnen Sie ihn über einen SSH-Tunnel: ssh -p <port> -L 8081:localhost:8081 root@<address>, mit Port und Adresse aus der Serverkarte. Unter http://localhost:8081 finden Sie dann die eingebaute Chatseite von llama.cpp. Wie Sie den Schlüssel einrichten, erklärt die Anleitung zum SSH-Schlüssel. Auf zwei Karten verteilt llama.cpp die Schichten von selbst.
vLLM: eine API für mehrere Nutzer
vLLM ist die Wahl, wenn andere Programme oder andere Menschen Anfragen schicken, denn es bündelt sie, und sein Gesamtdurchsatz wächst mit der Zahl paralleler Anfragen. Auf unserem vLLM-Server ist vLLM bereits installiert und Port 8000 freigegeben. Er startet von selbst ein kleines Qwen-7B-Modell; stoppen Sie das zuerst und starten Sie dann das 70B-Modell:
pkill -f "vllm serve"
# 48-GB-Karte: 4-Bit-AWQ, kurzer Kontext
vllm serve casperhansen/llama-3.3-70b-instruct-awq \
--max-model-len 8192 --gpu-memory-utilization 0.95 --max-num-seqs 8 \
--host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &
# H100 mit 80 GB: FP8, Qualität nah am Original
vllm serve RedHatAI/Llama-3.3-70B-Instruct-FP8-dynamic \
--max-model-len 16384 --gpu-memory-utilization 0.95 \
--host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &
# zwei 24-GB-Karten in einer Maschine: jede Schicht auf beide verteilen
vllm serve casperhansen/llama-3.3-70b-instruct-awq \
--tensor-parallel-size 2 --max-model-len 8192 --gpu-memory-utilization 0.95 \
--host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &
Nach dem Download dauert das Laden mehrere Minuten; tail -f /workspace/vllm.log zeigt den Fortschritt. vLLM prüft beim Start, ob mindestens eine Anfrage mit --max-model-len passt, und startet nicht, wenn das nicht der Fall ist. Die Meldung nennt dann den größten Kontext, der passen würde. Senken Sie den Wert oder ergänzen Sie --kv-cache-dtype fp8, was auf Ada-, Hopper- und Blackwell-Karten den Platz verdoppelt. Der FP8-Build auf einer H100 ist der knappe Fall: Seine Gewichte belegen etwa 72 GB, die 16.000 Tokens von oben brauchen also die Einstellung 0,95, und längere Kontexte brauchen den fp8-Cache oder eine größere Karte. Behalten Sie --api-key: Die API-Adresse ist von überall erreichbar, und ohne Schlüssel kann jeder, der sie findet, Ihre GPU nutzen. Unser vLLM-Server nutzt eine feste vLLM-Version, die zum CUDA-Treiber der Maschinen passt. Wenn Sie auf einem leeren Server eine neuere installieren, prüfen Sie vorher die CUDA-Version, die vor dem Start angezeigt wird.
Wie schnell: Tokens pro Sekunde nach Karte
Für einen Nutzer bedeutet jedes neue Token, dass das ganze Modell einmal aus dem Speicher gelesen wird. Die Geschwindigkeit ist also ungefähr die Speicherbandbreite geteilt durch die Modellgröße, abzüglich Overhead. Die Werte sind Ausgabe-Tokens für eine einzelne Unterhaltung, abgeleitet aus der Bandbreite und öffentlichen Berichten aus der Community, keine eigenen Benchmarks:
| Karte | VRAM | Bandbreite | 4 Bit (Q4_K_M, AWQ) | FP8 |
|---|---|---|---|---|
| RTX A6000 | 48 GB | 768 GB/s | 12–16 Tokens/s | passt nicht |
| L40S | 48 GB | 864 GB/s | 13–18 | passt nicht |
| 2 × RTX 3090 | 2 × 24 GB | je 936 GB/s | 14–18 (Aufteilung nach Schichten), 18–25 (vLLM, Tensor-Parallelität) | passt nicht |
| RTX PRO 6000 | 96 GB | 1.792 GB/s | 25–35 | 15–22 |
| A100 80 GB | 80 GB | 2.039 GB/s | 25–35 | kein Tempogewinn, nehmen Sie 4 Bit |
| H100 | 80 GB | 3.350 GB/s | 35–50 | 25–38 |
| H200 | 141 GB | 4.800 GB/s | 45–65 | 35–55 |
Menschen lesen etwa 5–8 Tokens pro Sekunde, selbst die langsamste Zeile wirkt im Chat also flüssig. In der Praxis zählen zwei weitere Zahlen. Das Einlesen des Prompts geht viel schneller als das Schreiben der Antwort, je nach Karte Hunderte bis einige Tausend Tokens pro Sekunde; bei einem Dokument mit 10 Seiten vergehen also einige Sekunden bis eine halbe Minute bis zum ersten Wort. Und bei vielen parallelen Anfragen wächst die gesamte Ausgabe von vLLM auf einer H100 auf mehrere Hundert bis über tausend Tokens pro Sekunde. Der Artikel zu den Kosten pro Million Tokens rechnet diese gebündelten Raten in Euro um.
Was ein erster Abend kostet und wann ein kleineres Modell reicht
Zuerst kommt der Download: etwa 40–43 GB für einen 4-Bit-Build und etwa 72 GB für FP8. Das ist abgerechneter Traffic zum GB-Tarif der Maschine, der vor dem Start angezeigt wird, plus die Minuten, die er dauert: von unter zehn Minuten auf einer schnellen Leitung bis zu einer halben Stunde auf einer langsameren. Zwei Stunden mit Ollama auf einer L40S kosten 2,12 € GPU-Zeit, zwei Stunden FP8 auf einer H100 7,80 €. Die Preise sind live, und der Minutenpreis steht beim Start fest.
Wenn Sie öfter wiederkommen, können Sie das Modell im gespeicherten Ordner behalten: 43 GB kosten 43 × 0,03 € pro Monat. Auch das Wiederherstellen auf dem nächsten Server ist Traffic; vergleichen Sie das also mit einem erneuten Download. Der Artikel zu den Dateien nach einem Stopp rechnet beides durch.
Bevor Sie sich auf 70B festlegen, probieren Sie ein 32B-Modell auf einer 24-GB-Karte. Qwen3 32B in 4 Bit passt auf eine RTX 4090 für 0,59 € pro Stunde, antwortet etwa doppelt so schnell, und bei vielen alltäglichen Chat- und Schreibaufgaben ist der Unterschied zu einem 70B-Modell klein. Schicken Sie in einer Sitzung dieselben fünf echten Prompts durch beide; das 70B-Modell ist seine größere Karte wert, wenn das 32B-Modell Ihre Fakten oder Ihre Anweisungen falsch umsetzt. Die Llama-Modellseite zeigt den Speicherbedarf jeder Größe.