Die KI-Debatte hat sich lange so verhalten, als gäbe es nur eine Richtung: mehr Parameter, mehr Speicher, mehr Rechenzentren. Für Demos war diese Erzählung bequem. Für den Betrieb ist sie oft unerquicklich. Denn viele reale Anwendungen wollen gar nicht das größte Modell. Sie wollen eine Antwort, die schnell genug kommt, auf vorhandener Hardware läuft und keine ständige Verbindung in die Cloud erzwingt.

Genau dort werden kleine Modelle interessant. Nicht als moralische Alternative zu großen Systemen, sondern als pragmische. Sie lassen sich näher an den Daten betreiben, billiger ausrollen und in lokale Geräte integrieren, die niemand mehr auf dem Radar hatte. Die Frage ist nur: Wie weit trägt dieser Ansatz wirklich?

Wir haben das nicht auf einem frischen Server, sondern auf einem kleinen Fossil geprüft: einem OnePlus 5T von 2017 mit Snapdragon 835, acht CPU-Kernen und 8 GB RAM. Das Gerät ist alt genug, um jede wolkige Behauptung sofort zu entzaubern. Wenn ein Modell dort noch vernünftig läuft, ist das mehr als eine nette Folklore.

Was kleine CPU-Modelle so attraktiv macht

Der eigentliche Reiz kleiner Modelle liegt nicht nur in der Modellgröße, sondern in der veränderten Architektur. Ein kleines Modell auf der CPU kann ohne GPU-Farm, oft ohne Cloud-Zwang und in vielen Fällen direkt am Ort des Geschehens arbeiten. Das ist für Europa, für Edge-Szenarien und für datenschutznahe Systeme kein Randdetail. Es ist häufig der eigentliche Punkt.

Hinzu kommt etwas, das in KI-Diskussionen gern vergessen wird: Viele Aufgaben sind schmaler als die Modelle, die man auf sie wirft. Lokale Klassifikation, Extraktion, Zusammenfassung, einfache Dialoge, kontrollierte Tool-Aufrufe oder kleine Agentenschritte brauchen oft kein gewaltiges Sprachsystem. Sie brauchen eine präzise, latenzarme und berechenbare Inferenz.

Das eigentliche Problem ist nicht nur der Speicher

Wenn von CPU-Inferenz gesprochen wird, fällt schnell das Wort Quantisierung. Zu Recht. Große Modelle sind schon rein vom Speicherbedarf häufig unpraktisch. Acht Milliarden Parameter belegen in FP16 grob 16 GB. Das sprengt viele Notebooks, von älteren Smartphones ganz zu schweigen.

Quantisierung ist deshalb ein natürlicher erster Hebel. Weniger Bits pro Gewicht bedeuten kleinere Artefakte, geringeren Speicherverkehr und oft deutlich mehr Spielraum. Aber an dieser Stelle beginnt auch die häufigste Vereinfachung. Weniger Bits bedeuten nicht automatisch mehr Geschwindigkeit.

Auf moderner Hardware kann INT8 oder 4-Bit-Inferenz große Vorteile bringen. Auf älteren CPUs hängt der Gewinn jedoch an der Instruktionspalette. Wenn dem Prozessor geeignete Dot-Product-Erweiterungen fehlen, frisst der Rechenaufwand für Dequantisierung und Umwandlung den Speichervorteil teilweise wieder auf. Genau deshalb wollten wir nicht nur wissen, ob das Modell passt, sondern welcher Pfad auf alter ARM-Hardware tatsächlich schneller ist.

Unser Versuch: Qwen 2.5 in klein, aber ernst gemeint

Als Testmodelle haben wir Qwen 2.5 0.5B und Qwen 2.5 1.5B verwendet, jeweils in FP16 und einer Q8-Variante. Als Laufzeitumgebung diente llama.cpp, weil es sich für CPU-nahe Inferenz und GGUF-Artefakte inzwischen als robuster Standard etabliert hat.

Die Messung war bewusst schlicht gehalten, aber nicht schlampig. Pro Variante liefen 100 Messläufe mit konstanten Parametern, dazu kurze Warm-ups, damit Cache- und Taktverhalten sich stabilisieren. Wichtig war außerdem die CPU-Affinity: Die Inferenz wurde auf die vier schnellen Kerne des Snapdragon gebunden, um das Scheduling des Systems nicht mitmessen zu müssen.

# FP16 auf den "big"-Kernen
taskset -c 4-7 ./main -m qwen2.5-0.5b-instruct-fp16.gguf \
  -t 4 --n-predict 128 --temp 0 --seed 42 --no-mmap \
  -p "hi how are you doing"

# Q8 auf denselben Kernen
taskset -c 4-7 ./main -m qwen2.5-0.5b-instruct-q8_0.gguf \
  -t 4 --n-predict 128 --temp 0 --seed 42 --no-mmap \
  -p "hi how are you doing"

Die genaue Zahl ist am Ende weniger wichtig als die Richtung. Entscheidend war der Vergleich derselben Modelle unter denselben Bedingungen.

Das Ergebnis war auf den ersten Blick unlogisch

Beim kleineren Qwen 0.5B zeigte sich über die Läufe hinweg eine merkliche Streuung der Tokenraten. Das ist auf einem Mobilgerät wenig überraschend: Temperatur, Hintergrundprozesse und Taktregelung funken immer mit hinein. Überraschend war etwas anderes. Die FP16-Variante war auf dem Snapdragon 835 leicht schneller als die Q8-Version.

Das klingt zunächst paradox. Schließlich sollte das kleinere, stärker komprimierte Modell doch im Vorteil sein. Genau an diesem Punkt trennt sich Marketing von Architektur.

Beim größeren 1.5B-Modell wurde die Lage noch klarer. Es lief zwar grundsätzlich, fühlte sich aber bereits deutlich zäher an. Damit wird die Grenze sichtbar: Kleine Modelle auf alter CPU-Hardware sind praktikabel, aber nicht grenzenlos skalierbar.

Warum FP16 hier gegen Q8 gewinnt

Der Snapdragon 835 unterstützt zwar ARM-NEON sehr ordentlich, aber ihm fehlen die später wichtig gewordenen Dot-Product-Instruktionen für effiziente 8-Bit-Multiplikation. Das bedeutet praktisch: Die Q8-Gewichte sparen zwar Speicher, müssen aber beim Rechnen umständlicher behandelt werden. Der Pfad wird rechenlastiger, und genau dieser Zusatzaufwand frisst den erwarteten Vorteil auf.

Die FP16-Version dagegen profitiert von einem gut optimierten NEON/FMA-Pfad. Auf diesem Gerät war FP16 daher der Sweet Spot zwischen Speicherbedarf und Recheneffizienz. Die wichtige Lehre lautet nicht, dass FP16 grundsätzlich besser wäre. Die Lehre ist banaler und nützlicher: Quantisierung ist nur dann ein Gewinn, wenn sie zur Hardware passt.

Das gilt auch jenseits dieses Smartphones. Auf moderneren ARM-CPUs mit DotProd oder auf x86-Systemen mit VNNI oder AMX kann sich das Bild klar zugunsten von INT8 verschieben. Die richtige Antwort lautet also nicht “immer 8 Bit”, sondern “prüfe den Rechenpfad deiner Zielhardware”.

Was man daraus für die Praxis ableiten kann

Für ältere SoCs und viele schwächere Edge-Geräte lohnt es sich, kleine Modelle zuerst in einem konservativen Setup zu testen. Ein Modell um 0.5B bis 1B Parameter ist dort oft realistischer als das reflexhafte Greifen zu 3B oder 7B. Ebenso sinnvoll ist es, mehrere Artefakte gegeneinander zu prüfen, statt Quantisierung als linearen Fortschritt zu behandeln.

Für moderne CPUs verschiebt sich die Grenze. Dort können 4-Bit- und 8-Bit-Modelle sehr attraktiv sein, gerade wenn Bandbreite der eigentliche Engpass ist. Aber auch dann bleibt derselbe Grundsatz gültig: Nicht die Tabelle mit Modellgrößen entscheidet, sondern die Messung auf der konkreten Zielplattform.

Ein zweiter praktischer Punkt ist die Runtime. llama.cpp ist für diesen Bereich weiterhin ein starker Ausgangspunkt, weil es GGUF, Quantisierung und CPU-Pfade recht gut zusammenführt. Für andere Zielumgebungen können spezialisierte Laufzeiten wie OpenVINO oder servernahe Systeme wie vLLM sinnvoller sein. Wichtig ist weniger das Schlagwort als die Frage, ob die Runtime zur Hardware und zum Arbeitsprofil passt.

Der eigentliche Wert liegt nicht nur im Einzelmodell

Noch interessanter wird die Sache, wenn man aufhört, kleine Modelle als billigen Ersatz für große Modelle zu sehen. In vielen agentischen oder edge-nahen Systemen können mehrere kleine Modelle mit klaren Rollen produktiver sein als ein einziger Alleskönner.

Ein kleines Modell für Extraktion, ein zweites für Routing oder Tool-Auswahl, vielleicht ein drittes für knappe sprachliche Ausgabe: Solche Aufteilungen sind auf Multicore-CPUs oft realistischer, als man zunächst denkt. Der Speicherfußabdruck bleibt beherrschbar, die Zuständigkeiten werden klarer, und Ausfälle oder Schwächen eines Modells ziehen nicht sofort das ganze System in Mitleidenschaft.

Gerade für geisten ist das der interessantere Weg. Nicht die große KI-Geste, sondern ein sauber gebauter Stack kleiner Werkzeuge, die auf vorhandener Hardware sinnvoll zusammenspielen.

Fazit

Unsere Messungen auf dem Snapdragon 835 zeigen kein Wunder und keinen Absturz. Sie zeigen etwas Nützlicheres: Kleine Modelle auf alten CPUs können praktisch sein, wenn man die Architektur ernst nimmt.

Der entscheidende Punkt ist nicht bloß die Quantisierung, sondern die Passung zwischen Modell, Bitbreite, Runtime und Instruktionssatz. Auf alter ARM-Hardware ohne Dot-Product-Erweiterungen kann FP16 durchaus die bessere Wahl sein. Auf neuerer Hardware verschiebt sich das Verhältnis wieder.

Die eigentliche Einsicht lautet deshalb: Kleine lokale KI ist keine Notlösung. Sie ist ein eigener Entwurfsraum. Wer ihn sauber vermisst, kann auf erstaunlich bescheidener Hardware Systeme bauen, die schnell genug, privat genug und nützlich genug sind.

Weiterführende Quellen

Wenn Sie kleine Modelle auf CPU, Edge-Geräten oder lokaler Hardware produktiv einsetzen möchten, sprechen Sie uns gerne an: info@geisten.com