Monatelang haben wir eine Idee verfolgt, die zu gut klang, um sie liegen zu lassen: Die Gewichte eines Modells nicht speichern, sondern ausrechnen. Statt Millionen Zahlen im Speicher eine kleine Funktion, die jedes Gewicht aus seinen Koordinaten erzeugt. Es hat funktioniert. Jeder erhoffte Mechanismus war messbar. Wir haben es trotzdem eingestellt. Hier steht, warum — mit den Zahlen, die es entschieden haben.
Die Idee kam aus einer Messung, nicht aus einem Paper
Wir trainieren auf einer einzelnen Consumer-Grafikkarte. Gemessen: 39,88 TFLOP/s in bf16, aber nur 16 GB Speicher. Rechenleistung ist im Überfluss da, Speicher ist knapp — und diese Asymmetrie legt einen Tausch nahe: Rechnen ausgeben, um Speicher zu sparen.
Also haben wir gebaut, was wir Koordinaten-Gewichtsfeld nannten: Jedes Gewicht einer Schicht wird zur Laufzeit aus seiner Position von einer kleinen gelernten Funktion erzeugt. Die Parameter der Schicht sind nicht mehr die Gewichte selbst, sondern die Koordinaten und das Feld, das sie ausliest. In unserer Zielkonfiguration komprimierte das die Schichten um das 22,6-Fache und das gesamte Modell um das 8,4-Fache.
Die erste Lehre: glatt kann nicht funktionieren
Unsere ersten Felder waren glatt — die naheliegende Wahl. Sie scheiterten, und zwar nicht zufällig. Ein glatter Kern hat exponentiell abfallende Eigenwerte; die Matrix, die er erzeugen kann, ist also praktisch niedrigrangig, egal wie viele Parameter man hineinsteckt. Genau das haben wir gemessen: Der Rang sättigte bei etwa 44 von 256 möglichen Richtungen, bei einem stabilen Rang von rund 1,3. Das Feld konnte eine echte Gewichtsmatrix prinzipiell nicht ausdrücken.
Rauheit ist kein Makel, sondern die Voraussetzung. Mit logarithmisch gespreizten Kosinus-Frequenzen im Band 5–200 erreichte das Feld vollen stabilen Rang — bei einer Gradienten-Kohärenz von 0,972. Erst das rauhe Feld ist ausdrucksstark genug.
Wir haben auch die naheliegenden Alternativen getestet — SIREN, Fourier-Merkmale, Chebyshev-Basen. Alle waren schlechter als schlichte Kosinusse. Das ist ein kleines Ergebnis, aber ein gemessenes.
Der Lauf, der es entschieden hat
Ein Kompressionsverfahren ist nur interessant, wenn es bei gleichen Kosten etwas einbringt. Also haben wir den ehrlichen Vergleich gefahren: gleiches Rezept, 500 Millionen Token, drei Arme. Ein CWF-Modell, ein dichtes Modell mit derselben erzeugten Form und ein dichtes Modell mit derselben physischen Parameterzahl.
| Arm | physisch | Loss @500M | Laufzeit | VRAM |
|---|---|---|---|---|
| CWF | 32,64 M | 4,3171 | 4,57 h | 3,41 GB |
| dicht (gleiche Form) | 57,49 M | 4,0188 | 3,31 h | 7,46 GB |
| dicht (gleiches Budget) | 32,68 M | 4,1498 | 2,52 h | 7,47 GB |
Lies die letzte Zeile zuerst. Ein schlichtes dichtes Modell mit derselben Parameterzahl erreicht den besseren Loss — in knapp der halben Laufzeit. CWF gewinnt genau eine Spalte: Speicher. Und in dieser Größenordnung passen beide dichten Zwillinge bequem in 16 GB, der Gewinn bringt also nichts.
Auch beim Trend bleiben wir ehrlich: Der Abstand schließt sich tatsächlich, um rund 0,16 nats pro Zehnerpotenz an Token. Naiv hochgerechnet wäre er bei etwa 35 Milliarden Token bei null. Aber das ist eine Hochrechnung über zwei Zehnerpotenzen aus einer halben Zehnerpotenz Evidenz. Das ist ein Trend, keine Vorhersage — und wir verkaufen ihn auch nicht als eine.
Woran es lag — und drei Hypothesen, die wir begraben mussten
Das Interessante ist nicht, dass CWF verloren hat, sondern dass die naheliegenden Erklärungen alle falsch waren:
- Keine Kapazitätsgrenze. Auf einen festen Batch angesetzt, drückt CWF den Loss auf 0,0074 — ein dichtes Modell erreicht 0,004. Die Ausdruckskraft ist da.
- Keine Überanpassung. Der Abstand zwischen Trainings- und Validierungs-Loss ist identisch zum dichten Modell (+0,086 gegen +0,090). Jeder Regularisierer, den wir dazugab, machte es monoton schlechter.
- Keine Frage der Optimierer-Konditionierung. Weight-Normalisierung und der Muon-Optimierer brachten beide nichts.
Was übrig bleibt, ist feiner: CWF holt pro Gradientenschritt weniger Signal heraus. Der Koordinaten-Gradient ist eine Summe über eine ganze Gewichtszeile, die Information pro Gewicht wird auf dem Rückweg also weggemittelt. Das Modell fittet die Trainingsdaten pro Token schlechter — und generalisiert aus dem Gefitteten exakt so gut wie ein dichtes. Es ist eine Unteranpassungs-Lücke, keine Generalisierungs-Lücke.
Noch ein Befund, der es wert ist, behalten zu werden: CWF ist ein Schicht-Kompressor, kein Embedding-Kompressor. Embeddings sind Nachschlagetabellen mit hoher Entropie — das falsche Ziel zum Zusammendrücken. Das Embedding dicht zu lassen schloss allein schon rund 88 Prozent der Lücke.
Was bleibt
Wir haben die Linie am 26. Juli 2026 geschlossen. Nicht weil sie gescheitert wäre — der Mechanismus ist bewiesen, die Kapazität ist bewiesen — sondern weil sie nicht der Weg zu einem besseren LuNa ist. In einer Größenordnung, in der Speicher nicht die bindende Grenze ist, bringt der Tausch von Rechenzeit gegen Speicher nichts.
Was weiterlebt, sind die Kernel, die unterwegs entstanden sind. Sie hingen nie am CWF-Ergebnis und machen heute unser normales Training schneller — diese Geschichte steht auf unserer Research-Seite.
Negativergebnisse werden selten aufgeschrieben — deshalb laufen sie immer wieder neu. Dieses hier hat echte GPU-Stunden gekostet. Wenn es jemand anderem dieselben Monate erspart, hat sich das Veröffentlichen gelohnt — inklusive der Stelle, an der wir uns selbst korrigieren mussten.