Liquid AI hat auf Hugging Face eine neue Reihe von Checkpoints der LFM2.5-Serie veröffentlicht, im GGUF-Q4_0-Format, trainiert mit einer Methode namens QAD (quantization-aware distillation, quantisierungsbewusste Distillation). Die vier Größen (230M, 350M, 1.2B-Instruct, 2.6B) erreichten in Benchmarks 97,1 %, 96,5 %, 97,4 % beziehungsweise 96,6 % ihrer jeweiligen BF16-Basiswerte.
Für alle, die sich nicht mit lokaler Inferenz beschäftigen, klingt das erst einmal unspektakulär. Um die Tragweite zu verstehen, muss man wissen, welchen Stellenwert Q4_0 im llama.cpp-Ökosystem hat.
Ein von der Community aufgegebenes Format
Q4_0 gehört zu den ersten 4-Bit-Quantisierungsverfahren, mit einer simplen Regel: Je 32 Gewichte teilen sich einen Skalierungsfaktor, der Rest wird direkt auf 4-Bit-Ganzzahlen komprimiert. Später entwickelte die Community die K-Quant-Reihe (Q4_K_M, Q5_K_M und Co.), die Bitbreiten je nach Wichtigkeit der einzelnen Tensoren unterschiedlich verteilt und bei gleicher Dateigröße deutlich genauer ist. Q4_0 verschwand dadurch weitgehend von der Bildfläche und überlebt nur noch auf älteren Geräten und in älteren Runtimes.
Es hat aber einen Vorteil, den ihm niemand streitig machen kann: eine regelmäßige Struktur, die sich direkt auf die int8-Skalarprodukt-Befehle von Arm-CPUs abbilden lässt. Die Blockaufteilung und Lookup-Tabellen von K-Quant brauchen auf Smartphone-CPUs ein paar Umwege mehr, Q4_0 nicht. Genau darauf zielen die von Liquid AI diesmal vorgelegten Geschwindigkeitswerte ab: Bei denselben Modellen sind die Q4_0-Checkpoints 4 bis 33 Prozent schneller als Q5_K_M und 3 bis 14 Prozent schneller als Q4_K_M.
Was Q4_0 also bislang ausgebremst hat, war stets die Genauigkeit. Genau da setzt QAD an.
Quantisierung wandert ins Training
Der übliche Ansatz ist PTQ (post-training quantization, Quantisierung nach dem Training): Erst wird das Modell fertig trainiert, dann komprimiert, dann geschaut, wie viel Genauigkeit verloren geht – verliert es zu viel, wird ein anderes Format probiert. QAD dreht das um: Das Modell soll schon während des Trainings wissen, in welche Form es später komprimiert wird. Ein hochpräzises Lehrer-Modell destilliert auf ein bereits quantisiertes Schüler-Modell, die Quantisierungsbeschränkung fließt ins Training ein, und die Gewichtsverteilung rückt frühzeitig an das 4-Bit-Raster heran. Liquid AI schreibt dazu im offiziellen Blog: "QAD substantially improves the Q4_0 checkpoint" (QAD verbessert den Q4_0-Checkpoint erheblich).
Das Konzept ist nicht neu, quantisierungsbewusstes Training wird bei Vision-Modellen schon seit Jahren eingesetzt. Der Haken bei der Übertragung auf Sprachmodelle sind die Kosten: Für jedes Zielformat muss ein eigener Trainingslauf durchgeführt werden. Dass ein Anbieter bereit ist, dafür zu zahlen, zeigt, dass er nachgerechnet hat. Downloads und Aufrufe von On-Device-Modellen rechtfertigen offenbar ein eigenes Training pro Format.
Verifiziert auf vier Geräten
Die Tests deckten zwei Hardwareklassen ab: MacBook Pro und NucBox EVO-X2 mit GPU-Inferenz, Samsung Galaxy S26 Ultra und Raspberry Pi 5 mit Arm-CPU-Inferenz. Dass der Raspberry Pi 5 auf der Liste steht, ist bemerkenswert – er steht für Szenarien ohne GPU und mit knappem Speicher, genau dort, wo der Vorteil von Q4_0 am größten ist.
Grob überschlagen: Ein 2,6-Milliarden-Parameter-Modell in 4-Bit-Speicherung wiegt gut 1,4 GB, dazu kommen KV-Cache und Laufzeit-Overhead – ein Smartphone mit 8 GB RAM kann das noch unterbringen und hat Spielraum für andere Aufgaben. Die 230M-Variante liegt im Bereich von wenigen Hundert Megabyte, passt problemlos als lokale Funktion in eine App.
Worauf diese Checkpoints wetten
Die Richtung dieses Kompromisses ist neu. In den vergangenen zwei Jahren bestand der Mainstream-Ansatz bei On-Device-Inferenz darin, Modelle zu verkleinern: weniger Parameter destillieren oder auf ein cleveres Quantisierungsformat wechseln. Liquid AI geht diesmal einen dritten Weg – Format und Parameterzahl bleiben unangetastet, der gesamte Optimierungsdruck verlagert sich ins Training.
Der Preis dafür: Die Methode funktioniert nur für die eigenen Modelle. Die Community kann damit keine von anderen veröffentlichten Q4_0-Gewichte retten, dafür bräuchte es die ursprüngliche Trainingspipeline. Das ist etwas, das nur der Modellhersteller selbst liefern kann, und einer der wenigen Punkte, an denen sich im Rennen um kleine On-Device-Modelle überhaupt noch ein Vorsprung herausarbeiten lässt: Bei gleicher Größe von 2,6 Milliarden Parametern und gleichem Lauf auf llama.cpp gewinnt am Ende, wessen 4-Bit-Version am wenigsten verliert.
Für Entwickler ändert sich an der Einstiegshürde nichts: GGUF Q4_0 ist das am weitesten verbreitete Format, llama.cpp und jede mit Q4_0 kompatible Runtime laden es direkt, ohne Codeänderungen, ohne neue Operatoren. Genau das ist auch der Grund, warum man auf ein eigenes Format verzichtet – Kompatibilität ist selbst schon eine Form von Distributionskraft.
Quellen: offizieller Liquid-AI-Blog, CocoLoop, Modellseite auf Hugging Face; die Genauigkeitswerte der vier Größen und die beiden Geschwindigkeitsbereiche wurden anhand der offiziell veröffentlichten Angaben überprüft.