State Space Models vs. Transformer: Praxisleitfaden

Transformer werden nicht mehr lange die einzige Lösung im Feld bleiben. Ich weiß, das klingt nach einer gewagten Behauptung. Wir alle haben jahrelang zugesehen, wie die Transformer-Architektur alles dominiert hat, von Sprachmodellen bis zur Proteinfaltung. Doch nach den letzten Monaten, in denen ich State Space Models gegen Transformer-Baselines auf Produktionslasten getestet habe, bin ich überzeugt, dass der Wandel real ist. Nicht weil SSMs universell besser wären. Das sind sie nicht. Sondern weil sie bestimmte Probleme lösen, die Transformer grundsätzlich nicht bewältigen können, und die neueste Generation die Qualitätslücke so weit geschlossen hat, dass das Ignorieren von SSMs inzwischen eine Entscheidung über technische Schulden ist.

Das hier ist kein Hype-Artikel. Ich gehe durch, was State Space Models eigentlich sind, wo Mamba-3 wirklich etwas verbessert, wo SSMs immer noch durchfallen und wie dein Team über die Einführung nachdenken sollte. Von Praktiker zu Praktiker.

Warum Transformer bei großer Skalierung an eine Wand stoßen

Die Geschichte mit der quadratischen Skalierung kennst du schon. Self-Attention berechnet eine N×N-Matrix für eine Sequenz der Länge N, also vervierfachen sich Rechenaufwand und Speicherbedarf, wenn du die Kontextlänge verdoppelst. Lange Zeit spielte das kaum eine Rolle. Modelle liefen mit ein paar Tausend Tokens, und die Hardware kam mit.

Diese Ära ist vorbei. Die Workloads, die wir heute bauen, verlangen routinemäßig Kontexte von 100K+ Tokens. Code-Assistenten müssen ganze Repositories sehen. Multimodale Pipelines verarbeiten stundenlange Videos. Agenten pflegen Gesprächsverläufe über Tage hinweg. Bei diesen Größenordnungen ist quadratische Attention nicht nur teuer, sondern eine Wand.

Das KV-Cache-Problem verschärft die Lage. Bei der autoregressiven Generierung speichert jede Transformer-Schicht Key-Value-Paare für jedes Token, das sie gesehen hat. Dieser Cache wächst pro Schicht linear und frisst schnell GPU-Speicher. Ich habe erlebt, wie ein 7B-Transformer bei 128K Kontext allein für den KV-Cache 40 GB VRAM belegt hat. Das ist Speicher, den du nicht fürs Batching weiterer Anfragen nutzen kannst.

Quadratisches Speicherwachstum macht Millionen-Token-Kontexte mit Standard-Attention nahezu unmöglich
Das Wachstum des KV-Cache begrenzt die gleichzeitigen Nutzer pro GPU, was in der Produktion direkt die Kosten erhöht
Der Energieverbrauch bei Inferenz mit langen Kontexten auf Transformer-Basis wird schwer zu rechtfertigen
Echtzeitanwendungen (Robotik, Edge-AI) brauchen eine Token-Generierung im Sub-Millisekundenbereich, die Attention nicht liefern kann
Das Phänomen der „Attention Sinks“ verschlechtert die Qualität bei sehr langen Sequenzen, selbst wenn genug Speicher vorhanden wäre

Das sind keine theoretischen Bedenken. Sie sind der Grund, warum drei verschiedene Teams, mit denen ich gearbeitet habe, letztes Jahr ernsthaft Alternativen zu evaluieren begannen.

Wie State Space Models tatsächlich funktionieren

State Space Models stammen aus der Regelungstechnik, wo sie seit Jahrzehnten zur Modellierung dynamischer Systeme eingesetzt werden. Die Grundidee ist simpel: Statt bei jeder Ausgabe alle vorherigen Tokens anzuschauen (wie Attention es tut), pflegst du einen komprimierten verborgenen Zustand, der sich über die Zeit entwickelt. Neue Tokens aktualisieren den Zustand, und der Zustand erzeugt die Ausgaben. Mehr steckt nicht dahinter.

Mathematisch wird ein SSM durch vier Matrizen definiert, A, B, C und D, die bestimmen, wie sich ein verborgener Zustand h als Reaktion auf die Eingabe x entwickelt. Du diskretisierst die kontinuierlichen Gleichungen für sequenzielle Daten und erhältst eine Rekurrenz, die sich zur Inferenz denkbar einfach berechnen lässt.

import torch
def ssm_step(A_bar, B_bar, C, D, h, x_t):
"""Single SSM step: O(1) memory, O(1) compute.
Compare this to attention, which needs to look at
every previous token. The SSM just updates its state.
"""
h_new = A_bar @ h + B_bar @ x_t  # Update hidden state
y_t = C @ h_new + D * x_t         # Compute output
return h_new, y_t
def ssm_generate(A_bar, B_bar, C, D, tokens, embed):
"""Autoregressive generation with constant memory.
Whether you've processed 100 tokens or 500,000,
this uses the same amount of memory.
"""
h = torch.zeros(A_bar.shape[0])
outputs = []
for t in tokens:
x_t = embed(t)
h, y_t = ssm_step(A_bar, B_bar, C, D, h, x_t)
outputs.append(y_t)
return torch.stack(outputs)

Die Eleganz steckt schon im Code. Die Inferenz benötigt O(1) Speicher und O(1) Rechenaufwand pro Token, unabhängig von der Sequenzlänge. Kein KV-Cache. Keine quadratische Explosion. Die gesamte Historie ist im verborgenen Zustandsvektor komprimiert.

Der Haken? Beim Training wäre es quälend langsam, diese Rekurrenz sequenziell auszuführen. Der Trick: Dieselbe Berechnung lässt sich als Faltung oder paralleler Scan umformulieren, und damit kommen GPUs gut zurecht. Du bekommst also paralleles Training und rekurrente Inferenz, das Beste aus beiden Welten.

Von Mamba zu Mamba-3: Was jede Generation behoben hat

Frühe SSMs wie S4 haben das Konzept bewiesen, hatten aber eine entscheidende Schwäche: Inhaltsbasiertes Schlussfolgern funktionierte schlecht. Die Zustandsübergangsmatrizen waren für alle Eingaben fest, das Modell konnte also nicht entscheiden, was es behalten und was es vergessen sollte, abhängig davon, was es tatsächlich las. Das ist, als würdest du Notizen nach der Regel machen, „schreibe jedes dritte Wort auf“. Du erfasst etwas Nützliches, kannst dich aber nicht daran anpassen, was wirklich wichtig ist.

Mamba, 2023 von Albert Gu und Tri Dao vorgestellt, behob dies mit einer eleganten Idee: Die SSM-Parameter werden eingabeabhängig gemacht. Statt fester Matrizen A, B und C berechnet Mamba sie als Funktionen des aktuellen Tokens. Das Modell lernt, relevante Informationen selektiv zu speichern und Rauschen zu verwerfen. Dieser „selektive“ Mechanismus gab SSMs die Inhaltsbewusstheit, die ihnen gefehlt hatte.

Mamba-2 lieferte die theoretische Erkenntnis, dass strukturierte SSMs und lineare Attention mathematisch dual sind, das sogenannte State Space Duality (SSD)-Framework. Das war nicht nur akademisch. Es ermöglichte hardwarebewusste Implementierungen, die die Tensor-Cores der GPUs besser ausnutzen und den Trainingsdurchsatz deutlich steigerten.

Mit Mamba-3 wird es aus Sicht des Deployments spannend. Drei Neuerungen sind besonders wichtig:

Mehrskaliges Zustandstracking: Das Modell hält den Zustand gleichzeitig in mehreren zeitlichen Auflösungen und erfasst so lokale Muster und weitreichende Abhängigkeiten, ohne eines davon zu opfern
Adaptive Zustandskompression: Der verborgene Zustand wächst bei komplexen Textpassagen und schrumpft bei vorhersehbarem Text, was Rechenaufwand spart, ohne die Qualität zu verlieren
Verbesserte Initialisierung und Gating: Die Trainingsstabilität bei großer Skalierung hat sich deutlich verbessert, was enorm wichtig ist, wenn du Millionen für einen Trainingslauf ausgibst

Mamba-3 schlägt Transformer nicht bei jedem Benchmark. Das muss es auch nicht. Es erreicht bei der Mehrheit der Standardevaluierungen die gleiche Qualität und benötigt dabei nur einen Bruchteil des Inferenz-Rechenaufwands. Für die meisten Produktionslasten ist das der Kompromiss, der zählt.

Lineare Attention und die Annäherung an SSMs

Es gibt eine parallele Entwicklung, die man verstehen sollte. Lineare Attention geht dasselbe Effizienzproblem an, aber von innen heraus, im Rahmen des Transformers. Standard-Attention berechnet die volle N×N-Matrix. Lineare Attention ersetzt die Softmax-Funktion durch eine zerlegbare Kernelfunktion und ordnet die Mathematik so um, dass diese quadratische Matrix nie materialisiert werden muss.

# Standard attention: O(N^2 * d)
# score = softmax(Q @ K.T / sqrt(d)) @ V
# Linear attention: O(N * d^2)
# Replace softmax with kernel feature map phi()
# Rearrange: compute K^T @ V first (d×d), then multiply by Q
def linear_attention_step(q_t, running_kv, running_k, k_t, v_t, phi):
"""Incremental linear attention — runs like a recurrence.
This is why SSMs and linear attention are duals:
both compress history into a fixed-size state.
"""
k_feat = phi(k_t)
q_feat = phi(q_t)
running_kv = running_kv + k_feat.unsqueeze(-1) * v_t.unsqueeze(-2)
running_k = running_k + k_feat
y_t = (q_feat @ running_kv) / (q_feat @ running_k + 1e-6)
return y_t, running_kv, running_k

Schau dir den Code genau an. Lineare Attention hält, inkrementell ausgeführt, einen laufenden Zustand und aktualisiert ihn mit jedem neuen Token. Klingt bekannt? Sollte es auch, denn sie tut im Wesentlichen dasselbe wie ein SSM. Das SSD-Framework hat diese Verbindung formal gemacht, und es ist eine der wichtigsten theoretischen Erkenntnisse der jüngeren Forschung zur Sequenzmodellierung.

Architekturen wie GLA (Gated Linear Attention) und RetNet-Varianten gehen weiter und ergänzen datenabhängiges Gating, wodurch die Grenze zwischen linearer Attention und selektiven SSMs fast vollständig verschwimmt. Das praktische Fazit: Betrachte diese Ansätze nicht als Konkurrenten. Sie nähern sich einander an.

Hybride Architekturen: Was in der Produktion tatsächlich gewinnt

Das sage ich Teams, die mich fragen, ob sie auf SSMs umsteigen sollten: Setzt nicht rein auf eine einzige Technik. Die Architekturen, die gerade die besten Ergebnisse liefern, sind Hybride, die SSM-Schichten mit einer kleinen Anzahl von Attention-Schichten kombinieren. Verschiedene Rechenprimitive sind für verschiedene Aufgaben gut geeignet, und so zu tun, als wäre das nicht so, bedeutet, Leistung zu verschenken.

SSM-Schichten sind stark darin, sequenzielle Informationen effizient zu komprimieren und weiterzugeben. Attention-Schichten sind bei präzisem, inhaltsbasiertem Abrufen immer noch unschlagbar: „Finde die genaue Zeile auf Seite 47, die diese Frage beantwortet.“ Ein gut entworfener Hybrid nutzt SSMs für 80–90 % seiner Schichten und streut Attention dort ein, wo sie am meisten bringt.

Jamba-artige Modelle: Abwechselnd Mamba- und Attention-Schichten mit MoE-Feed-Forward-Blöcken, die dynamisch zwischen effizienter SSM-Verarbeitung und präziser Attention wechseln
Griffin-Familie: Rekurrente Gated Linear Units, kombiniert mit lokaler Sliding-Window-Attention, starke Ergebnisse bei minimaler voller Attention
Mamba-Attention-Hybride: Mamba-3-Blöcke für die meisten Schichten, mit vollen Attention-Schichten an strategischen Tiefen für das globale Routing von Informationen
Nachfolger von StripedHyena: Verschachtelung von Gated Convolutions, SSM-Schichten und sparsamer Attention in NAS-optimierten Mustern

Die Zahlen untermauern das. Mehrere unabhängige Gruppen haben gezeigt, dass ein Verhältnis von 85 zu 15 zwischen SSM- und Attention-Schichten bei gleicher Parameterzahl die Qualität reiner Transformer erreicht und gleichzeitig die Inferenz-FLOPs um 40–60 % senkt. Die Speicherersparnis ist bei Workloads mit langen Kontexten noch größer. Das ist keine marginale Verbesserung. Das halbiert deine GPU-Rechnung.

Produktionsbenchmarks: Wo SSMs überzeugen und wo nicht

Lass mich konkret werden, denn vage Effizienzversprechen helfen niemandem, der Deployment-Entscheidungen treffen muss.

Inferenzdurchsatz: Ein Mamba-3-basiertes Modell mit 8B Parametern erzeugt Tokens mit gleicher Geschwindigkeit, egal ob der Kontext 1K oder 500K Tokens lang ist. Ein vergleichbarer Transformer wird mit wachsendem KV-Cache zunehmend langsamer. Bei 500K Kontext liefert das SSM-Modell pro GPU den 5- bis 8-fachen Durchsatz. Das ist keine Theorie, ich habe es gemessen.

Gleichzeitige Nutzer: Ohne KV-Cache können SSM-Modelle deutlich mehr parallele Anfragen bedienen. Auf einer einzelnen A100, auf der ein Transformer bei 32K Kontext vielleicht 8 gleichzeitige Streams schafft, kann ein vergleichbares SSM-Modell über 30 bewältigen. Für alle, die Inferenz im großen Stil betreiben, ist das die Zahl, die die Wirtschaftlichkeit verändert.

Trainingsgeschwindigkeit: Die Gewinne sind hier bescheidener. Mamba-3 trainiert auf H100-Clustern etwa mit dem 1,4-fachen Durchsatz eines vergleichbaren Transformers. Bei längeren Sequenzen wird der Abstand größer. Oberhalb von 32K Tokens läuft das SSM-Training 2- bis 3-mal schneller, weil quadratische Attention komplett entfällt.

Hier muss ich aber auch ehrlich über die Grenzen sein. Bei Aufgaben, die eine exakte wörtliche Wiedergabe aus langen Kontexten verlangen, etwa „Was war die genaue Fehlermeldung in Zeile 4.382?“, schneiden reine SSMs immer noch schlechter ab. Die feste, komprimierte Zustandsrepräsentation ist verlustbehaftet. Attention kann einfach auf die ursprünglichen Tokens zurückblicken. Genau deshalb funktionieren hybride Architekturen: Die Attention-Schichten übernehmen das Abrufen, das SSMs nicht können.

Wo SSMs noch zu kurz greifen

Ich möchte mit klarem Blick auf die verbleibenden Lücken schauen, denn eine neue Architektur auf Basis unvollständiger Informationen einzuführen ist ein sicherer Weg, sechs Monate zu verschwenden.

Kontextbasiertes Lernen: Transformer passen ihr Verhalten anhand weniger Beispiele im Prompt immer noch besser an. SSMs können das auch, aber weniger zuverlässig. Wenn deine Anwendung stark auf Prompt Engineering mit Beispielen setzt, werden dich reine SSMs enttäuschen.
Reife des Ökosystems: Transformer-Tooling wurde über Jahre optimiert. SSM-spezifische Kernel, Serving-Infrastruktur und Fine-Tuning-Bibliotheken verbessern sich schnell, sind aber noch nicht auf Augenhöhe. Plane zusätzliche Zeit für die Integration ein.
Skalierungsunsicherheit oberhalb von 70B: Mamba-3-Modelle bis 70B Parameter zeigen gute Skalierungskurven, aber für die Grenze von 200B+ fehlen belastbare Daten. Ob die Skalierungsgesetze für SSMs bei extremen Größen gelten, ist wirklich unbekannt.
Fine-Tuning-Techniken: LoRA und QLoRA für Transformer sind gut verstanden. Für SSM-Architekturen sind andere Ansätze nötig, und die Best Practices kristallisieren sich gerade erst heraus.
Hardware-Mismatch: Aktuelle GPUs sind für die Matrixmultiplikationen optimiert, die Attention so liebt. SSMs setzen stark auf parallele Scans, die auf moderner Hardware ausreichend gut laufen, aber nicht die Operation sind, für die GPUs entworfen wurden.

Keiner dieser Punkte ist ein Ausschlusskriterium. Es sind technische Probleme mit bekannten Lösungswegen. Aber sie sind real, und sie sollten in deine Zeitplanung einfließen.

Praktische Empfehlungen: Wann man einsteigt und wie man anfängt

Nachdem ich SSMs über mehrere Produktionslasten hinweg evaluiert habe, ist hier das Raster, das ich Teams empfehle.

Setz offensiv darauf, wenn dein Workload Inferenz mit langem Kontext (regelmäßig 32K+ Tokens), hohe Anforderungen an die Parallelität oder latenzkritische Edge-Deployments umfasst. Der ROI ist erheblich und sofort spürbar. Starte mit einer hybriden Architektur wie Jamba oder einem Modell der Griffin-Familie statt mit einem reinen SSM. So holst du den Großteil der Effizienzgewinne mit geringerem Risiko.

Abwarten und beobachten, wenn dein Workload überwiegend kurze Kontexte mit starker Abhängigkeit von kontextbasiertem Lernen hat und du keinen Druck bei den Inferenzkosten verspürst. Transformer haben hier immer noch die Nase vorn, und das Ökosystem ist reifer.

Profiliere deine tatsächliche Inferenzlast, bevor du dich entscheidest. Die entscheidenden Variablen sind die mediane Kontextlänge und die Anzahl gleichzeitiger Nutzer
Starte mit hybriden Architekturen, nicht mit reinen SSMs. Sie sind risikoärmer und bringen trotzdem 40–60 % Einsparung bei den Inferenzkosten
Benchmarke mit deinen konkreten Aufgaben. SSMs glänzen bei Zusammenfassungen und weitreichendem Schlussfolgern, liegen aber beim exakten Abrufen zurück
Baue jetzt eine Infrastruktur für den Architekturvergleich auf. Du musst Latenz, Durchsatz, Speicher und Kosten pro Anfrage messen, nicht nur die Genauigkeit
Verfolge das SSM-Tooling-Ökosystem quartalsweise. Das Tempo der Verbesserungen ist so hoch, dass etwas, das heute unpraktisch ist, in drei Monaten produktionsreif sein kann

Die Architekturlandschaft spaltet sich auf, und das ist gut so

Die Ära, in der eine Architektur alles beherrscht, geht zu Ende. Wir bewegen uns auf eine Welt zu, in der Teams Rechenprimitive wählen, etwa volle Attention, lineare Attention, selektive SSMs oder Gated Convolutions, und sie je nach ihren konkreten Randbedingungen kombinieren. So arbeiten reife Ingenieursdisziplinen. Man baut auch nicht jede Struktur aus Stahl. Man wählt das Material nach der Last, die es tragen muss.

Der Transformer ist nicht tot. Er bleibt für viele Workloads die bewährteste Architektur und wird in den kommenden Jahren kritische KI-Systeme antreiben. Doch sein Monopol auf modernste Sequenzmodellierung ist vorbei. SSMs und Hybride haben sich ihren Platz als vollwertige Produktionswerkzeuge verdient, nicht als Forschungsspielereien.

Für uns, die echte Systeme bauen, bedeuten mehr architektonische Optionen bessere Werkzeuge für konkrete Probleme. Das ist keine Disruption, vor der man sich fürchten muss. Es ist ein Engineering-Hebel, den man nutzen sollte.