SubQ AI förklarat: Hur bra är LLM:et med 12M kontextfönster?

Den 5 maj 2026 släppte ett litet Miami-baserat startupföretag vid namn Subquadratic en modell som heter SubQ. Teamet är litet, men de har tagit in 29 miljoner dollar i såddfinansiering och påstår att modellen kan bearbeta upp till 12 miljoner token i en enda körning.

De har också framfört andra hisnande påståenden, som att deras modell är upp till 52 gånger effektivare än FlashAttention vid 1M token och uppnår en kodningsprestanda liknande Claude Opus till ungefär en tjugondel av kostnaden.

Det här är stora ord, så det är rimligt att bryta ner dem och se vad som egentligen pågår. I den här texten går jag igenom vad SubQ är, hur arkitekturen fungerar och vad tidiga detaljer och utvecklarcommunityn antyder om dessa påståenden.

Vad är SubQ?

SubQ är Subquadratics LLM, släppt den 5 maj 2026 och byggd kring en enda huvudfunktion: ett kontextfönster på 12 miljoner token. Det är den första modellen företaget har skeppat, och den kommer med djärva påståenden om effektivitet och kostnad som redan har väckt rejäl debatt. 

Modellen är ännu inte offentligt tillgänglig; åtkomst till API:et, SubQ Code och SubQ Search är för närvarande begränsad till tidig åtkomst via väntelista.

Den är byggd på något som kallas SSA, kort för Subquadratic Sparse Attention.

I stället för att jämföra varje token med varje annan token, vilket är hur standardiserad tät attention fungerar, tar SSA ett selektivt grepp. För varje token väljer modellen de mest relevanta token och beräknar relationer endast inom den delmängden.

Detta har två tydliga effekter.

• För det första minskar det antalet beräkningar, vilket direkt förbättrar effektiviteten och sänker kostnaden. 
• För det andra är urvalet innehållsberoende. Det betyder att modellen inte bara tittar på närliggande token. Den kan plocka in relevanta token var som helst i sekvensen, även om de är långt ifrån varandra.

Vad är speciellt med SubQ?

I praktiken innebär SSA-arkitekturen att modellen fokuserar på det som faktiskt spelar roll snarare än att bearbeta allt lika. Avsett utfall är liknande noggrannhet som full attention men med avsevärt lägre krav på beräkning och minne.

Låt oss titta närmare på tät attention först och sedan jämföra angreppssätten.

Det kvadratiska skalningsproblemet i transformatorer

Dagens modeller som GPT, Claude och Gemini bygger på tät attention. På en hög nivå betyder det att varje token jämförs med varje annan token i inmatningen. När inmatningen växer ökar antalet jämförelser kvadratiskt.

Ta ett långt dokument och föreställ dig att modellen ska generera det sista ordet. Den tittar tillbaka på varje token i det dokumentet, bygger relationer och bestämmer sedan vad som kommer härnäst. Det är därför tät attention fungerar bra. Den beaktar allt.

Men den styrkan har ett pris. När inmatningsstorleken ökar stiger kraven på beräkning och minne kraftigt och skapar begränsningar i kontextfönstret. Enkelt uttryckt skalar det som O(n²), där n är antalet token.

Det är därför de flesta modeller håller sig inom praktiska gränser. I standardmodeller är 128k token norm, och de mest kraftfulla modellerna som Claude Opus toppar på 1M kontextfönster.

För att komma runt detta undviker de flesta AI-drivna system att mata modellen med fullständiga dataset. I stället förlitar de sig på tekniker som:

• RAG (Retrieval-Augmented Generation): Lagra data externt, hämta endast relevanta delar och mata in dem i modellen.
• Chunking: Dela upp stora texter i mindre bitar och skicka endast relevanta delar till modellen.
• Summeringsstrategier: Komprimera långa texter och mata in sammanfattningar i modellen i stället för hela texten.

Om du vill få en djupare förståelse för attention-mekanismer kan du kolla in den här handledningen om Attention-mekanismen i LLM:er. För praktisk erfarenhet av byggstenarna i moderna LLM:er rekommenderar jag vår kurs Transformer Models with PyTorch.

Hur SubQ positionerar sig annorlunda

Tät attention växer kvadratiskt med inmatningsstorleken, medan SSA är utformad för att skala subkvadratiskt, närmare O(n·k) i stället för O(n²), där k är antalet valda token per steg. När k hålls litet i förhållande till n är detta avsevärt mer effektivt än full attention.

Diagram över kvadratisk vs linjär attention som visar täta alla-till-alla-kopplingar kontra glesa selektiva kopplingar.

Den uppenbara oron här är noggrannhet. Om modellen bara tittar på en del av inmatningen kan den missa viktiga relationer. Den avvägningen är vanligtvis skälet till att tät attention finns från början.

SubQ:s påstående är att den avvägningen inte visar sig i praktiken. De säger att modellen uppmärksammar alla nödvändiga token, även om de ligger långt från den aktuella token, och bibehåller liknande noggrannhet som toppmodeller.

Hur fungerar Subquadratic Sparse Attention?

Vid det här laget vet vi att SSA, i stället för att jämföra varje token mot varje annan token, bara väljer de token som spelar roll i sekvensen och beräknar attention över de positionerna. Låt oss titta på hur urvalet görs.

Hur SSA väljer relevanta relationer

SSA använder innehållsberoende dirigering. Enkelt uttryckt väljer den token baserat på hur relevanta de är för den aktuella token. Den beräknar en likhetspoäng mellan token, något i stil med similarity(query_i, key_j), och behåller bara de översta k token med högst poäng för attention.

Med tiden lär sig modellen att prioritera meningsfulla token och ignorera brus. Det inkluderar nyckelord, viktiga entiteter och token som bär starka kontextuella signaler.

Det beror inte bara på innehållet, utan SSA bevarar också strukturella relationer i sekvensen. Till exempel ges närliggande token alltid attention genom lokala mönster, medan vissa globala token är utformade för att uppmärksamma hela sekvensen.

SSA inkluderar också hierarkiska och klustringsbaserade attention-tekniker. Till exempel klustrar den liknande token och beräknar attention med de mest relevanta klustren. Det betyder att modellen inte behöver utvärdera varje token individuellt, utan kan resonera på gruppnivå först och sedan zooma in på token inom de klustren vid behov.

Träning för långkontextåterhämtning

Ett stort kontextfönster i sig gör inte underverk. Även om du ger modellen 12M token behöver den fortfarande veta hur den använder den kontexten effektivt. SSA tränas för detta ändamål:

• Förträning: Basmodellen tränas på massiva, varierade dataset med långkontextrepresentationer. 
• Övervakad finjustering: Modellen tränas sedan på strukturerade uppgifter, inklusive resonemang och kodgenerering. 
• Förstärkningsinlärning: I stället för att begränsa modellen till att beakta närliggande token (lokal attention) syftar detta steg till att få den att använda relevanta token från hela texten (global attention).

Steget med förstärkningsinlärning är särskilt viktigt för företagsanvändning inom kodning. Det gör att modellen kan beakta en bredare kontext på en gång — i detta fall hela kodbasen — när den genererar utdata.

SubQ benchmark och prestanda

Observera att "SubQ 1M-Preview" avser versionen som benchmarkats vid 1M token. Det fulla kontextfönstret på 12M är åtkomligt via API:et.

På de tre benchmark Subquadratic valde att släppa mäter SubQ 1M-Preview sig med Claude Opus 4.7, GPT-5.5 och Gemini 3.1 Pro. 

Men urvalet av benchmark är snävt; exakt tre tester, alla fokuserade på långkontextåterhämtning och kodning, de två sakerna som SubQ uttryckligen är byggd för att vara bra på. Bredare utvärderingar över allmänt resonemang, matematik, flerspråkig prestanda och säkerhet har inte publicerats.

Hela modellkortet listas som "kommer snart" på webbplatsen, så vi kan förvänta oss fler benchmark över allmänna användningsfall där.

För närvarande är här resultaten för långkontextåterhämtning och kodningsanvändningsfall:

Vad siffrorna visar

RULER 128K: SubQ får 95% versus Opus 4.7 på 94,8%. Även om skillnaden i noggrannhet är försumbar är det som faktiskt spelar roll här kostnaden: Subquadratic hävdar att denna utvärdering på SubQ kostade runt 8 dollar, mot ungefär 2 600 dollar på Opus vid samma kontextlängd.

MRCR v2 (8-needle, 1M): Detta benchmark testar om modellen korrekt hämtar och följer 8 separata fakta inbäddade över ett kontextfönster på 1M token. SubQ visar ett forskningsresultat på 83%, men produktionspoängen sjunker till 65,9%. Detta glapp på cirka 17 poäng mellan labb- och driftsatt prestanda är anmärkningsvärt och inte fullt ut förklarat. Ändå förblir den konkurrenskraftig med GPT-5.5 (74,0%) och avsevärt före Claude Opus 4.7 (32,2%) och Gemini 3.1 Pro (26,3%).

SWE-Bench Verified: SubQ får 81,8%, före Opus 4.6 på 80,8% men bakom Opus 4.7 på 87,6%. Marginalerna mot Opus 4.6 är små och känsliga för rigginställningen. Mot Opus 4.7 och GPT-5.5 ligger SubQ tydligt efter.

Vid 12 miljoner token: SubQ har rapporterats få över 90% på "needle-in-a-haystack"-uppgifter vid 12M kontext, även om denna siffra inte har verifierats i officiella benchmark. Ingen annan frontlinjemodell har testats vid denna längd, så det finns inget att jämföra direkt med. Det är det mest arkitektoniskt intressanta resultatet från lanseringen och också det som behöver oberoende reproduktion innan man drar slutsatser.

Vad SubQ betyder för RAG, kodningsagenter och AI-kostnader

Om SubQ:s arkitektur håller i skala förändrar det hur LLM-system byggs. Längre kontext blir praktisk, vilket minskar behovet av aggressiv segmentering, återhämtning och tokenoptimering. Låt oss titta närmare på dessa förändringar.

När RAG blir valfritt

De senaste två åren har Retrieval-Augmented Generation (RAG) varit standardsvaret på en grundläggande begränsning i LLM:er: modeller kan inte läsa allt på en gång. Om din kunskapsbas är större än kontextfönstret delar du upp dokument, skapar embeddingar, lagrar dem i en vektordatabas, hämtar de mest relevanta delarna och matar endast in dessa fragment i modellen tillsammans med prompten.

Hela det ekosystemet finns för att kontext är en bristvara.

När en modell pålitligt kan bearbeta miljoner token i en enda körning blir många av de ingenjörslager som byggts kring återhämtning mindre nödvändiga för vissa arbetsflöden. I stället för att lägga tid på att avgöra vilka segment som ska hämtas kan systemet ta in råmaterialet direkt och resonera över det från början till slut.

Utöver kontextfönstret är dock RAG fortfarande viktigt för följande förmågor:

• Minnesfunktion över sessioner: LLM:er minns inget när en session avslutas. Om en användare kommer tillbaka senare börjar modellen från noll. Återhämtningssystem (eller databaser) lagrar viktig information som tidigare beslut, dokument eller användardata så att modellen kan minnas och använda det i framtida interaktioner.
• Behörigheter och åtkomstkontroll: Återhämtningssystem kan upprätthålla regler som ”den här användaren kan bara komma åt data från sitt team”. På så sätt får modellen endast dokument som användaren har behörighet att se, vilket förhindrar oavsiktliga dataläckor.
• Spårbarhet: I företagsmiljöer räcker det inte att ge ett svar; du behöver visa varför det är korrekt. Återhämtningssystem kan peka ut de exakta dokumenten eller källorna som använts, så att team kan verifiera resultat och felsöka om något blir fel.
• Strukturerad kunskapshantering: Företag lägger ständigt till, uppdaterar och tar bort dokument. Återhämtningssystem använder embeddingar och indexering för att organisera dessa data så att modellen snabbt kan hitta den senaste och mest relevanta informationen utan att bearbeta om allt varje gång.

För ett nytt, intressant sätt att lägga till beständigt minne i AI-agenter kan du läsa vår Supermemory-handledning, i vilken du lär dig bygga en träningscoach med kort- och långtidsminne.

Kodningsarbetsflöden med lång kontext

Just nu kan de flesta kodningsmodeller inte se hela kodbasen. Så vi lägger lager ovanpå — filsökning, segmentering, rankning och flerstegsplanering — bara för att hålla rätt kontext i fönstret och bygga relationer mellan filer.

Men med SubQ:s 12M-kontext laddas hela kodbasen in i modellen på en gång. Detta förenklar agentdesign på ett meningsfullt sätt.

• Planeringen blir global: Modellen kan resonera om arkitektur, beroenden och interaktioner mellan filer utan att missa kontext.
• Utförandet blir mer sammanhängande: Ändringar över flera filer kan samordnas i en körning, i stället för genom inkrementella uppdateringar.
• Granskningen blir mer tillförlitlig: Modellen kan verifiera sina egna ändringar mot hela kodbasen, vilket minskar inkonsekvenser.

Kostnadsekonomi

I standardtransformatormodeller skalar attention kvadratiskt med sekvenslängden. Om du fördubblar kontexten blir inte kostnaden bara dubbelt så hög; den kan göra det fyra gånger dyrare.

SubQ säger sig bryta den avvägningen.

• De rapporterar ~1/20 av kostnaden jämfört med likvärdiga frontlinjemodeller (Claude Opus)
• Och upp till ~1 000× minskning av beräkning vid 12M-token kontext

Om detta håller i produktion slutar långkontextbearbetning att vara ett dyrt specialfall och blir något du kan använda mer rutinmässigt.

Men tillsammans med ett billigt kontextfönster bör modellen effektivt kunna använda informationen vi laddar in i dess kontext. Baserat på benchmark hävdar SubQ jämförbar noggrannhet till mycket lägre kostnad, men det är för tidigt att slå fast något slutgiltigt.

Hur får jag tillgång till SubQ?

SubQ är inte offentligt tillgängligt ännu. Alla tre produkterna — kärn-API:et, SubQ Code och SubQ Search — är för närvarande i privat beta, och åtkomst kräver en tidig åtkomstförfrågan via SubQ:s webbplats.

Ur ett utvecklarperspektiv är API:et utformat för att vara enkelt att integrera. Det stöder:

• strömmande svar
• verktygs-/funktionsanrop
• OpenAI-kompatibla ändpunkter

Det betyder att om din stack redan fungerar med OpenAI-liknande API:er behöver du vanligtvis inte skriva om din integration.

SubQ Code positioneras som en kommandoradsbaserad kodningsagent, medan SubQ Search fokuserar på långkontextsökning för djupare forskningsarbetsflöden. Tänk på dem som SubQ-versionerna av Claude Code och Perplexity. 

Prissättning för något av dessa verktyg är ännu inte transparent. Det finns inga offentligt tillgängliga per-token-priser, vilket gör det svårt att oberoende validera företagets kostnadspåståenden.

Skepticism och öppna frågor

Inom timmar efter lanseringen fanns redan mycket skepsis och blandade reaktioner på sociala medier och forum som Hacker News. Diskussionen är delad, där vissa ser det som ett verkligt genombrott medan andra jämför det med ett ”AI Theranos” (en referens till det misslyckade blodtest-startupet som gjorde bedrägliga teknikpåståenden).

De flesta tvivel fokuserar på: 

• De hävdar ett kontextfönster på 12M, men de delade benchmarkerna ligger alla på 1M.
• De gav företaget namnet Subquadratic, men på vissa ställen nämner de O(1)-liknande skalning. Vid O(1) skulle du förvänta dig mycket mer än ett kontextfönster på 12M token. Även O(log n) skulle tillåta större gränser.

En liknande berättelse dök upp med Magic.dev 2024. De kom med starka påståenden om extremt stora kontextfönster, upp till 100M token, och stora effektivitetsvinster, särskilt för kodningsarbetsflöden. 

Upplägget var nästan identiskt: ladda hela kodbaser, minska återhämtningskomplexiteten och förenkla agentdesign. Men utfallet, åtminstone offentligt, har varit mer dämpat. Trots att de tog in runt 500 miljoner dollar finns det fortfarande begränsad synlighet eller användning i verkligheten i början av 2026.

Vad som har verifierats

SubQ:s påståenden är inte rent teoretiska. Subquadratic rapporterar att benchmark på RULER, MRCR v2 och SWE-Bench Verified kördes av en oberoende testtjänst, med stark prestanda på långkontextåterhämtning och konkurrenskraftiga resultat på kodningsuppgifter. 

Dessa resultat har dock ännu inte reproducerats oberoende av externa forskare, och utvärderingens omfattning är snäv. Alla tre benchmarken betonar exakt de områden som SubQ är byggd för (att hämta signaler från stor kontext och arbeta över kod).

En annan viktig detalj är arkitekturen. CTO:n har bekräftat att SubQ inte tränar modeller från grunden, utan bygger på öppenkällkodsbasmodeller (troligen från familjer som DeepSeek eller Kimi). Detta är ett praktiskt val för ett litet team. Det påskyndar iteration och minskar träningskostnaden. Det betyder också att kärninnovation inte är själva basmodellen, utan attention-mekanismen och systemdesignen runt den.

Avslutande tankar

SubQ är här, och påståendena är rätt djärva. Riktningen är tydlig: ta bort begränsningen i kontextfönstret och låt modeller hantera mycket större inmatningar. De positionerar den som att matcha eller slå frontlinjemodeller på kodning och långkontextåterhämtning, till en mycket lägre kostnad.

Det sagt, det är fortfarande tidigt. Vi väntar fortfarande på hela modellkortet för bättre insyn i bredare förmågor och testning. Produkterna som byggs ovanpå, SubQ Code och API:et, är inte heller offentligt tillgängliga ännu. Jag ser fram emot att få praktisk erfarenhet av dessa verktyg och se hur påståendena står sig i produktion.