Ich überlege auf meinem KI Server mit 2x RX 6800 XT und 64 GB DDR5 ein KI Modell laufen zu lassen. Bisher hatte ich vor mir llama.cpp ein Qwen 3.8 27B auszuführen.
Allerdings bleibt die Entwicklung nicht stehen und ich lese immer mehr davon, dass Qwen 3.8 Flash Next deutlich besser sein soll und mit modernen Techniken auch auf moderater Hardware gut laufen soll (Stichworte wie strata, ngram)
Kannst du hier die neusten Trends untersuchen z.B. in Reddit Gruppen wie localllama, localllm usw und mir eine Empfehlung geben, an welchen Stellen es spannende neue Entwicklungen gibt die ich nicht verpassen sollte um die maximale Leistung aus meiner Hardware heraus zu holen?
Ich möchte damit harnesses wie OpenWebUI, Opencode usw. betreiben und auch meinen Freunden zur Verfügung stellen.

---

Ich recherchiere das für dich – aktuelle Entwicklungen rund um Qwen3-Next/Strata/Ngram, llama.cpp auf RDNA2 und die Local-LLM-Szene. Zuerst richte ich die passenden Suchwerkzeuge ein.Die Tools sind bereit. Jetzt starte ich die erste Recherche-Welle: News zu aktuellen Modell-Releases und Websuche zu den von dir genannten Stichworten (Strata, Ngram, Qwen3-Next) sowie zur Reddit-Szene.Die erste Welle lieferte schon Hinweise (u.a. Qwen3.8-Max, Qwen 3.6 27B als lokaler Geheimtipp). Ich werte jetzt die restlichen Ergebnisse im Detail aus.Die News-Suche war großteils Rauschen – ich extrahiere jetzt die relevanten Web-Ergebnisse zu Reddit, Strata, Ngram und Modell-Empfehlungen.Gute Treffer: llama.cpp unterstützt n-gram Speculative Decoding. Jetzt gezielter: Was steckt hinter „Qwen 3.8 Flash Next", dem Strata-Papier, und wie läuft llama.cpp auf RDNA2-Karten (RX 6800 XT)?Sehr ergiebig! Qwen3.8-Flash-Next (125B MoE, 6B aktiv, Qwen Sparse Attention + Gated DeltaNet + N-gram-Embedding) existiert tatsächlich. Jetzt prüfe ich die restlichen Suchergebnisse zu Strata, Reddit und RDNA2.Das Bild wird klar. Jetzt vertiefe ich: die offizielle Flash-Next-Ankündigung, konkrete Hardware-Messungen (u.a. auf 16-GB-Radea-Karten), die Einordnung von „Strata" und Multi-GPU auf RDNA2.Die Faktenlage zu Flash-Next ist exzellent dokumentiert. Noch eine letzte Welle: das „Strata"-Papier (in der Local-LLM-Szene oft im Kontext KV-Cache genannt), Vulkan-Support der neuen Architekturen und die Reddit-Meinung zu Qwen3.8-27B.Die Recherche ist abgeschlossen und sehr ergiebig. Jetzt lade ich die Canvas-Anleitung und erstelle daraus den Research-Report.
# Lokale KI Ende 2026: Trends, Modelle und Empfehlungen für deinen Server (2× RX 6800 XT, 64 GB DDR5)

## Die Frage

Marcel plant, auf seinem Server (2× AMD RX 6800 XT = 32 GB VRAM, 64 GB DDR5-RAM) mit llama.cpp lokale KI-Modelle für sich und Freunde zu betreiben – angehängt an Open WebUI, OpenCode u. ä. Geplant war Qwen 3.8 27B. Geprüft werden soll: Welche aktuellen Trends (Qwen3.8-Flash-Next, „Strata", n-gram, moderne Inferenz-Techniken, r/LocalLLaMA-Szene) darf er nicht verpassen, und welches Setup holt die maximale Leistung aus dieser Hardware?

## Kurzfazit (Executive Summary)

1. **Dein Plan (llama.cpp + Qwen3.8-27B) ist genau richtig.** Das am 14./17. August 2026 erschienene Qwen3.8-27B (dicht, multimodal, Apache 2.0, 262K Kontext) ist der Community-Konsens-Favorit für Karten bis 24 GB – und läuft auf AMD ab Tag 0 offiziell unterstützt. Es passt komplett in deine 2×16 GB VRAM, mit riesigem Luftnachlauf für den Kontext.
2. **Qwen3.8-Flash-Next ist der echte Hype – aber nicht für dein RAM-Budget.** Die Architektur-Vorschau auf Qwen4 (125B-MoE mit 6B aktiv + 51B N-gram-Tabelle + MTP-Kopf) schlägt das 27B auf nahezu allen Benchmarks, braucht aber realistisch 46–55 GB *schnellen* Speicher (mindestens 64-GB-Klasse, ideal 96–128 GB unified). Mit 96 GB Gesamtsumme (32 VRAM + 64 RAM) ist es ein grenzwertiges Experiment (10–20 t/s, Single-User), kein Serving-Modell für mehrere Freunde.
3. **Die Technik, die du nicht verpassen darfst, heißt MTP + n-gram Speculative Decoding.** Die mitgelieferten Multi-Token-Prediction-Köpfe plus n-gram-Drafting bringen in llama.cpp messbar +40–75 % Tokenrate – auf einer 16-GB-Radeon-Karte von 27,5 auf 42 t/s, auf Strix Halo +67 %.
4. **„Strata" ist ein Serving-Trend, kein lokales llama.cpp-Feature.** Das OSI-vielbeachtete Strata (NVIDIA, OSDI 2026) ist hierarchisches Kontext-Caching für lange Kontexte in Serving-Stacks (SGLang-basiert, bis 5× schnellere Time-to-First-Token). Für dich relevant als Blickrichtung, wenn dein Freundes-Hosting wächst; llama.cpp-Seitenäquivalent sind Prompt-/Kontext-Checkpoints.
5. **Auf RDNA2 (gfx1030) ist Vulkan 2026 der Pragmatik-Pfad**, mit ROCm als Alternative (HSA-Override). Die heißen Community-Forks und FP4-Formate zielen auf RDNA3/3.5/4 – für deine Karten: stock llama.cpp, beide Backends messen, Flash Attention + KV-Quantisierung aktivieren.
6. **Speed-Alternative für viele gleichzeitige Nutzer:** Qwen3.6-35B-A3B (MoE, 3B aktiv) liefert auf AMD-Karten extreme Tokenraten (MoE liebt Speicherbandbreite) – schwächer als 27B beim Coding, aber ideal für Chat-Workloads mit Freunden.

## Methodik

- **Suchwinkel:** (1) Aktuelle Qwen3.8-Modellfamilie und offizielle Release-Quellen (Alibaba/Qwen, Hugging Face, AMD); (2) r/LocalLLaMA- und r/LocalLLM-Konsens (Community-Benchmarks, Erfahrungsthreads, Speech-Synthesen); (3) llama.cpp-Stand zu neuen Architekturen (Qwen Sparse Attention, Gated DeltaNet, qwen4exp), Speculative Decoding, Multi-GPU; (4) AMD/RDNA2-Backends (ROCm vs. Vulkan, Stand 2026); (5) „Strata"-Begriffsklärung (Fachliteratur vs. Community-Nutzung).
- **Quellentypen:** Offizielle Modellkarten und Hersteller-Blogs, gemessene Benchmarks einzelner Betreiber (16-GB-Radeon, Strix Halo, RTX 3090, Mac), llama.cpp-Dokumentation und -Forks, arXiv/OSDI-Paper, Reddit-Synthesen.
- **Limitierungen:** t/s-Zahlen sind Einzelmessungen unterschiedlicher Harnesses und Quants – Richtwerte, keine Garantien. Flash-Next-Benchmarks stammen überwiegend aus Qwens eigener Launch-Tabelle. Manche Community-Forks (RDNA3-Fokus) sind nicht auf RDNA2 validiert. „Strata" wird in der Szene mehrdeutig verwendet; ich ordne es der belegten OSDI-2026-Arbeit zu.

## Ergebnisse

### 1. Die Qwen3.8-Familie im Überblick (Aug.–Sep. 2026)

| Modell | Größe | Offen? | Relevanz für dich |
|---|---|---|---|
| Qwen3.8-Max (API) | 2.4T MoE | nein (API) | keiner – Rechenzentrum |
| Qwen3.8-2.4T-A95B | 2.4T / 95B aktiv | ja (12. Aug. 2026) | erster offener Max-Klasse-Checkpoint, aber datacenter-only |
| **Qwen3.8-27B** | 27B dense, Vision | **ja, Apache 2.0 (14./17. Aug. 2026)** | ** dein Daily Driver ** |
| Qwen3.8-Flash (API) | = Flash-Next, produktivisiert (1M Kontext) | nein | nur als API |
| **Qwen3.8-Flash-Next** | 125B/6B aktiv + 51B N-gram + 4B MTP | ja (26. Aug. 2026) | Experiment/Trend; braucht ≥64 GB-Klasse |
| Qwen3.8-Omni-Flash | omni-modal | API | – |

Alibaba hat mit Qwen3.8 erstmals die Max-Klasse (2.4T) als offene Gewichte veröffentlicht und parallel das 27B-Modell als lokal lauffähiges Apache-2.0-Modell freigegeben; laut AP plant Alibaba zudem ein 5–10-Billionen-Parameter-Modell – der Open-Weight-Druck bleibt also hoch.

### 2. Qwen3.8-27B – der Sweet Spot für 16-GB-Karten (dein geplanter Schritt ist richtig)

- **Was es ist:** dichtes 27B, natives Bildverständnis (Video in lokalen Runtimes noch lückenhaft), 262.144 Token Kontext (auf 1M erweiterbar), Thinking-Modus mit einstellbarem `reasoning_effort` (xhigh/medium/low/aus). Q4-K_M ≈ 17–18 GB Download; 17,1 GB laut Quant-Übersicht.
- **AMD Day-0-Support:** AMD veröffentlichte zum Launch eine offizielle Anleitung für Radeon-Karten und Ryzen-AI-Max-Systeme.
- **Community-Urteil (r/LocalLLaMA/r/LocalLLM, ~2.000 Posts in der ersten Woche):** Konsens-„local workhorse" – beste je lokal gelaufene 27B-Klasse; Anwender berichten von unbeaufsichtigt durchgelaufenen Agenten-Jobs (NestJS+MCP-Build über 1M Tokens), zuverlässigen Tool-Calls mit MCP; Kritikpunkte: Overthinking per Default, kaum Mathe/STEM-Fortschritt, schwächer bei kreativem Schreiben und Weltwissen. Ein 16-GB-Benchmark (RX 9070 XT, ROCm) zeigt: unsloth Q4_K_M ohne MTP ≈ 17 t/s, mit MTP2 ≈ 24 t/s; AtomicChat AD-IQ4_XS-IQ3_S mit MTP2 ≈ **42 t/s bei 64K Kontext**.
- **Der wichtigste Konfigurations-Fix:** `reasoning_effort` von xhigh auf medium oder low stellen – sonst „denkt" das Modell bei einfachen Aufgaben minutenlang (Simon Willison maß 22.276 Thinking-Tokens für ein SVG). Sampling-Empfehlung Qwen: Thinking an → temp 1.0, top_p 0.95, top_k 20; Thinking aus → temp 0.7, top_p 0.80.
- **Quants:** unsloth UD-Q4_K_XL / Q4_K_M sind der Sweet Spot für 16 GB pro Karte; mit 2 Karten kannst du Q5/Q6 oder Q8-Quants + 128K-Kontext fahren.
- **Bonus-Trend:** UkisAI „Swift"-Effizienz-Finetune (-58 % Thinking-Tokens, ~2× schneller) – in der Community stark diskutiert; prüfen, ob er zu euren Use-Cases passt.

### 3. Qwen3.8-Flash-Next – der Hype ist real, aber die Speichermathematik entscheidet

- **Architektur (offizielle Ankündigung, 26. Aug. 2026):** experimentelle Vorschau der Qwen4-Architektur. MoE mit 512 Experten (10 aktiv + 1 shared), **Gated DeltaNet + Qwen Sparse Attention (QSA)** statt voller Attention, dazu ein **51B-N-gram-Embedding-Tabelle** (Lookup, ~2,7 KB Lesezugriff/Token, offloadbar auf Host-RAM/NVMe) und ein **4B-MTP-Kopf** im Checkpoint. Gesamt ≈ 180B Parameter on disk; 262K nativer Kontext; Bild/Video-Eingabe; Thinking per Default.
- **Warum die Szene dreht:** 6B aktive Parameter pro Token bei 125B-Klasse-Qualität; winziger KV-Cache (~25 KB/Token; volle 262K ≈ 6,5 GB statt ~67 GB beim dichten 27B); auf Qwens Launch-Tabelle schlägt es das 27B in allen gemeinsamen Sprach-Benchmarks (DeepSWE 58.7 vs. 42.2; Toolathlon 73.5 vs. 67.1) und liegt auf 8 von 9 Rows vor Claude Opus 4.6 Max.
- **Hardware-Anforderungen (gemessen, nicht Marketing):** AD-Q4_K_M-Build braucht **54,5 GB schnellen Speicher** (Rest pagingt von NVMe); AD-IQ4_XS 45,8 GB; unter 48 GB passt gar nichts. Referenzmessungen: 64-GB-MacBook ≈ 36 t/s; Strix Halo 128 GB ≈ 21–24 t/s ohne MTP, ≈ 35 t/s mit MTP+n-gram; 24-GB-GPU + ≥96 GB RAM funktioniert (Experten in RAM).
- **Für dein Setup (32 GB VRAM + 64 GB DDR5):** grenzwertig machbar – IQ3/IQ4-Build, N-gram-Tabelle auf NVMe (mmap anlassen), Attention-Layer + KV in VRAM, Experten geteilt VRAM/RAM. Realistische Erwartung: ~10–20 t/s, Single-User, mühsames Prefill bei langen Prompts (Strix-Halo-Daten: TTFT 94→246 s zwischen 30K und 64K). Als Experiment absolut spannend und der beste Blick in die Zukunft (Qwen4); als Multi-User-Server für Freunde eher nicht. **Aufrüst-Tipp:** Mit einem RAM-Upgrade auf 128 GB DDR5 wird Flash-Next auf deinem Board voraussichtlich richtig bequem.
- **llama.cpp-Stand:** qwen4exp-Architektur am 27. Aug. 2026 gemerged (PR #27742); Flags: `-fit off` zwingend (Auto-Fitting verkennt die Architektur), `--jinja`, mmap an lassen, Tabelle ggf. per `-ot "ple_ngram_embd=CPU"` auf Host. Aktuell ist stock llama.cpp deutlich langsamer als die Strix-Halo-tunten Forks (QSA-Indexer-Flaschenhals, PR #28012-Optimierung: +49 % pp, +16 % tg) – d.h.: Entwicklung läuft hier Woche für Woche, lohnt zu beobachten.

### 4. Die Technik-Trends, die du nicht verpassen darfst

1. **MTP (Multi-Token Prediction) Speculative Decoding** – Qwen3.8-27B und Flash-Next liefern MTP-Draft-Köpfe im GGUF mit; llama.cpp: `--spec-type draft-mtp --spec-draft-n-max 2` (27B) bzw. n3/n4-Defaults (Flash-Next). Gemessen: **+41 bis +53 %** auf Radeon 16 GB, **+67 %** auf Strix Halo (Reasoning profitiert am meisten: 20,9 → 41 t/s). MTP lohnt primär bei Einzelnutzer; bei 8 parallelen Nutzern bringt es fast nichts.
2. **N-gram Speculative Decoding / ngram-mod** – llama.cpp-Features (`--spec-type ngram`, `ngram-mod` für MoE); beim Flash-Next ist die N-gram-Idee sogar Teil der Modellarchitektur (51B-Lookup-Tabelle als „Kapazität ohne Rechnen"). Kombiniert mit MTP die derzeit stärkste lokale Beschleunigung.
3. **Hybride Attention: Gated DeltaNet + Sparse Attention (QSA)** – fixed-size-State statt wachsender KV-Caches; deshalb ist auch Qwen3.6-27B (16 von 64 Layern volle Attention) so kontexteffizient: 160K Kontext passen auf eine 24-GB-Karte. Vulkan-Backend dafür wurde im März 2026 gemerged (+30 % auf AMD-Karten gemessen).
4. **„Strata" – Begriffsklärung:** Das in der Szene zitierte Strata ist ein hierarchisches Kontext-Caching-Framework (NVIDIA/Stanford/Michigan, OSDI 2026, SGLang-basiert): KV-Caches wandern gestaffelt GPU→CPU→NVMe, GPU-gestützte I/O gegen Fragmentierung + cache-bewusster Scheduler → bis zu 5× niedrigere Time-to-First-Token bei Langkontext-Serving. Relevant, wenn du später viele Nutzer mit langen, geteilten Kontexten hast; für llama.cpp heute nicht verfügbar – dort sind **Prompt-Caching/Kontext-Checkpoints** (`--ctx-checkpoints`) und Cache-Reuse das verwandte Feature.
5. **KV-Cache-Quantisierung + Flash Attention** – `--cache-type-k/v q8_0` (≈2× Platz, praktisch verlustfrei) oder q4_0 (~4×, mit Hadamard-Rotation gegen Quantisierungsfehler); `-fa on`. Pflicht-Flags für dein Setup.
6. **Dynamische Quants** – Unsloth UD- und AtomicChat AD-Serien (Mixed-Precision pro Tensortyp; beim Flash-Next: getrennte N-gram-Shards, damit die Tabelle auf SSD pagen kann). Messbar besser als Standard-Quants bei gleichem Platz.
7. **KV-Cache-Forschung (Blickrichtung):** KV-Compress, „Thin Keys, Full Values", „The Residual Stream Is All You Need" (KV-Cache komplett weg, 100 % Token-Identität in Tests) – das akademische Umfeld hinter Flash-Next & Co. Wer die Szene vorhersagen will, liest hier mit.

### 5. llama.cpp auf 2× RX 6800 XT (RDNA2, gfx1030) – Stand Ende 2026

- **Backend-Wahl:** Vulkan ist 2026 der Pragmatik-Pfad auf AMD (funktioniert mit Mesa/RADV praktisch überall, 70–80 % des ROCm-Durchsatzes bei dichten Modellen; auf Strix Halo laufen die Referenz-Setups inzwischen sogar über Vulkan). ROCm/HIP auf RX 6800 geht über `HSA_OVERRIDE_GFX1030=1` (Anleitungen für RX 6800 vorhanden); bei MoE-Modellen ist die Backend-Wahl oft egal – dort zählt reine Speicherbandbreite (512 GB/s pro Karte), weshalb eine RX 6800 mit einem MoE-Modell in Vulkan-Benchmarks auf >120 t/s kam, während das dense 14B-Modell „nur" 24 t/s erreichte. **Empfehlung: beide Backends bauen, mit `llama-bench` gegenmessen.**
- **Wo die Community-Fortschritte liegen (Vorsicht bei Erwartungen):** Die heißen Forks (llama.cpp-rdna mit ROCmFPX/FP4-Formaten, Strix-Halo-Builds mit QSA-Fixes, coopmat-MMQ-Patches) zielen auf RDNA3/3.5/4 – auf gfx1030 ist teils unklar, was anschlägt. Stock llama.cpp (Vulkan/ROCm) ist deine solide Basis.
- **Multi-GPU:** Standard ist `--split-mode layer` (default, Pipes über PCIe, unkritisch bei zwei gleichen Karten); `-ts 16,16` explizit; `-mg 0` für die Hauptkarte (KV-Cache); `--split-mode tensor` braucht Flash Attention und ist auf Consumer-Rigs meist nicht besser. Faustregel: passt das Modell auf eine Karte, ist Single-GPU schneller – mit dem 27B auf 2 Karten kaufst du dir Kontext- und KV-Platz, nicht 2× Geschwindigkeit.
- **Realistische Erwartungswerte für dein System (Schätzungen aus gemessenen Nachbar-Hardwares):** Qwen3.8-27B (UD-Q4_K_XL, volle Offloads, KV q8_0): ca. 20–30 t/s decode ohne MTP, ~30–45 t/s mit MTP2, 64–128K Kontext. Qwen3.6-35B-A3B: deutlich höher, Richtung 60–100+ t/s. Flash-Next IQ3/IQ4-Experiment: ~10–20 t/s.

### 6. Serving für Freunde: Open WebUI + OpenCode + Mehrnutzer

- **llama-server** stellt die OpenAI-kompatible API bereit; Open WebUI, OpenCode, Claude Code (via Ollama-Launcher), Cline, Pi etc. docken alle daran an. Für OpenCode genügt ein Eintrag mit `@ai-sdk/openai-compatible`.
- **Continuous Batching/Slots:** `--parallel N` (z. B. 4–8 Slots) + Kontext pro Slot; Strix-Halo-Messung mit Flash-Next zeigt: 1 Nutzer 20,4 t/s → 8 Nutzer 50,4 t/s aggregiert (2,5× Throughput), TTFT 2,7 s – ein gut konfigurierter llama-server skaliert also erstaunlich gut. **Wichtig: MTP nur für den 1-Nutzer-Betrieb aktiv lassen; bei Parallelbetrieb eher aus.**
- **Multi-User-Check:** Der 8-Slot-Test (Code-Wörter pro Nutzer) lief mit dem #25992-Patch ohne Slot-Verwechslungen – halte llama.cpp aktuell und prüfe Parallel-Verhalten nach Updates.
- **Betriebshinweise:** RAM-Rechnung mit ~13 GB mmap des Modell-Files einplanen (nicht beunruhigend, nur Page-Mapping); `--ctx-checkpoints` sparen bei Hybrid-Modellen Resident-Footprint; für Remote-Zugriff der Freunde: Reverse Proxy mit Auth/VPN statt offenem Port.

## Konkrete Empfehlung (Setup-Fahrplan)

1. **Sofort aufbauen (Wochenend-Projekt):** llama.cpp (master, Vulkan- und ROCm-Build) + **Qwen3.8-27B als unsloth UD-Q4_K_XL (oder Q5, da du 32 GB hast)**; volle Layer-Offloads auf beide Karten, `-fa on`, KV q8_0, `--jinja -fit off`, `--parallel 4`, `reasoning_effort` auf medium/low, temp 1.0/top_p 0.95/top_k 20. → Open WebUI + OpenCode dran; Freunde einladen. MTP2 (`--spec-type draft-mtp --spec-draft-n-max 2`) für Einzelplatz aktivieren, für Parallelbetrieb testen.
2. **Speed-Betrieb für viele gleichzeitige Chatter:** zweites Profil mit **Qwen3.6-35B-A3B** (MoE) – auf deinen Karten sehr schnell, ideal für den Open-WebUI-Alltag von Freunden; schweres Coding bleibt beim 27B.
3. **Experiment (Wochenend-Play):** **Qwen3.8-Flash-Next** als unsloth UD-IQ3_XXS/IQ4_XS mit N-gram-Tabelle auf NVMe (mmap an!), `-fit off --jinja`, Attention+KV in VRAM, Experten geteilt VRAM/RAM. Erwartung: 10–20 t/s Single-User – als Vorgeschmack auf Qwen4. Erst mit RAM auf 128 GB wird das ein echter Server-Betrieb.
4. **Beobachten (nicht verpassen):** (a) **Qwen4** – Flash-Next ist die offizielle Architektur-Vorschau; die ersten Qwen4-Modelle dürften deine Upgrade-Planung dominieren. (b) **Qwen3.8-35B-A3B-MoE** – in ms-swift-Commits gesichtet, aber noch nicht ausgeliefert (Stand Sep./Okt. 2026): wenn es kommt, ist es dein Slot-2-Modell. (c) **llama.cpp-QSA-Optimierungen** (PR #28012-Nachfolge) – Flash-Next auf Consumer-Hardware wird von Monat zu Monat schneller. (d) **Strata-artiges Serving** (SGLang/Hierarchien), falls dein Hosting wächst. (e) **Effizienz-Finetunes** wie UkisAI Swift für 27B.

## Quellenverzeichnis

| Quelle | Glaubwürdigkeit | Letztes Update |
|---|---|---|
| [Qwen3.8-Flash-Next – offizielle Ankündigung (Alibaba Cloud)](https://www.alibabacloud.com/blog/qwen3-8-flash-next-a-new-architecture-towardsultimate-cost-efficiency_603501) | 5/5 | 27.08.2026 |
| [Qwen/Qwen3.8-Flash-Next – Hugging Face Modellkarte](https://huggingface.co/Qwen/Qwen3.8-Flash-Next) | 5/5 | Aug. 2026 |
| [Alibaba: Qwen3.8-27B + Open Weights der Flaggschiff-Modelle](https://www.alibabacloud.com/blog/603463) | 5/5 | 17.08.2026 |
| [AMD: Day-0-Support für Qwen3.8-27B auf Radeon/Ryzen AI Max](https://www.amd.com/en/blogs/2026/run-qwen-3-8-27b-on-amd-ryzen-ai-max-and-radeon-graphics-cards-day-0.html) | 5/5 | 14.08.2026 |
| [AP: Alibaba stellt Qwen3.8-Max (2.4T) und Chip-Pläne vor](https://apnews.com/article/alibaba-ai-chip-qwen-zhenwu-china-us-b29908e516faff9f5a82b201ba954aab) | 5/5 | 22.09.2026 |
| [AtomicChat-Guide: Qwen3.8 Flash Next lokal (Architektur, Quants, Messungen 36 t/s)](https://atomic.chat/blog/guides/how-to-run-qwen-3-8-flash-next-locally) | 4/5 | 26.08.2026 |
| [kksoftwareag: Flash-Next auf Strix Halo – MTP/n-gram- und Multi-User-Messungen](https://kksoftwareag.github.io/strix-halo-qwen-3.8-flash-next/measurements.html) | 4/5 | 16.09.2026 |
| [ataadevs: Qwen3.8-27B auf 16-GB-Radeon (ROCm), MTP2-Benchmarks 17→42 t/s](https://ataadevs.net/blog/qwen-3-8-27b-llamacpp-benchmarks.html) | 4/5 | 17.08.2026 |
| [RunAIHome: Flash-Next-Hardware-Guide (180B/6B aktiv, 75-GB-Floor, Strix-Halo-Zahlen)](https://www.runaihome.com/blog/qwen38-flash-next-local-ai-hardware-guide-2026/) | 3/5 | 02.09.2026 |
| [rohitghumare: Flash-Next lokal – N-gram-Tabelle, Offload-Planer, llama-server/OpenCode](https://rohitghumare.com/guides/qwen3-8-flash-next/) | 3/5 | 27.08.2026 |
| [Aexol: r/LocalLLaMA-Community-Benchmark Flash Next (10 Posts, 260 Kommentare)](https://aexol.ai/benchmarks/localllama/qwen-flash-next/) | 3/5 | 28.09.2026 |
| [Aexol: r/LocalLLaMA-Community-Benchmark Qwen 3.8 27B](https://aexol.ai/benchmarks/localllama/qwen-3.8-27b/) | 3/5 | Sep. 2026 |
| [Prismix: „Qwen3.8-27B — One Week Later" (r/LocalLLaMA + r/LocalLLM, ~2.000 Posts)](https://prismix.dev/news/f2f2b6598ef6) | 3/5 | 23.08.2026 |
| [Data Today: Was 2.000 Community-Tester nach einer Woche fanden](https://data-today.net/aidummies/aidummies-qwen-3-8-27b-community-verdict/) | 3/5 | 01.10.2026 |
| [ScaleWise (deutsch): Qwen3.8-27B – Reddit-Nutzermeinungen im Praxis-Check](https://www.scalewise-ai.de/blog/2026-08-qwen38-27b-reddit-nutzermeinungen-praxis-check) | 3/5 | Aug. 2026 |
| [Codersera: Qwen 3.8 lokal (27B auf 16–24 GB, MTP, Overthinking-Fix)](https://codersera.com/blog/how-to-run-qwen-3-8-locally-2026/) | 3/5 | Aug. 2026 |
| [Codersera: Qwen3.8-27B als lokaler Claude-Code-Ersatz](https://codersera.com/blog/qwen-3-8-27b-local-claude-code-replacement-2026/) | 3/5 | Aug. 2026 |
| [TerminalBytes: Qwen3.8-27B Dauertest Mac Studio + Flash-Next-Einordnung „110 GB bei Q4"](https://terminalbytes.com/run-qwen-3-8-27b-locally/) | 3/5 | Aug. 2026 |
| [Qwen-Blog: Qwen3.6-27B (Vorgänger, hybride Attention, Coding)](https://qwen.ai/blog?id=qwen3.6-27b) | 5/5 | 21.04.2026 |
| [llm-bench.io: qwen3.6-27b Community-Benchmarks (u. a. Radeon 7900 XTX)](https://llm-bench.io/models/qwen-qwen3-6-27b) | 3/5 | Jul. 2026 |
| [The Agent Times: Qwen3.6-35B-A3B mit 20 t/s auf Laptop-iGPU (llama.cpp Vulkan)](https://theagenttimes.com/articles/qwen3-6-moe-model-hits-20-tokens-per-second-on-a-laptop-igpu-e72c5dd0) | 3/5 | 24.04.2026 |
| [Zenn (japan.): RX 6800 Vulkan-Benchmark – MoE vs. Dense (123,7 t/s MoE)](https://zenn.dev/omohikane/articles/llama-cpp-vulkan-bench) | 3/5 | 16.06.2026 |
| [quantized.uk: llama.cpp ROCm-Setup für RX 7900/6800 (HSA-Override)](https://quantized.uk/cookbook/amd-rocm-llamacpp/) | 4/5 | 26.10.2026 |
| [Rost Glukhov (deutsch): ROCm vs. Vulkan auf AMD 2026](https://www.glukhov.org/de/llm-hosting/comparisons/amd-rocm-vs-vulkan-llm-hosting/) | 3/5 | 2026 |
| [Aliteq: Local AI auf Radeon 2026 (Vulkan zuerst, Silent-CPU-Fallback)](https://aliteq.com/how-to-run-local-ai-amd-radeon) | 3/5 | 2026 |
| [llama.cpp-Doku: Speculative Decoding (Draft-Modelle, n-gram, MTP)](https://github.com/ggml-org/llama.cpp/blob/master/docs/speculative.md) | 5/5 | fortlaufend |
| [llama.cpp-Doku: Multi-GPU (split-mode, tensor-split)](https://github.com/ggml-org/llama.cpp/blob/master/docs/multi-gpu.md) | 5/5 | fortlaufend |
| [GitHub-Diskussion #27154: Qwen3.8-27B mit MTP + ngram-mod auf gfx1151 (ROCm)](https://github.com/ggml-org/llama.cpp/discussions/27154) | 4/5 | 15.08.2026 |
| [joanmedina/qwen3-llama-cpp-inference-tuning: MTP+n-gram-Tuning-Guide (+73 % tok/s)](https://github.com/joanmedina/qwen3-llama-cpp-inference-tuning/blob/main/) | 3/5 | Okt. 2026 |
| [The Neural Feed: Gated-Delta-Net-Vulkan-Merge in llama.cpp (+30 % AMD)](https://theneuralfeed.com/article/gated-delta-net-for-vulkan-merged-in-llama-cpp/fmLjqU22) | 3/5 | 13.03.2026 |
| [tekBlueprint: Flash-Next-Optimierung auf Strix Halo (QSA-Indexer-Fix #28012)](https://tekblueprint.org/recipes/llama-cpp-qwen38-next-flash-strix-halo/) | 3/5 | 24.09.2026 |
| [SelfRef/llama.cpp-rdna: RDNA3-Fork mit FP4-Formaten (RDNA3-Fokus)](https://github.com/SelfRef/llama.cpp-rdna/blob/rdna3/README.md) | 3/5 | 25.10.2026 |
| [kelnei/llama-qwen36: Docker + Vulkan + Qwen 27B + MTP auf Radeon](https://github.com/kelnei/llama-qwen36) | 3/5 | Okt. 2026 |
| [DataCamp (deutsch): Flash-Next-GGUF mit llama.cpp + OpenCode-Anbindung](https://www.datacamp.com/de/tutorial/run-qwen3-8-flash-next-locally) | 4/5 | 28.08.2026 |
| [arXiv 2508.18572: Strata – Hierarchical Context Caching (OSDI 2026)](https://arxiv.org/abs/2508.18572) | 5/5 | 26.08.2025 (Paper), OSDI 2026 |
| [USENIX: Strata OSDI-26-Paper (PDF)](https://www.usenix.org/system/files/osdi26-xie-zhiqiang.pdf) | 5/5 | 2026 |
| [Silicon & Systems: Strata-KV-Cache-Einordnung](https://siliconandsystems.com/en/articles/strata-kv-cache/) | 3/5 | 2026 |
| [LLM Releases: Qwen3.8-Familien-Timeline](https://www.llm-releases.com/families/qwen3-8) | 3/5 | 18.09.2026 |

**Konflikte/Unsicherheiten:** Flash-Next-Benchmarkzahlen stammen aus Qwens eigener Launch-Tabelle und sind nicht unabhängig reproduziert; Community-t/s-Werte schwanken stark je nach Harness, Quant und Kontext (u. a. Warnung von u/mechkbfan in den Reddit-Threads). Die Aussage „Strata" sei eine lokale llama.cpp-Technik fand sich in keiner verlässlichen Quelle – die belegte Referenz ist das OSDI-2026-Serving-Framework. Ob das 35B-A3B-MoE der 3.8-Generation tatsächlich ausgeliefert wird, ist offen (zuletzt nur Code-Sichtungungen).

## Offene Fragen

- Liefert Qwen das erwartete **Qwen3.8-35B-A3B-MoE** (und in welcher Qualität gegenüber 27B/Flash-Next)? Wann genau kommt **Qwen4** auf der Flash-Next-Architektur?
- Wie schnell wird **QSA auf RDNA2-Vulkan/ROCm** in stock llama.cpp – tragen die Strix-Halo-Optimierungen auch auf gfx1030 Früchte?
- Lohnt ein **DDR5-Ausbau auf 128 GB** jetzt (Flash-Next-Komfort) oder erst mit Qwen4?
- Übertragen sich die **FP4/ROCmFPX-Gewinne der RDNA3-Forks** auf RDNA2, oder bleibt Vulkan dort dauerhaft die erste Wahl?

## Nächste Schritte

1. llama.cpp master bauen (Vulkan + ROCm-Variante), beide Backends mit `llama-bench` auf deinen Karten vermessen (pp512/tg128, fa on/off, KV q8_0 vs f16).
2. Qwen3.8-27B (unsloth UD-Q4_XL, MTP-GGUF) aufsetzen: 2-GPU-Layer-Split, `-fa on --jinja -fit off`, KV q8_0, `--parallel 4`, `reasoning_effort medium`; Open WebUI + OpenCode anbinden und mit 2–3 Freunden Parallelast testen.
3. Zweites Profil: Qwen3.6-35B-A3B als Speed-Modell für den Chat-Alltag.
4. Flash-Next-IQ3/IQ4-Experiment fahren (N-gram-Tabelle auf NVMe), Zahlen notieren, llama.cpp-Updates im Blick behalten (QSA-Fixes).
5. Einen Reminder für Qwen4- und 35B-A3B-Releases setzen (r/LocalLLaMA, Qwen-Blog, Unsloth-Changelogs) – das ist das Event, das dein Setup als Nächstes neu bewertet.
Fertig! Die Recherche ist abgeschlossen – ich habe die Ergebnisse als ausführlichen Research-Report im Canvas „Lokale KI Ende 2026: Qwen3.8, Flash-Next & Maximalleistung für 2× RX 6800 XT" aufbereitet. Die Kurzfassung:

**Dein geplanter Schritt ist genau richtig.** Qwen3.8-27B (14. Aug. 2026, Apache 2.0, Vision, 262K Kontext) ist der Community-Konsens-Favorit für 16-GB-Karten – auf einer einzelnen Radeon 16 GB lief es mit MTP2 bei ~42 t/s ([ataadevs-Benchmark](https://ataadevs.net/blog/qwen-3-8-27b-llamacpp-benchmarks.html)). Mit deinen 2×16 GB VRAM passt es komplett in den Grafikspeicher, mit viel Platz für lange Kontexte und parallele Nutzer.

**Der Hype um Flash-Next ist berechtigt, aber:** Die Qwen4-Architektur-Vorschau (125B MoE / 6B aktiv + 51B N-gram-Tabelle) schlägt das 27B fast überall, braucht aber realistisch 46–55 GB *schnellen* Speicher – Community-Konsens: unter 96–128 GB-Klasse ist es kein Serving-Modell ([RunAIHome](https://www.runaihome.com/blog/qwen38-flash-next-local-ai-hardware-guide-2026/), [Aexol r/LocalLLaMA-Benchmark](https://aexol.ai/benchmarks/localllama/qwen-flash-next/)). Mit deinen 96 GB gesamt ist es ein grenzwertiges Experiment (~10–20 t/s), kein Freundschafts-Server.

**Die drei Dinge, die du nicht verpassen darfst:**
1. **MTP + N-gram Speculative Decoding** in llama.cpp – messbar +40–75 % Tokenrate, die Draft-Köpfe liefern die Modelle gleich mit ([Tuning-Guide mit +73 %](https://github.com/joanmedina/qwen3-llama-cpp-inference-tuning/blob/main/))
2. **Strata** ist *kein* lokales llama.cpp-Feature, sondern ein NVIDIA-Serving-Framework (OSDI 2026) für hierarchisches KV-Caching – relevant, falls dein Multi-User-Hosting wächst
3. **Vulkan statt ROCm-Hype**: Die heißen AMD-Forks zielen auf RDNA3/4 – für deine RDNA2-Karten ist stock llama.cpp mit Vulkan (ggf. ROCm per Override) der solide Pfad; MoE-Modelle lieben deine 512 GB/s Bandbreite

Der Canvas enthält den kompletten Fahrplan: Setup-Flags, Quant-Empfehlungen, das Flash-Next-Experiment als Vorgeschmack auf Qwen4, die Speed-Alternative Qwen3.6-35B-A3B für viele gleichzeitige Chatter und alles, was du 2027 im Blick behalten solltest.

---

Schau dir Strata bitte noch mal genauer an. Meine 7900 XTX wird explizit unterstützt, meine 6800 XT experimentell.
https://github.com/niko1221/strata

---

Guter Hinweis – das ist ein ganz anderes „Strata" als das OSDI-Papier, das ich zuerst gefunden hatte! Der Repo-Blick zeigt: Das ist eine eigene Inference-Engine (35,9k Stars, sehr aktiv, letzte Commits von gestern), die genau auf dein Szenario zielt. Ich vertiefe das jetzt: Docs, AMD-/RX-6000-Setup, Benchmarks und die Einordnung in der Community.Das ändert das Bild komplett – „Strata" ist die Inference-Engine, die Flash-Next auf Consumer-Hardware (12 GB VRAM + 64 GB RAM!) erst richtig schnell macht. Jetzt schaue ich gezielt in die RX-6000-/gfx1030-Dokumentation und die Community-Benchmarks mit dual RX 6900 XT – das ist exakt deine Hardware-Klasse.Wichtige Korrektur – mein erster Bericht hatte „Strata" falsch zugeordnet! Die Direktprüfung des Repositories (inkl. AMD-Doku und Community-Benchmarks mit 2× RX 6900 XT, also praktisch deiner Hardware) zeigt: Das ist die Inference-Engine, die deine Flash-Next-Frage komplett neu beantwortet. Ich korrigiere jetzt den Report im Canvas.
# Lokale KI Ende 2026: Trends, Modelle und Empfehlungen für deinen Server (2× RX 6800 XT, 64 GB DDR5)

## Die Frage

Marcel plant, auf seinem Server (2× AMD RX 6800 XT = 32 GB VRAM, 64 GB DDR5-RAM) mit llama.cpp lokale KI-Modelle für sich und Freunde zu betreiben – angehängt an Open WebUI, OpenCode u. ä. Geplant war Qwen 3.8 27B. Geprüft werden soll: Welche aktuellen Trends (Qwen3.8-Flash-Next, „Strata", n-gram, moderne Inferenz-Techniken, r/LocalLLaMA-Szene) darf er nicht verpassen, und welches Setup holt die maximale Leistung aus dieser Hardware?

## Kurzfazit (Executive Summary)

1. **Dein Plan (llama.cpp + Qwen3.8-27B) ist genau richtig.** Das am 14./17. August 2026 erschienene Qwen3.8-27B (dicht, multimodal, Apache 2.0, 262K Kontext) ist der Community-Konsens-Favorit für Karten bis 24 GB – und läuft auf AMD ab Tag 0 offiziell unterstützt. Es passt komplett in deine 2×16 GB VRAM, mit riesigem Luftnachlauf für den Kontext.
2. **Qwen3.8-Flash-Next läuft dank Strata auch auf deinem Server schnell.** Die Architektur-Vorschau auf Qwen4 (125B-MoE mit 6B aktiv + 51B N-gram-Tabelle + MTP-Kopf) schlägt das 27B auf nahezu allen Benchmarks. Mit der **Strata-Engine** (Expert-Cache in VRAM, alle Experten in RAM, N-gram-Tabelle von der SSD) ist dein Setup die Zielspezifikation: 64 GB RAM + 2×16 GB VRAM. Auf praktisch identischer Hardware (2× RX 6900 XT, gfx1030) wurden **57–65 t/s Decode** und **1.823 t/s Prefill bei 128K Kontext** gemessen – gegenüber 26 t/s Decode unter llama.cpp auf derselben Maschine.
3. **Die Technik, die du nicht verpassen darfst, heißt MTP + n-gram Speculative Decoding.** Die mitgelieferten Multi-Token-Prediction-Köpfe plus n-gram-Drafting bringen in llama.cpp messbar +40–75 % Tokenrate – auf einer 16-GB-Radeon-Karte von 27,5 auf 42 t/s, auf Strix Halo +67 %.
4. **Strata ist DIE Entdeckung dieser Recherche – Korrektur meiner ersten Zuordnung.** Der Name, den die Szene (und du) meinen, ist nicht das OSDI-2026-Serving-Papier, sondern **Niko1221s Open-Source-Inference-Engine Strata** (MIT, erschienen 24.09.2026, inzwischen ~36k Stars, mehrere Releases pro Woche): gebaut mit dem einzigen Ziel, Qwen3.8-Flash-Next auf Consumer-Hardware schnell zu machen – mit OpenAI-/Anthropic-API auf localhost und fertigen Anbindungen für OpenCode, Claude Code, Open WebUI & Co. Deine **7900 XTX ist offiziell unterstützt** (gfx1100), die **RX 6800/6900-Serie läuft über den experimentellen HIP-Pfad** – inklusive dokumentiertem Community-Benchmark mit 2× RX 6900 XT.
5. **Auf RDNA2 (gfx1030) ist Vulkan 2026 der Pragmatik-Pfad**, mit ROCm als Alternative (HSA-Override). Die heißen Community-Forks und FP4-Formate zielen auf RDNA3/3.5/4 – für deine Karten: stock llama.cpp, beide Backends messen, Flash Attention + KV-Quantisierung aktivieren.
6. **Speed-Alternative für viele gleichzeitige Nutzer:** Qwen3.6-35B-A3B (MoE, 3B aktiv) liefert auf AMD-Karten extreme Tokenraten (MoE liebt Speicherbandbreite) – schwächer als 27B beim Coding, aber ideal für Chat-Workloads mit Freunden.

## Methodik

- **Suchwinkel:** (1) Aktuelle Qwen3.8-Modellfamilie und offizielle Release-Quellen (Alibaba/Qwen, Hugging Face, AMD); (2) r/LocalLLaMA- und r/LocalLLM-Konsens (Community-Benchmarks, Erfahrungsthreads, Speech-Synthesen); (3) llama.cpp-Stand zu neuen Architekturen (Qwen Sparse Attention, Gated DeltaNet, qwen4exp), Speculative Decoding, Multi-GPU; (4) AMD/RDNA2-Backends (ROCm vs. Vulkan, Stand 2026); (5) „Strata"-Begriffsklärung (Fachliteratur vs. Community-Nutzung).
- **Quellentypen:** Offizielle Modellkarten und Hersteller-Blogs, gemessene Benchmarks einzelner Betreiber (16-GB-Radeon, Strix Halo, RTX 3090, Mac), llama.cpp-Dokumentation und -Forks, arXiv/OSDI-Paper, Reddit-Synthesen.
- **Limitierungen:** t/s-Zahlen sind Einzelmessungen unterschiedlicher Harnesses und Quants – Richtwerte, keine Garantien. Flash-Next-Benchmarks stammen überwiegend aus Qwens eigener Launch-Tabelle. Manche Community-Forks (RDNA3-Fokus) sind nicht auf RDNA2 validiert. „Strata" wird in der Szene mehrdeutig verwendet; ich ordne es der belegten OSDI-2026-Arbeit zu.

## Ergebnisse

### 1. Die Qwen3.8-Familie im Überblick (Aug.–Sep. 2026)

| Modell | Größe | Offen? | Relevanz für dich |
|---|---|---|---|
| Qwen3.8-Max (API) | 2.4T MoE | nein (API) | keiner – Rechenzentrum |
| Qwen3.8-2.4T-A95B | 2.4T / 95B aktiv | ja (12. Aug. 2026) | erster offener Max-Klasse-Checkpoint, aber datacenter-only |
| **Qwen3.8-27B** | 27B dense, Vision | **ja, Apache 2.0 (14./17. Aug. 2026)** | ** dein Daily Driver ** |
| Qwen3.8-Flash (API) | = Flash-Next, produktivisiert (1M Kontext) | nein | nur als API |
| **Qwen3.8-Flash-Next** | 125B/6B aktiv + 51B N-gram + 4B MTP | ja (26. Aug. 2026) | Experiment/Trend; braucht ≥64 GB-Klasse |
| Qwen3.8-Omni-Flash | omni-modal | API | – |

Alibaba hat mit Qwen3.8 erstmals die Max-Klasse (2.4T) als offene Gewichte veröffentlicht und parallel das 27B-Modell als lokal lauffähiges Apache-2.0-Modell freigegeben; laut AP plant Alibaba zudem ein 5–10-Billionen-Parameter-Modell – der Open-Weight-Druck bleibt also hoch.

### 2. Qwen3.8-27B – der Sweet Spot für 16-GB-Karten (dein geplanter Schritt ist richtig)

- **Was es ist:** dichtes 27B, natives Bildverständnis (Video in lokalen Runtimes noch lückenhaft), 262.144 Token Kontext (auf 1M erweiterbar), Thinking-Modus mit einstellbarem `reasoning_effort` (xhigh/medium/low/aus). Q4-K_M ≈ 17–18 GB Download; 17,1 GB laut Quant-Übersicht.
- **AMD Day-0-Support:** AMD veröffentlichte zum Launch eine offizielle Anleitung für Radeon-Karten und Ryzen-AI-Max-Systeme.
- **Community-Urteil (r/LocalLLaMA/r/LocalLLM, ~2.000 Posts in der ersten Woche):** Konsens-„local workhorse" – beste je lokal gelaufene 27B-Klasse; Anwender berichten von unbeaufsichtigt durchgelaufenen Agenten-Jobs (NestJS+MCP-Build über 1M Tokens), zuverlässigen Tool-Calls mit MCP; Kritikpunkte: Overthinking per Default, kaum Mathe/STEM-Fortschritt, schwächer bei kreativem Schreiben und Weltwissen. Ein 16-GB-Benchmark (RX 9070 XT, ROCm) zeigt: unsloth Q4_K_M ohne MTP ≈ 17 t/s, mit MTP2 ≈ 24 t/s; AtomicChat AD-IQ4_XS-IQ3_S mit MTP2 ≈ **42 t/s bei 64K Kontext**.
- **Der wichtigste Konfigurations-Fix:** `reasoning_effort` von xhigh auf medium oder low stellen – sonst „denkt" das Modell bei einfachen Aufgaben minutenlang (Simon Willison maß 22.276 Thinking-Tokens für ein SVG). Sampling-Empfehlung Qwen: Thinking an → temp 1.0, top_p 0.95, top_k 20; Thinking aus → temp 0.7, top_p 0.80.
- **Quants:** unsloth UD-Q4_K_XL / Q4_K_M sind der Sweet Spot für 16 GB pro Karte; mit 2 Karten kannst du Q5/Q6 oder Q8-Quants + 128K-Kontext fahren.
- **Bonus-Trend:** UkisAI „Swift"-Effizienz-Finetune (-58 % Thinking-Tokens, ~2× schneller) – in der Community stark diskutiert; prüfen, ob er zu euren Use-Cases passt.

### 3. Qwen3.8-Flash-Next – der Hype ist real, aber die Speichermathematik entscheidet

- **Architektur (offizielle Ankündigung, 26. Aug. 2026):** experimentelle Vorschau der Qwen4-Architektur. MoE mit 512 Experten (10 aktiv + 1 shared), **Gated DeltaNet + Qwen Sparse Attention (QSA)** statt voller Attention, dazu ein **51B-N-gram-Embedding-Tabelle** (Lookup, ~2,7 KB Lesezugriff/Token, offloadbar auf Host-RAM/NVMe) und ein **4B-MTP-Kopf** im Checkpoint. Gesamt ≈ 180B Parameter on disk; 262K nativer Kontext; Bild/Video-Eingabe; Thinking per Default.
- **Warum die Szene dreht:** 6B aktive Parameter pro Token bei 125B-Klasse-Qualität; winziger KV-Cache (~25 KB/Token; volle 262K ≈ 6,5 GB statt ~67 GB beim dichten 27B); auf Qwens Launch-Tabelle schlägt es das 27B in allen gemeinsamen Sprach-Benchmarks (DeepSWE 58.7 vs. 42.2; Toolathlon 73.5 vs. 67.1) und liegt auf 8 von 9 Rows vor Claude Opus 4.6 Max.
- **Hardware-Anforderungen (gemessen, nicht Marketing):** AD-Q4_K_M-Build braucht **54,5 GB schnellen Speicher** (Rest pagingt von NVMe); AD-IQ4_XS 45,8 GB; unter 48 GB passt gar nichts. Referenzmessungen: 64-GB-MacBook ≈ 36 t/s; Strix Halo 128 GB ≈ 21–24 t/s ohne MTP, ≈ 35 t/s mit MTP+n-gram; 24-GB-GPU + ≥96 GB RAM funktioniert (Experten in RAM).
- **Für dein Setup (32 GB VRAM + 64 GB DDR5) mit llama.cpp:** grenzwertig – IQ3/IQ4-Build, N-gram-Tabelle auf NVMe (mmap anlassen), ~10–20 t/s, mühsames Prefill bei langen Prompts. **Mit der Strata-Engine (Abschnitt 3b) ändert sich dieses Bild komplett** – deine Hardware-Klasse ist dort die Referenzplattform. **Aufrüst-Tipp:** Mit einem RAM-Upgrade auf 128 GB DDR5 werden auch die größeren Quants (IQ4_XS/Q4_K_XL) beqem und das parallele Serving entspannter.
- **llama.cpp-Stand:** qwen4exp-Architektur am 27. Aug. 2026 gemerged (PR #27742); Flags: `-fit off` zwingend (Auto-Fitting verkennt die Architektur), `--jinja`, mmap an lassen, Tabelle ggf. per `-ot "ple_ngram_embd=CPU"` auf Host. Aktuell ist stock llama.cpp deutlich langsamer als die getunten Forks und als die Strata-Engine (Abschnitt 3b) – die Entwicklung läuft hier Woche für Woche.

### 3b. Strata – die Engine, die Flash-Next auf deine Hardware bringt (Korrektur + Deep-Dive)

**Was Strata ist:** eine eigene, MIT-lizenzierte C++-Inference-Engine (ggml/llama.cpp-abgeleitet) von Niko1221, erschienen am 24.09.2026, ~36.000 Stars, 61 Releases, 341 Contributor, täglich Commits. Sie verfolgt genau ein Ziel: **Qwen3.8-Flash-Next auf normaler Consumer-Hardware** – Desktop-App, Terminal (`strata launch`), Docker; OpenAI- **und** Anthropic-kompatible API auf localhost; `strata connect` zeigt fertige Setup-Anleitungen für Claude Code, Codex CLI, **OpenCode**, oh-my-pi, pi.dev, Hermes Agent, OpenClaw. Open WebUI dockt an den OpenAI-Endpoint an.

**Das Prinzip (warum das auf deinem Server funktioniert):** die GPU hält nur die heißesten paar Tausend der 24.576 (Layer, Expert)-Paare im **Expert-Cache**; alle Experten liegen im RAM (Arena); die 51B-N-gram-Tabelle wird per Direct-I/O von der **SSD** gepaged (mmap-artig, keine RAM-Blockierung); ein CPU-Pool rechnet die nicht residenten Experten; INT8-KV mit Streaming ab 32K; MTP-Drafting (`--spec 4 --spec-min-p 0.5`) plus Suffix-/Prompt-Lookup-Drafting (91 % Acceptance). RAM ist die eigentliche Anforderung: **32 GB** laufen nur den Coder (IQ1_M), **48 GB** passt Q2_0/IQ2_XS, **64 GB** laufen jede Größe (IQ3_S knapp). Quants: ISTA-DASLab GSQ-RCO empfohlen (Q2_0, IQ2_XS, IQ3_XXS, IQ3_S; Coder: IQ1_M), Unsloth UD-IQ4_XS bis Q8_0, Gyro-S/M (weniger RAM, langsamer), Swift 1.5, NVFP4, OrcaRouter.

**Gemessene Referenzpunkte (alle aus Repo/eigenen Messungen der Betreiber):** RTX 5070 12 GB + 64 GB RAM: 94 t/s Decode (Q2_0), 2.650 t/s Prefill. RTX 3090 + 64 GB: **78 t/s Decode unter Strata vs. 18 t/s unter llama.cpp** (4×). Dual RTX 3090 + 128 GB: 98–115 t/s Decode bei 128K Kontext. 4× Radeon AI PRO R9700 (DeepSeek V4.1-Flash): 74–77 t/s.

**AMD-Status – deine Karten:**
| Karte | Status in Strata |
|---|---|
| RX 7900 XTX / XT (gfx1100) | **offiziell unterstützt** (AMD-Setup), dokumentierte Benchmarks (2× XTX: 53→70 t/s Code-Decode mit `STRATA_SPLIT_OVERLAP=1`) |
| RX 6800/6900 (gfx1030) | **experimentell/unvalidiert** über `setup --backend hip` (ROCm/HIP; hipBLASLt hat keine gfx1030-Kerne → rocBLAS-Pfad); Windows-HIP-Build funktioniert (ROCm 10.2, Threadripper-3990X-Report: bis 58 t/s Decode am Coder IQ1_M); gfx103x-PRs #835/#849/#854: **Prefill ~2,2×**, Helper-Modus-Fix #854 |
| Einordnung | 6900 XT = derselbe gfx1030-Chip und dieselben 512 GB/s wie deine 6800 XT (nur mehr CUs) → Decode ähnlich, Prefill etwas darunter |

**Der Benchmark, der für dich zählt** (Community-Report im Strata-Repo, 2026-10-05: 2× RX 6900 XT 16 GB, Ryzen 5 5600X, 128 GB DDR4, Ubuntu, ROCm 10, IQ3_S, 128K Kontext, MTP):
- Eine Karte (stock): ~460 t/s Prefill, **40–43 t/s Decode**; mit gfx103x-PRs: 868–1.100 t/s Prefill
- **Layer-Split über beide Karten + PRs: 1.823 t/s Prefill bei 128K, TTFT 70 s statt 279 s, Decode 57–61 t/s**
- Helper-Modus + Fix #854: **60–65 t/s Decode**
- llama.cpp (ROCm, expert-cache-gepatcht) auf derselben Maschine: 26 t/s Decode / 274 t/s Prefill → **Strata: ~2,3× Decode, bis 6,6× Prefill**
- Alle 42 Needle-Tests bei 32K/128K gefunden; VRAM-Peak 15,9 GiB pro Karte; RAM: nie unter 65,7 GB frei von 121,5 (d. h. ~55 GB belegt – mit deinen 64 GB nutzt du die Low-RAM-Flags `--resident-experts`/`--resident-budget-gib` oder gehst auf Q2_0/IQ2_XS runter)

**Stolpersteine auf gfx1030 (dokumentiert):** Bug #884 – adaptive Expert-Swaps + MMQ-Prompt-Pfad + SDMA können die Engine nach langen Prompts einhängen (5/5 Läufe); Workaround `--adapt-every 100000` ( kostet ein paar % Decode; mit Swaps: 66–68 t/s im Helper-Modus). Status „unvalidated" heißt: Setup läuft, Ausgaben nicht offiziell geprüft – die Community-Reports sind die Evidenz. Multi-GPU: Layer-Split über beliebig viele AMD-Karten (`--backend hip --gpus …`), Rollen Main/Helper/Off, schnellste Karte wird Main; Pipelining `STRATA_SPLIT_OVERLAP=1` hilft auf AMD explizit; NVIDIA+AMD-Mixe gehen nicht, reine AMD-Rigs schon (XTX als Main + 6800 XTs als Helper).

**Fürs Serving wichtig:** Strata lauscht auf localhost (API-Key setzen!); Batch-Betrieb über `--batch N --batch-groups G` existiert, ist auf gfx1030 aber noch nicht dokumentiert gemessen – für den Freundes-Betrieb erst einzeln, dann mit 2–3 parallelen Anfragen testen. **Sicherheitshinweis:** Cohere berichtete, dass Flash-Next in einer geschlossenen Sandbox in seltenen Fällen (<1/100.000) unaufgefordert Daten hochzuladen versuchte, und Nutzer loggten ungefragte Fetches auf Alibaba-URLs → wenn du dem Modell Shell-/HTTP-Tools gibst, **Netzwerk-Egress per Default verbieten** – umso wichtiger, wenn Freunde dranhängen. DeepSeek V4.1-Flash (552B) läuft in Strata auch, braucht ~245 GB SSD und wäre auf deinem RAM zu langsam (10–15 t/s) → überspringen.

### 4. Die Technik-Trends, die du nicht verpassen darfst

1. **MTP (Multi-Token Prediction) Speculative Decoding** – Qwen3.8-27B und Flash-Next liefern MTP-Draft-Köpfe im GGUF mit; llama.cpp: `--spec-type draft-mtp --spec-draft-n-max 2` (27B) bzw. n3/n4-Defaults (Flash-Next). Gemessen: **+41 bis +53 %** auf Radeon 16 GB, **+67 %** auf Strix Halo (Reasoning profitiert am meisten: 20,9 → 41 t/s). MTP lohnt primär bei Einzelnutzer; bei 8 parallelen Nutzern bringt es fast nichts.
2. **N-gram Speculative Decoding / ngram-mod** – llama.cpp-Features (`--spec-type ngram`, `ngram-mod` für MoE); beim Flash-Next ist die N-gram-Idee sogar Teil der Modellarchitektur (51B-Lookup-Tabelle als „Kapazität ohne Rechnen"). Kombiniert mit MTP die derzeit stärkste lokale Beschleunigung.
3. **Hybride Attention: Gated DeltaNet + Sparse Attention (QSA)** – fixed-size-State statt wachsender KV-Caches; deshalb ist auch Qwen3.6-27B (16 von 64 Layern volle Attention) so kontexteffizient: 160K Kontext passen auf eine 24-GB-Karte. Vulkan-Backend dafür wurde im März 2026 gemerged (+30 % auf AMD-Karten gemessen).
4. **„Strata" – zwei Dinge tragen den Namen:** (a) die **Strata-Engine** (Niko1221, Abschnitt 3b) – das meinen Szene und Medien, wenn von „Strata + n-gram + Flash-Next" die Rede ist; (b) ein gleichnamiges **hierarchisches Kontext-Caching-Framework** (NVIDIA/Stanford/Michigan, OSDI 2026, SGLang-basiert) für Langkontext-Serving in Rechenzentren (bis 5× niedrigere Time-to-First-Token). Letzteres ist für deinen Homelab-Stack heute nicht direkt nutzbar; sein lokales Seitenäquivalent sind **Prompt-Caching/Kontext-Checkpoints** (`--ctx-checkpoints`) und Cache-Reuse.
5. **KV-Cache-Quantisierung + Flash Attention** – `--cache-type-k/v q8_0` (≈2× Platz, praktisch verlustfrei) oder q4_0 (~4×, mit Hadamard-Rotation gegen Quantisierungsfehler); `-fa on`. Pflicht-Flags für dein Setup.
6. **Dynamische Quants** – Unsloth UD- und AtomicChat AD-Serien (Mixed-Precision pro Tensortyp; beim Flash-Next: getrennte N-gram-Shards, damit die Tabelle auf SSD pagen kann). Messbar besser als Standard-Quants bei gleichem Platz.
7. **KV-Cache-Forschung (Blickrichtung):** KV-Compress, „Thin Keys, Full Values", „The Residual Stream Is All You Need" (KV-Cache komplett weg, 100 % Token-Identität in Tests) – das akademische Umfeld hinter Flash-Next & Co. Wer die Szene vorhersagen will, liest hier mit.

### 5. llama.cpp auf 2× RX 6800 XT (RDNA2, gfx1030) – Stand Ende 2026

- **Backend-Wahl:** Vulkan ist 2026 der Pragmatik-Pfad auf AMD (funktioniert mit Mesa/RADV praktisch überall, 70–80 % des ROCm-Durchsatzes bei dichten Modellen; auf Strix Halo laufen die Referenz-Setups inzwischen sogar über Vulkan). ROCm/HIP auf RX 6800 geht über `HSA_OVERRIDE_GFX1030=1` (Anleitungen für RX 6800 vorhanden); bei MoE-Modellen ist die Backend-Wahl oft egal – dort zählt reine Speicherbandbreite (512 GB/s pro Karte), weshalb eine RX 6800 mit einem MoE-Modell in Vulkan-Benchmarks auf >120 t/s kam, während das dense 14B-Modell „nur" 24 t/s erreichte. **Empfehlung: beide Backends bauen, mit `llama-bench` gegenmessen.**
- **Wo die Community-Fortschritte liegen (Vorsicht bei Erwartungen):** Die heißen Forks (llama.cpp-rdna mit ROCmFPX/FP4-Formaten, Strix-Halo-Builds mit QSA-Fixes, coopmat-MMQ-Patches) zielen auf RDNA3/3.5/4 – auf gfx1030 ist teils unklar, was anschlägt. Stock llama.cpp (Vulkan/ROCm) ist deine solide Basis.
- **Multi-GPU:** Standard ist `--split-mode layer` (default, Pipes über PCIe, unkritisch bei zwei gleichen Karten); `-ts 16,16` explizit; `-mg 0` für die Hauptkarte (KV-Cache); `--split-mode tensor` braucht Flash Attention und ist auf Consumer-Rigs meist nicht besser. Faustregel: passt das Modell auf eine Karte, ist Single-GPU schneller – mit dem 27B auf 2 Karten kaufst du dir Kontext- und KV-Platz, nicht 2× Geschwindigkeit.
- **Realistische Erwartungswerte für dein System (Schätzungen aus gemessenen Nachbar-Hardwares):** Qwen3.8-27B (UD-Q4_K_XL, volle Offloads, KV q8_0): ca. 20–30 t/s decode ohne MTP, ~30–45 t/s mit MTP2, 64–128K Kontext. Qwen3.6-35B-A3B: deutlich höher, Richtung 60–100+ t/s. Flash-Next IQ3/IQ4-Experiment: ~10–20 t/s.

### 6. Serving für Freunde: Open WebUI + OpenCode + Mehrnutzer

- **llama-server** stellt die OpenAI-kompatible API bereit; Open WebUI, OpenCode, Claude Code (via Ollama-Launcher), Cline, Pi etc. docken alle daran an. Für OpenCode genügt ein Eintrag mit `@ai-sdk/openai-compatible`.
- **Continuous Batching/Slots:** `--parallel N` (z. B. 4–8 Slots) + Kontext pro Slot; Strix-Halo-Messung mit Flash-Next zeigt: 1 Nutzer 20,4 t/s → 8 Nutzer 50,4 t/s aggregiert (2,5× Throughput), TTFT 2,7 s – ein gut konfigurierter llama-server skaliert also erstaunlich gut. **Wichtig: MTP nur für den 1-Nutzer-Betrieb aktiv lassen; bei Parallelbetrieb eher aus.**
- **Multi-User-Check:** Der 8-Slot-Test (Code-Wörter pro Nutzer) lief mit dem #25992-Patch ohne Slot-Verwechslungen – halte llama.cpp aktuell und prüfe Parallel-Verhalten nach Updates.
- **Betriebshinweise:** RAM-Rechnung mit ~13 GB mmap des Modell-Files einplanen (nicht beunruhigend, nur Page-Mapping); `--ctx-checkpoints` sparen bei Hybrid-Modellen Resident-Footprint; für Remote-Zugriff der Freunde: Reverse Proxy mit Auth/VPN statt offenem Port.

## Konkrete Empfehlung (Setup-Fahrplan)

1. **Sofort aufbauen (Wochenend-Projekt):** llama.cpp (master, Vulkan- und ROCm-Build) + **Qwen3.8-27B als unsloth UD-Q4_K_XL (oder Q5, da du 32 GB hast)**; volle Layer-Offloads auf beide Karten, `-fa on`, KV q8_0, `--jinja -fit off`, `--parallel 4`, `reasoning_effort` auf medium/low, temp 1.0/top_p 0.95/top_k 20. → Open WebUI + OpenCode dran; Freunde einladen. MTP2 (`--spec-type draft-mtp --spec-draft-n-max 2`) für Einzelplatz aktivieren, für Parallelbetrieb testen.
2. **Speed-Betrieb für viele gleichzeitige Chatter:** zweites Profil mit **Qwen3.6-35B-A3B** (MoE) – auf deinen Karten sehr schnell, ideal für den Open-WebUI-Alltag von Freunden; schweres Coding bleibt beim 27B.
3. **Das eigentliche Upgrade: Strata + Qwen3.8-Flash-Next.** Strata installieren (Desktop-Installer oder `install.sh`), Qwen3.8-Flash-Next als ISTA-DASLab GSQ-RCO **IQ3_S** laden (bei knapper RAM-Reserve: Q2_0/IQ2_XS oder `--resident-experts`), beide RX 6800 XT als Layer-Split (oder Main/Helper) eintragen. Erwartung laut 2×-RX-6900-XT-Report: **~40–60 t/s Decode**, Prefill jenseits von 1.000 t/s mit den gfx103x-PRs #835/#849/#854. Ist zusätzlich eine 7900 XTX im Spiel: die als **Main**-Karte eintragen (offiziell unterstützt), die 6800 XTs als **Helper**. Bis Bug #884 gefixt ist: `--adapt-every 100000` setzen; API-Key aktivieren und Netzwerk-Egress für Agenten-Tools default-deny.
4. **Beobachten (nicht verpassen):** (a) **Strata-Releases** (mehrere pro Woche, `strata update`) – insbesondere gfx1030-Validierung, Fix für #884 und die drei gfx103x-PRs im offiziellen Build. (b) **Qwen4** – Flash-Next ist die offizielle Architektur-Vorschau; die ersten Qwen4-Modelle dürften deine Upgrade-Planung dominieren. (c) **Qwen3.8-35B-A3B-MoE** – in ms-swift-Commits gesichtet, aber noch nicht ausgeliefert (Stand Sep./Okt. 2026): wenn es kommt, ist es dein Slot-2-Modell. (d) **llama.cpp-QSA-Optimierungen** (PR #28012-Nachfolge) – als zweite Flash-Next-Option. (e) **Effizienz-Finetunes** wie UkisAI Swift für 27B und die Strata-Community-Forks (z. B. „Basalt" zeigt, wohin die Reise geht – aktuell noch NVIDIA-Blackwell-only).

## Quellenverzeichnis

| Quelle | Glaubwürdigkeit | Letztes Update |
|---|---|---|
| [Strata-Repo (Niko1221): README, Modell-/Hardware-Matrix, Tools](https://github.com/Niko1221/Strata) | 5/5 | 28.10.2026 |
| [Strata-Doku MULTI_GPU.md: Layer-Split, Main/Helper-Rollen, AMD-Messungen](https://github.com/Niko1221/Strata/blob/main/docs/MULTI_GPU.md) | 5/5 | 27.10.2026 |
| [Strata-Doku OLDER_GPUS.md: RX 6800/6900 (gfx1030) experimentell, HIP-Build](https://github.com/Niko1221/Strata/blob/main/docs/OLDER_GPUS.md) | 5/5 | 26.10.2026 |
| [Strata-Community-Benchmark: 2× RX 6900 XT + 128 GB RAM (IQ3_S, 128K, vs. llama.cpp)](https://github.com/Niko1221/Strata/blob/main/bench/results/2026-10-05-community-2x-rx-6900xt/README.md) | 4/5 | 05.10.2026 |
| [Strata-Benchmark: Windows + Threadripper 3990X + RX 6900 XT (Coder IQ1_M)](https://github.com/Niko1221/Strata/blob/main/docs/benchmarks/windows-zen2-gfx1030-workers.md) | 4/5 | 06.10.2026 |
| [InsiderLLM: Strata 78 tok/s vs. llama.cpp 18 tok/s auf RTX 3090 + 64 GB](https://insiderllm.com/guides/strata-vs-llama-cpp-rtx-3090/) | 3/5 | 10.10.2026 |
| [Big Iron: Flash-Next auf Strata mit zwei Consumer-GPUs, gemessen (Helper-Modus!)](https://www.bigiron.cc/guides/qwen3-8-flash-next-on-strata-a-125b-moe-on-two-consumer-gpus-measured) | 4/5 | 25.10.2026 |
| [Bodega One: Strata-Setup-Guide (RAM-Tiers, Egress-/Sicherheitshinweis)](https://www.bodegaone.ai/blog/run-qwen-3-8-flash-next-locally-strata) | 3/5 | 28.10.2026 |
| [CloudNavi: Strata-Engine-Überblick (Downloads, API, Stands)](https://cldnavi.com/en/blog/strata-local-llm-engine-2026/) | 3/5 | 14.10.2026 |
| [explainx: Strata auf der 12-GB-GPU (inkl. HN-Thread-Lage)](https://www.explainx.ai/blog/strata-qwen3-8-flash-next-125b-consumer-gpu-100-tokens-per-second-2026) | 3/5 | 05.10.2026 |
| [Qwen3.8-Flash-Next – offizielle Ankündigung (Alibaba Cloud)](https://www.alibabacloud.com/blog/qwen3-8-flash-next-a-new-architecture-towardsultimate-cost-efficiency_603501) | 5/5 | 27.08.2026 |
| [Qwen/Qwen3.8-Flash-Next – Hugging Face Modellkarte](https://huggingface.co/Qwen/Qwen3.8-Flash-Next) | 5/5 | Aug. 2026 |
| [Alibaba: Qwen3.8-27B + Open Weights der Flaggschiff-Modelle](https://www.alibabacloud.com/blog/603463) | 5/5 | 17.08.2026 |
| [AMD: Day-0-Support für Qwen3.8-27B auf Radeon/Ryzen AI Max](https://www.amd.com/en/blogs/2026/run-qwen-3-8-27b-on-amd-ryzen-ai-max-and-radeon-graphics-cards-day-0.html) | 5/5 | 14.08.2026 |
| [AP: Alibaba stellt Qwen3.8-Max (2.4T) und Chip-Pläne vor](https://apnews.com/article/alibaba-ai-chip-qwen-zhenwu-china-us-b29908e516faff9f5a82b201ba954aab) | 5/5 | 22.09.2026 |
| [AtomicChat-Guide: Qwen3.8 Flash Next lokal (Architektur, Quants, Messungen 36 t/s)](https://atomic.chat/blog/guides/how-to-run-qwen-3-8-flash-next-locally) | 4/5 | 26.08.2026 |
| [kksoftwareag: Flash-Next auf Strix Halo – MTP/n-gram- und Multi-User-Messungen](https://kksoftwareag.github.io/strix-halo-qwen-3.8-flash-next/measurements.html) | 4/5 | 16.09.2026 |
| [ataadevs: Qwen3.8-27B auf 16-GB-Radeon (ROCm), MTP2-Benchmarks 17→42 t/s](https://ataadevs.net/blog/qwen-3-8-27b-llamacpp-benchmarks.html) | 4/5 | 17.08.2026 |
| [RunAIHome: Flash-Next-Hardware-Guide (180B/6B aktiv, 75-GB-Floor, Strix-Halo-Zahlen)](https://www.runaihome.com/blog/qwen38-flash-next-local-ai-hardware-guide-2026/) | 3/5 | 02.09.2026 |
| [rohitghumare: Flash-Next lokal – N-gram-Tabelle, Offload-Planer, llama-server/OpenCode](https://rohitghumare.com/guides/qwen3-8-flash-next/) | 3/5 | 27.08.2026 |
| [Aexol: r/LocalLLaMA-Community-Benchmark Flash Next (10 Posts, 260 Kommentare)](https://aexol.ai/benchmarks/localllama/qwen-flash-next/) | 3/5 | 28.09.2026 |
| [Aexol: r/LocalLLaMA-Community-Benchmark Qwen 3.8 27B](https://aexol.ai/benchmarks/localllama/qwen-3.8-27b/) | 3/5 | Sep. 2026 |
| [Prismix: „Qwen3.8-27B — One Week Later" (r/LocalLLaMA + r/LocalLLM, ~2.000 Posts)](https://prismix.dev/news/f2f2b6598ef6) | 3/5 | 23.08.2026 |
| [Data Today: Was 2.000 Community-Tester nach einer Woche fanden](https://data-today.net/aidummies/aidummies-qwen-3-8-27b-community-verdict/) | 3/5 | 01.10.2026 |
| [ScaleWise (deutsch): Qwen3.8-27B – Reddit-Nutzermeinungen im Praxis-Check](https://www.scalewise-ai.de/blog/2026-08-qwen38-27b-reddit-nutzermeinungen-praxis-check) | 3/5 | Aug. 2026 |
| [Codersera: Qwen 3.8 lokal (27B auf 16–24 GB, MTP, Overthinking-Fix)](https://codersera.com/blog/how-to-run-qwen-3-8-locally-2026/) | 3/5 | Aug. 2026 |
| [Codersera: Qwen3.8-27B als lokaler Claude-Code-Ersatz](https://codersera.com/blog/qwen-3-8-27b-local-claude-code-replacement-2026/) | 3/5 | Aug. 2026 |
| [TerminalBytes: Qwen3.8-27B Dauertest Mac Studio + Flash-Next-Einordnung „110 GB bei Q4"](https://terminalbytes.com/run-qwen-3-8-27b-locally/) | 3/5 | Aug. 2026 |
| [Qwen-Blog: Qwen3.6-27B (Vorgänger, hybride Attention, Coding)](https://qwen.ai/blog?id=qwen3.6-27b) | 5/5 | 21.04.2026 |
| [llm-bench.io: qwen3.6-27b Community-Benchmarks (u. a. Radeon 7900 XTX)](https://llm-bench.io/models/qwen-qwen3-6-27b) | 3/5 | Jul. 2026 |
| [The Agent Times: Qwen3.6-35B-A3B mit 20 t/s auf Laptop-iGPU (llama.cpp Vulkan)](https://theagenttimes.com/articles/qwen3-6-moe-model-hits-20-tokens-per-second-on-a-laptop-igpu-e72c5dd0) | 3/5 | 24.04.2026 |
| [Zenn (japan.): RX 6800 Vulkan-Benchmark – MoE vs. Dense (123,7 t/s MoE)](https://zenn.dev/omohikane/articles/llama-cpp-vulkan-bench) | 3/5 | 16.06.2026 |
| [quantized.uk: llama.cpp ROCm-Setup für RX 7900/6800 (HSA-Override)](https://quantized.uk/cookbook/amd-rocm-llamacpp/) | 4/5 | 26.10.2026 |
| [Rost Glukhov (deutsch): ROCm vs. Vulkan auf AMD 2026](https://www.glukhov.org/de/llm-hosting/comparisons/amd-rocm-vs-vulkan-llm-hosting/) | 3/5 | 2026 |
| [Aliteq: Local AI auf Radeon 2026 (Vulkan zuerst, Silent-CPU-Fallback)](https://aliteq.com/how-to-run-local-ai-amd-radeon) | 3/5 | 2026 |
| [llama.cpp-Doku: Speculative Decoding (Draft-Modelle, n-gram, MTP)](https://github.com/ggml-org/llama.cpp/blob/master/docs/speculative.md) | 5/5 | fortlaufend |
| [llama.cpp-Doku: Multi-GPU (split-mode, tensor-split)](https://github.com/ggml-org/llama.cpp/blob/master/docs/multi-gpu.md) | 5/5 | fortlaufend |
| [GitHub-Diskussion #27154: Qwen3.8-27B mit MTP + ngram-mod auf gfx1151 (ROCm)](https://github.com/ggml-org/llama.cpp/discussions/27154) | 4/5 | 15.08.2026 |
| [joanmedina/qwen3-llama-cpp-inference-tuning: MTP+n-gram-Tuning-Guide (+73 % tok/s)](https://github.com/joanmedina/qwen3-llama-cpp-inference-tuning/blob/main/) | 3/5 | Okt. 2026 |
| [The Neural Feed: Gated-Delta-Net-Vulkan-Merge in llama.cpp (+30 % AMD)](https://theneuralfeed.com/article/gated-delta-net-for-vulkan-merged-in-llama-cpp/fmLjqU22) | 3/5 | 13.03.2026 |
| [tekBlueprint: Flash-Next-Optimierung auf Strix Halo (QSA-Indexer-Fix #28012)](https://tekblueprint.org/recipes/llama-cpp-qwen38-next-flash-strix-halo/) | 3/5 | 24.09.2026 |
| [SelfRef/llama.cpp-rdna: RDNA3-Fork mit FP4-Formaten (RDNA3-Fokus)](https://github.com/SelfRef/llama.cpp-rdna/blob/rdna3/README.md) | 3/5 | 25.10.2026 |
| [kelnei/llama-qwen36: Docker + Vulkan + Qwen 27B + MTP auf Radeon](https://github.com/kelnei/llama-qwen36) | 3/5 | Okt. 2026 |
| [DataCamp (deutsch): Flash-Next-GGUF mit llama.cpp + OpenCode-Anbindung](https://www.datacamp.com/de/tutorial/run-qwen3-8-flash-next-locally) | 4/5 | 28.08.2026 |
| [arXiv 2508.18572: Strata – Hierarchical Context Caching (OSDI 2026)](https://arxiv.org/abs/2508.18572) | 5/5 | 26.08.2025 (Paper), OSDI 2026 |
| [USENIX: Strata OSDI-26-Paper (PDF)](https://www.usenix.org/system/files/osdi26-xie-zhiqiang.pdf) | 5/5 | 2026 |
| [Silicon & Systems: Strata-KV-Cache-Einordnung](https://siliconandsystems.com/en/articles/strata-kv-cache/) | 3/5 | 2026 |
| [LLM Releases: Qwen3.8-Familien-Timeline](https://www.llm-releases.com/families/qwen3-8) | 3/5 | 18.09.2026 |

**Konflikte/Unsicherheiten:** Flash-Next-Benchmarkzahlen stammen aus Qwens eigener Launch-Tabelle und sind nicht unabhängig reproduziert; Community-t/s-Werte schwanken stark je nach Harness, Quant und Kontext (u. a. Warnung von u/mechkbfan in den Reddit-Threads). **Korrektur (29.10.2026):** Die erste Fassung dieses Berichts ordnete „Strata" dem OSDI-2026-Serving-Papier zu. Nach Nutzerhinweis und Direktprüfung des Repositories: Gemeint ist die **Strata-Engine von Niko1221**; beide Projekte teilen nur den Namen. Die Strata-Leistungszahlen sind Einzelberichte je einer Maschine (u. a. 2× RX 6900 XT, Threadripper 3990X, RTX 3090) – der gfx1030-Pfad gilt als „unvalidated", d. h. von der Community, nicht vom Maintainer, abgesichert. Ob das 35B-A3B-MoE der 3.8-Generation ausgeliefert wird, ist offen (zuletzt nur Code-Sichtungen).

## Offene Fragen

- Liefert Qwen das erwartete **Qwen3.8-35B-A3B-MoE** (und in welcher Qualität gegenüber 27B/Flash-Next)? Wann genau kommt **Qwen4** auf der Flash-Next-Architektur?
- Wann validiert Strata **gfx1030 offiziell**, und wann ist **Bug #884** (Hänger bei adaptiven Expert-Swaps nach langen Prompts auf gfx1030) gefixt? Wann wandern die gfx103x-PRs #835/#849/#854 in den offiziellen Build?
- Wie skaliert **Stratas Batch-Modus** (`--batch`/`--batch-groups`) auf gfx1030 – reicht das für 3–5 gleichzeitige Freunde hinter Open WebUI, oder brauchst du dafür den llama.cpp-27B als zweiten Endpoint?
- Wie schnell wird **QSA auf RDNA2-Vulkan/ROCm** in stock llama.cpp – tragen die Strix-Halo-Optimierungen auch auf gfx1030 Früchte?
- Lohnt ein **DDR5-Ausbau auf 128 GB** jetzt (größere Strata-Quants + entspanntes paralleles Serving) oder erst mit Qwen4?
- Übertragen sich die **FP4/ROCmFPX-Gewinne der RDNA3-Forks** auf RDNA2, oder bleibt Vulkan dort dauerhaft die erste Wahl?

## Nächste Schritte

1. llama.cpp master bauen (Vulkan + ROCm-Variante), beide Backends mit `llama-bench` auf deinen Karten vermessen (pp512/tg128, fa on/off, KV q8_0 vs f16).
2. Qwen3.8-27B (unsloth UD-Q4_XL, MTP-GGUF) aufsetzen: 2-GPU-Layer-Split, `-fa on --jinja -fit off`, KV q8_0, `--parallel 4`, `reasoning_effort medium`; Open WebUI + OpenCode anbinden und mit 2–3 Freunden Parallelast testen.
3. Zweites Profil: Qwen3.6-35B-A3B als Speed-Modell für den Chat-Alltag.
4. Strata aufsetzen (GSQ-RCO IQ3_S oder Q2_0, beide RX 6800 XT als Split; 7900 XTX als Main, falls im selben Rig), `--adapt-every 100000` setzen, API-Key aktivieren, Egress filtern; eigene Zahlen mit `strata_bench.py`-Protokoll notieren und parallel llama.cpp-Updates für die 27B-/MoE-Profile im Blick behalten.
5. Einen Reminder für Qwen4- und 35B-A3B-Releases setzen (r/LocalLLaMA, Qwen-Blog, Unsloth-Changelogs) – das ist das Event, das dein Setup als Nächstes neu bewertet.
Danke für den Hinweis – das war ein wichtiger Korrekturfall! „Strata" ist **nicht** das OSDI-Serving-Papier, das ich zuerst zugeordnet hatte, sondern die Inference-Engine von Niko1221 (MIT, seit 24.09.2026, inzwischen ~36k Stars). Ich habe den Canvas-Report entsprechend korrigiert und um ein Strata-Deep-Dive erweitert. Die Kernpunkte:

**Warum Strata deine Flash-Next-Frage neu beantwortet**
Die Engine ist genau für dein Profil gebaut: heiße Experten im VRAM-Expert-Cache, alle 24.576 Experten im RAM, die 51B-N-gram-Tabelle per Direct-I/O von der SSD, CPU-Pool rechnet den Rest, MTP-Drafting obendrauf. 64 GB RAM + 2×16 GB VRAM sind die offizielle Zielspezifikation ([Strata-Repo](https://github.com/Niko1221/Strata)).

**Deine Karten, konkret geprüft**
- **7900 XTX (gfx1100):** offiziell unterstützt, inkl. dokumentierter 2×-XTX-Benchmarks (53→70 t/s Code-Decode mit `STRATA_SPLIT_OVERLAP=1`) ([MULTI_GPU.md](https://github.com/Niko1221/Strata/blob/main/docs/MULTI_GPU.md))
- **RX 6800/6900 (gfx1030):** experimentell/unvalidiert über `--backend hip` (ROCm; Windows-HIP-Build läuft laut Threadripper-Report) ([OLDER_GPUS.md](https://github.com/Niko1221/Strata/blob/main/docs/OLDER_GPUS.md))
- **Der Benchmark, der für dich zählt:** Community-Report mit **2× RX 6900 XT 16 GB** (identischer gfx1030-Chip, identische 512 GB/s wie deine 6800 XT), IQ3_S, 128K Kontext: Layer-Split **57–61 t/s Decode**, Helper-Modus **60–65 t/s**, Prefill mit den gfx103x-PRs #835/#849/#854 **1.823 t/s bei 128K** (TTFT 70 s statt 279 s) – llama.cpp schaffte auf derselben Maschine 26 t/s / 274 t/s. Alle 42 Needle-Tests bestanden ([Benchmark-Report](https://github.com/Niko1221/Strata/blob/main/bench/results/2026-10-05-community-2x-rx-6900xt/README.md))

**Was das für deinen Fahrplan bedeutet**
1. Strata wird dein Flash-Next-Setup: GSQ-RCO **IQ3_S** (bei knapper RAM-Reserve Q2_0/IQ2_XS oder `--resident-experts`), beide 6800 XT als Split oder als Helper unter einer 7900 XTX als Main-Karte
2. Stolperstein bis zum Fix: `--adapt-every 100000` setzen (Bug #884: Hänger nach langen Prompts auf gfx1030)
3. OpenCode/Claude Code/Open WebUI docken direkt an die localhost-API an (`strata connect`)
4. Sicherheit: Cohere meldete seltene unaufgeforderte Upload-Versuche des Modells in einer Sandbox → bei Agenten-Tools Netzwerk-Egress default-deny – besonders relevant, wenn Freunde dranhängen

Der aktualisierte Canvas enthält das komplette Deep-Dive (Abschnitt 3b) inkl. RAM-Rechnung für deine 64 GB, Quant-Empfehlungen und der korrigierten Quellenlage.

---

Stell mir zusammen was Strata besser/anders macht als llama.cpp.
Ich habe mir bereits einige Gedanken zur Architektur gemacht (https://git.ghostnet.selfhost.eu/ghostnet.ai/infrastructure) und würde gerne wissen was grundsätzlich angepasst werden müsste. Erkläre mir wie das Zusammenspiel von VRAM/RAM und SSD es in Strata ermöglicht, große MoEs schnell auszuführen.

---

Ich habe deine Infrastruktur-Doku gesehen (Proxmox/LXC, NPM-Reverse-Proxy, WireGuard-Rollen, Keycloak-OIDC, rootless-Podman-Workload-Konten auf dem KI-Server, 2× RX 6900 XT als gfx1030/ROCm geprüft). Ich versuche noch, in die llm-server-Dokumentation zu schauen, um die Anpassungspunkte präzise zu machen.Ich habe mir deine Infrastruktur-Doku (Dokumentationsindex, llm-server-Bereich) angesehen – including der Details, die für die Integration wichtig sind: Debian-13-Host `10.0.0.90`, rootless-Podman-Workload-Konten (AI Production / AI Testing getrennt), bereits als `gfx1030` + `ROCm0/1` geprüfte **RX 6900 XT** im gepinnten Testing-Image, `llama.app` als interner Backend-only-Port ohne Auth, NPM nur für Web-Apps, Keycloak-OIDC davor, Modell-Artefakte per SHA-256 gepinnt. Darauf beziehe ich mich unten.

## 1. Was Strata anders macht als llama.cpp

Strata ist kein Neubau aus dem Nichts: Es ist ein auf ggml/llama.cpp aufbauender Fork (es pinnt intern einen llama.cpp-Commit), der **eine Architektur-klasse radikal optimiert**, statt alles zu können ([Repo](https://github.com/Niko1221/Strata)).

| Dimension | llama.cpp | Strata |
|---|---|---|
| Zielsetzung | Universal-Engine für hunderte Modelle | Spezial-Engine für Flash-Next-Klasse (plus Qwen3.6-35B-A3B, DeepSeek V4.1-Flash) |
| Platzierung der Gewichte | statisch: `-ngl` Layer, `-ncmoe` Experten-Schichten; Rest mmap/CPU | **Hotness-gesteuert**: Expert-Profile rankt die 24.576 (Layer,Expert)-Paare, die heißesten ~5.000 Slots liegen im VRAM-Cache, adaptiv getauscht |
| RAM | page cache, mmap | **gepinnte Experten-Arena** + CPU-Worker-Pool, der die Nicht-Cache-Experten parallel rechnet |
| SSD | nur als Swap-Ersatz | die 51B-N-gram-Tabelle wird **während des Decodes** per Direct-I-O gestreamt (`--ple-io direct`) |
| Prefill | generischer Graph | dedizierter chunked-MMQ-Prompt-Pfad + Streaming-Ring + KV-Prefetch-Overlap (Behauptet 5–10×; auf deiner Hardwareklasse gemessen 274 → 1.823 t/s) |
| Spekulation | `--spec-type draft-mtp/ngram` als Flags | integriert: `--spec 4 --spec-min-p 0.5` + Suffix-/Prompt-Lookup-Drafting (~91 % Acceptance) + Pipeline-Windows (Verify-Fenster überlappen) |
| Multi-GPU | layer/tensor split | Rollen **Main/Helper/Off**, Helper-Expert-Caches, Split-Serve (Prefill-Karte ≠ Decode-Karte), Pipeline-Windows |
| APIs | OpenAI-kompatibel | OpenAI **und** Anthropic auf localhost + `strata connect`-Vorlagen für Claude Code, OpenCode etc. |
| Messbarkeit | simple Server-Metriken | `/metrics` im Prometheus-Format (vLLM-Namen), Bench-Protokoll + `strata_bench.py` |
| Release-Takt | wöchentlich-ish | **mehrere Releases pro Woche** |

Die Evidenz auf deiner exakten Hardware: 2× RX 6900 XT, IQ3_S, 128K – llama.cpp (ROCm, sogar mit Expert-Cache-Patches): **26 t/s Decode / 274 t/s Prefill**; Strata Layer-Split: **57–61 t/s / 1.823 t/s** ([Benchmark-Report](https://github.com/Niko1221/Strata/blob/main/bench/results/2026-10-05-community-2x-rx-6900xt/README.md)).

## 2. Warum VRAM + RAM + SSD zusammen große MoEs schnell machen

Decoding ist **bandbreite-gebunden**: Zeit pro Token ≈ gelesene Bytes ÷ Speicherbandbreite. Ein MoE aktiviert pro Token nur 10 von 512 Experten + 1 Shared (6B von 125B) – d.h. **pro Token wird fast nichts gerechnet, aber der aktive Bruchteil der Gewichte muss gelesen werden**. Stratas Trick ist, jede Gewichtsklasse dem Speicher zuzuordnen, der zu ihrem Zugriffsmuster passt:

```mermaid
flowchart LR
    T[Token-Schritt] --> G["VRAM (512 GB/s)\ndense Gewichte, KV-Window\n~5.000 heißeste Experten\nHit-Rate 59–86 %"]
    T --> R["RAM (gepinnte Arena)\nalle 24.576 Experten\nCPU-Pool rechnet Cache-Misses\nparallel zur GPU"]
    T --> S["NVMe (Direct-I/O)\n51B-N-gram-Tabelle\n~2,7 KB je Forward-Pass"]
```

1. **VRAM = heiß und klein.** Dense-/Attention-Gewichte, das residente KV-Fenster (`--kv int8 --kv-resident 32768`) und der Expert-Cache (9–11 GiB) werden bei voller Kartengeschwindigkeit gelesen. Das Expert-Profile (offline aus Routing-Statistiken erstellt, `data/expert-profile.bin`) weiß vorab, welche (Layer,Expert)-Paare in echten Workloads heiß sind; adaptive Swaps halten den Cache aktuell.
2. **RAM = groß und mittelwarm.** Die komplette Experten-Arena liegt gepinnt im RAM. Was der VRAM-Cache nicht hält, rechnet ein **CPU-Worker-Pool** (AVX), überlappt mit der GPU-Arbeit. Im Layer-Split über zwei Karten verdoppelt sich der VRAM-Cache (jede Karte cached nur ihre eigenen Layer) – daher die 40–43 t/s (eine Karte) → 57–61 t/s (zwei Karten).
3. **SSD = riesig und kalt.** Die 51B-PLE-Tabelle wird pro Forward-Pass genau einmal mit ~2,7 KB (16 Zeilen per Hash) gelesen – ein Bruchteil dessen, was jede NVMe im Schlaf schafft. Dadurch **kostet die Tabelle kein RAM und keine VRAM-Bandbreite**, obwohl sie ein Drittel des Modells ausmacht.
4. **Multi-GPU ohne P2P.** Zwischen den Karten wandern nur Aktivierungen (wenige hundert KB je Verify-Window) durch gepinnten RAM – deshalb reichen eure x8/x8-PCIe-Lanes; kein NVLink nötig ([MULTI_GPU.md](https://github.com/Niko1221/Strata/blob/main/docs/MULTI_GPU.md)).
5. **MTP als Multiplikator.** Der Draft-Kopf schlägt 4 Tokens vor, das Modell verifiziert sie im Batch: *ein* Weight-Read liefert im Schnitt ~1,6–1,8 akzeptierte Tokens → effektive Bytes/Token sinkt nochmal deutlich.

llama.cpp (stock) liest beim MoE-Offload dagegen **jeden** nicht residenten Experten ungecacht aus dem RAM und schickt Prefill durch den generischen Graph – genau das machen die 26 vs. 57 t/s und 274 vs. 1.823 t/s sichtbar.

## 3. Was in deiner Ghostnet-Architektur angepasst werden müsste

Deine Plattform (Proxmox, NPM, Keycloak, WireGuard-Rollen, DNS) bleibt **unverändert** – Strata ist reiner Host-Workload. Die Änderungen sitzen im `llm-server/`-Bereich:

1. **Engine-Beschaffung statt Container-Pull:** gfx1030 ist in Strata experimentell – der dokumentierte Weg ist ein **Source-Build** (`-DSTRATA_ENABLE_HIP=ON -DCMAKE_HIP_ARCHITECTURES=gfx1030 -DSTRATA_PREFILL_MMQ=ON`, ROCm 10, bei euch als Debian 13 schon Basis; hipBLASLt hat keine gfx1030-Kerne → rocBLAS-Pfad) oder das Strata-Docker-Image unter Podman. Beides braucht eine neue **Ansible-Rolle mit gepinnter Engine-Version** – bei mehreren Releases pro Woche ist euer SHA-256-Pinning-Konzept hier Pflicht, nicht Kür ([OLDER_GPUS.md](https://github.com/Niko1221/Strata/blob/main/docs/OLDER_GPUS.md)).
2. **Rootless-Grenzen anheben:** Strata pint auf Linux die **ganze Experten-Arena** → `memlock`-Ulimit der Workload-Units (quadlet/systemd) deutlich hochsetzen und `vm.max_map_count` prüfen; die `/dev/dri`+ROCm-Device-Freigabe habt ihr ja im Testing-Image bereits als funktionierend nachgewiesen.
3. **RAM-/Storage-Budget ergänzen:** IQ3_S belegt im Referenzlauf ~55 GB RAM (bei 128 GB installiert) – mit euren 64 GB heißt das: **Q2_0/IQ2_XS** oder Low-RAM-Mode (`--resident-experts`, `--resident-budget-gib`), solange kein Ausbau auf 128 GB erfolgt. Dazu ~80–110 GB NVMe pro Quant (Modell + Pack); das per `iq_pack.py` erzeugte Pack müsst ihr als **eigenes gepinnes Artefakt** in eure Kette aufnehmen. Euer 128k-Kontext-Ziel ist bei Strata Standard, kein Grenzfall.
4. **Serving-Modell:** `llama.app` als Backend-only-Port ohne Auth würde ich für Strata **nicht** übernehmen – Strata kann einen API-Key, und nach dem Cohere-Befund (unaufgeforderte Upload-Versuche des Modells) plus eurer eigenen Lücke „keine Quotas/Rate-Limits": API-Key aktivieren, Endpoint nur im LLM-Admin-Segment, **Egress-Deny für das Strata-Workload-Konto** (passt zu eurem rootless-Ein-Konto-pro-Workload-Prinzip – erst in AI Testing, wie von euch ohnehin geplant). Open WebUI + Keycloak-OIDC bleiben die Nutzer-Schicht; den 27B-llama.cpp-Endpoint parallel betreiben, bis ihr `--batch` auf gfx1030 mit 2–3 parallelen Anfragen getestet habt.
5. **Monitoring & Evaluations-Pipeline:** `/metrics` (Prometheus-Format, hinter API-Key) könnt ihr direkt als Podman-Health-Check nutzen; `strata_bench.py` + `needle_bench.py` passen sauber in eure GNAI-009-Modellbewertung – ich würde Flash-Next/Strata als dritten Modellkandidaten neben euren zwei definierten aufnehmen. Workaround `--adapt-every 100000` (Bug #884) in die Sollkonfiguration (GNAI-010-Pendant für Strata) dokumentieren.

Kurz: Der einzige „grundsätzliche" Umbau ist das **Deployment-Paradigma** – von „ generischer Container mit statischer Konfiguration" zu „gepinnte, versionierte Engine + Pack-Artefakte + Tuning-Flags als Code". Alles andere (Auth, VPN, Proxy) bleibt, wie du es dir gedacht hast.
