echo-core/memory/kb/youtube/2026-05-06_llama-cpp-35b-6gb-vram.md

Running a 35B AI Model on 6GB VRAM, FAST (llama.cpp Guide)

URL: https://youtu.be/8F_5pdcD3HY Data: 2026-05-06 Durata: 15:05 Tags: @work @tech #llama.cpp #AI #local-AI #hardware

---

TL;DR

Cum rulezi Qwen3 35B (model Mixture of Experts) pe un GPU de 8 ani cu 6GB VRAM la 17 token/s și 256K context — prin 5 flag-uri llama.cpp specifice arhitecturii MoE. Defaulturile sunt bottleneck-ul, nu hardware-ul.

---

Setup de test (worst-case floor)

• GPU: GTX 1060, 6GB VRAM, PCIe Gen3
• CPU: i3 8100, 4 core, fără hyperthreading
• RAM: 24GB DDR4
• Model: Qwen3 35B A3B — MoE, 35B parametri total, dar doar 3B activi per token (8 experți din 256 per layer)

---

Cele 5 flag-uri (de la 3 tok/s → 17 tok/s)

Flag 1: --n-cpu-moe 41 (+230%)

• Problema: Split naiv (jumătate GPU, jumătate CPU pe layers) = 3 tok/s. Fiecare layer aduce toți experții cu el pe CPU → PCIe se înfundă.
• Soluția MoE: Experții stau "adormiți" majoritatea timpului. Pune TOATE expert-blocks pe CPU (RAM), restul pe GPU.
• Rezultat: 3 → 10 tok/s

Flag 2: --no-mmap (+35%)

• Problema: llama.cpp face "lazy loading" din disk (mmap). Fiecare expert neîncărcat → page fault → pauză.
• Soluția: Încarcă toți cei 20GB în RAM la start. Niciun read din disk la inferență.
• Rezultat: 10 → 13.5 tok/s

Flag 3: --n-cpu-moe 35 (ajustare fină, +26%)

• 2GB VRAM liberi → readuci 6 layere de experți înapoi pe GPU
• Trade-off: context scade 100K → 64K (mai puțin room pentru KV cache)
• Rezultat: 13.5 → 17 tok/s

Flag 4: Turbo Quant KV cache (--cache-type-k q4_0 --cache-type-v q3_0)

• Problema: KV cache crește liniar cu contextul → mânâncă VRAM
• Soluția: Google DeepMind Turbo Quant — rotație aleatoare + quantizare agresivă (4bit keys, 3bit values), fără pierdere vizibilă de calitate
• Asimetrie justificată: grouped query attention 8:1 → keys suportă compresie mai mare
• Rezultat: Context 64K → 256K la același 17 tok/s (5.9/6GB VRAM)

Flag 5: --mlock (stabilitate pe termen lung)

• Problema: Kernelul paginează experții din RAM pe disk după ore de idle → stutter la token 1000
• Soluția: mlock — spui kernelului "nu atinge RAM-ul ăsta". Necesită 3 locuri: LXC/container permisiuni, Docker --cap-add IPC_LOCK, flag llama.cpp
• Rezultat: mlocked: 12KB → 16GB. Sistem stabil după o săptămână.

---

Ce NU a funcționat: Speculative Decoding

• Idee: draft model mic (Qwen3 0.8B) ghicește 8 token-uri → big model verifică în batch
• Rezultat: 17 → 11 tok/s (mai lent)
• De ce eșuează pe MoE:
  1. MoE + batching = memory thrash: 8 tokeni în batch pot activa 64 experți diferiți/layer → nu mai e batch real
  2. SSM layers (state space): 30/40 layers sunt SSM — secvențiale prin definiție, nu se pot paraleliza

---

Rezultat final

Model:    Qwen3 35B A3B (MoE)
VRAM:     5.9 / 6 GB
Context:  256,000 tokens
Viteză:   17 tok/s
Hardware: GTX 1060, 8 ani vechime

---

Puncte cheie

• MoE ≠ dense: Experții "dormiți" sunt mai ieftini în RAM decât pe GPU — inversul intuiției normale
• Defaulturile sunt bottleneck-ul, nu hardware-ul — 5 flag-uri = 5.6x speedup
• No-mmap e contra-intuitiv: "lazy loading" sună smart, dar pentru inferență e catastrofal
• Turbo Quant (DeepMind): 4bit/3bit KV cache fără pierdere vizibilă — folosește rotație aleatoare înainte de quantizare
• mlock e critic pentru producție — fără el, sistemul degradează silențios după ore
• Speculative decoding nu merge pe MoE+SSM — arhitectura contează, nu doar parametrii

---

Quote-uri

"The hardware isn't the bottleneck anymore. The defaults are."

"Dead weight if you're sitting on the GPU, but cheap rent if you're sitting in RAM."

"Twice the context, twice the memory." — KV cache crește liniar

"No code, no retraining, no quantization tricks, just telling the OS: stop being clever about my RAM."

---

Relevanță pentru Marius

• Rulezi modele mari local pe hardware vechi/modest — fără cloud, fără cost lunar
• Relevant pentru LXC 104 (Ollama) — flag-urile sunt compatibile și cu Ollama (via GGUF + llama.cpp backend)
• Qwen3 35B cu 256K context = poate procesa cod-sursă întreg ca context
• Flag-urile --n-cpu-moe sunt specifice MoE — nu se aplică la all-minilm (dense, mic)