Vi utformade modellfamiljen GPT‑5.6 för att balansera kapacitet och kostnad för hela det spektrum av uppgifter som människor använder våra modeller till. Vår flaggskeppsmodell GPT‑5.6 Sol med maximalt resonemang överträffar Claude Fable 5 i Artificial Analysis Coding Agent Index till mindre än halva kostnaden. Terra presterar lika bra som GPT‑5.5 i intelligensriktmärken till halva priset, och Luna är vår snabbaste och mest prisvärda modell, med ett pris som är 80 % lägre än Sols. För att uppnå denna effektivitet har våra forsknings- och teknikteam gjort betydande optimeringar i alla större lager av vår stack. Förbättringarna omfattar våra modeller, inferens (hur vi kör modeller för att generera utdata) och vår agentbaserade körmiljö, som används av både Codex och ChatGPT Work.
När vi under de senaste fyra åren har skalat upp våra modeller till en miljard aktiva användare och fler än två miljoner företag har effektivitet varit avgörande för att sprida intelligensens fördelar till alla. Vårt uppdrag är att säkerställa att artificiell generell intelligens kommer hela mänskligheten till godo. Under dessa år har vi arbetat med att kontinuerligt uppnå större optimeringar i hela vår stack för att kunna erbjuda de mest högpresterande modellerna i varje del av kostnads- och intelligenskurvan. Med GPT‑5.6 uppnådde vi vår hittills högsta effektivitet mätt i intelligens per token. Modellen har tränats för att utföra mer arbete per token. Under träningen optimerar vi både för framgångsrikt slutförande av uppgifter och för effektivitet, så att modellen tar en mer direkt väg genom uppgiften.
I det här inlägget tittar vi bortom våra modeller och beskriver hur vi har utformat systemet för högre effektivitet genom framsteg i två andra viktiga delar av stacken: 1) inferens, där vi optimerar processer som lastbalansering, spekulativ avkodning, cachelagring och kärnoptimering för att få ut mer prestanda från samma maskinvara, och 2) vår agentbaserade körmiljö, bland annat genom bättre hantering av svällande kontext, verktygsanvändning och upprepat arbete. Vi beskriver också hur GPT‑5.6 Sol självständigt bidrog till flera av dessa förbättringar. Även om varje enskild förbättring kan verka begränsad förstärker de varandra och gör det möjligt för oss att ligga i framkant inom både intelligens och effektivitet.
I en värld med begränsad beräkningskapacitet, där efterfrågan på modeller växer snabbare än kapaciteten, är effektivitet en grundläggande princip i all systemdesign. Detta gäller särskilt vår inferensstack, som kör tränade modeller för att generera svar. Vårt främsta mål är att generera fler token med samma maskinvara, utan att kompromissa med den intelligens, svarstid, tillgänglighet och tillförlitlighet som användarna förväntar sig.
För att uppnå detta måste hela systemet optimeras. En modell kan vara mycket effektiv isolerat, men ändå vara dyr att köra om förfrågningar fördelas dåligt, maskinvara står oanvänd eller dataöverföring bromsar beräkningarna. Förbättringar i varje lager samverkar, och vinsterna kommer från optimeringar av dirigering (vart förfrågningar skickas), schemaläggning (när de skickas), kärnor (programvara som körs på grafikprocessorer), cachelagring (sparade och återanvända beräkningar) och modellimplementering (ordningen på GPU-koden). GPT‑5.6 Sol i Codex spelade en avgörande roll i alla dessa optimeringar.
Det första viktiga exemplet är lastbalansering. Globalt dirigerar vi förfrågningar utifrån faktorer som geografi, tillgänglig kapacitet och acceleratortyp (typen av GPU eller specialiserat chip som kör modellen). Inom ett kluster fördelar vi arbetet mellan modellinstanser utifrån belastning, kontextlängd, cachetillgänglighet och andra egenskaper hos förfrågningar. Inom varje instans måste arbetet sedan fördelas effektivt mellan acceleratorer, modellens delnätverk och beräkningskärnor. GPT‑5.6 Sol i Codex hjälper oss att analysera produktionstrafik, identifiera tidigare förbisedda källor till obalans, testa nya dirigeringsstrategier och kontinuerligt finjustera dessa beslutsregler. Enbart dessa förbättringar av lastbalanseringen minskade kostnaderna för att köra våra modeller dramatiskt.
Vi använde också GPT‑5.6 Sol för att optimera modellens framåtpass: den beräkning som omvandlar indata till prediktioner av nästa token. Även när enskilda operationer går snabbt kan onödig minnesöverföring, synkronisering och ineffektiva datalayouter göra att GPU:er står oanvända. För att undvika detta identifierade GPT‑5.6 Sol beräkningar som kunde förberäknas, undvikas eller parallelliseras. Med hjälp av Codex skrev GPT‑5.6 Sol självständigt om och optimerade våra produktionskärnor – den centrala kod som utför de matematiska operationer som utgör modellen. Detta fungerade delvis eftersom vi har tränat GPT‑5.6 att effektivt skriva och förbättra kärnor i Triton(öppnas i ett nytt fönster) och Gluon(öppnas i ett nytt fönster), två GPU-programmeringsspråk med öppen källkod som underhålls av OpenAI. Dessa insatser, tillsammans med GPT‑5.6 Sols bredare förbättringar av kärnor, minskade de totala kostnaderna för inferens med 20 %. Vi har också investerat stort i verifieringsverktyg, exempelvis verktyget FpSan(öppnas i ett nytt fönster) (Floating-Point Sanitizer) med öppen källkod, för att verifiera att de kärnor som GPT‑5.6 Sol skriver är korrekta.
Spekulativ avkodning är ytterligare ett sätt att förbättra hastighet och effektivitet. Tekniken innebär att en mindre utkastmodell (eller ”spekulator”) körs tillsammans med den primära modellen och föreslår flera token som den primära modellen verifierar parallellt. När dessa förslag godtas kan systemet generera flera utdatatoken med ett enda pass genom den primära modellen, vilket minskar mängden kostsamma sekventiella beräkningar. GPT‑5.6 Sol förbättrade sin egen utkastmodell genom att utforma och genomföra hundratals experiment med dess arkitektur och testa förändringar i storlek, struktur och funktioner. Dessutom startade och övervakade GPT‑5.6 Sol spekulatorns träningsprocess och ingrep självständigt när problem uppstod, däribland maskinvarufel och instabilitet under träningen. Förbättringarna ökade effektiviteten i tokengenereringen med mer än 15 %.
När indatatoken som inte finns i cachen bearbetas bygger modellen upp nyckel-värde-cachen (KV-cachen) i ett beräkningsintensivt pass. När utdata genereras läser modellen upprepade gånger från och utökar cachen. Den optimala konfigurationen för inferens, exempelvis batchning, sharding och KV-hantering, beror i hög grad på arbetsbelastningen – prompt- och utdatalängd, batchstorlek, cacheträffgrad, förfrågningarnas egenskaper med mera. Tidigare var konfigurationsutrymmet dock för stort för att kunna optimeras systematiskt, vilket tvingade ingenjörerna att förlita sig på övergripande beslutsregler. Med GPT‑5.6 Sol i Codex kunde vi analysera produktionsarbetsbelastningar, generera och utvärdera kandidatkonfigurationer samt hyperoptimera hur motorn och modellen konfigureras för varje scenario. Detta gör en ny nivå av arbetsbelastningsspecifik optimering praktiskt möjlig och gör det möjligt att få ut mer inferens från samma maskinvara.
Inferensoptimering är en kontinuerlig återkopplingsloop. Vi mäter beteendet i produktion, identifierar de största bristerna, genomför ändringar och verifierar att de förbättrar hela systemet snarare än ett enskilt prestandatest. GPT‑5.6 Sol och Codex påskyndar varje del av denna loop. Det innebär att vårt team kan utforska fler idéer, reagera snabbare på förändrade arbetsbelastningar och skapa en inferensstack med kortare svarstid, större kapacitet och lägre kostnader för användarna.
ChatGPT Work och Codex utför komplexa uppgifter genom en serie förfrågningar till modellen och verktygsanrop. Under en enda användaromgång – från användarens begäran till det slutliga svaret – kan Codex granska källkod, söka i driftsättningshistoriken, läsa incidentrapporter, redigera en fil och köra tester. Varje steg kan kräva en ny förfrågan till modellen.
Att förbereda kontext, överföra data, köra inferens, anropa verktyg och starta processer kräver både tid och beräkningsresurser. Om en uppgift kräver 30 förfrågningar till modellen blir en extra sekund per förfrågan snabbt märkbar. Att förbättra den övergripande prestandan handlar om att minska det upprepade arbetet i hela systemet, inte bara om att göra modellen snabbare.– det räcker inte att bara göra Modellen snabbare.
En enda användaromgång kan omfatta många iterationer med modellen och verktygen. Kostnader i den upprepade delen kan uppstå många gånger.
Dessa multiplikatoreffekter har påverkat utformningen av vår agentbaserade körmiljö – ett orkestreringslager i Rust som kopplar samman våra modeller, verktyg och användarens miljö. Härnäst går vi igenom hur man gör varje förfrågan effektivare genom att undvika växande kontext, effektivisera inläsningen av verktyg och återanvända tidigare beräkningar.
När agenter får tillgång till fler verktyg, färdigheter, insticksprogram och mer konversationshistorik kan kontextfönster lätt växa. Det ökar kostnaderna, distraherar modellen och leder till onödiga resonemang. Körmiljön kan minska denna belastning genom uppskjuten identifiering, vilket gör att integrationer, anpassade MCP-verktyg, färdigheter och insticksprogram bara blir tillgängliga när de behövs. Körmiljön förhindrar också att enskilda verktyg och MCP-integrationer oväntat tar upp utrymme i kontextfönstret. Verktygsutdata begränsas som standard till 10 000 token, om inte modellen begär en annan gräns.
Som tidigare nämnts kan en agentloop skicka samma instruktioner, konversationshistorik, verktygsdefinitioner och tidigare resultat till GPU:erna flera gånger under en och samma användaromgång. Det är kostsamt att bearbeta dessa upprepade indata, så promptcache återanvänder de beräkningar som är kopplade till ett tidigare bearbetat promptprefix. För att bevara detta prefix behandlar körmiljön all historik som är synlig för modellen som endast tilläggsbar: nya meddelanden, verktygsresultat och miljöuppdateringar läggs till i slutet i stället för att infogas tidigare i kontexten. Verktygen presenteras också i en deterministisk ordning, medan körningsinställningar, exempelvis godkännandepolicyer, tillämpas under körningen i stället för att bäddas in i verktygsdefinitionerna. Detta designval bidrar till de höga övergripande träffgraderna för promptcache i Codex och ChatGPT Work.
Inkrementell överföring förändrar vad som skickas över nätverket, medan promptcache förändrar vilka delar modellen kan undvika att beräkna på nytt. Bredderna är konceptuella och det ytterligare komprimeringslagret visas inte.
Effektivitetsvinsterna med GPT‑5.6 är resultatet av flera års samverkande förbättringar i hela stacken – från forskning och inferens till vår agentbaserade körmiljö. GPT‑5.6:s roll i att möjliggöra många av dessa förbättringar gör oss optimistiska om att optimeringstakten kommer att öka. Vi kommer att fortsätta att göra ytterligare optimeringar inom områden som kärnoptimering, parallellt med grundläggande förbättringar av vår stack. Vi ser fram emot att föra dessa fortlöpande förbättringar i den underliggande tekniken vidare till våra användare och kunder i form av mer allmänt tillgänglig och kostnadseffektiv intelligens.
Ett särskilt tack till Matthew Ferrari, Philippe Tillet, Ahmed Ibrahim, Joe Gershenson och Steve Coffey, Members of Technical Staff, för deras bidrag till det här inlägget.
