llama-cpp-turboquant-guide / WHITEPAPER.de.md
AI Engineering Lab
Initial release: TurboQuant practical guide for consumer hardware
87efc66
# TurboQuant auf Consumer-Hardware
## 100.000 Token Context auf einer RTX 3090 — Schritt für Schritt
> AI Engineering Lab | April 2026
> Getestet auf: NVIDIA RTX 3090 (24 GB VRAM), Windows + Docker Desktop
> Modell: Mistral-Small-3.2-24B-Instruct-2506-Q4_K_M
---
## Executive Summary
TurboQuant ist eine KV-Cache-Quantisierungsmethode aus dem Paper
"TurboQuant: Ultra-Low-Bit KV-Cache Quantization for LLMs" (ICLR 2026, arXiv:2504.19874).
**Das Ergebnis in einer Zeile:**
Mit TurboQuant turbo3 (3-bit KV-Cache) erreichen wir auf einer RTX 3090
einen Context von **100.000 Tokens** — bei nur 8,5% Geschwindigkeitsverlust
und ohne Änderung der Modellgewichte.
| | Baseline (f16) | TurboQuant turbo3 | Delta |
|--|:---:|:---:|:---:|
| **Context** | 8.192 | **100.000** | **+12,2×** |
| **VRAM** | 15,4 GB | 17,2 GB | +1,8 GB |
| **Tokens/s** | 49,2 | 45,0 | −8,5% |
| **KV-Cache** | ~1 GB (f16) | ~2,8 GB (3-bit) | 4,3× Kompression |
---
## 1. Das Problem: Der KV-Cache frisst VRAM
Wenn ein LLM läuft, berechnet es für jeden Token Key-Value-Paare (KV).
Diese werden im VRAM gecacht, damit spätere Tokens darauf zugreifen können.
Das Problem: Der KV-Cache **wächst linear mit der Kontextlänge**.
Für Mistral-Small-3.2 24B auf einer RTX 3090 (24 GB, davon ~14,4 GB für Modellgewichte):
```
Context KV-Cache (f16) Verfügbar nach Modell Passt?
8.192 ~1 GB 9,6 GB ✅
32.000 ~4 GB 9,6 GB ✅
100.000 ~12 GB 9,6 GB ❌ OOM
100.000 ~2,8 GB (turbo3) 9,6 GB ✅
```
100K Context ist ohne Optimierung auf einer 24-GB-GPU schlicht nicht möglich.
---
## 2. Was TurboQuant macht
TurboQuant komprimiert den KV-Cache von 16-bit auf 2–4-bit.
**NICHT die Modellgewichte** — nur den Laufzeit-Cache.
```
f16 KV-Cache (16 bit) → turbo3 KV-Cache (3 bit) = 4,3× weniger Speicher
```
Das Modell liest den quantisierten Cache und generiert Text ganz normal.
Qualitätsverlust: laut Paper <1% Perplexity-Anstieg bei turbo3.
---
## 3. Das Ecosystem — Zwei Repos, ein häufiger Fehler
Es gibt zwei TurboQuant-Repositories mit verwirrenden Namen:
| Repo | Was es ist | Wann benutzen |
|------|-----------|--------------|
| `TheTom/turboquant_plus` | Python-Bibliothek | HuggingFace-Modelle, Forschung |
| `TheTom/llama-cpp-turboquant` | llama.cpp-Fork | **Dieser Guide — llama-server** |
**Dieser Guide verwendet `TheTom/llama-cpp-turboquant`, Branch `feature/turboquant-kv-cache`.**
Kritisch: Der Default-Branch `master` ist ein normales llama.cpp **ohne TurboQuant**.
Die Implementierung liegt auf `feature/turboquant-kv-cache`.
---
## 4. Setup — Schritt für Schritt
### 4.1 Branch verifizieren (vor dem Build!)
```bash
curl -s "https://api.github.com/repos/TheTom/llama-cpp-turboquant/branches" \
| python3 -c "import sys,json; [print(b['name']) for b in json.load(sys.stdin)]"
# Erwartet: feature/turboquant-kv-cache, master
```
### 4.2 Docker Image bauen (~20 Minuten)
```bash
docker build -t turboquant:feature .
# Verifizieren: turbo2, turbo3, turbo4 müssen erscheinen
docker run --rm turboquant:feature llama-server -h 2>&1 | grep -A3 "cache-type-k"
```
### 4.3 Modell herunterladen (~14 GB)
```bash
export HF_TOKEN=hf_dein_token
bash scripts/download-model.sh
```
### 4.4 Baseline starten (Referenzwert)
```bash
bash scripts/run-baseline.sh
# → Port 8180, f16 KV-Cache, 8192 Context
```
### 4.5 TurboQuant starten
```bash
bash scripts/run-turbo.sh
# → Port 8182, turbo3 KV-Cache, 100.000 Context
```
---
## 5. Fehler-Protokoll
Alle 5 Fehler aus unserem Setup — damit du sie nicht wiederholst:
### Fehler 1: Falsches Repository
**Symptom:** Kein `turbo2`/`turbo3`/`turbo4` nach dem Build.
**Ursache:** `TheTom/turboquant_plus` (Python-Bibliothek) statt `TheTom/llama-cpp-turboquant` gebaut.
**Fix:** Richtiges Repo verwenden — siehe Dockerfile.
### Fehler 2: Falsches cmake-Flag
**Symptom:** Kein CUDA, CPU-Fallback.
**Ursache:** `-DLLAMA_CUBLAS=ON` wurde umbenannt.
**Fix:** `-DGGML_CUDA=ON` (modernes llama.cpp, post-GGML-Refactor).
### Fehler 3: libcuda.so.1 fehlt beim Build
**Symptom:** Linker-Fehler beim cmake-Build.
**Ursache:** Docker-Build-Time hat keinen NVIDIA-Treiber — nur ein Stub ohne `.1`-Suffix.
**Fix:** Symlink VOR cmake setzen (siehe Dockerfile).
### Fehler 4: Falscher Branch
**Symptom:** `Unsupported cache type: turbo3` zur Laufzeit.
**Ursache:** Master-Branch geklont (standard llama.cpp, kein TurboQuant).
**Fix:** `git clone --branch feature/turboquant-kv-cache`
### Fehler 5: Falscher HuggingFace-Repo-Name
**Symptom:** 404 beim Modell-Download.
**Ursache:** Repo-Namen aus dem Gedächtnis rekonstruiert — falsch.
**Fix:** Immer live via HF Search API verifizieren (nie aus dem Kontext nehmen).
---
## 6. Benchmark-Methodik
Jede Messung:
1. VRAM messen nach Server-Start (nvidia-smi)
2. 3× curl an `/v1/chat/completions` mit "Count from 1 to 200"
3. Durchschnitt aus 3 Läufen
4. Container stoppen, 30s warten, nächste Messung
TPS-Berechnung: `completion_tokens / (total_duration_ms / 1000)`
---
## 7. Produktions-Checkliste
Bevor du TurboQuant in Produktion einsetzt:
- [ ] Image gebaut von `feature/turboquant-kv-cache` (NICHT master)
- [ ] Verifiziert: `llama-server -h | grep turbo` zeigt turbo2, turbo3, turbo4
- [ ] VRAM-Budget berechnet: Modell + KV-Cache + Overhead ≤ GPU-VRAM
- [ ] Port-Konflikte geprüft (kein anderer Service auf dem Port)
- [ ] Startup-Zeit eingeplant: 100K Context braucht ~90s Startzeit
- [ ] Qualität getestet: Stichproben-Outputs mit turbo3 vs f16 verglichen
- [ ] Modell-Download via HF Search API verifiziert (nicht aus Erinnerung)
---
## 8. Rohdaten
Alle Benchmark-Rohdaten: [`results/turboquant-rtx3090-2026-04-01.json`](results/turboquant-rtx3090-2026-04-01.json)
---
*AI Engineering Lab · April 2026 · [ai-engineering.at](https://ai-engineering.at)*
*Basierend auf TurboQuant (arXiv:2504.19874) von Thomas et al. (ICLR 2026)*