Geschrumpfte Chatbots: So passt die KI plötzlich in 4 GByte RAM

Quantisierung, also das Reduzieren der Genauigkeit gespeicherter Gewichte von Large Language Models (LLMs) und anderen generativen KI-Modellen, ohne dass deren Ausgaben stark an Qualität verlieren, ist bei sehr großen LLMs Standard. Jüngste Ungetüme wie Kimi K3 mit 2,8 Billionen Parametern werden gar nicht erst mit mehr als 4 Bit ausgeliefert, und auch ein guter Teil des Trainings hat schon mit 4 Bit stattgefunden. Üblich waren früher 32-Bit-Gleitkommazahlen fürs Training, ausgeliefert wurden FP16-Gewichte. Übliche Quantisierungsziele sind FP8, also Gleitkommazahlen mit 8 Bit Genauigkeit und Q4, also 4-Bit-Formate, die entweder mit Integerwerten speichern oder neue Gleitkommaformate wie NVFP4 (Nvidia) oder MXFP4 (offener Standard) verwenden. Dankenswerterweise gilt die Faustregel: Je größer das Modell (in Anzahl Parameter) ist, desto weniger schadet die Quantisierung der Antwortqualität. Während bei Modellen mit 8 bis 12 Milliarden Parametern die Qualitätseinbußen noch deutlich spürbar sind, fallen sie in der 100B-Liga (B steht für das englische Billion, also Milliarden) schon sehr gering (meist <1%) aus. Spätestens bei Modellen mit 300B und darüber (z.B. DeepSeek v4 Flash oder Qwen 3.5 397B) reduziert Quantisierung bis hin zu 4 Bit die Antwortqualität nicht mehr.

Generell gilt aber, dass die Qualitätseinbußen durch Quantisierung meist geringer sind, als die Gewinne, die sich durch den Einsatz größerer Modelle ergeben. Bei gegebener Hardware ist es also sinnvoller, ein quantisiertes großes Modell zu betreiben, als ein kleineres mit FP16-Genauigkeit. Der Speicher ist der limitierende Faktor. Hat man beispielsweise 12 GByte VRAM in der Grafikkarte, so ist man auf Modelle mit weniger als 6B Parametern beschränkt (FP16 = 2 Byte pro Parameter). Zusätzlich braucht man noch Platz für den KV-Cache. Realistisch sind also eher 4B-Modelle. Nutzt man dagegen 4-Bit-Quantisierung, kann man größere Modelle bis zur 20B-Klasse betreiben, zum Beispiel ein GPT-OSS 20B oder das neue AMD Instella 16B A3B.

Unter vier Bit: BitNet und Bonsai

Aktuell sind jetzt wieder Quantisierungen im Gespräch, die noch weiter gehen und mit weniger als 4 Bit pro Parameter arbeiten. Das ist grundsätzlich nichts Neues. So sorgte Microsoft schon im April 2025 mit BitNet b1.58 für Aufsehen, das im Durchschnitt mit nur 1,58 Bit pro Parameter auskommt. Der schräge Wert ergibt sich aus der Mischkalkulation, wo viele Parameter tatsächlich nur mit 0 oder 1, also einem Bit gespeichert werden, manche andere aber mit bis zu 4 Bit.

Auch damals war von Zeitenwende die Rede. Anschließend flaute der Hype aber schnell wieder ab, und die 4-Bit-Quantisierung blieb der Standard (etwa wenn man sich über ollama oder LM Studio ein Modell aus dem Katalog lädt). Jetzt wirbt das Startup Prism ML damit, ein 27B-Modell wie Qwen 3.6, das in den gängigen Benchmarks fast die Qualität eines Nemotron 3 Ultra (550B) erreicht, durch Quantisierung auf Consumer-Geräte zu bringen. Bonsai heißt die Modellfamilie und soll mit minimal 4 GByte RAM auskommen. Damit wäre sie sogar auf Handys und Rechnern ohne GPU nutzbar. Dafür benötigt man eine angepasste Variante von llama.cpp, einer gängigen Laufzeitumgebung für LLM-Inferencing. In Tests unter Ubuntu konnte der Autor dieses Artikels mit der „Ternary“-Variante, die im Schnitt mit 1,7 Bit pro Gewicht auskommt und 7,2 GByte groß ist (statt 54 GByte in FP16), auf einer Nvidia RTX 4070 Super mit 12 GByte VRAM 50 Token pro Sekunde generieren. Das ist mehr als passabel. Ab 30 Token pro Sekunde (T/s) wirkt ein interaktiver Chat-Betrieb verzögerungsfrei, weil man nicht schneller lesen kann als generiert wird. Im „Reasoning“-Modus, wenn das Modell erst Token für den internen Gebrauch produziert, bevor die finale Antwort an den Benutzer geht, haben sich 60 T/s als akzeptabel etabliert. Das bedeutet also rund 17 Sekunden Wartezeit für den Nutzer, wenn das Modell 1000 Thinking-Token generiert.

Die Antwortqualität war dabei inhaltlich gut, allerdings von der sprachlichen Korrektheit im Deutschen sehr zweifelhaft. Während das Originalmodell trotz chinesischer Wurzeln keinerlei Probleme mit deutscher Rechtschreibung, Wortwahl und Grammatik hat, fiel Bonsai 27B durch kreative Wortneuschöpfungen und Rechtschreibfehler auf (z.B. Haustiherd statt Haustier).

Mobil und auf der CPU: noch ein Geduldsspiel

Für einen Test auf dem Smartphone kam ein Asus Zenfone 9 mit 8 GByte RAM und der App „LLM AI Server with llama.cpp“ zum Einsatz. Dort lassen sich komfortabel Modelle bei Hugging Face suchen, herunterladen und über ein Web-UI im Browser direkt verwenden. Die App misst die Geschwindigkeit nicht. Gefühlt waren es allerdings rund 2 T/s. Das änderte sich auch bei einem Wechsel von 27B- auf 8B- oder 4B-Varianten nicht grundlegend.

Ähnliches gilt für den CPU-Betrieb. Ein flotter Intel Core i7-14700K mit 20 Kernen / 28 Threads erreichte nur 2 bis 3 T/s, was nicht wirklich praktikabel ist. In die Schublade „netter Showcase ohne praktische Nutzbarkeit“ ist auch Colibri einzuordnen: Der Hersteller der eigenen LLM-Laufzeitumgebung verspricht ein stark quantisiertes GLM 5.2 mit 744B Parametern auf Consumer-Hardware ganz ohne GPU mit nur 32 GByte RAM lauffähig zu machen. Das scheint nach Berichten im Internet auch zu funktionieren. Allerdings mit 0,3 Token pro Sekunde, wenn man eine schnelle SSD hat. Für die 1000 Reasoning-Token aus dem vorigen Beispiel wartet man also fast eine Stunde.