In den letzten Beiträgen ging es oft um (Abo-)Modelle und OpenClaw. Damit habe ich viel Erfahrung gesammelt und es läuft soweit. Hier kann ich kurz ein Sideprojekt der letzten Wochen abwerfen: Fluxer.app (Discord-Alternative) + OpenClaw-Plugin. Dazu in einem anderen Beitrag mehr.

Also die Software läuft, aber mit dem HTPC war ich unzufrieden. Zusammengebaut aus einem i7-7700, 16 GB langsamen DDR4-RAM, einer 6700 XT mit 12 GB RAM und einem maßlos überdimensionierten 850-W-Netzteil. Der Gedanke, als ich den (Frankenstein-)HTPC gebaut habe: Kann man gelegentlich mal am TV in Full-HD zocken. Dafür war der perfekt — habe ich nur leider nicht oft gemacht. Aber zum Testen für OpenClaw habe ich ihn hinbenutzt, monatelang. War ich nie zufrieden mit. Die Kisten im Dauerbetrieb haben mich gestört. Also viel Recherche — Hardwarepreise sind ja gerade teuer. Das Ergebnis war ein GMKtec K12:

  • Ryzen 255H, Radeon 780M iGPU (Vulkan), 32 GB DDR5, 1 TB NVMe
  • RAM-Bandbreite: ~89 GB/s — der Flaschenhals

Was sich geändert hat: – HTPC hatte dedizierte GPU (6700 XT) — K12 hat nur iGPU (780M) – K12 ist ~5× kleiner, leiser, aber auch langsamer bei großen Modellen

Hier werden sich die ersten Fragen stellen: Wieso ein Mini-PC fürs lokale LLM? Da braucht man doch eine NVIDIA-Grafikkarte mit 32 GB VRAM.

Ja klar, und noch besser wäre etwas mit 48 GB, dann kann man Modelle in guter Qualität oder mehrere gleichzeitig nutzen. Aber es kommt auch darauf an, was man machen will. OpenClaw macht bei mir vieles im Hintergrund: Recherche zu Thema X, SVG erstellen. So richtig eilig ist davon nichts. Naja, und der Preis spielt auch eine Rolle.

Das Ziel für mich war: Ich will OpenClaw notfalls komplett mit lokalem Modell betreiben können, wenn auch langsam. Das heißt, eine gewisse Modellgröße ist erforderlich, mit Kompromissen bei der Geschwindigkeit.

Die Vorgeschichte: https://text.tchncs.de/wiulinu/openclaw-alfred-uebernehmen-sie-teil-6

Ergebnis: – Für Chat, Configs bearbeiten und alles, was etwas mehr Sorgfalt braucht: 30B-Modell oder mehr – Für Cronjobs: Gemma4-12B ist gut, spart viele Tokens im Abo

Cronjobs, scriptbasiert, laufen auch mit einem kleinen 2B-Modell. Nicht perfekt, aber sehr effizient: LFM2.5-2.6B Q8, genug Kontextlänge und gutes Tool-Calling. Kleiner ging nicht — darunter wurde es qualitativ schlecht, mit vielen Pseudo-Daten.

Nächster Schritt: Chat und Wartung von OpenClaw als Herausforderung.

Überlegung 1: Viel VRAM, aka Grafikkarte für den HTPC kaufen. Also viel Recherche zu neuer Hardware, gebrauchter Hardware, NVIDIA, Intel, AMD. Gebrauchte P40, Instinct MI50/60/100 … oder doch eine zweite 6700 XT? Das wären immerhin 24 GB VRAM. Aber 24 GB VRAM ist auch noch nicht ideal. Und was bei all diesen Lösungen bleibt: der hohe Stromverbrauch und die alte Hardware.

Einer meiner Lieblingskandidaten war eine Intel Arc Pro B60 mit 24 GB VRAM. Die wiederum braucht aber PCIe 5.0, und der HTPC hat nur PCIe 3.0. Das und die Überlegung mit 2× 6700 XT haben mir aber einen Hinweis gegeben, was für Tokens pro Sekunde relevant ist: Bandbreite.

RAM-Bandbreite

RAM-Typ Takt Kanäle Bandbreite
DDR4-2600 2600 MT/s Dual ~41,6 GB/s
DDR4-3200 3200 MT/s Dual ~51,2 GB/s
DDR5-4800 4800 MT/s Dual ~76,8 GB/s
DDR5-5600 5600 MT/s Dual ~89,6 GB/s (K12/780M)
DDR5-6400 6400 MT/s Dual ~102,4 GB/s
LPDDR5X-8000 8000 MT/s Quad ~215 GB/s (Strix Halo)

PCIe-Bandbreite

Standard Lanes Bandbreite
PCIe 3.0 ×16 16 ~15,75 GB/s
PCIe 4.0 ×16 16 ~31,5 GB/s
PCIe 4.0 ×4 4 ~7,88 GB/s
PCIe 5.0 ×16 16 ~63 GB/s
USB4 — ~5 GB/s

GPU-VRAM-Bandbreite

GPU VRAM Speicherbus Bandbreite Leistungsaufnahme
Radeon 6700 XT 12 GB GDDR6 192-bit 384 GB/s 230 W
RX 9060 XT 16 GB GDDR6 128-bit + 32 MB IC 322 GB/s 150 W
Intel Arc Pro B60 24 GB GDDR6 192-bit 456 GB/s ~150 W
Radeon 8060S (Strix Halo) 96 GB unified LPDDR5X ~215 GB/s 50–120 W
NVIDIA P40 24 GB GDDR5X 384-bit 346 GB/s 250 W
AMD MI50 32 GB HBM2 4096-bit 1 TB/s 300 W
RTX 4090 (Referenz) 24 GB GDDR6X 384-bit 1.008 GB/s 450 W

Was das für LLM-Inferenz bedeutet

Faustregel: tok/s ≈ Bandbreite ÷ aktive Parameter (Q4)

  • 780M (89 GB/s) + 3,8 B aktiv = ~23 tok/s
  • 6700 XT (384 GB/s) + 7 B aktiv = ~55 tok/s
  • B60 (456 GB/s) + 27 B aktiv = ~17 tok/s
  • MI50 (1 TB/s) + 27 B aktiv = ~37 tok/s

Mein Fazit

Bei mehr als einer Grafikkarte könnte man das Modell auf beide verteilen, aber jedes Mal, wenn die Grafikkarten Daten austauschen, bremst das PCIe — vor allem, weil ich nur PCIe 3.0 habe.

Eine große Grafikkarte ist zu teuer, und dann ist der Rest immer noch alte Hardware, die für den Dauerbetrieb nicht ideal ist. Aber es muss doch irgendeine halbwegs tragbare Lösung geben.

Die nächste Überlegung war dann: DDR4-RAM aufrüsten. Aber das ist auch zu langsam. Wirklich? Es ist Zeit für den nächsten Frickeltest. Ich bin mehrmals über die Option gestolpert, Modelle aufteilen zu können — aber das war immer so 50 % je Grafikkarte. Tief genug im Rabbit Hole tauchte dann die Option auf: „Lagere doch die Experts vom Mixture of Experts auf die CPU aus.”

Da dachte ich: Das bringt mich aber nicht weiter, so habe ich ja trotzdem nicht mehr Platz im VRAM fürs Modell. Man kann die Experts auslagern, aber das ist sozusagen zusätzlich notwendig und verteilt nur die Last. Ein Beispiel:

Qwen3.6-35B-A3B braucht 18 GB VRAM/RAM. Ich habe auf der Workstation (ja, es gibt nicht nur den HTPC) eine 9060 XT mit 16 GB VRAM — passt also nicht. Aber es gibt noch 32 GB DDR4 (sehr langsam). Also wieder Recherche: llama.cpp kann in beide Richtungen auslagern.

ramalama serve --backend vulkan \
  --image ghcr.io/ggml-org/llama.cpp:full-vulkan-b10775 \
  --runtime-args="-cmoe --cache-ram 0 --spec-type draft-mtp --spec-draft-n-max 2 --jinja" \
  hf://unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-IQ4_XS \
  --port 8081 --threads 6 --thinking false \
  --ctx-size 256000 --host 0.0.0.0

Jetzt sind also 18 GB DDR4-RAM belegt, und die Experts liegen in der 9060 XT. Auf der 9060 XT wurde es trotzdem knapp: 256.000 Kontext + Experts belegen ca. 10 GB VRAM, und der Desktop hat sich auch noch ein bisschen gegönnt.

Ja, und wie schnell?

Qwen3.6-35B-A3B IQ4_XS Modus Geschwindigkeit
Qwen3.6-35B-A3B IQ4_XS -cmoe (Experts → RAM, Attention → VRAM) ~15–25 tok/s
Qwen3.6-35B-A3B IQ4_XS -cmoe + MTP n=3 ~25–40 tok/s

25 tok/s sind okay, 40 tok/s empfinde ich als gut. Jetzt wusste ich: MoE-Modell + mind. 50 GB/s Bandbreite ist okay — alles darunter ein absolutes No-Go.

Ab hier war klar: Mit DDR5 ist das machbar. Aber man will ja trotzdem nicht auf der CPU rechnen. Und dann bin ich über Begriffe gestolpert, von denen ich noch nie gehört habe, die aber wie Magie funktionieren!

GTT

GTT steht für Graphics Translation Table — ein Speicherpool im Kernel, den der AMD-Treiber (amdgpu) für GPU-Operationen reserviert.

Prüfen: cat /sys/class/drm/card0/device/mem_info_gtt_total

Das ist für Vulkan. Es gibt noch andere Parameter für ROCm, und deprecated Parameter, und keine Ahnung was alles.

Weiter zur nächsten Erkenntnis: Eine Ryzen-APU erfüllt den Zweck sehr wahrscheinlich auch. Noch unklar ist, wie das mit der Grafikkarten-RAM-Zuweisung im BIOS funktioniert. Resizable BAR war auch noch so ein Stichwort. Dann gab es sehr unterschiedliche Berichte: einmal mit „Kannst im BIOS die Graka auf 24 von 32 stellen, passt” und „Mach 512 MB, Rest macht GTT” — ROCm, Vulkan, Intel, wild gemischt. Für mich kam nur Vulkan in Frage.

Die Magie an GTT + Vulkan ist folgendes: GTT hat als Standardwert die Hälfte vom verfügbaren RAM.

  • Standardkonfig: 32 GB RAM, 6 GB „VRAM”, macht 12 GB GTT — sprich 18 GB verfügbar fürs Modell.
  • Variante 1: 1 GB VRAM, ca. 15 GB GTT, 16 GB verfügbar fürs Modell.
  • Variante 2: 24 GB VRAM, 3 GB GTT, 27 GB verfügbar fürs Modell. Hängt vom BIOS ab, bei mir nicht möglich.
  • Variante 3: Nimm Variante 1 und ändere den GTT-Wert per Kernel-Parameter (siehe unten).

Meine Variante: 16 GB VRAM + 8 GB GTT. Reicht für Modell + 128K-Context und etwas Puffer. Kein Gefrickel, nur einmal im BIOS umstellen.

LLM-Performance auf dem K12

Warum MoE hier fast immer gewinnt: Die 780M hat ~89 GB/s Bandbreite (DDR5-5600 Dual-Channel). Pro Token werden die Modellgewichte aus dem RAM gestreamt. Dense 27B liest ~16 GB pro Token, MoE liest nur ~3,8 GB pro Token. Dasselbe Bandbreiten-Budget, aber 4× mehr Tokens pro Sekunde.

Theoretisches Maximum: 89 GB/s ÷ aktive Parameter (Q4) — z. B. 89 ÷ 3,8 = ~23 tok/s. Gemessen: 23–25, also passt.

Prüfen: cat /sys/class/drm/card0/device/mem_info_gtt_used

Richtige Lösung: ttm.pages_limit und ttm.page_pool_size in der Kernel-Cmdline, berechnet als (GB × 1024 × 1024 × 1024) / 4096.

Qwen3.6-35B-A3B auf dem K12 — live gemessen

Parameter Wert
Modell Qwen3.6-35B-A3B IQ4_XS (~18,2 GB)
Modellgewichte + MTP ~3,38 GiB
Context 84K
MTP n=2
tok/s 23 ohne MTP, 26–28 mit MTP
GTT belegt (84K) 5,20 GiB
GTT Limit 7,69 GiB
GTT frei ~2,49 GiB
KV-Cache (84K) ~1,70 GiB
KV-Cache pro Token ~20,6 KiB

Hochrechnung auf größere Contexte:

Context KV-Cache (ca.) GTT belegt (ca.) Frei Status
12K ~0,24 GiB ~3,62 GiB ~4,07 GiB ✅ locker
64K ~1,28 GiB ~4,66 GiB ~3,03 GiB ✅ komfortabel
84K ~1,70 GiB 5,20 GiB ~2,49 GiB ✅ stabil (gemessen)
128K ~2,58 GiB ~6,08 GiB ~1,61 GiB ✅ passt
160K ~3,30 GiB ~6,80 GiB ~0,89 GiB ⚠️ knapp, kein Puffer

Dazu die GTT-Rohdaten bei 84K-Context (live gemessen):

  • mem_info_gtt_used: 5.581.713.408 Bytes = 5,20 GiB
  • ttm/pageslimit: 2.015.931 Pages = 7,69 GiB Limit
  • KV-Cache bei 84K: ~1,70 GiB → ~20,6 KiB pro Context-Token

Die eigentlich spannende Zahl: 128K-Context passt auf 32 GB RAM — mit ~1,61 GiB Puffer. Das war vorher unklar, weil die hybride Architektur von Qwen3.6 (Gated DeltaNet + Attention) nur bei ~10 von 40 Blöcken KV-Cache erzeugt. Dadurch ist der KV-Cache ~75 % kleiner als bei einem Standard-Transformer.

Die 128K habe ich so auch getestet und jetzt im Einsatz. Sie läuft mit ca. 25 Tokens pro Sekunde.

HTPC verkauft, Mini-PC gekauft, Gesamtkosten 400 Euro.

Bonus: Der PC läuft (meistens) leise, braucht weniger Strom, sieht schöner aus und hat genug Platz fürs Modell.

#wiulinuslog #locallm #ryzen #780m #ramalama

#wiulinuslog