Ein Computer in den Gewichten: Warum Bastler Prozessoren in Sprachmodelle kompilieren

Darum geht es

Sprachmodelle können über Mathematik plaudern, verrechnen sich aber bei einer zwanzigstelligen Multiplikation. Die übliche Abhilfe ist ein Werkzeug: Das Modell schreibt ein Stück Python-Code, ein externes Programm führt es aus und reicht das Ergebnis zurück. Eine kleine, gerade sehr aktive Bastlerszene geht einen anderen Weg und baut den Rechner direkt in das Modell ein.

Innerhalb weniger Monate sind dazu drei Projekte erschienen. Im März 2026 stellte das Start-up Percepta einen Transformer vor, der WebAssembly ausführt, also ein standardisiertes Maschinenformat, in das sich etwa C-Programme übersetzen lassen. Ende Oktober folgte Qwenputer von Divyansh Agrawal, ein 32-Bit-RISC-V-Prozessor in Qwen3.5-4B. Jetzt gibt es Qwenx86 vom Hugging-Face-Nutzer Quazim0t0: Vor die 32 Schichten von Qwen3.5-4B kommen 13 zusätzliche Schichten, die eine 64-Bit-x86-Maschine bilden. Die Model Card betont, dass diese Schichten keine gelernten Gewichte enthalten, sondern dass alle Werte ein Compiler berechnet.

Unsere These: Als Alltagswerkzeug taugt das noch nicht. Es ist aber ein ernsthafter Forschungsansatz, an dem sich zeigen kann, ob Modelle exaktes Rechnen künftig eingebaut statt über ein Tool erledigen.

Wie aus einem Programm Gewichte werden

Normalerweise lernt ein Transformer seine Gewichte im Training. Man kann sie aber auch von Hand ausrechnen, wenn man weiß, was jede Schicht tun soll. Den Grundstein legten Gail Weiss, Yoav Goldberg und Eran Yahav 2021 mit RASP. Das ist eine kleine Programmiersprache, deren Befehle genau den beiden Bausteinen eines Transformers entsprechen. Attention, der Mechanismus, mit dem ein Token in früheren Token nachschlägt, wird dort zur Operation „suche die passende Stelle und lies den Wert“. Das MLP, das kleine Rechennetz in jeder Schicht, wird zur Operation „berechne etwas aus dem, was hier steht“. DeepMind baute 2023 mit Tracr einen echten Compiler dafür: Er übersetzt RASP-Programme in Transformer-Gewichte. Gedacht war das als Labor für Interpretierbarkeitsforschung, weil man bei einem kompilierten Modell genau weiß, welchen Algorithmus es ausführt. Später kamen „Looped Transformers as Programmable Computers“ (ICML 2023) hinzu, die einen einfachen Computer in einen 13-schichtigen Transformer verdrahteten, der in einer Schleife läuft, und Googles ALTA (2024), das zusätzlich Schleifen beherrscht.

Die heutigen Projekte nutzen dieselben Grundtricks:

• Attention als Speicherzugriff. Ein Attention-Kopf vergleicht eine Anfrage mit allen gespeicherten Schlüsseln und liest den Wert am besten Treffer. Wählt man die Schlüssel geschickt, trifft immer genau eine Adresse. Percepta legt dafür jeden Schlüssel als Punkt (2j, −j²) ab. Fragt man mit (i, 1) an, ergibt sich die Punktzahl 2ij − j², und die ist genau bei j = i am größten. So wird aus einer Ähnlichkeitssuche ein exakter Arrayzugriff.
• MLP als Rechenwerk. Neuronen mit Schwellwert verhalten sich wie Logikgatter. Bei Qwenputer rechnet das MLP Additionen über Vier-Bit-Häppchen mit Übertrag aus, multipliziert in fünf Stufen und ermittelt Divisionen über Vorzeichenvergleiche. Laut Design-Dokument verteilen sich die elf Schichten ungefähr auf Befehl holen (Schicht 1–4), ausführen (5–9) und Ergebnis zurückschreiben (10–11).
• Gated DeltaNet als Arbeitsspeicher. Qwen3.5 nutzt neben normaler Attention auch Gated-DeltaNet-Schichten, eine Art Notizblock mit fester Größe, der bei jedem Token gezielt überschrieben wird. Qwenputer schreibt mit „One-hot“-Schlüsseln, bei denen genau eine Stelle aktiv ist. Dadurch wird jede Zeile dieses Notizblocks zu einer Speicherzelle, die sich exakt überschreiben lässt.

Jeder Prozessorschritt ist ein kleiner Block aus Token, die das Modell selbst erzeugt, die sogenannten Trace- oder Maschinen-Token. Wenn Qwen in seinem gewohnten Format einen <tool_call> schreibt, übernimmt die eingebaute Maschine den Aufruf. Die Maschinen-Token sind für Qwens eigene Schichten unsichtbar, nur das Ergebnis taucht wieder als normaler Text auf. Qwens Originalgewichte bleiben unverändert. Laut Model Card stimmte bei Qwenx86 das wahrscheinlichste nächste Wort an 48 von 48 getesteten Stellen mit dem Original überein.

Was Qwenx86 laut Model Card kann

Der Kern von Qwenx86 ist eine weiterentwickelte Fassung von Qwenputers RISC-V-Kern, ergänzt um x86-Flags und bedingte Sprünge. Er verwaltet 64 KB RAM, 256 KB Code-ROM und 128 KB schreibgeschützte Daten, alles im DeltaNet-Zustand. Indirekte Sprünge und SSE-Befehle fehlen. x86-Code wird vorher in interne Mikrobefehle übersetzt. Im Checkpoint steckt außerdem Firmware für sechs Werkzeuge: einen exakten Bruch-Rechner, ein abgespecktes MicroPython, einen kleinen C-Compiler, einen Notizspeicher, 647 physikalische Konstanten samt Periodensystem und 1.003 Python-Dokumentationseinträge.

Ein paar Einschränkungen sind wichtig. Der Arithmetiktest mit 1.000 von 1.000 gehört zum „Memory“-Modul der Version 2. Dieses läuft laut Model Card neben dem Modell und wird von Python-Code gesteuert, nicht von Qwen selbst. Der GSM8K-Test umfasst nur 28 Aufgaben, der Unterschied beträgt also drei Aufgaben. Bei Qwenputer endete GSM8K nach Angaben des Entwicklers sogar unentschieden, weil bei Textaufgaben das Denken der Engpass ist, nicht das Rechnen. Auch Qwenputers eigene Zahlen sind aufschlussreich: Bei DeepMinds Aufgabensatz mul_big steigt die Trefferquote von 55,0 auf 97,5 Prozent, mit einem echten Python-Werkzeug sind es 100. Die eingebaute Maschine rechnet also exakt. Die verbleibenden Fehler entstehen, wenn Qwen die Aufgabe falsch formuliert oder das Ergebnis falsch abliest. Das gilt bei einem externen Werkzeug genauso.

Nachgerechnet: Was kostet ein eingebauter Rechner?

Hier wird es ernüchternd. Aus den veröffentlichten Zahlen haben wir die Durchsätze abgeleitet:

Für ein C-Programm nennt die Qwenx86-Karte 0,1 bis 6 Millionen Maschinen-Token. Bei rund 4.000 Token pro Sekunde sind das nach unserer Rechnung etwa 25 Sekunden bis 25 Minuten. Ein Python-Aufruf auf dem eigenen Rechner dauert für dieselbe Aufgabe typischerweise Millisekunden. Den Doom-Lauf hat Aditya Narayana mit einer für Mikrocontroller gedachten Doom-Fassung durchgeführt, die das Bild in 25 Streifen zeichnet. Er zeigt ein einziges geprüftes Bild, kein Spiel, und Qwens Sprachschichten waren dabei gar nicht geladen. Am deutlichsten wird es beim Projekt qwendoom, das Qwenputer auf 4 MB RAM und 328 Schichten aufgebläht hat. Ein Spielbild kostet dort etwa 3,7 Millionen Token und 17 Minuten. Die komplette Demo mit 7.155 Bildern bräuchte rund zwei Monate, ein normaler C-Emulator schafft sie in 21 Sekunden. Grob gerechnet ist das ein Faktor von etwa 250.000.

Dazu kommt die Hardware. Die kompakte Qwenx86-Datei ist 8,75 GB groß und braucht rund 9 GB Grafikspeicher auf einer CUDA-GPU, eine 16-GB-Karte reicht also. Der zusammengeführte Qwenputer belegt in bf16 18,7 GB, der Entwickler empfiehlt dafür 24 GB. Die Variante QwenPU mit Vektoreinheit braucht 40 GB oder mehr. Außerdem laufen die schnellen Durchsätze nur mit einem eigenen Triton-Ausführungsprogramm, also selbst geschriebenem GPU-Code. Über den normalen Hugging-Face-Weg schafft der Chip laut Design-Dokument nur etwa 250 Token pro Sekunde.

Was spricht trotzdem dafür?

Auf Hacker News wurde Qwenputer in 147 Kommentaren intensiv diskutiert. Ein Nutzer fand es „wirklich nicht so interessant“, ein anderer hielt die Behauptung „keine externe Laufzeitumgebung“ für „ein wenig unehrlich“, weil ein Host-Programm die Ausführung steuert. Auch der zweite Kritikpunkt ist berechtigt: Ein Rechner, der in Tests auf 97,5 Prozent kommt, wirkt seltsam. Bei Percepta lautete der Einwand, Befehle auf einer echten CPU auszuführen sei immer schneller.

Es gibt aber auch ernst zu nehmende Argumente dafür, die zum Teil aus denselben Diskussionen stammen:

• Keine Sandbox: Es läuft kein fremder Code auf dem Host-Rechner. Der Computer kann nur in seinen 64 KB RAM schreiben, das verkleinert die Angriffsfläche. Prompt-Injection, also das Einschleusen fremder Anweisungen über den Text, bleibt dagegen möglich, wie Kommentatoren anmerkten.
• Nachprüfbarkeit: Jeder Rechenschritt liegt als Token-Spur vor und lässt sich Schritt für Schritt gegen eine Referenz prüfen. Qwenputer hat so rund 230.000 Positionen ohne Abweichung geprüft, die CHIP-8-Vorversion sogar 3,9 Millionen.
• Kein Unterbrechen: Häufige Toolaufrufe stören auf Servern das Bündeln vieler Anfragen (Batching). Läuft die Rechnung im Modell, entfällt der Umweg.
• Ein Modell als einzige Datei: Rechenwerkzeug, Nachschlagewerk und Notizspeicher stecken im Checkpoint und laufen überall dort, wo das Modell läuft.

Percepta geht beim Tempo am weitesten. Durch eine geometrische Datenstruktur namens HullKVCache sinkt der Aufwand pro Speicherzugriff von linear auf logarithmisch, also von „alle Einträge durchgehen“ auf „gezielt halbieren“. Das Team nennt über 30.000 Token pro Sekunde auf einer CPU und ein schweres Sudoku in unter drei Minuten. Der Code ist als transformer-vm (Apache-2.0) erschienen. Die Gewichte werden laut README „analytisch berechnet“, 35 WebAssembly-Befehle sind direkt eingebaut. Ein unabhängiger Nachbau durch den Blogger Oskar Austegard bestätigte das logarithmische Adressieren in einer Spielzeugversion. Er kritisiert aber, dass die Bezeichnung „konvexe Hülle“ irreführend sei, und lässt offen, ob das Ganze einen echten WebAssembly-Interpreter im Alltag schlägt.

Wer arbeitet sonst daran?

Die bekannten Grundlagen kommen aus der Forschung: Tracr von Google DeepMind, ALTA von Google, Looped Transformers aus Wisconsin und Princeton, dazu Percepta mit Geldgeber General Catalyst. Die aktuelle Welle von Qwenputer, Qwenx86, den Doom-Ablegern sowie Dateisystem- und NPU-Varianten stammt dagegen von Einzelpersonen, die das nach eigener Aussage in ihrer Freizeit machen. Hinweise darauf, dass große Labore kompilierte Rechenwerke in Produktmodelle einbauen, haben wir nicht gefunden. Arbeiten wie „Compiling Agentic Workflows into LLM Weights“ (2026) setzen auf Training und verfolgen damit einen anderen Ansatz.

Einordnung

Unsere Einschätzung: Qwenx86 und Qwenputer sind kein Werkzeug für deinen Alltag. Wer exakt rechnen will, ist mit einem Python-Toolaufruf schneller, billiger und mindestens genauso genau unterwegs. Die Projekte zeigen aber zwei Dinge sauber und nachprüfbar. Erstens lässt sich ein vollständiger, gegen echte Emulatoren getesteter Prozessor in die Standardbausteine eines gewöhnlichen Sprachmodells übersetzen, ohne dass die Sprachfähigkeiten messbar leiden. Zweitens stammt der Gewinn an Genauigkeit vom Rechenwerk, die verbleibenden Fehler entstehen an der Schnittstelle zwischen Sprache und Rechnung.

Offen sind die eigentlich spannenden Fragen. Lassen sich kompilierte Bausteine so einbauen, dass ein Modell beim Training lernt, sie zu nutzen? Kann man Rechenwerke wie Programmbibliotheken nachrüsten, wie es Percepta skizziert? Und rechnet sich das jemals gegenüber einer echten CPU? Bisher beruhen fast alle Zahlen auf Angaben der Entwickler. Peer-Review gibt es nicht, und die beeindruckendsten Demos laufen auf selbst geschriebenen Executoren statt auf Standard-Software. Als Forschungsrichtung lohnt es sich trotzdem, sie zu verfolgen.