Sparse Attention vs. Dense Attention
Auch: Sparse Attention, Dense Attention, Full Attention, Subquadratische Attention, Kontextfenster
Zwei Bauweisen dafür, wie ein KI-Sprachmodell entscheidet, welche Teile eines langen Textes es beim Weiterschreiben anschaut — dense schaut auf alles, sparse nur auf eine ausgewählte Teilmenge. Der Unterschied entscheidet, wie lang ein Text werden darf, bevor die Rechenkosten explodieren.
Kurz: Zwei Bauweisen dafür, wie ein KI-Sprachmodell entscheidet, welche Teile eines langen Textes es beim Weiterschreiben überhaupt anschaut. Dense schaut jedes Mal auf alles, Sparse nur auf eine ausgewählte Teilmenge. Der Unterschied entscheidet darüber, wie lang ein Text werden darf, bevor die Rechenkosten explodieren.
Das Problem in einem Bild
Ein Sprachmodell, das das nächste Wort bestimmt, vergleicht dieses mit allen vorherigen Wörtern. Bei 10 Wörtern sind das 10 Vergleiche, bei 100 schon 100 — pro Wort. Für den ganzen Text wächst der Aufwand also quadratisch: doppelt so langer Text, vierfacher Rechenaufwand.
In der Fachsprache: O(n²) in der Sequenzlänge. Genau deshalb waren Kontextfenster jahrelang der Engpass — nicht weil niemand mehr Text hineingeben wollte, sondern weil jede Verdopplung vierfach kostet.
Dense Attention (auch: Full Attention)
Der klassische Weg seit der Transformer-Architektur (2017): jedes Token wird mit jedem anderen verglichen. Vollständig, verlustfrei — und quadratisch teuer.
Stärke: Keine Information geht verloren. Eine Angabe auf Seite 1 ist beim Schreiben von Seite 400 exakt so verfügbar wie eine von Seite 399.
Schwäche: Die Kosten. Sowohl Rechenzeit als auch Speicher wachsen im Quadrat.
Sparse Attention
Die Gegenidee: nicht alles anschauen, sondern nur das Relevante. Wenn die meisten Wortpaare ohnehin nichts miteinander zu tun haben, muss man sie auch nicht vergleichen.
Drei klassische Muster — und warum sie in der Praxis Ärger machten:
| Muster | Idee | Schwäche |
|---|---|---|
| Sliding Window / Local Attention | nur die letzten k Token anschauen | alles davor ist blind — eine Angabe vom Anfang ist weg |
| Global Tokens | wenige „Anker"-Token sehen alles, der Rest nur lokal | der Anker verdichtet und verliert dabei Details |
| Fixed Sparse Patterns | feste Auswahlregel, vorab bestimmt | die Route steht fest, bevor die Frage bekannt ist |
Allen dreien ist dasselbe gemeinsam: Die Auswahl passiert unabhängig vom Inhalt. Deshalb verloren sie regelmäßig genau die Stelle, auf die es ankam — messbar besonders bei Retrieval („finde die eine Angabe") und mehrstufigem Schlussfolgern.
Content-adaptive Sparsity — der aktuelle Ansatz
Der Fortschritt liegt darin, die Auswahl lernen zu lassen statt sie festzulegen: Das Modell entscheidet je nach Inhalt, welche Positionen es anschaut (content dependent selection). Damit sinkt die Komplexität in die Nähe von O(n log n) statt O(n²), ohne die Blindstellen fester Muster.
Praktisches Beispiel: SubQ von Subquadratic (öffentlich seit 5. Mai 2026) beansprucht auf dieser Grundlage ein Kontextfenster von 12 Millionen Token — grob das Zehnfache dessen, was Modelle mit 1-Mio.-Fenster fassen. Zum Vergleich: alle sieben Harry-Potter-Bände zusammen sind rund 1 Million Token.
⚠️ Belegstand: Die Architekturidee ist etabliertes Fachwissen. Die konkreten Leistungszahlen zu SubQ (81,8 % SWE-Bench Verified, 95 % RULER@128K, 52-facher Prefill-Speedup, ~64-fache Compute-Reduktion bei 1 Mio. Token) stammen aus Anbieterangaben und darauf aufbauender Berichterstattung — ein begutachtetes Paper mit unabhängiger Reproduktion lag am 2026-08-30 nicht vor.
Häufige Verwechslung: FlashAttention ist NICHT sparse
FlashAttention rechnet vollständige Dense Attention — nur speichereffizienter, indem es Zwischenergebnisse nicht auslagert. Es ist eine exakte Optimierung: dasselbe Ergebnis, schneller. Sparse Attention dagegen rechnet bewusst weniger und nimmt eine Näherung in Kauf.
Wer beides gleichsetzt, vergleicht Äpfel mit Birnen: FlashAttention verschiebt die Konstante, Sparse Attention verschiebt die Wachstumskurve.
Ebenfalls andere Baustellen, oft im selben Atemzug genannt:
- GQA / MQA (Grouped/Multi-Query Attention) — reduziert den KV-Cache, nicht die Vergleichsmenge
- KV-Cache-Kompression — verkleinert das Gedächtnis nachträglich
- RAG — umgeht das Problem, indem gar nicht erst alles ins Fenster kommt
Warum das für einen Betrieb zählt
Die Frage hinter der Technik lautet: Muss ein großes Dokument zerschnitten werden, oder passt es am Stück hinein?
- Zerschneiden (RAG) ist erprobt, läuft im eigenen Haus und ist billig — kostet aber Zusammenhang. Was in zwei Schnipsel fällt, wird nur gefunden, wenn die Suche beide holt.
- Am Stück (großes Fenster) erhält den Zusammenhang vollständig — kostet aber, dass das Dokument zu einem fremden Anbieter hochgeladen wird, solange kein selbstbetreibbares Modell mit solchen Fenstern existiert.
Für Betriebe mit Vertraulichkeitsbedarf ist das keine technische, sondern eine Datenhoheits-Entscheidung. Ein 12-Millionen-Token-Fenster in fremder Cloud löst ein Bequemlichkeitsproblem und schafft ein Vertrauensproblem.
Verwandt
- lex-ki-betriebssystem — Kontextarchitektur als Ganzes
- Herkunft dieses Eintrags:
~/vault/Links/2026-08-29-ist-dieser-ki-durchbruch-echt.md(PNLS-Bewertung des Videos, Ergebnisrejectedwegen fehlender Datenhoheit — der Begriff wurde unabhängig vom Produkt übernommen, Operator-Entscheidung 2026-08-30 „2b")