12 GB VRAM Benchmarks: Ausführen von Qwen 3.6 und Gemma 4 Modellen auf einer RTX 4070 Super

Ein Reddit-Nutzer hat Geschwindigkeits-Benchmarks für den Betrieb mehrerer großer MoE-Modelle auf einer 12 GB RTX 4070 Super (mit +10% OC) veröffentlicht, gepaart mit einer AMD 9800X3D CPU und 64 GB DDR5-6000 RAM. Der Nutzer lagert die Anzeige auf die iGPU aus, um VRAM zu sparen, und stellt einen Leistungseinbußen von etwa 10% fest, falls dies nicht geschieht. Das Setup verwendet CUDA 13.1 und die neueste llama.cpp mit folgender Hardware-Konfiguration:
n-gpu-layers = 999
threads = 8
threads-batch = 16
batch-size = 4096
ubatch-size = 4096
ctx-size = 65536
flash-attn = true
Benchmark-Ergebnisse
Der Nutzer testete vier Modelle über Unsloth GGUF Quants in VS Code mit Cline und KiloCode (keine Tool-Call-Probleme). Alle Messungen sind in Tokens pro Sekunde (tgs) und Verarbeitung pro Sekunde (pps).
- Qwen3.6-35B-A3B-GGUF Q6_K_XL: 40 tgs, 2100 pps
- Qwen3.6-27B-IQ3_XXS: 16 tgs, 1000 pps
- Gemma 4 26B-A4B-it-UD-Q8: 26 tgs, 2150 pps
- Gemma-4-31B-it-IQ3_XXS: 13-16 tgs, 650 pps
Bemerkenswerte Konfigurationsdetails
Der Nutzer teilte individuelle Modellkonfigurationen mit spezifischer Optimierung. Die wichtigsten Punkte:
- Für Qwen3.6-35B-A3B:
n-cpu-moe = 35(lagert 35 MoE-Experten auf die CPU aus),cache-type-k = q8_0,cache-type-v = q8_0,swa-full = true,cache-reuse = 512, Kontextgröße 131072, Reasoning aktiviert mit Budget 8096. - Für Gemma 4 26B:
n-cpu-moe = 27, Kontext 102400,fit = onmitfit-target = 256undfit-ctx = 32768. - Für Gemma 4 31B: Verwendet spekulatives Decodieren mit
ngram-mod(spec-type = ngram-mod),n-gpu-layers = 58(teilweises GPU-Offloading),cache-type-k = q4_0,no-kv-offload = true. - Alle Modelle verwenden
flash-attn = trueundno-mmproj-offload = true.
Das bevorzugte Modell des Nutzers für die Webentwicklung ist Qwen3.6-35B-A3B, das er für seine Qualität und das Fehlen von Tool-Call-Problemen in VS Code-Erweiterungen lobt.
📖 Vollständige Quelle lesen: r/LocalLLaMA
👀 Siehe auch

Behebung der Fehler 'Navigate Unsupported' und Browser-Plugin bei selbst gehostetem OpenClaw auf Docker
Schritt-für-Schritt-Lösung für EACCES-Berechtigungsfehler, fehlendes Playwright und Chromium-Binärdateien beim Selbsthosten von OpenClaw mit Docker auf einer VPS wie Hostinger.

Wie OpenCLAW-Speicher tatsächlich funktioniert: Behebung des Agenten-‚Vergessens‘
OpenCLAW-Agenten verfügen nicht über persistente Erinnerungen zwischen Konversationen – sie rekonstruieren den Kontext aus Dateien wie SOUL.md, USER.md und MEMORY.md in jeder Sitzung neu. Häufige 'Vergessens'-Probleme entstehen durch aufgeblähte Sitzungen, unstrukturierte Speicherdateien und die Verwechslung von Chatverlauf mit dauerhafter Speicherung.

5 häufige Fehler bei der OpenClaw-Einrichtung und wie man sie behebt
Praktische Lösungen für die fünf häufigsten OpenClaw-Einrichtungsfehler: Fehlender persistenter Speicher, kein ausgehender Zugriff, überladener System-Prompt, fehlendes Fallback-Verhalten und Verwendung nur eines Modells.

Claude vs GPT für die akademische Doktorarbeit: Bewahrung der fachlichen Bedeutung in Methodenabschnitten
Ein Doktorand vergleicht Claude und GPT für die Überarbeitung von Aufsätzen über Computer Vision / Hardware Co-Design und stellt fest, dass Claude zuverlässiger die technische Bedeutung und die Argumentationsstruktur bewahrt, während GPT manchmal Aussagen vereinfacht.