SubQ: 12 Millionen Token Kontext – echter Durchbruch oder gut verpacktes Marketing?

Auf X kursiert seit kurzem ein Post, der die KI-Bubble in helle Aufregung versetzt hat: Ein neues Modell namens SubQ (kurz für Subquadratic) soll mit einem Kontextfenster von 12 Millionen Token arbeiten – also dem Zwölffachen dessen, was GPT-Klasse-Modelle aktuell bieten. Dazu kommen 150 Token pro Sekunde Geschwindigkeit und ein Preis, der angeblich nur ein Fünftel der Konkurrenz beträgt. Klingt zu gut, um wahr zu sein? Genau das ist die richtige Frage.

Was wurde angekündigt?

Der Ankündigungs-Thread stammt von einem gewissen Alexander und beschreibt SubQ als „den ersten echten Durchbruch in LLM-Intelligenz" – das erste Modell mit einer subquadratischen Sparse-Attention-Architektur. Die wichtigsten Versprechen im Überblick:

• 12 Millionen Token Kontextfenster (zur Einordnung: alle sieben Harry-Potter-Bände zusammen liegen bei rund einer Million Token – es würden also zehn komplette Harry-Potter-Reihen reinpassen)
• 52× schneller als aktuelle Modelle bei einer Million Token Kontext
• 5 % der Kosten von Opus
• Verfügbar werden API, SubQ Code (Coding-Agent) und SubQ Search (Deep Research)

Was leider fehlt: Detaillierte technische Papers. Die offizielle Ankündigung bleibt erstaunlich oberflächlich, und das macht eine seriöse Einordnung schwierig.

Warum Kontext überhaupt das große Thema ist

Aktuelle Modelle sehen bei großen Codebasen oder Dokumentensammlungen immer nur Ausschnitte. Deshalb der ganze Workaround-Zoo: RAG, Subagenten, Datei-Splits, Komprimierungs-Tricks. Jeder dieser Wege hat seinen Preis:

• RAG verliert oft Position, Hierarchie und Nachbarschaftsbeziehungen.
• Agenten-Workflows komprimieren Kontext zwischen Einzelschritten – wichtige Details fallen unter den Tisch.
• Je größer die Datenbasis, desto kritischer wird funktionaler Kontext (also nicht nur „passt rein", sondern „bleibt nutzbar").

Ein echtes 12-Millionen-Token-Fenster würde viele dieser Umwege schlicht überflüssig machen.

Die Technik: Dense vs. Sparse Attention

Das Herzstück ist die Attention – also der Mechanismus, mit dem ein Modell entscheidet, welche vorherigen Token bei der Berechnung des nächsten Tokens relevant sind.

Dense Attention (wie sie die meisten LLMs nutzen): Für jeden neuen Token wird ein dichtes Netz an Beziehungen zu allen vorherigen Token berechnet. Qualitativ stark, aber: Verdoppelt sich der Kontext, vervierfacht sich der Rechenaufwand. KV-Caching mildert das, löst es aber nicht. Lange Kontexte werden langsam und speicherhungrig – einer der Gründe, warum Speicher-Aktien wie Micron gerade durch die Decke gehen.

Sparse Attention (SubQs Ansatz): Das Modell wählt inhaltsabhängig aus, welche Positionen wirklich Signal tragen, und überspringt den Rest. Statt jeden Token mit jedem zu vergleichen, werden nur die relevanten Token konsultiert. Resultat: lineare statt quadratische Skalierung.

Konkret behauptete Zahlen:

Sparse Attention ist nicht neu – und genau hier liegt der Hund begraben

Sparse Attention gibt es schon länger. DeepSeek nutzt etwas Vergleichbares bei einer Million Token, was deren niedrige Preise mit erklärt. Das Problem war historisch nie nur Effizienz, sondern Effizienz ohne Qualitätsverlust bei Retrieval und Reasoning. Bisherige Ansätze:

• Local / Sliding Window – das Modell sieht nur die letzten N Token. Funktioniert, solange relevante Information nahe ist; weit entfernte Bezüge gehen verloren.
• Global Tokens – komprimierte Repräsentationen, die den restlichen Kontext verdichten. Details verschwimmen oder verschwinden ganz. Genau das Problem, das man bei Cursor, Cloud Code und Codex sieht, wenn sie nach längerer Session „komprimieren".
• Fixed Sparse Patterns – feste Masken legen vorab fest, welche Token relevant sind. Problem: die Auswahl steht fest, bevor klar ist, wonach gesucht wird.
• Content-Dependent Selection – für jede Anfrage werden dynamisch die Positionen aktiviert, die tatsächlich Signal tragen. Das ist der Kern des behaupteten Architekturvorteils von SubQ.

Die Benchmarks – ein gemischtes Bild

Die veröffentlichten Benchmarks sind selektiv (wie immer bei Eigenmarketing), aber interessant:

• Ruler-Benchmark (Retrieval + Reasoning, 128k Token): SubQ bei ~95 %, etwa gleichauf mit Opus 4.6.
• MRCR v2 (Needle-in-a-Haystack-artig, 1M Token): SubQ bei ~66 %. GPT 5.5 schlägt das mit ~74 %, aber SubQ liegt deutlich vor Gemini und Opus 4.7.
• Klassischer Needle-in-a-Haystack (mit sieben versteckten Nadeln in 1M Token): Hier führen GPT 5.5 und Opus 4.6. Allerdings haben die Cloud-Code-Macher diese Benchmark als wenig aussagekräftig eingestuft – die Einordnung bleibt also schwierig.
• SWE-Bench Verified (Software Engineering): SubQ besser als Opus 4.6 und Gemini 3.1 Pro.

Die Benchmarks zeigen also: nicht überall Spitze, aber bei Coding und mittlerem Long-Context-Bereich konkurrenzfähig – bei dramatisch niedrigeren Kosten und höherer Geschwindigkeit, wenn man den Angaben glaubt.

Was wäre, wenn es wirklich funktioniert?

Sollte SubQ halten, was die Ankündigung verspricht, ändert sich einiges:

• Komplette Codebasen statt Ausschnitten im Kontext – kein RAG-Gefrickel mehr für Coding.
• Ganze Unternehmensdokumentationen mittlerer Betriebe direkt nutzbar.
• Monatelange Agentenhistorien in einem Lauf – ohne ständiges Komprimieren.
• Direkte Analyse großer Vertragssammlungen.
• Weniger Orchestrierung, weniger Zusammenfassung, mehr Fokus auf die eigentliche Aufgabe.

Auch makroökonomisch interessant: Eine Architektur, die ~1000× weniger Compute pro Token braucht, würde die aktuelle Speicher- und Rechenknappheit spürbar entschärfen.

Fazit: Vielversprechend, aber mit Vorsicht zu genießen

Das Potenzial ist riesig, die Beweislage aber dünn. Benchmarks lassen sich tunen, Modelcards und technische Papers sind angekündigt, aber noch nicht da. Die zentrale offene Frage bleibt:

Bleibt die Qualität bei Millionen von Tokens stabil – oder kollabiert das Modell, sobald reale Workflows draufkommen?

Ein großes Kontextfenster ist nur dann wertvoll, wenn das Modell die Information funktional nutzen kann, nicht nur reinpacken. Es würde nicht überraschen, wenn am Ende mehr Marketing als Substanz dahintersteckt – aber auch nicht, wenn hier tatsächlich ein Architektur-Sprung passiert ist.

Sicher ist nur: Sobald das Modell verfügbar wird, lohnt sich ein eigener Test mit einer echten großen Codebasis oder Dokumentensammlung. Synthetische Benchmarks sind das eine, der eigene Workflow das andere.

Quelle: Video „12 Mio. Token… wirklich?" von AI mit Arnie, 07.05.2026