16-Milliarden-Modell auf der TV-Box: smolmaxxing holt KI aus Uralt-Hardware

Worum es geht

In fast jedem Haushalt stehen Geräte mit Prozessor, Arbeitsspeicher und Flash-Speicher, die den Großteil des Tages nichts tun: TV-Boxen, alte Handys und Tablets, Einplatinenrechner oder Router. Das Projekt smolmaxxing will herausfinden, welches Sprachmodell so ein Gerät wirklich noch ausführen kann. Danach versuchen die Entwickler, es mit eigenen Optimierungen schneller zu machen. Der Code und eine ausführliche Dokumentation liegen auf GitHub unter github.com/hyperionaidev/smolmaxxing. Auf der koreanischen Tech-Plattform GeekNews wurde das Projekt jetzt vorgestellt.

Die Macher legen Wert darauf, dass jede Angabe direkt auf der jeweiligen Hardware gemessen wurde. Bisher gibt es zwei Testgeräte: eine Xiaomi TV Box S der dritten Generation und ein iPad Air der ersten Generation von 2013. Weitere TV-Boxen, Handys, Einplatinenrechner und Router sollen folgen.

Gerät 1: Eine TV-Box mit nur einem Gigabyte RAM

In der Xiaomi-Box steckt ein Amlogic-S7D-Chip mit vier Cortex-A55-Kernen bei 2,5 GHz. Das sind sparsame, eher langsame ARM-Kerne, die Befehle strikt der Reihe nach abarbeiten. Dazu kommen 1,9 GB RAM, von denen nur etwa 1 GB wirklich nutzbar ist, eMMC-Flash als Speicher und Android 14 ohne Root-Rechte. Auf dieser Box laufen Modelle von winzigen 260.000 bis zu 16 Milliarden Parametern. Die wichtigsten Ergebnisse, gemessen in Tokens pro Sekunde (ein Token entspricht grob einer Silbe oder einem kurzen Wort):

Der riesige Faktor von 77 beim 2B-Modell erklärt sich so: Die Originaldatei passte nicht in den Speicher und musste ständig aus dem Flash nachgeladen werden. Schon die erste Version, die ins RAM passte, lief mit 4,8 Tokens pro Sekunde. Ab diesem Punkt gerechnet beträgt der Gewinn noch das 1,6-Fache. Laut den Entwicklern schwankt die Geschwindigkeit der Box über den Tag um etwa 10 Prozent. Deshalb wurde jede Änderung direkt im Vergleich mit der vorherigen Version gemessen.

Als besten Kompromiss aus Tempo und Qualität empfiehlt das Projekt auf dieser Box Qwen3.5-2B. Ein größeres Modell ist nicht automatisch besser. Ling-mini-2.0 ist doppelt so groß wie Moon-Beam, schneidet bei der Qualität pro Byte aber schlechter ab und läuft langsamer. Die Qualität misst das Projekt in „Bits pro Byte“, also wie gut ein Modell einen festen englischen Text von 22 KB vorhersagen kann. Niedrigere Werte sind besser. Weil die Angabe pro Byte gilt, lassen sich auch Modelle mit unterschiedlicher Wortzerlegung fair vergleichen. Den besten Wert erreicht Qwen3.5-9B mit 0,885, das dafür aber nur 0,27 Tokens pro Sekunde schafft.

Warum der Flash-Speicher das eigentliche Problem ist

Die Entwickler beschreiben genau, wo die Grenzen der Box liegen. Ein einzelner Prozess kann etwa 0,96 GB belegen, bevor Android anfängt, Programme zu beenden. Im sogenannten Headless-Modus, bei dem Launcher und Google-Dienste zwangsweise gestoppt werden, sind es rund 1,15 GB. Der Flash-Speicher liest höchstens 278 MB pro Sekunde, und ein einzelner zufälliger Lesezugriff von etwa 1 MB dauert rund 6 Millisekunden.

Daraus folgt eine einfache Rechnung: Muss ein Modell pro Token X Megabyte aus dem Flash nachladen, kann es nie schneller als 278 geteilt durch X Tokens pro Sekunde sein. Laut Projekt begrenzt also der Speicher und nicht die CPU alles oberhalb von 2 Milliarden Parametern. Hier kommen Mixture-of-Experts-Modelle (MoE) ins Spiel. Sie bestehen aus vielen spezialisierten Teilnetzen, den „Experten“, von denen pro Token nur wenige rechnen. Moon-Beam-8B-A1B hat 128 Experten, von denen 6 genutzt werden. Pro Token braucht es damit nur etwa 1 Milliarde seiner 8 Milliarden Parameter.

Dafür hat das Team einen „Expert Pager“ gebaut. Er lädt Experten erst dann aus dem Flash, wenn sie gebraucht werden, ähnlich wie eine Bibliothekarin, die nur die gerade verlangten Bücher aus dem Magazin holt. Das Routing berücksichtigt außerdem den Zwischenspeicher und bevorzugt Experten, die schon im RAM liegen. Zusätzlich werden die Experten der nächsten Schicht im Voraus angefordert. So sank die Quote der Experten, die nicht im RAM lagen, von 13 auf etwa 2 Prozent, und Moon-Beam wurde von 4,4 auf 7,2 Tokens pro Sekunde schneller. Ling-mini-2.0 mit 256 Experten von je 1 MB, von denen 8 genutzt werden, läuft mit demselben Rezept ohne Änderungen.

Kann man 10 Tokens pro Sekunde bei 8B erreichen? Das Team hat es ausprobiert. Moon-Beam schafft 10,4 Tokens pro Sekunde, wenn nur 2 Experten pro Token rechnen, aber dann entsteht Kauderwelsch. Die beste Einstellung, die noch zusammenhängenden Text liefert, liegt bei etwa 7 bis 8 Tokens pro Sekunde.

Die Werkzeugkiste: eigene Kernel, 1-Bit-Modelle, Speichertricks

Die Optimierungen sind nach dem Engpass sortiert, den sie angehen:

• Rechenleistung: Insgesamt zehn Maßnahmen, darunter umgepackte Q2_K- und ternäre Formate für spezielle ARM-Befehle (vdotq_laneq) und ein Lookup-Table-Kernel für 1-Bit-Modelle. Ein Kernel ist eine handoptimierte Rechenroutine. Bei der Lookup-Table-Methode werden Ergebnisse aus einer vorberechneten Tabelle abgelesen, statt sie jedes Mal neu zu berechnen. Dazu kommen eine Attention-Berechnung in 8 Bit und eine verschmolzene Gated-DeltaNet-Berechnung, ein Architekturbaustein der neuen Qwen3.5-Modelle. Q2_K-Gewichte verarbeitet die Box dadurch mit 13,9 statt 7,8 Milliarden Gewichten pro Sekunde. Lange Antworten halbieren das Tempo nicht mehr.
• Arbeitsspeicher: Fünf Maßnahmen, darunter ein verkleinerter Ausgabekopf, der nur noch etwa 60.000 bis 65.000 statt aller Wörter des Vokabulars kennt (1,3 Prozent der Tokens fallen dadurch heraus), und eine verlustfreie ternäre Speicherung mit 1,875 Bit. Ternär heißt, dass jedes Gewicht nur die Werte −1, 0 oder +1 annimmt. Hinzu kommen der Headless-Modus und ein Cache für umgepackte Dateien im Flash. Pro Modell sparen diese Maßnahmen 0,2 bis 0,5 GB. Der freie Speicher stieg von etwa 1.000 auf etwa 1.300 MB.
• Flash: Streaming der Gewichte direkt am Systemcache vorbei (O_DIRECT) sowie MTP-Spekulation, bei der das Modell mehrere Tokens auf einmal vorhersagt und anschließend prüft. Dazu kommen der Expert Pager und das vorausschauende Laden. Das 9B-Modell wurde dadurch um 69 Prozent schneller.
• Ausgabequalität: Ein eigener Test erkennt, wenn lange Antworten in Wiederholungsschleifen kippen. Eine Wiederholungsstrafe von 1,15 über 256 Tokens senkte die Zahl solcher entgleisten Antworten von 12 von 13 auf 1 von 13.

Die Techniken sind laut Projekt nicht an ein bestimmtes Gerät gebunden. Der 1-Bit-Kernel braucht nur die einfachen NEON-Befehle, die praktisch jeder ARM-Chip hat. Die übrigen Kernel laufen auf jedem ARM-Chip mit dotprod-Erweiterung. Die Streaming-Engine funktioniert auf jedem Linux- oder Android-Gerät, dessen Modell größer ist als der Arbeitsspeicher. Gemessen wurde mit llama-server bei echten Chat-Anfragen und mit llama-bench, beides Teil des bekannten Projekts llama.cpp.

Gerät 2: Ein 13 Jahre altes iPad

Das zweite Testgerät ist ein iPad Air der ersten Generation mit Apple-A7-Chip, zwei Kernen und 1 GB RAM. Der Chip hat NEON, aber keine dotprod-Befehle. Das iPad läuft unter iOS 12.5.7 und wurde mit dem Tool Amethyst gejailbreakt. Ohne Jailbreak funktioniert das Ganze also nicht. Gerechnet wird nur auf der CPU mit 2 Threads und einem Kontext von 1.024 Tokens. Die Software wird auf einem Mac für das iPad kompiliert, und der Chat läuft als Webseite im eigenen Safari. Die Ergebnisse:

• Bonsai-1.7B (1-Bit): 24 bis 26 Tokens pro Sekunde, in langen Chats 18 bis 22
• Bonsai-4B: etwa 10 Tokens pro Sekunde
• Moon-Beam-8B-A1B (MoE): etwa 3,5 Tokens pro Sekunde, mit der Hälfte der Experten 5, dann aber mit schlechterer Qualität
• Ling-mini-2.0 (16B MoE): 2,6 bis 4,5 Tokens pro Sekunde, Experten aus dem Flash nachgeladen

Die Anleitung zum Kompilieren steht im Ordner ipad-air/ des Repositorys.

Offen dokumentiert

Auffällig ist, wie gründlich das Projekt dokumentiert ist. Die Datei EXPERIMENT.md beschreibt 160 einzelne Experimente (E1 bis E160) mit Messwerten, darunter auch die, die nicht funktioniert haben. Ein Beispiel ist Granite 4.0 H 1B von IBM. Es kam der Qualität des 2B-Modells am nächsten, lief nach dem Umbau aber nur mit 5,29 Tokens pro Sekunde und passte nur nach dem Freiräumen von Speicher. Die optimierten Modelldateien stellt das Projekt auf Hugging Face bereit. Nur die 9B-Variante muss man selbst bauen.

Einordnung

smolmaxxing zeigt, dass mit sorgfältiger Arbeit an Speicher und Rechenroutinen auf Billig-Hardware deutlich mehr möglich ist, als es die Datenblätter vermuten lassen. Auf einer Box mit 1 GB RAM laufen Modelle mit 8 und 16 Milliarden Parametern in Lesegeschwindigkeit. Die wichtigste Erkenntnis geht über das Kuriose hinaus: Auf Geräten mit wenig Speicher bremst vor allem der Flash-Speicher. MoE-Modelle sind deshalb der naheliegende Weg zu mehr Modellgröße, weil sie pro Token nur einen kleinen Teil ihrer Gewichte brauchen.

Einige Einschränkungen sollte man kennen. Alle Zahlen stammen vom Projekt selbst, unabhängige Nachmessungen gibt es bisher nicht. Die Qualität wurde nur über einen englischen Text gemessen, über Deutsch oder echte Aufgaben sagt das wenig. Modelle mit 1 bis 2 Milliarden Parametern bleiben inhaltlich klar hinter großen Cloud-Modellen zurück. Für das iPad braucht man einen Jailbreak, und der Headless-Modus der TV-Box beendet zwangsweise Systemdienste. Für den Alltag ist das alles eher unpraktisch. Als offen dokumentiertes Lehrstück für Bastler und Entwickler, die KI auf Edge-Geräten betreiben wollen, ist das Projekt aber sehr wertvoll.