Come GPT‑5.6 unisce intelligenza ed efficienza di frontiera

Abbiamo progettato la famiglia di modelli GPT‑5.6 per bilanciare capacità e costi nell’intero spettro di attività per cui le persone utilizzano i nostri modelli. Il nostro modello di punta, GPT‑5.6 Sol, con ragionamento Max supera Claude Fable 5 nell’Artificial Analysis Coding Agent Index a meno della metà del costo. Terra eguaglia GPT‑5.5 nei benchmark sul livello di ragionamento a metà prezzo, mentre Luna è il nostro modello più veloce e conveniente, con un prezzo inferiore dell’80% rispetto a Sol. Per raggiungere questi livelli di efficienza, i nostri team tecnici e di ricerca hanno apportato importanti ottimizzazioni a ogni livello principale dello stack. Questi miglioramenti riguardano i nostri modelli, l’inferenza, cioè il modo in cui eseguiamo i modelli per generare output, e la nostra infrastruttura per agenti, utilizzata sia da Codex sia da ChatGPT Work.

Negli ultimi quattro anni abbiamo ampliato l’uso dei nostri modelli fino a un miliardo di utenti attivi e oltre due milioni di aziende; l’efficienza è stata fondamentale per estendere a tutti i benefici del livello di ragionamento. La nostra missione è garantire che l’intelligenza artificiale generale porti benefici a tutta l’umanità. Nel corso di questi anni abbiamo lavorato per ottenere continuamente maggiori ottimizzazioni in tutto lo stack, così da offrire i modelli più performanti in ogni punto della curva tra costi e livello di ragionamento. Con GPT‑5.6 abbiamo raggiunto la nostra migliore efficienza in termini di livello di ragionamento per token: il modello è addestrato per svolgere più lavoro per token. Durante l’addestramento ottimizziamo sia il successo nelle attività sia l’efficienza, orientando il modello verso un percorso più diretto per completarle.

Questo articolo va oltre i nostri modelli e illustra come abbiamo progettato l’efficienza attraverso i progressi in altre due parti principali dello stack: 1) l’inferenza, ottimizzando processi quali bilanciamento del carico, decodifica speculativa, caching e kernel per ottenere più output dallo stesso hardware; 2) la nostra infrastruttura per agenti, con una migliore gestione dell’aumento del contesto, dell’uso degli strumenti e del lavoro ripetuto. Illustreremo anche il ruolo di GPT‑5.6 Sol nel realizzare autonomamente molti di questi progressi. Anche se ogni singolo miglioramento può sembrare limitato, nel loro insieme questi risultati ci permettono di raggiungere la frontiera sia dell’intelligenza sia dell’efficienza.

In un mondo con risorse di calcolo limitate, dove la domanda di modelli cresce più rapidamente della capacità, l’efficienza è alla base della progettazione di ogni sistema. Ciò vale soprattutto per il nostro stack di inferenza, che esegue i modelli addestrati per generare risposte. Il nostro obiettivo principale è elaborare più token con lo stesso hardware, mantenendo il livello di ragionamento, la latenza, la disponibilità e l’affidabilità che gli utenti si aspettano.

Per riuscirci, è necessario ottimizzare l’intero sistema. Un modello può essere molto efficiente da solo, ma comunque costoso da utilizzare se le richieste sono distribuite male, l’hardware resta inattivo o il trasferimento dei dati rallenta il calcolo. I miglioramenti a ogni livello si sommano, grazie alle ottimizzazioni di instradamento (dove vengono inviate le richieste), pianificazione (quando vengono inviate), kernel (software eseguito sulle GPU), caching (lavoro salvato e riutilizzato) e implementazione del modello (ordine del codice GPU). GPT‑5.6 Sol in Codex ha svolto un ruolo determinante in tutte queste ottimizzazioni.

Il primo esempio importante è il bilanciamento del carico. A livello globale, instradiamo le richieste in base a fattori quali posizione geografica, capacità disponibile e tipo di acceleratore, ovvero il tipo di GPU o chip specializzato che esegue il modello. All’interno di un cluster, distribuiamo il lavoro tra le istanze del modello in base al carico, alla lunghezza del contesto, alla disponibilità della cache e ad altre proprietà delle richieste. In ogni istanza, il lavoro deve poi essere suddiviso in modo efficiente tra acceleratori, sottoreti del modello e core di calcolo. GPT‑5.6 Sol in Codex ci aiuta ad analizzare il traffico di produzione, individuare cause di squilibrio prima trascurate, testare nuove strategie di instradamento e perfezionare continuamente queste euristiche. Questi soli miglioramenti al bilanciamento del carico hanno ridotto drasticamente il costo di utilizzo dei nostri modelli.

Abbiamo usato GPT‑5.6 Sol anche per ottimizzare il forward pass del modello, cioè il calcolo che trasforma gli input nelle previsioni del token successivo. Anche quando le singole operazioni sono rapide, trasferimenti eccessivi di memoria, sincronizzazione e layout dei dati inefficienti possono lasciare inattive le GPU. Per evitarlo, GPT‑5.6 Sol ha individuato calcoli che potevano essere eseguiti in anticipo, evitati o parallelizzati. Con Codex, GPT‑5.6 Sol ha riscritto e ottimizzato autonomamente i nostri kernel di produzione, il codice centrale che esegue le operazioni matematiche alla base del modello. Ciò è stato possibile in parte perché abbiamo addestrato GPT‑5.6 a scrivere e migliorare efficacemente kernel in Triton⁠(si apre in una nuova finestra) e Gluon⁠(si apre in una nuova finestra), due linguaggi open source per la programmazione delle GPU gestiti da OpenAI. Queste attività, insieme ai più ampi progressi sui kernel ottenuti con GPT‑5.6 Sol, hanno ridotto del 20% i costi di utilizzo end-to-end. Abbiamo inoltre investito molto negli strumenti di verifica, come lo strumento open source FpSan⁠(si apre in una nuova finestra) (Floating-Point Sanitizer), per convalidare la correttezza dei kernel scritti da GPT‑5.6 Sol.

La decodifica speculativa è un’altra leva per aumentare velocità ed efficienza. La tecnica consiste nell’eseguire, insieme al modello principale, un modello preliminare più piccolo, detto anche "speculatore", che propone diversi token affinché il modello principale li verifichi in parallelo. Quando le proposte vengono accettate, il sistema può produrre più token di output con un solo passaggio del modello principale, riducendo i costosi calcoli sequenziali. GPT‑5.6 Sol ha migliorato il proprio modello preliminare progettando ed eseguendo centinaia di esperimenti sulla sua architettura e testando variazioni di dimensioni, struttura e funzionalità. Inoltre, GPT‑5.6 Sol ha avviato e monitorato l’addestramento dello speculatore, intervenendo autonomamente in caso di problemi, tra cui guasti hardware e instabilità dell’addestramento. I miglioramenti ottenuti hanno aumentato di oltre il 15% l’efficienza nella generazione dei token.

Durante l’elaborazione di token di input non memorizzati nella cache, il modello crea la cache chiave-valore (KV) in un unico passaggio ad alta intensità di calcolo; quando genera l’output, legge ed estende ripetutamente questa cache. La configurazione ottimale per l’utilizzo, inclusi batching, sharding e gestione KV, dipende fortemente dal carico di lavoro: lunghezza del prompt e dell’output, dimensione del batch, tasso di riscontro nella cache, caratteristiche delle query e altro ancora. In precedenza, tuttavia, lo spazio delle configurazioni era troppo ampio per essere ottimizzato sistematicamente, costringendo gli ingegneri ad affidarsi a euristiche generali. Con GPT‑5.6 Sol in Codex abbiamo potuto analizzare i carichi di lavoro di produzione, generare e valutare configurazioni candidate e ottimizzare al massimo la configurazione del motore e del modello per ogni scenario. Ciò rende praticabile un nuovo livello di ottimizzazione specifica per il carico di lavoro, ottenendo più inferenza utile dallo stesso hardware.

L’ottimizzazione dell’inferenza è un ciclo di feedback continuo. Misuriamo il comportamento in produzione, individuiamo le lacune maggiori, implementiamo modifiche e verifichiamo che migliorino l’intero sistema, non soltanto un benchmark isolato. GPT‑5.6 Sol e Codex accelerano ogni fase di questo ciclo. Il nostro team può così esplorare più idee, reagire più rapidamente alle variazioni dei carichi di lavoro e creare uno stack di inferenza con minore latenza, maggiore capacità e costi inferiori per gli utenti.

ChatGPT Work e Codex completano attività complesse attraverso una serie di richieste al modello e chiamate agli strumenti. In un singolo turno, dalla richiesta dell’utente alla risposta finale, Codex può esaminare il codice sorgente, cercare nella cronologia dei deployment, leggere i report sugli incidenti, modificare un file ed eseguire test. Ogni passaggio può richiedere una richiesta.

Preparare il contesto, trasmettere dati, eseguire l’inferenza, chiamare strumenti e avviare processi richiede tempo e risorse di calcolo. Se un’attività richiede 30 richieste al modello, un secondo in più per ciascuna richiesta si accumula rapidamente. Migliorare le prestazioni complessive significa ridurre il lavoro ripetuto in tutto il sistema, non soltanto velocizzare il modello.

Questi fattori moltiplicativi hanno orientato la progettazione della nostra infrastruttura per agenti, un livello di orchestrazione in Rust che collega modelli, strumenti e ambiente dell’utente. Vedremo ora come evitare l’eccessivo aumento del contesto, caricare gli strumenti e riutilizzare il lavoro renda ogni richiesta più efficiente.

Man mano che gli agenti ottengono accesso a più strumenti, competenze, plugin e cronologia delle conversazioni, le finestre di contesto possono facilmente ampliarsi. Ciò aumenta i costi, distrae il modello e induce un ragionamento non necessario. L’infrastruttura può ridurre questo carico tramite l’individuazione differita, che rende disponibili integrazioni, strumenti MCP personalizzati, competenze e plugin soltanto quando servono. L’infrastruttura impedisce inoltre che singoli strumenti e integrazioni MCP consumino in modo imprevisto la finestra di contesto. Per impostazione predefinita, l’output degli strumenti è limitato a 10.000 token, salvo che il modello richieda un limite diverso.

Come già accennato, il ciclo di un agente può inviare più volte alle GPU, in un singolo turno, le stesse istruzioni, la cronologia della conversazione, le definizioni degli strumenti e i risultati precedenti. Elaborare ripetutamente questi input è costoso, quindi la cache dei prompt riutilizza il calcolo associato al prefisso di un prompt elaborato in precedenza. Per conservare questo prefisso, l’infrastruttura tratta tutta la cronologia visibile al modello come una sequenza a sola aggiunta: nuovi messaggi, risultati degli strumenti e aggiornamenti dell’ambiente vengono aggiunti alla fine, anziché inseriti nel contesto precedente. Anche gli strumenti vengono presentati in un ordine deterministico, mentre le impostazioni di runtime, come i criteri di approvazione, vengono applicate durante l’esecuzione anziché incorporate nelle definizioni degli strumenti. Questa scelta progettuale contribuisce agli elevati tassi complessivi di riscontro nella cache dei prompt di Codex e ChatGPT Work.

I guadagni di efficienza ottenuti con GPT‑5.6 derivano da anni di miglioramenti cumulativi nell’intero stack, che riguardano ricerca, inferenza e la nostra infrastruttura per agenti. Il ruolo svolto da GPT‑5.6 nel realizzare molti di questi miglioramenti ci rende ottimisti sulla futura accelerazione delle ottimizzazioni. Continueremo ad apportare ottimizzazioni più incisive in aree come i kernel, insieme a miglioramenti fondamentali del nostro stack. Vogliamo trasferire agli utenti e ai clienti questi continui miglioramenti interni, offrendo un livello di ragionamento più accessibile ed efficiente in termini di costi.

Un ringraziamento speciale a Matthew Ferrari, Philippe Tillet, Ahmed Ibrahim, Joe Gershenson e Steve Coffey, membri del personale tecnico, per il loro contributo a questo articolo.