SubQ AI erklärt: Wie gut ist das LLM mit 12M Kontextfenster?

Am 5. Mai 2026 hat ein kleines Startup aus Miami namens Subquadratic ein Modell namens SubQ veröffentlicht. Das Team ist klein, hat aber 29 Mio. US-Dollar Seed-Funding eingesammelt und behauptet, das Modell könne bis zu 12 Millionen Tokens in einem einzigen Durchlauf verarbeiten.

Sie haben zudem weitere extrem klingende Aussagen gemacht, etwa dass ihr Modell bei 1M Tokens bis zu 52-mal effizienter als FlashAttention sei und eine Codingleistung ähnlich wie Claude Opus zu ungefähr 1/20 der Kosten erreiche.

Das sind große Worte, daher lohnt sich ein genauer Blick, was wirklich dahintersteckt. In diesem Beitrag erkläre ich, was SubQ ist, wie die Architektur funktioniert und was frühe Details und Entwickler-Communities über diese Aussagen vermuten lassen.

Was ist SubQ?

SubQ ist das LLM von Subquadratic, veröffentlicht am 5. Mai 2026 und um ein einziges, großes Feature herum gebaut: ein Kontextfenster mit 12 Millionen Tokens. Es ist das erste Modell des Unternehmens und kommt mit kühnen Aussagen zu Effizienz und Kosten, die bereits für viel Diskussion sorgen. 

Das Modell ist noch nicht öffentlich verfügbar. Der Zugriff auf die API, SubQ Code und SubQ Search ist aktuell nur über eine Warteliste im Early Access möglich.

Es basiert auf SSA, kurz für Subquadratic Sparse Attention.

Anstatt jeden Token mit jedem anderen zu vergleichen, wie es bei standardmäßiger dichter Attention der Fall ist, wählt SSA selektiv aus. Für jeden Token bestimmt das Modell die relevantesten Tokens und berechnet Beziehungen nur innerhalb dieser Teilmenge.

Das hat zwei klare Effekte.

• Erstens sinkt die Anzahl der Berechnungen, was die Effizienz direkt erhöht und die Kosten senkt. 
• Zweitens ist die Auswahl inhaltsabhängig. Das bedeutet, das Modell betrachtet nicht nur nahe Tokens. Es kann relevante Tokens über die gesamte Sequenz hinweg heranziehen, selbst wenn sie weit entfernt sind.

Was ist besonders an SubQ?

In der Praxis sorgt die SSA-Architektur dafür, dass sich das Modell auf das Wesentliche konzentriert, statt alles gleichermaßen zu verarbeiten. Das angestrebte Ergebnis ist eine ähnliche Genauigkeit wie bei voller Attention, jedoch mit deutlich geringeren Rechen- und Speicheranforderungen.

Schauen wir uns zuerst dichte Attention näher an und vergleichen dann beide Ansätze.

Das quadratische Skalierungsproblem bei Transformern

Heutige Modelle wie GPT, Claude und Gemini setzen auf dichte Attention. Vereinfacht heißt das: Jeder Token wird mit jedem anderen Token im Input verglichen. Wächst der Input, steigt die Anzahl der Vergleiche quadratisch.

Nimm ein langes Dokument und stell dir vor, das Modell soll das letzte Wort generieren. Es blickt auf jeden Token in diesem Dokument zurück, baut Beziehungen auf und entscheidet dann, was als Nächstes kommt. Darum funktioniert dichte Attention gut. Sie berücksichtigt alles.

Doch diese Stärke hat ihren Preis. Mit zunehmender Eingabelänge steigen Rechen- und Speicherbedarf stark an und führen zu Kontextfenster-Limits. Vereinfacht skaliert es mit O(n²), wobei n die Anzahl der Tokens ist.

Deshalb bleiben die meisten Modelle innerhalb praktischer Grenzen. In Standardmodellen sind 128k Tokens üblich, und die meisten leistungsfähigen Modelle wie Claude Opus liegen maximal bei einem Kontextfenster von 1M.

Um das zu umgehen, vermeiden die meisten KI-Systeme, dem Modell komplette Datensätze zu geben. Stattdessen setzen sie auf Techniken wie:

• RAG (Retrieval-Augmented Generation): Daten extern speichern, nur relevante Abschnitte abrufen und dem Modell übergeben.
• Chunking: Lange Texte in kleinere Teile aufbrechen und nur die relevanten Abschnitte senden.
• Zusammenfassungsstrategien: Lange Inhalte verdichten und Zusammenfassungen statt des gesamten Texts ins Modell geben.

Wenn du die Aufmerksamkeitsmechanismen tiefer verstehen willst, sieh dir dieses Tutorial zum Attention-Mechanismus in LLMs an. Für praktische Erfahrung mit den Bausteinen moderner LLMs empfehle ich unseren Kurs Transformer Models with PyTorch.

Wie sich SubQ anders positioniert

Dichte Attention wächst quadratisch mit der Eingabelänge, während SSA darauf ausgelegt ist, unterquadratisch zu skalieren, näher an O(n·k) statt O(n²) zu liegen, wobei k die Anzahl der pro Schritt ausgewählten Tokens ist. Wenn k klein im Verhältnis zu n bleibt, ist das deutlich effizienter als volle Attention.

Diagramm: Quadratische vs. lineare Attention mit dichten Alle-zu-allen-Verbindungen vs. spärlichen selektiven Verbindungen.

Die naheliegende Sorge ist die Genauigkeit. Wenn das Modell nur einen Teil des Inputs betrachtet, könnte es wichtige Beziehungen übersehen. Dieser Trade-off ist normalerweise der Grund, warum es dichte Attention überhaupt gibt.

SubQ behauptet, dass dieser Trade-off in der Praxis nicht auftritt. Das Modell beachte alle erforderlichen Tokens, selbst wenn sie weit vom aktuellen Token entfernt sind, und halte eine ähnliche Genauigkeit wie Top-Modelle.

Wie funktioniert Subquadratic Sparse Attention?

Wir wissen nun, dass SSA statt jeden Token gegen alle anderen zu vergleichen, nur die relevanten Tokens in der Sequenz auswählt und über diese Positionen Attention berechnet. Schauen wir uns an, wie diese Auswahl entsteht.

Wie SSA relevante Beziehungen auswählt

SSA nutzt inhaltsabhängiges Routing. Vereinfacht: Es wählt Tokens basierend auf ihrer Relevanz für den aktuellen Token. Es berechnet eine Ähnlichkeitswertung zwischen Tokens, etwa similarity(query_i, key_j), und behält nur die Top-k Tokens mit den höchsten Werten für die Attention.

Mit der Zeit lernt das Modell, bedeutsame Tokens zu priorisieren und Rauschen zu ignorieren. Dazu gehören Schlüsselbegriffe, wichtige Entitäten und Tokens mit starken Kontextsignalen.

Es hängt nicht nur vom Inhalt ab, SSA bewahrt auch strukturelle Beziehungen in der Sequenz. Beispielsweise erhalten nahe Tokens stets Aufmerksamkeit über lokale Muster, während bestimmte globale Tokens über die gesamte Sequenz hinweg beachten können.

SSA umfasst zudem hierarchische und clusterbasierte Attention-Techniken. So werden ähnliche Tokens geclustert und die Attention gegenüber den relevantesten Clustern berechnet. Das bedeutet, das Modell muss nicht jeden Token einzeln bewerten, sondern kann zuerst auf Gruppenebene schließen und bei Bedarf in die Tokens innerhalb dieser Cluster hineinzoomen.

Training für Long-Context-Retrieval

Ein großes Kontextfenster allein bewirkt noch keine Wunder. Selbst bei 12M Tokens muss das Modell lernen, diesen Kontext effektiv zu nutzen. SSA wird dafür trainiert:

• Pretraining: Das Basismodell wird auf massiven, diversifizierten Datensätzen mit Long-Context-Repräsentationen trainiert. 
• Supervised Fine-Tuning: Das Modell wird anschließend auf strukturierte Aufgaben trainiert, darunter Reasoning und Codegenerierung. 
• Reinforcement Learning: Statt das Modell auf nahe Tokens zu begrenzen (lokale Attention), soll dieser Schritt die Nutzung relevanter Tokens aus dem gesamten Text (globale Attention) fördern.

Gerade für Enterprise-Coding-Anwendungsfälle ist das Reinforcement-Learning-Stadium wichtig. Es ermöglicht dem Modell, beim Generieren den weiteren Kontext auf einmal zu berücksichtigen – im Falle von Code also den gesamten Codebestand.

SubQ: Benchmarks und Performance

Beachte, dass "SubQ 1M-Preview" die bei 1M Tokens getestete Version bezeichnet. Das volle 12M-Kontextfenster ist über die API zugänglich.

Auf den drei Benchmarks, die Subquadratic veröffentlicht hat, liefert SubQ 1M-Preview ein Kopf-an-Kopf-Rennen mit Claude Opus 4.7, GPT-5.5 und Gemini 3.1 Pro. 

Die Auswahl der Benchmarks ist jedoch eng: exakt drei Tests, alle fokussiert auf Long-Context-Retrieval und Coding – die beiden Dinge, für die SubQ explizit entwickelt wurde. Breitere Auswertungen zu allgemeinem Reasoning, Mathematik, Mehrsprachigkeit und Sicherheit wurden nicht veröffentlicht.

Die vollständige Model Card ist auf der Website als "coming soon" gelistet, daher können wir weitere Benchmarks für allgemeine Anwendungsfälle erwarten.

Für den Moment sind hier die Ergebnisse zu Long-Context-Retrieval und Coding:

Was die Zahlen zeigen

RULER 128K: SubQ erreicht 95% gegenüber Opus 4.7 mit 94,8%. Der Genauigkeitsunterschied ist vernachlässigbar. Entscheidend ist hier der Preis: Subquadratic gibt an, dass dieser Test auf SubQ rund 8 US-Dollar kostete, gegenüber etwa 2.600 US-Dollar auf Opus bei derselben Kontextlänge.

MRCR v2 (8-needle, 1M): Dieser Benchmark prüft, ob das Modell 8 getrennte Fakten, die über einen 1M-Token-Kontext verteilt sind, korrekt abruft und verfolgt. SubQ zeigt ein Research-Ergebnis von 83%, doch die Produktionsversion fällt auf 65,9% ab. Diese Lücke von ~17 Punkten zwischen Labor- und Live-Performance ist bemerkenswert und nicht vollständig erklärt. Dennoch bleibt es konkurrenzfähig gegenüber GPT-5.5 (74,0%) und deutlich vor Claude Opus 4.7 (32,2%) und Gemini 3.1 Pro (26,3%).

SWE-Bench Verified: SubQ erzielt 81,8%, liegt damit vor Opus 4.6 mit 80,8%, aber hinter Opus 4.7 mit 87,6%. Die Abstände zu Opus 4.6 sind klein und sensibel für das Harness-Setup. Gegen Opus 4.7 und GPT-5.5 liegt SubQ klar zurück.

Bei 12 Millionen Tokens: Für Nadel-im-Heuhaufen-Aufgaben bei 12M Kontext wurden über 90% gemeldet, allerdings noch nicht durch offizielle Benchmarks verifiziert. Kein anderes Spitzenmodell wurde bei dieser Länge getestet, daher fehlt ein direkter Vergleich. Es ist das architektonisch spannendste Ergebnis des Launches – und zugleich das, das unabhängige Reproduktionen benötigt, bevor man Schlüsse zieht.

Was SubQ für RAG, Coding-Agenten und KI-Kosten bedeutet

Wenn SubQs Architektur im großen Maßstab trägt, verändert das den Bau von LLM-Systemen. Längerer Kontext wird praktikabel, was den Bedarf an aggressivem Chunking, Retrieval und Token-Optimierung reduziert. Schauen wir uns diese Änderungen genauer an.

Wenn RAG optional wird

In den letzten zwei Jahren war Retrieval-Augmented Generation (RAG) die Standardantwort auf eine grundlegende Begrenzung von LLMs: Modelle können nicht alles auf einmal lesen. Ist deine Wissensbasis größer als das Kontextfenster, werden Dokumente gechunkt, eingebettet, in einer Vektordatenbank gespeichert, die relevantesten Teile abgerufen und zusammen mit dem Prompt ins Modell gegeben.

Dieses gesamte Ökosystem existiert, weil Kontext knapp ist.

Wenn ein Modell zuverlässig Millionen von Tokens in einem Durchlauf verarbeiten kann, werden viele der Retrieval-Schichten für bestimmte Workflows weniger notwendig. Statt Zeit in die Auswahl der richtigen Chunks zu stecken, kann das System das Rohmaterial direkt aufnehmen und Ende-zu-Ende darüber schlussfolgern.

Darüber hinaus bleibt RAG jenseits des Kontextfensters für Folgendes relevant:

• Sitzungsübergreifendes Gedächtnis: LLMs merken sich nichts, sobald eine Session endet. Kommt ein Nutzer später zurück, beginnt das Modell von vorn. Retrieval-Systeme (oder Datenbanken) speichern wichtige Informationen wie vergangene Entscheidungen, Dokumente oder Nutzerdaten, damit das Modell sie in künftigen Interaktionen nutzen kann.
• Berechtigungen und Zugriffskontrolle: Retrieval-Systeme können Regeln durchsetzen wie „Dieser Nutzer darf nur Daten seines Teams sehen.“ So erhält das Modell nur Dokumente, die der Nutzer sehen darf, und versehentliche Datenpannen werden vermieden.
• Nachvollziehbarkeit: Im Enterprise-Kontext reicht eine Antwort nicht aus; man muss belegen können, warum sie korrekt ist. Retrieval-Systeme verweisen auf die genauen Dokumente oder Quellen, sodass Teams Ergebnisse prüfen und Probleme debuggen können.
• Strukturiertes Wissensmanagement: Unternehmen fügen ständig Dokumente hinzu, aktualisieren oder entfernen sie. Retrieval-Systeme organisieren diese Daten mit Embeddings und Indexierung, damit das Modell schnell die neuesten und relevantesten Informationen findet, ohne alles jedes Mal neu zu verarbeiten.

Einen neuen, spannenden Ansatz für persistentes Gedächtnis in KI-Agenten findest du in unserem Supermemory Tutorial, in dem du lernst, wie du einen Übungstrainer mit Kurz- und Langzeitgedächtnis baust.

Coding-Workflows mit langem Kontext

Aktuell können die meisten Coding-Modelle den gesamten Codebestand nicht überblicken. Also bauen wir Zusatzschichten darüber: Dateisuche, Chunking, Ranking und mehrstufige Planung, nur um den richtigen Kontext im Fenster zu halten und Beziehungen zwischen Dateien herzustellen.

Mit dem 12M-Kontext von SubQ wird jedoch der gesamte Codebestand auf einmal ins Modell geladen. Das vereinfacht das Design von Agenten spürbar.

• Planung wird global: Das Modell kann über Architektur, Abhängigkeiten und Cross-File-Interaktionen nachdenken, ohne Kontext zu verlieren.
• Ausführung ist kohärenter: Änderungen über mehrere Dateien lassen sich in einem Durchlauf koordinieren statt über inkrementelle Updates.
• Review ist zuverlässiger: Das Modell kann seine eigenen Änderungen gegen den gesamten Codebestand prüfen und Inkonsistenzen reduzieren.

Kostenökonomie

In Standard-Transformer-Modellen skaliert Attention quadratisch mit der Sequenzlänge. Verdoppelst du den Kontext, verdoppeln sich die Kosten nicht nur – sie können sich vervierfachen.

SubQ behauptet, diesen Trade-off aufzubrechen.

• Es berichtet von ~1/20 der Kosten gegenüber vergleichbaren Spitzenmodellen (Claude Opus)
• Und bis zu ~1.000× weniger Rechenaufwand bei 12M-Token-Kontext

Wenn sich das in der Praxis bestätigt, hört Long-Context-Verarbeitung auf, ein teurer Sonderfall zu sein, und wird zum Routinewerkzeug.

Allerdings muss das Modell neben einem günstigen Kontextfenster die geladenen Informationen auch effizient nutzen. Den Benchmarks nach reklamiert SubQ eine vergleichbare Genauigkeit bei deutlich geringeren Kosten, aber für ein endgültiges Urteil ist es noch zu früh.

Wie erhalte ich Zugriff auf SubQ?

SubQ ist noch nicht öffentlich verfügbar. Alle drei Produkte – die Kern-API, SubQ Code und SubQ Search – befinden sich derzeit in einer privaten Beta. Der Zugriff erfordert eine Early-Access-Anfrage über die SubQ-Website.

Aus Entwicklersicht ist die API einfach zu integrieren. Sie unterstützt:

• Streaming-Antworten
• Tool-/Funktionsaufrufe
• OpenAI-kompatible Endpunkte

Das bedeutet: Wenn dein Stack bereits mit OpenAI-ähnlichen APIs funktioniert, musst du deine Integration in der Regel nicht neu schreiben.

SubQ Code ist als Coding-Agent für die Kommandozeile positioniert, während SubQ Search sich auf Long-Context-Suche für tiefere Research-Workflows konzentriert. Denk an SubQ-Pendants zu Claude Code und Perplexity. 

Auch die Preise sind noch nicht transparent. Es gibt keine öffentlich verfügbaren pro-Tokensätze, was eine unabhängige Validierung der Kostenaussagen erschwert.

Skepsis und offene Fragen

Binnen Stunden nach dem Launch gab es bereits viel Skepsis und gemischte Reaktionen auf Social Media und Foren wie Hacker News. Die Diskussion ist gespalten: Manche sehen einen echten Durchbruch, andere ziehen Vergleiche zu einem „AI Theranos“ (eine Anspielung auf das gescheiterte Bluttest-Startup mit betrügerischen Technologieversprechen).

Die meisten Zweifel konzentrieren sich auf: 

• Sie behaupten ein 12M-Kontextfenster, zeigen aber nur Benchmarks bei 1M.
• Die Firma heißt Subquadratic, doch an manchen Stellen wird O(1)-ähnliches Skalieren erwähnt. Bei O(1) würde man deutlich mehr als ein 12M-Token-Kontextfenster erwarten. Selbst O(log n) ließe höhere Limits zu.

Eine ähnliche Erzählung gab es 2024 bei Magic.dev. Dort wurden sehr große Kontextfenster bis 100M Tokens und massive Effizienzgewinne propagiert, vor allem für Coding-Workflows. 

Das Versprechen war nahezu identisch: gesamte Codebasen laden, Retrieval-Komplexität reduzieren, Agenten-Design vereinfachen. Das Ergebnis ist öffentlich betrachtet jedoch verhaltener. Trotz rund 500 Mio. US-Dollar Funding gibt es Stand Anfang 2026 wenig reale Sichtbarkeit oder Adoption.

Was verifiziert wurde

SubQs Aussagen sind nicht rein theoretisch. Subquadratic berichtet, dass Benchmarks auf RULER, MRCR v2 und SWE-Bench Verified von einem Drittanbieter durchgeführt wurden und starke Ergebnisse bei Long-Context-Retrieval sowie wettbewerbsfähige Werte bei Coding-Aufgaben zeigen. 

Diese Ergebnisse wurden jedoch noch nicht von externen Forschenden unabhängig reproduziert, und der Bewertungsumfang ist schmal. Alle drei Benchmarks betonen genau die Bereiche, für die SubQ gebaut ist (Signale aus großem Kontext abrufen und über Code operieren).

Ein weiterer wichtiger Punkt ist die Architektur. Der CTO hat bestätigt, dass SubQ keine Modelle von Grund auf trainiert, sondern auf Open-Source-Basismodellen aufsetzt (wahrscheinlich Familien wie DeepSeek oder Kimi). Das ist für ein kleines Team sinnvoll: Es beschleunigt die Iteration und senkt Trainingskosten. Das bedeutet auch, dass die Kerninnovation nicht das Basismodell selbst ist, sondern der Attention-Mechanismus und das Systemdesign darum herum.

Fazit

SubQ ist da, und die Ansagen sind ziemlich kühn. Die Richtung ist klar: Die Beschränkung des Kontextfensters aufheben und Modelle mit deutlich größeren Inputs arbeiten lassen. Positioniert wird es so, dass es bei Coding und Long-Context-Retrieval mit Spitzenmodellen mithält oder sie übertrifft – zu deutlich geringeren Kosten.

Trotzdem: Es ist früh. Wir warten noch auf die vollständige Model Card für mehr Einblick in breitere Fähigkeiten und Tests. Auch die darauf aufbauenden Produkte, SubQ Code und die API, sind noch nicht öffentlich. Ich freue mich darauf, diese Tools praktisch zu testen und zu sehen, wie sich die Aussagen im Betrieb bewähren.