An Exact Instrument for State Usage in Selective State-Space Models, and the Input-Driven Migration It Reveals

Stellen Sie sich ein Mamba-Modell wie ein riesiges, superintelligentes Orchester vor. In jeder Schicht dieses Orchesters befindet sich eine Bank aus 16 winzigen, eintönigen Instrumenten (genannt „Modes“). Im alten Denken gingen wir davon aus, dass der Dirigent (das Modell) eine feste Auswahl von, sagen wir, den besten 8 Instrumenten wählt, die das gesamte Lied lang spielen, ungeachtet dessen, was in der Musik passiert.

Doch diese Arbeit zieht den Vorhang beiseite und enthüllt ein schockierendes Geheimnis: Der Dirigent wählt keineswegs ein festes Set.

Stattdessen ist der Dirigent ein Meister der Improvisation. Für jedes einzelne Wort (oder jeden „Token“), das das Modell liest, entscheidet es augenblicklich neu, welche 8 Instrumente tatsächlich benötigt werden, um die Melodie zu tragen. Manchmal sind es die Flöten; manchmal die Violinen; manchmal die Trommeln. Die „wichtigen“ Instrumente wandern (migrieren) je nach Input. Wenn man das Orchester dazu zwingt, bei einem festen Set von 8 Instrumenten zu bleiben (eine „statische“ Wahl), bittet man sie, ein Jazz-Solo mit der Partitur eines Marschkapelles zu spielen. Es funktioniert, aber es klingt schrecklich im Vergleich zum echten Ding.

Das magische Werkzeug: Das „Exakte Instrument“

Woher wussten die Autoren das? Sie bauten ein mathematisches „exaktes Instrument“.

Da die interne Struktur des Orchesters eine spezielle Art von „diagonaler“ Anordnung ist (bei der sich die Instrumente nicht gegenseitig stören), konnten die Autoren den Output in eine perfekte Summe der Beiträge jedes einzelnen Instruments zerlegen. Sie erstellten einen „Gram-Tensor“ (denken Sie an ein superpräzises Scorecard), der ihnen exakt sagt, wie groß der Fehler wäre, wenn man eine bestimmte Gruppe von Instrumenten weglassen würde.

Sie testeten dieses Werkzeug gegen das echte Modell und fanden, dass es eine relative Fehlerrate von 2,3 × 10⁻⁷ aufwies. Das ist, als würde man die Entfernung von der Erde zum Mond messen und weniger als die Breite eines menschlichen Haares danebenliegen. Es ist keine Schätzung; es ist eine präzise Messung.

Die große Entdeckung: Die „Migrationslücke“

Mit diesem Werkzeug untersuchten sie Modelle, die von winzig (130 Mio. Parameter) bis massiv (7 Mrd. Parameter, wie der eingesetzte Falcon-Mamba) reichen.

Sie fanden heraus, dass in den aktivsten Schichten ein festes Set an Instrumenten doppelt so viel Fehler verursacht wie ein Set, das sich mit dem Input verändert.

• Die Statistik: In den am stärksten betroffenen Schichten lag die „Migrationslücke“ (das Verhältnis des Fehlers zwischen einem festen Set und einem wechselnden Set) zwischen 0,44 und 0,57.
• Die Bedeutung: Wenn man das Modell erlaubt, die besten Instrumente für jeden spezifischen Moment zu wählen (ein „input-scheduled oracle“), reduziert man den Fehler im Vergleich zu einer bloßen einmaligen Auswahl einer statischen Liste um die Hälfte.

Dies geschieht in jedem getesteten Modell: der Mamba-1-Familie, dem 7B Falcon-Mamba und sogar Mamba-2.

Was verursacht die Migration? (Das „Warum“)

Die Autoren fragten: Welcher Teil des Modells treibt all dieses Umschalten an?
Es gibt drei Hauptsignale in einer Mamba-Schicht:

1. Die Write Map ($B_t$): Entscheidet, welche Instrumente das Eingangssignal erhalten.
2. Der Readout ($C_t$): Entscheidet, welche Instrumente gehört werden.
3. Der Zeitschritt ($\Delta$): Wird oft als der „Selektivitäts“-Regler angesehen.

Sie führten ein „Frozen-Signal“-Experiment durch. Dabei wurde jedes Signal einzeln auf seinen Durchschnittswert eingefroren, um zu sehen, ob die Migration aufhörte.

• Das Ergebnis: Als sie die Write Map ($B_t$) einfroren, verschwand die Migration. Das Modell hörte auf, die Instrumente zu wechseln.
• Die Überraschung: Als sie den Zeitschritt ($\Delta$) einfroren, blieb die Migration exakt gleich.

Das Urteil: Das „Zeitschritt“-Signal, von dem viele dachten, es sei der Schlüssel zur Selektivität, trägt fast gar nichts zum Migrationssignal bei. Der wahre Held ist die Write Map ($B_t$). Sie ist der Gatekeeper, der Token für Token entscheidet, welche Instrumente spielen dürfen.

Die Konsequenz: Können wir das nutzen?

Die Autoren versuchten, dieses Wissen zu nutzen, um das Modell zu beschneiden (Pruning), um Platz zu sparen.

• Statisches Pruning: Wähle die besten 8 Instrumente basierend auf einem Durchschnittstest aus und behalte sie für immer.
• Input-Scheduled Pruning: Betrachte den aktuellen Satz, miss, welche 8 Instrumente gerade jetzt aktiv sind, und behalte nur diese.

Das Ergebnis:
Bei der halben State-Budget (Behalten von nur 8 aus 16 Modes) performte die Input-Scheduled Methode genauso gut wie (und in einigen Fällen sogar etwas besser als) das volle, unbeschnittene Modell in Bezug auf die reine Genauigkeit.

• Beim 130M-Modell hatte die Scheduled-Methode eine Perplexität von 11,84, während das unbeschnittene Modell bei 12,38 lag.
• Beim 7B Falcon-Mamba lag die Scheduled-Methode bei 4,44 und schlug das unbeschnittene Modell mit 4,48.

Es gibt jedoch einen entscheidenden Haken: Die Arbeit stellt explizit klar, dass diese „scheduled“ Methode ein Zwei-Pass-Oracle ist. Sie liest das gesamte Fenster einmal, um zu entscheiden, welche Instrumente beibehalten werden sollen, und führt dann den zweiten Durchgang aus, um den Output zu generieren. Das bedeutet, dass sie in einer realen Implementierung weder Rechenleistung noch Speicher spart (man muss die Daten zweimal lesen).

Die Autoren klären auf, dass dieses Ergebnis den realisierbaren Spielraum (realizable headroom) demonstriert, nicht einen einsatzfähigen Effizienzgewinn. Es beweist, dass das Potenzial besteht, dass ein winziges, super-effizientes Modell das riesige Modell erreicht – aber nur, wenn wir einen billigen, schnellen Prädiktor bauen können, der die richtigen Instrumente vorhersagt, ohne diesen teuren ersten Durchgang zu benötigen. Die aktuelle Methode zeigt uns lediglich die Decke dessen auf, was möglich ist.

Was sie ausgeschlossen haben

Die Arbeit ist sehr deutlich darüber, was nicht funktioniert:

• Statische Rankings: Methoden, die ein festes Set von Modes basierend auf durchschnittlicher Aktivität oder „Hankel-Energie“ (wie GHOST oder LAST) wählen, sind signifikant schlechter. Sie können mit dem beweglichen Ziel nicht mithalten.
• Zeitschritt-Aktivität: Das Pruning basierend darauf, wie aktiv das Zeitschritt-Signal ist, ist eine Sackgasse, da der Zeitschritt die Migration nicht antreibt.
• Einfache Prädiktoren: Sie versuchten, die Maske allein basierend auf der ersten Hälfte eines Satzes oder dem „Domänen-Typ“ (wie Code vs. Prosa) vorherzusagen. Diese billigen Tricks brachten nur 2–6 % des potenziellen Gewinns zurück. Das „wichtige“ Set an Instrumenten ändert sich so schnell (innerhalb weniger hundert Token), dass man die spezifischen Token, die man bewertet, messen muss, um den vollen Nutzen zu erzielen.

Das Fazative Fazit

Die Arbeit beweist, dass trainierte selektive State-Space-Modelle dynamische, lebendige Wesen sind, die ihre internen Ressourcen ständig basierend auf dem Input neu zuteilen. Die „Write Map“ ist der Dirigent dieser Migration. Obwohl wir noch nicht in der Lage sind, ein Modell einzusetzen, das seine eigenen Instrumente in Echtzeit wechselt, ohne die Kosten eines „Zwei-Pass“-Verfahrens zu verursachen, liefert diese Forschung eine exakte Karte des Territoriums. Sie zeigt uns, dass die aktuellen „statischen“ Pruning-Methoden eine enorme Menge an Performance liegen lassen und dass der Weg nach vorne darin liegt, Scheduler zu bauen, die diese Migrationen im Vorbeigehen vorhersagen können.