SubQ AI explicat: Cât de bun este LLM-ul cu fereastră de context de 12M?

Pe 5 mai 2026, o mică startup din Miami numită Subquadratic a lansat un model denumit SubQ. Echipa este mică, dar a strâns 29 de milioane de dolari în finanțare seed și susține că modelul poate procesa până la 12 milioane de tokeni într-o singură trecere.

Au făcut și alte afirmații care sună nebunește, precum că modelul lor este de până la 52 de ori mai eficient decât FlashAttention la 1M de tokeni și obține o performanță la programare similară cu Claude Opus la aproximativ 1/20 din cost.

Sunt afirmații mari, așa că merită să le descompunem și să vedem ce se întâmplă, de fapt. În acest material, voi trece în revistă ce este SubQ, cum funcționează arhitectura și ce sugerează detaliile inițiale și comunitățile de dezvoltatori despre aceste afirmații.

Ce este SubQ?

SubQ este LLM-ul Subquadratic, lansat pe 5 mai 2026 și construit în jurul unei caracteristici principale: o fereastră de context de 12 milioane de tokeni. Este primul model pe care compania l-a livrat și vine cu o serie de afirmații îndrăznețe despre eficiență și cost, care au stârnit deja dezbateri semnificative. 

Modelul nu este încă disponibil public, accesul la API, SubQ Code și SubQ Search fiind în prezent limitat la early access, exclusiv pe bază de listă de așteptare.

Este construit pe ceva numit SSA, prescurtare de la Subquadratic Sparse Attention.

În loc să compare fiecare token cu fiecare alt token, așa cum funcționează atenția densă standard, SSA adoptă o abordare selectivă. Pentru fiecare token, modelul alege cei mai relevanți tokeni și calculează relațiile doar în cadrul acelui subset.

Acest lucru are două efecte clare.

• În primul rând, reduce numărul de calcule, ceea ce îmbunătățește direct eficiența și scade costul. 
• În al doilea rând, selecția depinde de conținut. Asta înseamnă că modelul nu privește doar tokenii din apropiere. Poate aduce tokeni relevanți de oriunde din secvență, chiar dacă sunt departe.

Ce e special la SubQ?

În practică, arhitectura SSA înseamnă că modelul se concentrează pe ceea ce contează cu adevărat, în loc să proceseze totul în mod egal. Rezultatul dorit este o acuratețe similară cu atenția completă, dar cu cerințe semnificativ mai mici de calcul și memorie.

Să analizăm mai întâi atenția densă, apoi să comparăm ambele abordări.

Problema scalării pătratice în transformere

Modelele de astăzi precum GPT, Claude și Gemini se bazează pe atenție densă. La nivel înalt, asta înseamnă că fiecare token este comparat cu fiecare alt token din input. Pe măsură ce inputul crește, numărul comparațiilor crește pătratic.

Luați un document lung și imaginați-vă că modelul trebuie să genereze ultimul cuvânt. Se uită înapoi la fiecare token din acel document, construiește relații și apoi decide ce urmează. De aceea atenția densă funcționează bine. Ia totul în considerare.

Dar această forță vine cu un cost. Pe măsură ce dimensiunea inputului crește, cerințele de calcul și memorie cresc abrupt și creează limite ale ferestrei de context. În termeni simpli, scara este O(n²), unde n este numărul de tokeni.

Acesta este motivul pentru care majoritatea modelelor rămân în limite practice. În modelele standard, 128k tokeni este norma, iar cele mai puternice modele precum Claude Opus se opresc la o fereastră de context de 1M.

Pentru a ocoli asta, majoritatea sistemelor bazate pe AI evită să alimenteze modelul cu seturi de date complete. În schimb, se bazează pe tehnici precum:

• RAG (Retrieval-Augmented Generation): Stocați datele extern, preluați doar fragmentele relevante și introduceți-le în model.
• Fragmentarea (chunking): Împărțiți textul mare în bucăți mai mici și trimiteți modelului doar fragmentele relevante.
• Strategii de rezumare: Comprimați conținutul lung și introduceți în model rezumatele, în locul întregului text.

Dacă doriți o înțelegere mai profundă a mecanismelor de atenție, puteți consulta acest tutorial despre Mecanismul de atenție în LLM-uri. Pentru a obține experiență practică cu elementele de bază ale LLM-urilor moderne, vă recomandăm cursul nostru Modele Transformer cu PyTorch.

Cum se poziționează SubQ diferit

Atenția densă crește pătratic odată cu dimensiunea inputului, în timp ce SSA este concepută să scaleze sub-pătratic, mai aproape de O(n·k) în loc de O(n²), unde k este numărul de tokeni selectați pe pas. Când k este menținut mic în raport cu n, acest lucru este substanțial mai eficient decât atenția completă.

Diagramă atenție pătratică vs liniară, care arată conexiuni dense toate-cu-toate versus conexiuni selective rare.

Îngrijorarea evidentă aici este acuratețea. Dacă modelul privește doar o parte din input, ar putea rata relații importante. Acest compromis este, de obicei, motivul pentru care există atenția densă.

Afirmația SubQ este că acest compromis nu apare în practică. Ei spun că modelul acordă atenție tuturor tokenilor necesari, chiar dacă sunt departe de tokenul curent, și menține o acuratețe similară cu modelele de top.

Cum funcționează Subquadratic Sparse Attention?

Până acum știm că, în loc să compare fiecare token cu fiecare alt token, SSA selectează doar tokenii care contează în secvență și calculează atenția asupra acelor poziții. Să vedem cum face acea selecție.

Cum selectează SSA relațiile relevante

SSA folosește rutare dependentă de conținut. În termeni simpli, alege tokenii în funcție de cât de relevanți sunt pentru tokenul curent. Calculează un scor de similaritate între tokeni, ceva de tipul similarity(query_i, key_j), și păstrează doar primii k tokeni cu cele mai mari scoruri pentru atenție.

În timp, modelul învață să prioritizeze tokenii semnificativi și să ignore zgomotul. Asta include cuvinte-cheie, entități importante și tokeni care poartă semnale contextuale puternice.

Nu depinde doar de conținut, SSA păstrează și relațiile structurale din secvență. De exemplu, tokenii apropiați primesc întotdeauna atenție prin tipare de atenție locală, în timp ce anumiți tokeni globali sunt proiectați să acorde atenție pe întreaga secvență.

SSA include, de asemenea, tehnici de atenție ierarhică și bazată pe clustering. De exemplu, grupează tokenii similari și calculează atenția cu cele mai relevante clustere. Asta înseamnă că modelul nu trebuie să evalueze fiecare token individual, ci poate raționa mai întâi la nivel de grupuri, apoi să facă zoom pe tokenii din acele clustere, dacă este necesar.

Antrenare pentru regăsire în context lung

O fereastră de context mare, de una singură, nu face magie. Chiar dacă oferiți modelului 12M tokeni, el tot trebuie să știe cum să folosească eficient acel context. SSA este antrenată în acest scop:

• Pre-antrenare: Modelul de bază este antrenat pe seturi de date masive, diverse, cu reprezentări de context lung. 
• Ajustare supervizată: Modelul este apoi antrenat pe sarcini structurate, inclusiv raționament și generare de cod. 
• Învățare prin întărire: În loc să limiteze modelul la tokenii apropiați (atenție locală), acest pas îl face să folosească tokeni relevanți din întregul text (atenție globală).

Etapa de învățare prin întărire este deosebit de importantă pentru cazurile de utilizare de programare în mediul enterprise. Îi permite modelului să ia în considerare simultan un context mai larg, în acest caz întreaga bază de cod, în timp ce generează ieșirea.

Benchmark-uri și performanță SubQ

Rețineți că „SubQ 1M-Preview” se referă la versiunea evaluată la 1M tokeni. Fereastra completă de context de 12M este accesibilă prin API.

Pe cele trei benchmark-uri pe care Subquadratic a ales să le publice, SubQ 1M-Preview se bate de la egal la egal cu Claude Opus 4.7, GPT-5.5 și Gemini 3.1 Pro. 

Însă selecția benchmark-urilor este îngustă; exact trei teste, toate axate pe regăsirea în context lung și programare, cele două lucruri pentru care SubQ este proiectat explicit să exceleze. Evaluări mai ample privind raționamentul general, matematica, performanța multilingvă și siguranța nu au fost publicate.

Fișa completă a modelului este listată ca „în curând” pe site, deci ne putem aștepta la mai multe benchmark-uri pentru cazuri de utilizare generale.

Deocamdată, iată rezultatele pe cazuri de regăsire în context lung și programare:

Ce arată cifrele

RULER 128K: SubQ obține 95% față de Opus 4.7 cu 94.8%. Deși diferența de acuratețe este neglijabilă, ceea ce contează aici este costul: Subquadratic susține că rularea acestei evaluări pe SubQ a costat aproximativ 8 USD, față de circa 2.600 USD pe Opus la aceeași lungime de context.

MRCR v2 (8-needle, 1M): Acest benchmark testează dacă modelul regăsește corect și urmărește 8 fapte distincte împrăștiate într-un context de 1M de tokeni. SubQ arată un rezultat de cercetare de 83%, dar scorul în producție scade la 65.9%. Această diferență de aproximativ 17 puncte între performanța din laborator și cea din producție este notabilă și nu este pe deplin explicată. Chiar și așa, rămâne competitiv cu GPT-5.5 (74.0%) și semnificativ înaintea lui Claude Opus 4.7 (32.2%) și Gemini 3.1 Pro (26.3%).

SWE-Bench Verified: SubQ obține 81.8%, peste Opus 4.6 cu 80.8%, dar sub Opus 4.7 cu 87.6%. Marjele față de Opus 4.6 sunt mici și sensibile la configurarea harness-ului. În comparație cu Opus 4.7 și GPT-5.5, SubQ este clar în urmă.

La 12 milioane de tokeni: S-a raportat că SubQ depășește 90% la sarcini de tip „acul în carul cu fân” la context de 12M, deși această cifră nu a fost verificată în benchmark-uri oficiale. Niciun alt model de vârf nu a fost testat la această lungime, așadar nu există o comparație directă. Este rezultatul cel mai interesant din punct de vedere arhitectural al lansării și totodată cel care are nevoie de reproducere independentă înainte de a trage concluzii.

Ce înseamnă SubQ pentru RAG, agenții de cod și costurile AI

Dacă arhitectura SubQ rezistă la scară, se schimbă modul în care sunt construite sistemele LLM. Contextul mai lung devine practic, reducând nevoia de fragmentare agresivă, regăsire și optimizare a tokenilor. Să privim aceste schimbări în detaliu.

Când RAG devine opțional

În ultimii doi ani, Retrieval-Augmented Generation (RAG) a fost răspunsul implicit la o limitare fundamentală a LLM-urilor: modelele nu pot citi totul dintr-o dată. Dacă baza dumneavoastră de cunoștințe este mai mare decât fereastra de context, fragmentați documentele, le încorporați, le stocați într-o bază de date vectorială, regăsiți cele mai relevante bucăți și introduceți doar acele fragmente în model alături de prompt.

Întregul acest ecosistem există pentru că contextul este rar.

Când un model poate procesa în mod fiabil milioane de tokeni într-o singură trecere, multe dintre straturile de inginerie construite în jurul regăsirii devin mai puțin necesare pentru anumite fluxuri. În loc să petreacă timp decidând ce fragmente să recupereze, sistemul poate înghiți materialul brut direct și să raționeze cap-coadă peste el.

Totuși, dincolo de fereastra de context, RAG rămâne important pentru aceste capabilități:

• Memorie între sesiuni: LLM-urile nu își amintesc nimic după încheierea unei sesiuni. Dacă un utilizator revine mai târziu, modelul pornește de la zero. Sistemele de regăsire (sau bazele de date) stochează informații importante precum decizii anterioare, documente sau date despre utilizator, astfel încât modelul să le poată folosi în interacțiuni viitoare.
• Permisiuni și control al accesului: Sistemele de regăsire pot impune reguli precum „acest utilizator poate accesa doar datele echipei sale”. Astfel, modelul primește doar documentele pe care utilizatorul are voie să le vadă, prevenind scurgerile accidentale de date.
• Auditabilitate: În mediile enterprise, nu este suficient să dai un răspuns; trebuie să arăți de ce este corect. Sistemele de regăsire pot indica exact documentele sau sursele folosite, astfel încât echipele să poată verifica rezultatele și să depaneze dacă ceva nu merge bine.
• Gestionarea structurată a cunoștințelor: Companiile adaugă, actualizează și elimină constant documente. Sistemele de regăsire folosesc embedding-uri și indexare pentru a organiza aceste date, astfel încât modelul să poată găsi rapid cele mai noi și relevante informații, fără a reprocese toate materialele de fiecare dată.

Pentru o abordare nouă și interesantă de a adăuga memorie persistentă agenților AI, citiți Tutorialul nostru Supermemory, în care învățați cum să construiți un antrenor de exerciții cu memorie pe termen scurt și lung.

Fluxuri de lucru de programare cu context lung

În prezent, majoritatea modelelor de programare nu pot vedea întreaga bază de cod. Așa că adăugăm straturi deasupra, căutare de fișiere, fragmentare, ierarhizare și planificare multietapă, doar pentru a păstra contextul potrivit în fereastră și a construi relații între fișiere.

Dar cu contextul de 12M al SubQ, întreaga bază de cod este încărcată în model dintr-o dată. Acest lucru simplifică în mod semnificativ proiectarea agenților.

• Planificarea devine globală: Modelul poate raționa despre arhitectură, dependențe și interacțiuni între fișiere fără a pierde context.
• Execuția este mai coerentă: Modificările în mai multe fișiere pot fi coordonate într-o singură trecere, mai degrabă decât prin actualizări incrementale.
• Revizuirea este mai fiabilă: Modelul își poate verifica propriile modificări față de întreaga bază de cod, reducând inconsistențele.

Economia costurilor

În modelele transformer standard, atenția scalează pătratic cu lungimea secvenței. Dacă dublați contextul, costul nu doar că se dublează; poate deveni de patru ori mai scump.

SubQ susține că rupe acest compromis.

• Raportează ~1/20 din costul modelelor de vârf comparabile (Claude Opus)
• Și până la ~1.000× reducere a calculelor la context de 12M tokeni

Dacă acest lucru se confirmă în producție, procesarea cu context lung încetează să mai fie un caz special costisitor și devine ceva ce puteți folosi mai des.

Totuși, pe lângă o fereastră de context ieftină, modelul ar trebui să poată folosi eficient informațiile pe care le încărcăm în context. Pe baza benchmark-urilor, SubQ revendică o acuratețe comparabilă la un cost mult mai mic, dar este prea devreme pentru o concluzie finală.

Cum pot accesa SubQ?

SubQ nu este încă disponibil public. Toate cele trei produse, API-ul de bază, SubQ Code și SubQ Search, sunt în prezent în beta privat, iar accesul necesită o cerere de early access prin site-ul SubQ.

Din perspectiva unui dezvoltator, API-ul este conceput pentru a fi ușor de integrat. Acceptă:

• răspunsuri în streaming
• apelarea de unelte/funcții
• endpoint-uri compatibile cu OpenAI

Asta înseamnă că, dacă stiva dumneavoastră funcționează deja cu API-uri în stil OpenAI, de obicei nu trebuie să vă rescrieți integrarea.

SubQ Code este poziționat ca un agent de programare în linie de comandă, în timp ce SubQ Search se concentrează pe căutarea în context lung pentru fluxuri de lucru de cercetare mai profunde. Gândiți-vă la ele ca la versiunile SubQ ale Claude Code și Perplexity. 

Prețurile pentru oricare dintre aceste instrumente nu sunt încă transparente. Nu există tarife pe token disponibile public, ceea ce face dificilă validarea independentă a afirmațiilor companiei privind costurile.

Scepticism și întrebări deschise

La câteva ore de la lansare, există deja mult scepticism și reacții mixte pe rețelele sociale și pe forumuri precum Hacker News. Discuția este împărțită: unii îl văd drept un adevărat progres, în timp ce alții îl compară cu un „Theranos al AI” (o referință la startup-ul eșuat de testare a sângelui care a făcut afirmații tehnologice frauduloase).

Majoritatea îndoielilor se concentrează pe: 

• Pretind o fereastră de context de 12M, dar benchmark-urile partajate sunt toate la 1M.
• Au numit compania Subquadratic, dar în unele locuri menționează scalare de tip O(1). La O(1), v-ați aștepta la mult mai mult decât o fereastră de context de 12M tokeni. Chiar și O(log n) ar permite limite mai mari.

O narațiune similară a apărut cu Magic.dev în 2024. Au făcut afirmații puternice despre ferestre de context extrem de mari, de până la 100M tokeni, și câștiguri majore de eficiență, în special pentru fluxurile de lucru de programare. 

Propunerea a fost aproape identică: încarcă baze de cod întregi, reduce complexitatea regăsirii și simplifică proiectarea agenților. Dar rezultatul, cel puțin public, a fost mai temperat. În ciuda strângerii a aproximativ 500 de milioane de dolari, încă există o vizibilitate sau adopție limitată în lumea reală, la începutul lui 2026.

Ce a fost verificat

Afirmațiile SubQ nu sunt pur teoretice. Subquadratic raportează că benchmark-urile pe RULER, MRCR v2 și SWE-Bench Verified au fost rulate de un serviciu terț de testare, arătând performanță puternică la regăsirea în context lung și rezultate competitive la sarcini de programare. 

Totuși, aceste rezultate nu au fost încă reproduse independent de cercetători externi, iar sfera evaluării este îngustă. Toate cele trei benchmark-uri pun accent exact pe zonele pentru care SubQ este construit (extrage semnale din context mare și operează peste cod).

Un alt detaliu important este arhitectura. CTO-ul a confirmat că SubQ nu antrenează modele de la zero, ci se bazează pe modele open-source de bază (probabil din familii precum DeepSeek sau Kimi). Este o alegere practică pentru o echipă mică. Accelerează iterația și reduce costul de antrenare. Asta înseamnă, de asemenea, că inovația de bază nu este modelul de bază propriu-zis, ci mecanismul de atenție și designul de sistem din jurul lui.

Concluzii finale

SubQ este aici, iar afirmațiile sunt destul de îndrăznețe. Direcția este clară: eliminați constrângerea ferestrei de context și lăsați modelele să gestioneze intrări mult mai mari. Îl poziționează ca egalând sau depășind modelele de vârf la programare și regăsire în context lung, la un cost mult mai mic.

Cu toate acestea, este încă devreme. Încă așteptăm fișa completă a modelului pentru mai multă vizibilitate asupra capabilităților și testărilor mai largi. Produsele construite deasupra lui, SubQ Code și API-ul, nu sunt încă disponibile public. Aștept cu interes să mă familiarizez cu aceste instrumente și să văd cum rezistă afirmațiile în producție.