Der Bericht stammt von einem langjährigen LocalLLaMA-Leser, der Bonsai-Ternary-27B als Drop-in-Ersatz für sein minimax-m3-Cloud-Abo evaluiert – ausgelöst durch Infrastrukturprobleme des Cloud-Anbieters (zufällige Abbrüche, verlangsamtes Prompt-Processing). Als Backend nutzt er einen PrismML-Fork von llama.cpp hinter llama-swap, davor läuft ein Pi-Agent mit selbst geschriebenen Erweiterungen für Obsidian-Vault-Verwaltung und ein selbst gebautes Projektmanagementsystem. Im direkten Vergleich mit Gemma 4 12B QAT (~1000 tk/s Prefill), Gemma 4 26B QAT (~400 tk/s Prefill) und Qwen 3.6 35B A3B (~300 tk/s Prefill) liegt Bonsai-Ternary-27B mit 600–700 tk/s Prefill im Mittelfeld, überzeugt aber als einziges Modell durch vollständiges Laden in den 16-GB-VRAM ohne Layer-Offloading. Decode-Geschwindigkeit beträgt 20 tk/s ohne dspark; mit funktionierendem dspark steigt sie auf ~40 tk/s – vergleichbar mit den Offloading-Alternativen. Ein konkreter Bug im PrismML-Fork sorgt dafür, dass der dspark-Draft-Kontext an den Hauptmodell-Kontext (150k) gekoppelt wird statt auf 4k zu bleiben, was zu CUDA-Speicherüberlauf führt. Besonders auffällig ist die schwache Instruktionstreue: Das Modell lädt einen vorgeschriebenen Produktivitäts-Skill nur in etwa einem von zehn Durchläufen eigenständig, findet zwar häufig Umwege, aber nicht immer den gewünschten.