Technologien · Künstliche Intelligenz
Lokale LLMs auf der GPU AMD Radeon AI PRO R9700
Wir betreiben einen eigenen Server mit einem Sprachmodell, der auf einer GPU am Firmensitz läuft. Wir optimieren ihn für die Arbeit mit Claude Code und KI-Agenten — Quellcode und Daten verlassen dabei unsere Infrastruktur nicht.
Warum ein lokales Modell
Bei der Anforderungsanalyse, beim Entwurf und bei der Umsetzung unserer Systeme setzen wir Claude Code ein. Damit weder Quellcode noch Daten das Unternehmen verlassen, binden wir es an einen eigenen LLM-Server llama.cpp in unserer Infrastruktur an — der Server bietet eine zur Anthropic API kompatible Schnittstelle, sodass Claude Code mit ihm genauso arbeitet wie mit einem Cloud-Modell. Das Modell, mit dem Claude Code arbeitet, wechseln wir einfach per Startskript.
Derselbe Server bedient auch autonome KI-Agenten (Hermes Agent) in unserem internen Netz.
- Vertraulichkeit — Quellcode und Daten bleiben im Unternehmen
- Kosten — keine Gebühren für verarbeitete Tokens
- Unabhängigkeit — Betrieb unabhängig von der Verfügbarkeit der Cloud
- Kontrolle — die gesamte Kette können wir messen, optimieren und korrigieren
Hardware und Software
Eine Workstation, eine Grafikkarte.
GPU
AMD Radeon AI PRO R9700 — RDNA4-Architektur, 32 GB VRAM.
Betriebssystem und Runtime
Windows 11 Pro, AMD ROCm 10 (HIP) — ohne Linux und WSL.
llama.cpp
Fork stew675 „llama-cpp-rdna-boosts“ mit Optimierungen für RDNA-GPUs, ergänzt um unsere eigenen Anpassungen auf Basis der aktuellen llama.cpp-Version.
Eigener Build
Unser Repository und der CI-Build für ROCm unter Windows auf GitHub — jede neue Version durchläuft Leistungsmessungen und eine Prüfung auf identische Ausgaben.
Eingesetzte Modelle
Produktivmodell: Qwen3.8-27B
- Quantisierung Unsloth UD-Q5_K_XL (ca. 21 GB)
- hybride Architektur SSM + Attention, Unterstützung für Bilder und Reasoning
- Kontext 262 144 Tokens — das Maximum des Modells — in zwei parallelen Slots
- KV-Cache quantisiert auf q8_0
- spekulatives Dekodieren MTP (Multi-Token Prediction)
Alternative und frühere Modelle
- Swift-1.5-Qwen3.8-27B (Q5_K_M, Q6_K_S)
- Qwen3.6-35B-A3B (Mixture of Experts), Qwen3.6-27B
Unsere aktuellen Ergebnisse
Stand Oktober 2026, gemessen an realen Prompts unserer Agenten.
| Zeitraum | Änderung | Prompt-Verarbeitung | Generierung |
|---|---|---|---|
| August 2026 | Umstieg auf ROCm und Portierung der rdna-boosts-Optimierungen | 312 → 574 t/s (+84 %) | — |
| September 2026 | WMMA-Kernel für Flash Attention auf RDNA4 | 660 → 752 t/s (+14 %) | −12,5 % Zeit pro Token |
| September 2026 | weitere Anpassungen der Dekodierung | 743 t/s | −5,4 % Zeit pro Token |
| Oktober 2026 | Qwen3.8-27B V2, MTP, Kontext 262k | 780–835 t/s | 45–47 t/s |
Zu Beginn (August 2026, Vulkan-Backend, Modell Qwen3.6-27B) erreichten wir ca. 530 t/s bei der Prompt-Verarbeitung und 21 t/s bei der Generierung. Die Werte der einzelnen Zeilen sind nicht streng vergleichbar — zwischenzeitlich haben sich Modell, Quantisierung und Dekodierverfahren geändert.
Qualität bei quantisiertem KV-Cache
Bei einem Kontext von 126k Tokens mit KV-Cache q8_0 fand das Modell alle 120 von 120 Testfakten korrekt, und seine Ausgabe war Token für Token identisch mit der Ausgabe bei voller Genauigkeit — bei deutlich geringerem VRAM-Bedarf.
Was geholfen hat und was nicht
Jede Änderung messen wir an realen Aufgaben und setzen nur ein, was sich bewährt.
Geholfen
- Portierung der rdna-boosts-Optimierungen (+84 % bei der Prompt-Verarbeitung)
- Überspringen maskierter Blöcke in Flash Attention (+8 bis 24 %)
- WMMA-Kernel für RDNA4
- KV-Cache q8_0 (ca. 2 GB weniger VRAM)
- einmalige Allokation des Hilfspuffers für Flash Attention — unsere Anpassung, +73k Tokens Kontext
- spekulatives Dekodieren MTP (+56 % bei der Generierung)
- Korrekturen am Prompt-Cache — Rückkehr zu einer Konversation in 1,2 s statt 41 s
Nicht geholfen
- größerer Micro-Batch — VRAM-Überlauf
- HIP Graphs — kein Gewinn, instabil bei langen Prompts
- nativer bf16-Prefill — 47 % langsamer
- Bibliothek hipBLASLt — nichtdeterministische Kernel-Auswahl, daher deaktiviert
Erkenntnisse aus dem Betrieb
- nach langer Laufzeit des Servers sind VRAM-Messungen unzuverlässig — vor Messungen starten wir neu
- der Treiber Adrenalin 26.7 war instabil, wir verwenden den OEM-Treiberzweig
- die meisten erneuten Prompt-Verarbeitungen gehen vom Client aus, nicht vom Server
Interesse am Einsatz lokaler LLMs?
Wir teilen gerne unsere Erfahrungen mit dem Betrieb von Sprachmodellen auf eigener Hardware.