Eine aktuelle Diskussion auf r/LocalLLaMA sammelt praktische Tipps für den Betrieb lokaler LLaMA-Modelle, insbesondere für dauerhaft aktive Agenten-Workflows.

Für die Performance empfehlen Community-Mitglieder persistente KV-Caches oder SSD-gestützte Checkpoints, um wiederholte Kontexte nicht neu auszuwerten — CachyLLama soll etwa persistente SSD-KV-Checkpoints und einen System-Prompt-Cache eingeführt haben. Spekulatives Dekodieren gilt als großer Gewinn: Ein Test der llama.cpp-Methoden auf Qwen 3.6 27B ergab rund 2,7x mit MTP, 3,7x mit DFlash und etwa 6x mit einem n-gram-Stack bei echten Coding-Aufgaben. Linux wird Windows vorgezogen; ein Vergleich zeigte 5:25 gegenüber 12:57 Minuten Laufzeit.

Bei der Hardware sollte der VRAM zu Quant und Kontextlänge passen, da ein Überlaufen in den System-RAM alles verlangsamt. Für Multi-GPU über Rechnergrenzen hinweg hilft 10GbE bei kalten Ladevorgängen, RDMA bringt die größten Gewinne in großen Setups; ein Nutzer meldete rund 2000-2800 Prompt-Tokens/s und 88 Generierungs-Tokens/s über gepooltes All-GPU-RPC — verdreifachtes Dekodieren, weil alle Experten im VRAM mehr bringen als die Netzwerk-Latenz kostet. Mehr als vier Karten pro Consumer-Gehäuse seien ohnehin unrealistisch.

Bei Modell- und Runtime-Wahl werden VRAM-passende Quants empfohlen (z. B. Qwen3.6-27B-MTP als Q4_K_XL mit VS Code Copilot), q8_0-KV-Caches, mmproj-Offload und --cache-ram (48 GB reichten einem Nutzer für Qwen3.6 27B). Flags wie --flash-attn, --cache-type-k q8_0 und --model-draft fehlen, wenn LM Studio einen älteren llama.cpp-Build festpinnt.

Operativ rät der Thread, bei Agenten-Integrationen klein anzufangen — der eigentliche Engpass sei oft die API-Anbindung (etwa G-suite), nicht das LLM. Lokales Hosting sei ein Kompromiss aus Datenschutz, Kontrolle und Kosten — ein Nutzer berichtete rund 80 Dollar zusätzliche Stromkosten pro Monat für zwei alte Tesla-Karten im Dauerbetrieb — und kein Ersatz für Frontier-Cloud-Modelle.