KI auf dem Gerät · 8 Min. Lesezeit
Wie ein Sprachmodell aufs Handy passt
Apps mit lokaler KI verlangen erstaunlich viel Speicher, und der Grund ist kein
aufgeblähter Code. Wenn du verstehst, wohin diese Gigabyte gehen,
verstehst du auch, warum das Modell auf einem neuen Handy schnell und auf
einem alten träge ist – und was der Dateiname
Q3_K_S dir eigentlich sagt.
Ein Modell ist ein großer Haufen Zahlen
Ein Sprachmodell ist eine Menge gelernter Parameter – Gewichte. Jedes ist eine Zahl, und es sind Milliarden davon. „2B“ in einem Modellnamen steht für rund zwei Milliarden Parameter.
In voller Genauigkeit gespeichert, braucht jedes Gewicht 4 Byte. Zwei Milliarden Gewichte zu je 4 Byte sind rund 8 GB – und das für eines der kleineren Modelle. Das ist das Problem in einem Satz: Die Datei ist groß, weil es viele Zahlen sind und jede einzelne genau gespeichert wird.
Quantisierung: weniger Bits pro Zahl
Quantisierung speichert jedes Gewicht mit weniger Bits. Statt 32 Bit pro Gewicht nimmst du 8, 4 oder 3 – mit Skalierungsfaktoren je Block von Gewichten, damit die Näherung nah am Original bleibt.
Die Datei schrumpft dabei ungefähr linear:
- 32 Bit – ~8 GB für ein 2B-Modell. Volle Genauigkeit, für Handys ungeeignet.
- 8 Bit – ~2 GB. Sehr nah an der ursprünglichen Qualität.
- 4 Bit – ~1,1 GB. Meist der beste Kompromiss.
- 3 Bit – ~800 MB. Spürbar verlustreicher, aber weiter brauchbar.
- 2 Bit – noch kleiner, und die Qualität fällt deutlich ab.
Das ist verlustbehaftete Kompression, wie bei einem JPEG. Treib sie weit genug, und du siehst die Artefakte – bei einem Sprachmodell zeigen sie sich als vagere Antworten, Wiederholungen oder als Abdriften von der Frage.
Quantisierung macht ein Modell nicht gleichmäßig dümmer. Sie macht es ungenauer, und Ungenauigkeit zeigt sich zuerst bei den schwersten Eingaben.
Den Dateinamen lesen
Ein Name wie Q4_K_M oder Q3_K_S ist ein Rezept, keine
Versionsnummer:
- Q4 / Q3 – ungefähr wie viele Bits pro Gewicht.
- _K – ein „k-quant“-Verfahren, das sein Bit-Budget ungleich verteilt und dort mehr Genauigkeit behält, wo das Modell am empfindlichsten ist.
- _S, _M, _L – klein, mittel oder groß innerhalb dieses Verfahrens. Größer behält mehr Qualität und mehr Bytes.
Also ist Q3_K_S ein kleiner 3-Bit-k-quant: aggressiv komprimiert, gewählt, wenn es wichtiger ist,
aufs Gerät zu passen, als die letzten paar Prozent Qualität zu behalten.
GGUF: der Container
GGUF ist das Dateiformat, das die quantisierten Gewichte enthält, dazu die Metadaten, die eine Laufzeitumgebung braucht – Tokenizer, Architektur, Prompt-Vorlage. Eine Datei, kein Ordner voller Konfiguration daneben.
Für Handys ist das wichtig, denn GGUF ist ausgelegt auf Memory-Mapping. Statt 1,7 GB in den RAM zu lesen, bildet die Laufzeitumgebung die Datei in ihren Adressraum ab, und das Betriebssystem lädt genau die Teile nach, die gerade gebraucht werden. Deshalb läuft auch ein Modell, das größer ist als der freie RAM des Handys, und deshalb kommt die erste Antwort nach dem Öffnen der App langsamer als die nächste – die Seiten werden noch geladen.
Warum das Handy warm wird
Ein Wort zu erzeugen – ein Token – heißt, die Eingabe durch diese Milliarden Parameter zu schicken. Und danach noch einmal für das nächste Token. Eine Antwort mit hundert Wörtern sind hundert Durchläufe.
Das ist Dauerrechnen auf der CPU oder dem neuronalen Beschleuniger – genau die Last, mit der Handys thermisch am schlechtesten umgehen. Geräte drosseln, wenn sie heiß werden, eine lange ununterbrochene Generierung wird also mit der Zeit langsamer. Gut gebaute lokale Apps takten ihre Arbeit – sie legen Aufgaben auseinander, damit der Chip abkühlen kann – statt alles direkt hintereinander abzuarbeiten.
Warum alte Handys sich schwertun
Drei Grenzen, alle drei hart:
- Speicherbandbreite. Für jedes Token muss ein großer Teil der Gewichte gelesen werden. Das Tempo hängt oft daran, wie schnell der Speicher gelesen werden kann, nicht an der reinen Rechenleistung.
- RAM. Memory-Mapping hilft, aber ein Gerät, das ohnehin knapp dran ist, lädt ständig nach – und das Betriebssystem beendet die App womöglich einfach.
- Beschleuniger. Neuere Chips haben Hardware, die zu dieser Rechenart passt. Ältere fallen auf allgemeine Kerne zurück und sind um ein Vielfaches langsamer.
Deshalb nennen Apps mit lokaler KI ein Mindestgerät, statt alles unterstützen zu wollen. Unterhalb eines bestimmten Punkts ist die Erfahrung nicht schlechter, sondern unbrauchbar.
Der Handel, den du eingehst
Ein quantisiertes Modell in Handygröße kommt bei schwerem Denken nicht an ein großes Cloud-Modell heran. Für eine klar umrissene Aufgabe – was heißt dieses Wort in diesem Satz, übersetze diese Wendung – reicht es völlig, und es bringt drei Eigenschaften mit, die ein Cloud-Modell nicht bieten kann: Es arbeitet ohne Verbindung, es kostet pro Nutzung nichts, und der Text verlässt das Gerät nie.
Das ist der ganze Handel bei KI auf dem Gerät. Du verzichtest auf das größtmögliche Modell und bekommst dafür Privatsphäre, Offline-Fähigkeit und keine Abrechnung pro Nutzung.
Wie ClickBook das macht
ClickBook liefert ein quantisiertes GGUF-Modell mit und führt es über llama.cpp auf deinem Gerät aus. Unter iOS steckt es in der App, du musst also nichts herunterladen. Mehr über E-Reader mit lokaler KI, oder sieh dir an, wie ClickBook funktioniert.