senn-techsenn-tech
KI & Entwicklung
KI & Entwicklung2026-09-26· Von Franz Senn

Lokale KI wird nicht nur besser, sie wird kleiner

Seit vergangenem Montag liegt alles auf dem Tisch, was man für eine Antwort auf die Frage braucht, ob lokale Sprachmodelle noch aufholen. llama.cpp hat den ersten Major-Release seit zwei Jahren, vLLM die Version 0.30.0, Xiaomi mit MiMo v2.6 ein offenes Modell von 1,02 Billionen Gesamtparametern nachgelegt, und PrismML schiebt mit ternären Gewichten die Untergrenze der Modellgröße ein weiteres Stück nach unten. Die vier Meldungen richten sich an verschiedene Adressaten, zusammen ergibt sich ein Bild.

Logo von Hugging Face
Alle vier Modellmeldungen der Woche sind über Hugging Face geladen: Ternary Bonsai 2 seit 16. September, MiMo v2.6 seit 21. September, die MOPD-Nachbauten vom Sonntag. Die Lizenzen unterscheiden sich, MIT hier, Apache-2.0 dort, der Reifegrad kaum: für keins davon liegt eine eigene Benchmark-Suite vor, für MiMo immerhin ein externer Index. (Quelle: Simple Icons, Datei huggingface.svg (CC0))

llama.cpp v0.5.0: Das Betriebs-Release

Version 0.5.0 vom 23. September ist kein Modell-Release, sondern ein Betriebs-Release, und deshalb für uns wichtiger als jede Zahlenkolonne. --host akzeptiert jetzt kommagetrennte Adressen und UNIX-Sockets in einem Aufruf, CUDA bekommt conv2d als implicit GEMM, die ROCm-Strecke hat ihre fp32-Akkumulation auf MFMA-GPUs und wieder aktiviertes AllReduce. Dazu die zwei Zeilen mit Betriebssignal: Das RPC-Protokoll steht auf major v7, und die Build-Palette ist komplett auf CUDA 13.4 gezogen.

Aus major v7 folgt eine Regel für alle, die llama.cpp mit RPC über mehrere Maschinen verteilen: keine gemischten Versionen. Ein alter Worker neben einem neuen Client ist ab v0.5.0 schlicht ein Verbindungsfehler. Und bei den CUDA-Builds heißt 13.4, dass der Host-Treiber vor dem Container-Update mit muss. Beides steht so nicht im Changelog, es folgt daraus.

vLLM v0.30.0: Der Weight-Cache und der Host-RAM

762 Commits von 315 Mitwirkenden, Datum 22. September. Zwei Features verändern die Architekturfrage im Eigenbau:

Der Weight-Cache-Daemon hält post-quantisierte, TP-geshardete Gewichte dauerhaft im GPU-Speicher. Ein Neustart der Engine mappt sie per CUDA IPC neu (--load-format ipc_cache) statt sie von der Platte zu laden, neuerdings auch für FP4-Checkpoints und über mehrere Knoten. Was das für eine Umgebung mit mehreren Modellen bedeutet, kennt jeder der schon mal zwei Minuten gewartet hat bis die erste Anfrage durch ist: Der Neustart verschwindet als Kostenpunkt. Die Version läuft bei uns bereits, die Funktion aber noch nicht: Unsere Produktiv-Lane auf einer RTX 5090 zeigt seit dem Wochenende das Image vllm/vllm-openai:v0.30.0, gemessen per docker ps am 24. September. Der Cache-Start ist damit erstmals kein Grund mehr, mit dem Update zu warten.

HiSparse (per HiSparseConnector, #53781) lagert KV-Seiten bei Druck in gepinnten Host-RAM aus. Der Arbeitsspeicher des Servers wird damit offizieller Teil des KV-Speichers, mit Prometheus-Zählern dazu. Wer 32-GB-Karten fährt, kennt das Problem: Der KV-Cache läuft zuerst voll, die Gewichte zuletzt. Ob der Auslagerungspfad unter Last sauber bleibt, ist eine Messfrage für uns, noch keine Kommentarfrage.

Die Brechstellen, die vor dem Update jeder Config durchgehen muss: Scale-out-Endpoints nur noch opt-in über --enable-scale-out, GPTQ ohne g_idx, die 0.29-Deprecations sind raus, gRPC heißt vllm serve --grpc, und YaRN skaliert max_model_len nicht mehr nach.

AllesTested vergleicht die beiden Engines, mit denen wir arbeiten: vLLM für Durchsatz auf dedizierten GPUs, llama.cpp für Flexibilität auf allem was läuft. Die Aufnahmen sind älter als diese Woche, die Grenzen sind es nicht.

MiMo v2.6: 1,02 Billionen gesamt, 42 aktive, und wo das für uns aufhört

Xiaomi hat die MiMo-V2.6-Linie am 21. September auf Hugging Face gestellt, Lizenz MIT, Sparse MoE mit 1,02 Billionen Gesamtparametern und 42 aktiven pro Token. Die Modellkarte führt 70 Schichten, 384 Routed Experts mit 8 aktiven pro Token und 1.048.576 Stellen Kontext, dazu Hybrid Attention mit einem Fensterschritt von 128. Am Sonntag, dem 27.09. um 03:58 UTC sind zwei Repos nachgezogen: MiMo-V2.6-Pro-MOPD und Flash-MOPD, auf dem RL-Checkpoint nachdistilliert, laut Karte gegen sich wiederholende Tool-Aufrufe im Agentenbetrieb.

Die Zahl, die diese Meldung von einer Releaseseite in die Schlagzeile bringt, kommt von außen. Artificial Analysis führt MiMo-V2.6-Pro mit 46 Punkten auf dem Intelligence Index und damit auf Platz 1 der offenen Modelle seiner Klasse, vor GLM-5.3 mit 45 und Kimi K3 mit 44. Das beste proprietäre Modell derselben Liste steht bei 58. Zum Vergleich: dieselbe Messstelle wies MiMo-V2.5-Pro, veröffentlicht im April 2026, mit 26 Punkten aus. Der Sprung von 26 auf 46 ist unabhängig gemessen, die Benchmarkwerte auf der Modellkarte dagegen nicht, DeepSWE 71.9 gegen Claude Opus 5 mit 74.0 ist eine Selbstangabe von Xiaomi.

Gesamtparameter und aktive Parameter, in MilliardenV2.6 Pro, gesamt1024V2.6 Pro, aktiv42V2.6 Flash, gesamt311V2.6 Flash, aktiv15Distill Qwen, gesamt901100
Vierundzwanzigstel der Gesamtparameter rechnet pro Token. Die aktive Breite bestimmt, wie schnell ein Token wird, die Gesamtzahl bestimmt, wie viel Speicher die Datei füllt. (Quelle: Modellkarten von XiaomiMiMo auf Hugging Face, abgerufen 27.09.2026)

An unserer Hardware hört die Begeisterung an einer Dateiendung auf. Die Gewichte von MiMo-V2.6-Pro-RL belegen auf Hugging Face 534 Gigabyte, verteilt auf 130 Safetensors-Dateien; unsere Inferenz läuft auf vier RTX 5090 mit je 32.607 MiB, das sind 130.428 MiB Videospeicher zusammen, drei der vier Karten dabei mit je rund 31,9 GiB belegt, nvidia-smi am 27.09.2026 auf 192.168.180.3. Die Gewichte sind das 4,2-Fache dessen, was in unsere Karten passt, und kleiner Quantisieren hilft nicht, sie liegen schon quantisiert abgestuft da. MiMo-V2.6-Flash-RL bringt 166 Gigabyte mit, die offiziellen GGUF-Builds von ggml-org starten bei 117 Gigacity für Q2_K, und das passt nicht neben die Lane, die auf derselben Maschine läuft.

Übrig bleibt ein Modell, das zu uns passt: MiMo-V2.6-Distill-Qwen-9B, 9 Milliarden Parameter, 5,4 Gigabyte als Q4_K_M, ein Feinschliff auf Qwen3.5-9B mit 262.144 Stellen Kontext. Auf dem Zettel steht deshalb nur diese Größe, und zwar als Vergleichskandidat gegen unsere Qwen-Schiene; den Rest der Familie beobachten wir über die API, solange unsere Karten dafür zu klein sind. Ein zweiter Kandidat derselben Woche liegt noch tiefer: Ternary Bonsai 2 als GGUF, 16. September, Apache-2.0, 3,34 Millionen Downloads am 27.09. Die Karte rechnet mit 1,72 Bit pro Gewicht und rund 5,9 Gigabyte für ein 27-Milliarden-Modell, verlinkt aber eine eigene KNOWN_ISSUES.md, und die nötigen llama.cpp-Builds kommen aus einem Fork von PrismML statt aus dem Hauptzweig. Die Qualitätszahlen der Karte, 98,2 Prozent der FP16-Intelligenz und 47 Tokens pro Sekunde auf einem M5 Max, sind Selbstangaben, eine unabhängige Messung war am Sonntag nicht aufzutreiben. Im Beitrag zu Bonsai von dieser Woche steht die Einordnung dazu.

Was wir daraus mitnehmen

Die Kluft zwischen API-Abo und Eigenbau war selten kleiner, und sie liegt neuerdings im Betrieb: RPC-Versionstreue, KV-Auslagerung unter Last, Gewichte im Cache statt auf der Platte. Wer llama.cpp und vLLM pflegt wie andere Leute ihre Backup-Software, dem gehört diese Woche. Dazu passt unsere eigene Schiene: LibreChat, bei uns selbst im Einsatz, legte in der Woche 949 Sterne zu, so viel wie selten. Wer seine Modelle selbst betreibt, betreibt inzwischen auch die Werkzeugkette drumherum. Der nächste Prüfstein für die neuen Engines ist ein normaler Werktag mit vollen Chatprotokollen, über mehrere Wochen wiederholt.

Weiterführende Quellen

Fragen?
Müssen wir nach llama.cpp v0.5.0 oder vLLM v0.30.0 sofort updaten?+

Nein. llama.cpp v0.5.0 bringt ein neues RPC-Protokoll (major v7), gemischte Versionen über die Inferenz-Hosts hinweg brechen damit die Kommunikation. vLLM v0.30.0 hat vier Bruchstellen, darunter die Scale-out-Endpoints. Beide Updates erst planen, dann einspielen.

Gilt die NVFP4-Performance-Story dieser Woche für unsere RTX 5090?+

Nein. Das neue FlashInfer-Backend ersetzt Marlin als Default nur auf SM100 und SM103. Die RTX 5090 ist SM120, dort bleibt der bisherige Pfad. Wer die Schlagzeile auf unsere Karten rechnet, bekommt eine Zahl für fremde Hardware.

Sind ternäre Modelle schon einsatzreif?+

Die Architektur ist da, die unabhängige Messung fehlt. Ternary Bonsai 2 steht seit 16. September auf Hugging Face, mit 3,3 Millionen Downloads, aber mit eigener Known-Issues-Datei und einem llama.cpp-Fork als Voraussetzung. Wir testen, bevor wir urteilen.