SubQ AI spiegato: quanto è valido l’LLM con finestra di contesto da 12M?

Il 5 maggio 2026, una piccola startup di Miami chiamata Subquadratic ha rilasciato un modello chiamato SubQ. Il team è ridotto, ma ha raccolto 29 milioni di dollari in seed e sostiene che il modello possa elaborare fino a 12 milioni di token in un unico passaggio.

Hanno anche fatto altre affermazioni che suonano folli, come che il loro modello è fino a 52 volte più efficiente di FlashAttention a 1M token e raggiunge prestazioni nel coding simili a Claude Opus a circa 1/20 del costo.

Sono dichiarazioni importanti, quindi ha senso analizzarle per capire cosa sta succedendo davvero. In questo articolo ti spiego cos’è SubQ, come funziona l’architettura e cosa suggeriscono i primi dettagli e le community di sviluppatori riguardo queste affermazioni.

Che cos’è SubQ?

SubQ è l’LLM di Subquadratic, rilasciato il 5 maggio 2026 e costruito attorno a un’unica caratteristica di punta: una finestra di contesto da 12 milioni di token. È il primo modello spedito dall’azienda e arriva con una serie di affermazioni audaci su efficienza e costi che hanno già acceso un acceso dibattito. 

Il modello non è ancora disponibile pubblicamente: l’accesso all’API, a SubQ Code e a SubQ Search è al momento limitato all’early access tramite lista d’attesa.

È basato su qualcosa chiamato SSA, acronimo di Subquadratic Sparse Attention.

Invece di confrontare ogni token con ogni altro token, come fa la standard dense attention, SSA adotta un approccio selettivo. Per ciascun token, il modello sceglie i token più rilevanti e calcola le relazioni solo all’interno di quel sottoinsieme.

Questo ha due effetti chiari.

• Primo, riduce il numero di computazioni, migliorando direttamente l’efficienza e abbassando i costi. 
• Secondo, la selezione dipende dal contenuto. Significa che il modello non guarda solo ai token vicini: può attingere token rilevanti ovunque nella sequenza, anche se molto distanti.

Cosa rende speciale SubQ?

In pratica, l’architettura SSA fa sì che il modello si concentri su ciò che conta davvero invece di processare tutto allo stesso modo. L’obiettivo è ottenere un’accuratezza simile alla full attention, ma con requisiti di calcolo e memoria significativamente inferiori.

Diamo prima un’occhiata più da vicino alla dense attention e poi confrontiamo i due approcci.

Il problema della scalabilità quadratica nei transformer

I modelli di oggi come GPT, Claude e Gemini si basano sulla dense attention. In sintesi, significa che ogni token viene confrontato con ogni altro token in input. All’aumentare dell’input, il numero di confronti cresce quadraticamente.

Prendi un documento lungo e immagina che il modello debba generare l’ultima parola. Guarda indietro a ogni token in quel documento, costruisce relazioni e poi decide cosa viene dopo. È per questo che la dense attention funziona bene: considera tutto.

Ma questa forza ha un costo. All’aumentare della dimensione dell’input, i requisiti di calcolo e memoria crescono rapidamente e creano limiti alla finestra di contesto. In termini semplici, scala come O(n²), dove n è il numero di token.

Ecco perché la maggior parte dei modelli rimane entro limiti pratici. Nei modelli standard, 128k token è la norma, e i modelli più potenti come Claude Opus arrivano al massimo a una finestra di contesto da 1M.

Per aggirare il problema, la maggior parte dei sistemi AI evita di fornire al modello interi dataset. Invece, fanno affidamento su tecniche come:

• RAG (Retrieval-Augmented Generation): Archiviare i dati esternamente, recuperare solo i blocchi rilevanti e passarli al modello.
• Chunking: Suddividere testi lunghi in parti più piccole e inviare al modello solo i blocchi pertinenti.
• Strategie di riassunto: Comprimere contenuti lunghi e fornire al modello i riassunti, invece dell’intero testo.

Se vuoi approfondire i meccanismi di attention, dai un’occhiata a questo tutorial sul Meccanismo di Attention negli LLM. Per fare pratica con i mattoni dei moderni LLM, ti consiglio il corso Transformer Models with PyTorch.

Come SubQ si posiziona in modo diverso

La dense attention cresce quadraticamente con la dimensione dell’input, mentre SSA è progettata per scalare in modo sub-quadratico, più vicino a O(n·k) invece di O(n²), dove k è il numero di token selezionati per step. Quando k è mantenuto piccolo rispetto a n, ciò è sostanzialmente più efficiente della full attention.

Diagramma di attention quadratica vs lineare che mostra connessioni dense tutti-con-tutti rispetto a connessioni sparse selettive.

La preoccupazione ovvia qui è l’accuratezza. Se il modello guarda solo a una parte dell’input, potrebbe perdere relazioni importanti. Questo compromesso è di solito il motivo per cui la dense attention esiste in primo luogo.

Secondo SubQ, questo compromesso non si manifesta nella pratica. Dicono che il modello presta attenzione a tutti i token necessari, anche se lontani dal token corrente, e mantiene un’accuratezza simile ai modelli di punta.

Come funziona la Subquadratic Sparse Attention?

A questo punto sappiamo che, invece di confrontare ogni token con tutti gli altri, SSA seleziona solo i token che contano nella sequenza e calcola l’attention su quelle posizioni. Vediamo come avviene questa selezione.

Come SSA seleziona le relazioni rilevanti

SSA usa un instradamento dipendente dal contenuto. In parole semplici, sceglie i token in base a quanto sono rilevanti per il token corrente. Calcola un punteggio di similarità tra token, qualcosa come similarity(query_i, key_j), e mantiene solo i primi k token con i punteggi più alti per l’attention.

Nel tempo, il modello impara a dare priorità ai token significativi e a ignorare il rumore. Ciò include parole chiave, entità importanti e token che portano segnali contestuali forti.

Oltre a dipendere dal contenuto, SSA preserva anche le relazioni strutturali nella sequenza. Ad esempio, ai token vicini viene sempre data attenzione tramite pattern locali, mentre alcuni token globali sono progettati per prestare attenzione all’intera sequenza.

SSA include inoltre tecniche di attention gerarchica e basata su clustering. Ad esempio, raggruppa token simili e calcola l’attention con i cluster più rilevanti. Questo significa che il modello non deve valutare ogni token individualmente, ma può ragionare prima a livello di gruppi e poi zoomare sui token all’interno di quei cluster, se necessario.

Training per il recupero a lungo contesto

Una grande finestra di contesto da sola non fa miracoli. Anche se fornisci al modello 12M token, deve comunque sapere come usare efficacemente quel contesto. SSA è addestrata con questo scopo:

• Pre-training: Il modello base è addestrato su dataset enormi e diversi con rappresentazioni a lungo contesto. 
• Fine-tuning supervisionato: Il modello viene poi addestrato su task strutturati, inclusi ragionamento e generazione di codice. 
• Reinforcement learning: Invece di limitare il modello a considerare i token vicini (local attention), questo step serve a fargli usare token rilevanti dall’intero testo (global attention).

La fase di reinforcement learning è particolarmente importante per i casi d’uso di coding in ambito enterprise. Permette al modello di considerare un contesto più ampio in una volta sola, in questo caso l’intera codebase, mentre genera l’output.

Benchmark e prestazioni di SubQ

Nota che "SubQ 1M-Preview" si riferisce alla versione valutata a 1M token. La finestra completa da 12M è accessibile tramite API.

Sui tre benchmark che Subquadratic ha scelto di pubblicare, SubQ 1M-Preview se la gioca con Claude Opus 4.7, GPT-5.5 e Gemini 3.1 Pro. 

Ma la selezione dei benchmark è ristretta: esattamente tre test, tutti focalizzati su long-context retrieval e coding, le due cose per cui SubQ è esplicitamente progettato. Valutazioni più ampie su ragionamento generale, matematica, multilinguismo e sicurezza non sono state pubblicate.

La model card completa è indicata come "in arrivo" sul sito, quindi possiamo aspettarci più benchmark su casi d’uso generali.

Per ora, ecco i risultati su retrieval a lungo contesto e casi d’uso di coding:

Cosa mostrano i numeri

RULER 128K: SubQ ottiene il 95% contro il 94,8% di Opus 4.7. Anche se la differenza di accuratezza è trascurabile, ciò che conta qui è il costo: Subquadratic sostiene che eseguire questa valutazione su SubQ è costato circa 8$, contro circa 2.600$ su Opus alla stessa lunghezza di contesto.

MRCR v2 (8-needle, 1M): Questo benchmark testa se il modello recupera e traccia correttamente 8 fatti separati inseriti in un contesto da 1M token. SubQ mostra un risultato di ricerca dell’83%, ma il punteggio in produzione scende al 65,9%. Questo gap di ~17 punti tra prestazioni in laboratorio e in deployment è notevole e non pienamente spiegato. Nonostante ciò, resta competitivo con GPT-5.5 (74,0%) e nettamente avanti a Claude Opus 4.7 (32,2%) e a Gemini 3.1 Pro (26,3%).

SWE-Bench Verified: SubQ ottiene l’81,8%, davanti a Opus 4.6 con l’80,8% ma dietro a Opus 4.7 con l’87,6%. I margini rispetto a Opus 4.6 sono ridotti e sensibili alla configurazione del harness. Contro Opus 4.7 e GPT-5.5, SubQ è chiaramente indietro.

A 12 milioni di token: Si riporta che SubQ superi il 90% nei task needle-in-a-haystack a 12M di contesto, anche se questa cifra non è stata verificata in benchmark ufficiali. Nessun altro modello di frontiera è stato testato a questa lunghezza, quindi non c’è nulla con cui confrontarlo direttamente. È il risultato più interessante dal punto di vista architetturale del lancio, ma anche quello che richiede riproduzioni indipendenti prima di trarre conclusioni.

Cosa significa SubQ per RAG, agenti di coding e costi dell’AI

Se l’architettura di SubQ regge su larga scala, cambia il modo in cui si costruiscono i sistemi LLM. Il contesto più lungo diventa praticabile, riducendo la necessità di chunking aggressivo, retrieval e ottimizzazione dei token. Vediamo più da vicino questi cambiamenti.

Quando RAG diventa opzionale

Negli ultimi due anni, la Retrieval-Augmented Generation (RAG) è stata la risposta predefinita a una limitazione fondamentale degli LLM: i modelli non possono leggere tutto in una volta. Se la tua knowledge base è più grande della finestra di contesto, spezzi i documenti, li trasformi in embedding, li memorizzi in un database vettoriale, recuperi i pezzi più rilevanti e passi al modello solo quei frammenti insieme al prompt.

Questo intero ecosistema esiste perché il contesto è scarso.

Quando un modello può elaborare in modo affidabile milioni di token in un unico passaggio, molti degli strati ingegneristici costruiti attorno al retrieval diventano meno necessari per alcune tipologie di flussi di lavoro. Invece di passare tempo a decidere quali chunk recuperare, il sistema può ingerire direttamente il materiale grezzo e ragionarci sopra end-to-end.

Tuttavia, oltre la finestra di contesto, RAG resta importante per queste capacità:

• Memoria tra sessioni: Gli LLM non ricordano nulla una volta terminata una sessione. Se un utente torna dopo, il modello riparte da zero. I sistemi di retrieval (o i database) memorizzano informazioni importanti come decisioni passate, documenti o dati utente affinché il modello possa ricordarli e usarli in interazioni future.
• Permessi e controllo degli accessi: I sistemi di retrieval possono far rispettare regole come “questo utente può accedere solo ai dati del suo team”. In questo modo, il modello riceve solo i documenti che l’utente è autorizzato a vedere, prevenendo fughe di dati accidentali.
• Auditabilità: In ambito enterprise, non basta dare una risposta; bisogna mostrare perché è corretta. I sistemi di retrieval possono indicare i documenti o le fonti esatte utilizzate, così i team possono verificare i risultati e fare debugging se qualcosa va storto.
• Gestione strutturata della conoscenza: Le aziende aggiungono, aggiornano e rimuovono continuamente documenti. I sistemi di retrieval usano embedding e indicizzazione per organizzare questi dati, così il modello può trovare rapidamente le informazioni più aggiornate e rilevanti senza rielaborare tutto ogni volta.

Per un approccio nuovo e interessante all’aggiunta di memoria persistente agli agenti AI, leggi il nostro Tutorial su Supermemory, in cui impari a creare un coach per esercizi con memoria a breve e lungo termine.

Workflow di coding a lungo contesto

Oggi, la maggior parte dei modelli di coding non riesce a vedere l’intera codebase. Quindi aggiungiamo livelli sopra: ricerca file, chunking, ranking e pianificazione multi-step, solo per mantenere il contesto giusto nella finestra e costruire relazioni tra file.

Ma con il contesto da 12M di SubQ, l’intera codebase viene caricata nel modello in una volta sola. Questo semplifica in modo significativo il design degli agenti.

• La pianificazione diventa globale: Il modello può ragionare su architettura, dipendenze e interazioni tra file senza perdere contesto.
• L’esecuzione è più coerente: Le modifiche su più file possono essere coordinate in un unico passaggio, anziché con aggiornamenti incrementali.
• La revisione è più affidabile: Il modello può verificare le proprie modifiche rispetto all’intera codebase, riducendo le incoerenze.

Economia dei costi

Nei transformer standard, l’attention scala quadraticamente con la lunghezza della sequenza. Se raddoppi il contesto, il costo non raddoppia soltanto; può diventare quattro volte più caro.

SubQ sostiene di rompere questo trade-off.

• Riporta ~1/20 del costo rispetto a modelli di frontiera comparabili (Claude Opus)
• E fino a ~1.000× di riduzione del compute a un contesto da 12M token

Se ciò si conferma in produzione, l’elaborazione a lungo contesto smette di essere un caso limite costoso e diventa qualcosa che puoi usare più di routine.

Tuttavia, insieme a una finestra di contesto economica, il modello deve essere in grado di usare in modo efficiente le informazioni caricate nel suo contesto. In base ai benchmark, SubQ rivendica un’accuratezza comparabile a un costo molto inferiore, ma è troppo presto per una dichiarazione definitiva.

Come posso accedere a SubQ?

SubQ non è ancora disponibile pubblicamente. Tutti e tre i prodotti, l’API core, SubQ Code e SubQ Search, sono attualmente in beta privata, e l’accesso richiede una richiesta di early access tramite il sito SubQ.

Dal punto di vista dello sviluppatore, l’API è progettata per essere facile da integrare. Supporta:

• risposte in streaming
• tool/function calling
• endpoint compatibili con OpenAI

Questo significa che, se il tuo stack funziona già con API in stile OpenAI, in genere non devi riscrivere l’integrazione.

SubQ Code è posizionato come un agente di coding da riga di comando, mentre SubQ Search si concentra sulla ricerca a lungo contesto per workflow di ricerca più profondi. Pensali come le versioni SubQ di Claude Code e Perplexity. 

Anche i prezzi di questi strumenti non sono ancora trasparenti. Non ci sono tariffe per token pubbliche, il che rende difficile convalidare in modo indipendente le affermazioni dell’azienda sui costi.

Scetticismo e domande aperte

Nel giro di poche ore dal lancio, c’è già molto scetticismo e reazioni miste sui social e su bacheche come Hacker News. La discussione è divisa: c’è chi lo vede come una vera svolta e chi lo paragona a una “Theranos dell’AI” (un riferimento alla startup di analisi del sangue fallita che fece affermazioni tecnologiche fraudolente).

La maggior parte dei dubbi si concentra su: 

• Dichiarano una finestra di contesto da 12M, ma i benchmark condivisi sono tutti a 1M.
• Hanno chiamato l’azienda Subquadratic, ma in alcuni punti menzionano uno scaling simile a O(1). Con O(1), ci si aspetterebbe molto più di una finestra da 12M token. Anche O(log n) consentirebbe limiti maggiori.

Una narrativa simile è emersa con Magic.dev nel 2024. Hanno fatto affermazioni forti riguardo a finestre di contesto estremamente grandi, fino a 100M token, e grossi guadagni di efficienza, soprattutto per i workflow di coding. 

Il pitch era quasi identico: caricare intere codebase, ridurre la complessità del retrieval e semplificare il design degli agenti. Ma l’esito, almeno pubblicamente, è stato più tiepido. Nonostante un fundraising di circa 500 milioni di dollari, a inizio 2026 si registra ancora una visibilità o adozione nel mondo reale limitata.

Cosa è stato verificato

Le affermazioni di SubQ non sono puramente teoriche. Subquadratic riferisce che i benchmark su RULER, MRCR v2 e SWE-Bench Verified sono stati eseguiti da un servizio di test terzo, mostrando solide prestazioni nel recupero a lungo contesto e risultati competitivi nei task di coding. 

Tuttavia, questi risultati non sono ancora stati riprodotti in modo indipendente da ricercatori esterni, e l’ambito della valutazione è limitato. Tutti e tre i benchmark enfatizzano esattamente le aree per cui SubQ è costruito (recuperare segnali da contesti ampi e operare sul codice).

Un altro dettaglio importante riguarda l’architettura. Il CTO ha confermato che SubQ non allena modelli da zero, ma si basa su modelli open source (probabilmente di famiglie come DeepSeek o Kimi). È una scelta pratica per un team piccolo: accelera l’iterazione e riduce i costi di training. Significa anche che l’innovazione principale non è il modello base in sé, ma il meccanismo di attention e il design di sistema attorno ad esso.

Considerazioni finali

SubQ è qui, e le affermazioni sono piuttosto audaci. La direzione è chiara: rimuovere il vincolo della finestra di contesto e lasciare che i modelli gestiscano input molto più grandi. Lo stanno posizionando come in grado di eguagliare o superare i modelli di frontiera nel coding e nel recupero a lungo contesto, a un costo molto più basso.

Detto questo, è ancora presto. Stiamo ancora aspettando la model card completa per avere maggiore visibilità su capacità e test più ampi. Anche i prodotti costruiti sopra, SubQ Code e l’API, non sono ancora pubblicamente disponibili. Non vedo l’ora di provarli con mano e vedere come reggono le affermazioni in produzione.