Jul, 134 minuti di lettura
Piattaforma
News · I nuovi GPT-5.4 mini e nano di OpenAI spingono una strategia di composizione a due livelli
Jul, 94 min di lettura
PiattaformaI nuovi GPT-5.4 mini e nano di OpenAI spingono una strategia di composizione a due livelli
I nuovi modelli piccoli sono pensati e prezzati per architetture a subagenti, dove un planner di grandi dimensioni delega compiti specifici a modelli più economici e veloci in esecuzione parallela.
Cosa ha lanciato davvero OpenAI
OpenAI ha rilasciato due modelli piccoli, GPT-5.4 mini e GPT-5.4 nano, presentati come i suoi modelli piccoli più capaci finora. La proposta è precisa e concreta: carichi di lavoro in cui la latenza definisce l'esperienza del prodotto — assistenti di coding, subagenti, sistemi che usano il computer leggendo screenshot e ragionamento multimodale in tempo reale.
Il modello mini funziona più del doppio più velocemente di GPT-5 mini e, sui benchmark interni di OpenAI, riduce gran parte del distacco dal GPT-5.4 completo. Su SWE-Bench Pro (Public) ottiene 54,4% contro il 57,7% di GPT-5.4, e su OSWorld-Verified arriva al 72,1% contro il 75,0%. Nano è posizionato più in basso — consigliato per classificazione, estrazione dati, ranking e subagenti di coding che gestiscono compiti di supporto più semplici.
Il prezzo conferma questo posizionamento. Nell'API, mini costa 0,75$ per milione di token in input e 4,50$ per milione di token in output, con una finestra di contesto da 400k; nano scende a 0,20$ e 1,25$. In Codex, mini consuma solo il 30% della quota di GPT-5.4 — circa un terzo del costo per i compiti di coding più semplici.
Il vero prodotto è il pattern a subagenti
OpenAI è insolitamente esplicita sull'architettura che vuole che gli sviluppatori adottino. In Codex, un modello più grande come GPT-5.4 gestisce pianificazione, coordinamento e giudizio finale, poi delega a subagenti GPT-5.4 mini che eseguono compiti più specifici in parallelo — cercare in un codebase, revisionare un file grande, elaborare documenti di supporto.
L'azienda lo dichiara senza mezzi termini: invece di usare un solo modello per tutto, gli sviluppatori possono comporre sistemi in cui i modelli più grandi decidono cosa fare e i modelli più piccoli eseguono velocemente su larga scala. La quota Codex al 30% e la possibilità di delegare al modello più economico il lavoro meno impegnativo dal punto di vista del ragionamento sono i meccanismi che rendono questo approccio economicamente sensato, non solo teorico.
Questo trasforma la scelta del modello da una decisione singola a un problema di routing. Il lavoro di engineering interessante si sposta sul decidere quali compiti siano 'sufficientemente specifici' per mini, e su come un modello planner coordini l'output di subagenti in parallelo — decisioni che ora comportano un differenziale di costo diretto e misurabile.
Dove i modelli piccoli sono ancora limitati
Le tabelle dei benchmark rivelano un limite netto: il contesto lungo. Su OpenAI MRCR v2 8-needle nella fascia 128K–256K, GPT-5.4 mini ottiene 33,6% contro il 79,3% di GPT-5.4, e nano si ferma al 33,1%. Anche nella fascia 64K–128K, mini raggiunge solo il 47,7% contro l'86,0% del modello completo.
Questo divario pesa sull'impostazione a subagenti. Un subagente incaricato di 'revisionare un file grande' o 'elaborare documenti di supporto' fa esattamente il tipo di lavoro di recupero su input lunghi in cui questi modelli peggiorano di più. Il pattern di composizione funziona bene per sottotask brevi e specifici; diventa più rischioso nel momento in cui un compito delegato richiede ragionamento su una finestra di contesto ampia.
Un dato riportato da un cliente va in direzione opposta. Il CTO di Hebbia riferisce che GPT-5.4 mini ha ottenuto tassi di successo end-to-end più alti e un'attribuzione delle fonti più solida rispetto al modello più grande GPT-5.4 nelle loro valutazioni. Questa inversione — un modello più piccolo che batte uno più grande su un compito specifico — conferma che 'più grande' e 'migliore' non sono la stessa cosa, ma significa anche che i team non possono presumere la classifica: devono testare caso per caso.
Cosa significa per i team che costruiscono agenti sensibili alla latenza
L'implicazione concreta di questo rilascio è che la scelta del modello ora è una decisione economica per ogni singolo sottotask, non per applicazione. Con mini al 30% della quota di GPT-5.4 e nano ancora più economico, il costo di eseguire un compito sul livello sbagliato è quantificabile, e l'incentivo a fare routing in modo aggressivo è forte.
Il lavoro pratico si sposta verso sistemi di valutazione che misurano ogni sottotask rispetto a ogni livello — perché i benchmark mostrano che i livelli divergono in modo non uniforme. Le chiamate a tool e i compiti di uso del computer tengono bene su mini (τ2-bench telecom al 93,4%, OSWorld-Verified al 72,1%), mentre il recupero su contesto lungo crolla. Un team che fa routing in base al tipo di compito, invece di assumere una capacità generica, otterrà gran parte del risparmio senza ereditarne le modalità di fallimento.
OpenAI ha di fatto trasformato in prodotto l'intuizione che il modello migliore spesso non è quello più grande. I team che ne beneficeranno saranno quelli che strumentano le proprie pipeline a sufficienza da sapere, per ogni compito, esattamente dove quell'intuizione regge.
Find this story relevant to you?
Contact us to find a unique solution
Cerchi un partner di ingegneria AI capace di costruire davvero?
Aiutiamo le aziende a integrare l AI nei prodotti, automatizzare i flussi di lavoro ad alto valore e modernizzare i sistemi software che sostengono la crescita.
Letture correlate
Altre analisi su delivery di prodotto, IA operativa e il lavoro sui sistemi che fa reggere il deployment alla prova dei fatti.