Sådan forener GPT‑5.6 banebrydende intelligens med banebrydende effektivitet

Vi designede GPT‑5.6‑modelfamilien til at skabe balance mellem kapacitet og pris på tværs af de opgaver, som vores modeller bruges til. Vores flagskibsmodel, GPT‑5.6 Sol, med Max-ræsonnering klarer sig bedre end Claude Fable 5 på Artificial Analysis Coding Agent Index til under halvdelen af prisen. Terra klarer sig lige så godt som GPT‑5.5 i intelligensbenchmarks til halv pris, mens Luna er vores hurtigste og mest prisvenlige model og koster 80 % mindre end Sol. For at opnå denne effektivitet har vores forsknings- og tekniske teams gennemført betydelige optimeringer i alle de vigtigste lag af vores stack. Forbedringerne omfatter vores modeller, inferens – måden vi kører modeller på for at generere output – og vores agentbaserede harness, som både Codex og ChatGPT Work bruger.

I takt med at vi gennem de seneste fire år har skaleret vores modeller til 1 milliard aktive brugere og over 2 millioner virksomheder, har effektivitet været afgørende for at gøre fordelene ved intelligens tilgængelige for alle. Vores mission er at sikre, at kunstig generel intelligens kommer hele menneskeheden til gode. Gennem disse år har vi løbende arbejdet på at frigøre større optimeringer i hele vores stack, så vi kan tilbyde modellerne med den bedste ydeevne på alle punkter af pris-intelligens-kurven. Med GPT‑5.6 har vi opnået vores hidtil bedste intelligens pr. token, fordi modellen er trænet til at udføre mere arbejde pr. token. Under træningen optimerer vi både for vellykket opgaveløsning og effektivitet, så modellen tager en mere direkte vej gennem opgaven.

Dette indlæg ser ud over selve modellerne og beskriver, hvordan vi har øget effektiviteten med fremskridt i to andre centrale dele af vores stack: 1) inferens, hvor vi optimerer processer som belastningsfordeling, spekulativ afkodning, cachelagring og kerneoptimering for at få mere output fra den samme hardware, og 2) vores agentbaserede harness, blandt andet gennem bedre styring af kontekstoverflod, brug af værktøjer og gentaget arbejde. Vi fortæller også, hvordan GPT‑5.6 Sol autonomt bidrog til flere af disse gevinster. Selv om hver enkelt forbedring kan synes begrænset, forstærker gevinsterne hinanden og gør det muligt at være banebrydende inden for både intelligens og effektivitet.

I en verden med begrænset regnekraft, hvor efterspørgslen efter modeller vokser hurtigere end kapaciteten, er effektivitet afgørende for udformningen af alle systemer. Det gælder især vores inferensstack, som kører trænede modeller for at generere svar. Vores primære mål er at behandle flere tokens med den samme hardware og samtidig bevare den intelligens, svartid, tilgængelighed og driftssikkerhed, som brugerne forventer.

Det kræver optimering af hele systemet. En model kan være meget effektiv isoleret set, men stadig være dyr at drive, hvis forespørgsler fordeles dårligt, hardware står ubrugt, eller dataoverførsel bremser beregningerne. Forbedringer på alle lag forstærker hinanden. Gevinsterne kommer fra optimering af routing (hvor forespørgsler sendes hen), planlægning (hvornår de sendes), kerner (software, der kører på GPU'er), cachelagring (arbejde, der gemmes og genbruges) og modelimplementering (rækkefølgen af GPU-koden). GPT‑5.6 Sol i Codex spillede en afgørende rolle i alle disse optimeringer.

Det første vigtige eksempel er belastningsfordeling. Globalt dirigerer vi forespørgsler ud fra faktorer som geografi, ledig kapacitet og acceleratortype – altså den type GPU eller specialchip, der kører modellen. I en klynge fordeler vi arbejdet mellem modelinstanser ud fra belastning, kontekstlængde, tilgængelig cache og andre egenskaber ved forespørgslen. I hver instans skal arbejdet derefter fordeles effektivt mellem acceleratorer, modellens undernetværk og beregningskerner. GPT‑5.6 Sol i Codex hjælper os med at analysere produktionstrafik, finde hidtil oversete kilder til ubalance, teste nye routingstrategier og løbende finjustere disse heuristikker. Alene disse forbedringer af belastningsfordelingen reducerede omkostningerne ved at drive vores modeller markant.

Vi brugte også GPT‑5.6 Sol til at optimere modellens forward pass: den beregning, der omdanner input til forudsigelser af næste token. Selv når de enkelte operationer er hurtige, kan unødig flytning af data i hukommelsen, synkronisering og ineffektive datalayouts efterlade GPU'er inaktive. For at undgå det fandt GPT‑5.6 Sol arbejde, der kunne forudberegnes, undgås eller paralleliseres. Med Codex omskrev og optimerede GPT‑5.6 Sol autonomt vores produktionskerner – den centrale kode, der udfører de matematiske operationer, som modellen består af. Det virkede blandt andet, fordi vi har trænet GPT‑5.6 i effektivt at skrive og forbedre kerner i Triton⁠(åbner i et nyt vindue) og Gluon⁠(åbner i et nyt vindue), som er to open source-programmeringssprog til GPU'er, der vedligeholdes af OpenAI. Denne indsats reducerede sammen med bredere kerneforbedringer fra GPT‑5.6 Sol de samlede driftsomkostninger med 20 %. Vi har også investeret massivt i verificeringsværktøjer såsom open source-værktøjet FpSan⁠(åbner i et nyt vindue) (Floating-Point Sanitizer), der hjælper med at validere korrektheden af de kerner, som GPT‑5.6 Sol skriver.

Speculative decoding er et andet middel til at forbedre hastighed og effektivitet. Teknikken går ud på at køre en mindre kladdemodel – også kaldet en »speculator« – sideløbende med den primære model. Den foreslår flere tokens, som den primære model kan verificere parallelt. Når forslagene accepteres, kan systemet generere flere outputtokens i én enkelt kørsel gennem den primære model og dermed reducere mængden af dyre sekventielle beregninger. GPT‑5.6 Sol forbedrede sin egen kladdemodel ved at designe og gennemføre hundredvis af eksperimenter med dens arkitektur og afprøve ændringer i størrelse, struktur og funktioner. Derudover startede og overvågede GPT‑5.6 Sol træningen af speculatoren og greb autonomt ind, når der opstod problemer, herunder hardwarefejl og ustabil træning. De efterfølgende forbedringer øgede effektiviteten ved tokengenerering med mere end 15 %.

Når modellen behandler inputtokens, der ikke ligger i cachen, opbygger den key-value-cachen (KV) i én beregningstung gennemløb. Når den genererer output, læser den gentagne gange fra cachen og udvider den. Den optimale driftskonfiguration – herunder batching, sharding og KV-styring – afhænger i høj grad af arbejdsbelastningen: prompt- og outputlængde, batchstørrelse, cachens træfrate, forespørgslernes egenskaber med mere. Tidligere var konfigurationsrummet dog for stort til systematisk finjustering, så teknikerne måtte basere sig på brede heuristikker. Med GPT‑5.6 Sol i Codex kunne vi analysere produktionsbelastninger, generere og evaluere mulige konfigurationer samt hyperoptimere konfigurationen af motoren og modellen til hvert scenarie. Det gør et nyt niveau af belastningsspecifik optimering praktisk muligt og giver mere nyttig inferens fra den samme hardware.

Inferensoptimering er en kontinuerlig feedbackcyklus. Vi måler adfærden i produktionen, finder de største mangler, implementerer ændringer og kontrollerer, at de forbedrer hele systemet frem for blot en isoleret benchmark. GPT‑5.6 Sol og Codex accelererer alle dele af denne cyklus. Det betyder, at vores team kan udforske flere idéer, reagere hurtigere på ændrede arbejdsbelastninger og udvikle en inferensstack med kortere svartid, større kapacitet og lavere omkostninger for brugerne.

ChatGPT Work og Codex løser komplekse opgaver gennem en række modelforespørgsler og værktøjskald. I én brugerhenvendelse – fra brugerens anmodning til det endelige svar – kan Codex gennemgå kildekode, søge i implementeringshistorikken, læse hændelsesrapporter, redigere en fil og køre test. Hvert trin kan kræve en forespørgsel.

Det kræver både tid og regnekraft at forberede kontekst, overføre data, køre inferens, kalde værktøjer og starte processer. Hvis en opgave kræver 30 modelforespørgsler, løber ét ekstra sekund pr. forespørgsel hurtigt op. Bedre samlet ydeevne kræver, at gentaget arbejde reduceres i hele systemet – ikke kun at modellen gøres hurtigere.

Disse multiplikatoreffekter har præget udformningen af vores agentbaserede harness, som er et orkestreringslag i Rust, der forbinder vores modeller og værktøjer med brugerens miljø. Nu gennemgår vi, hvordan mindre kontekstoverflod, indlæsning af værktøjer efter behov og genbrug af arbejde gør hver forespørgsel mere effektiv.

Når agenter får adgang til flere værktøjer, færdigheder, plugins og mere samtalehistorik, kan kontekstvinduer nemt vokse. Det øger omkostningerne, distraherer modellen og udløser unødvendig ræsonnering. Harnesset kan reducere denne belastning gennem udskudt registrering, så integrationer, tilpassede MCP-værktøjer, færdigheder og plugins kun bliver synlige, når der er brug for dem. Harnesset forhindrer også enkelte værktøjer og MCP-integrationer i uventet at optage plads i kontekstvinduet. Værktøjsoutput er som standard begrænset til 10.000 tokens, medmindre modellen anmoder om en anden grænse.

Som tidligere nævnt kan et agent-loop sende de samme instruktioner, samtalehistorikken, værktøjsdefinitionerne og tidligere resultater til GPU'erne flere gange i én enkelt brugerhenvendelse. Det er dyrt at behandle disse gentagne input, så prompt-cachelagring genbruger de beregninger, der er knyttet til et tidligere behandlet promptpræfiks. For at bevare præfikset behandler harnesset hele den historik, som modellen kan se, som skrivebeskyttet: Nye beskeder, værktøjsresultater og miljøopdateringer tilføjes til sidst i stedet for at blive indsat tidligere i konteksten. Værktøjer præsenteres også i en deterministisk rækkefølge, mens kørselsindstillinger såsom godkendelsespolitikker anvendes under kørslen i stedet for at blive indlejret i værktøjsdefinitionerne. Dette designvalg bidrager til de generelt høje træfrater for prompt-cachen i Codex og ChatGPT Work.

Effektivitetsgevinsterne i GPT‑5.6 er resultatet af flere års akkumulerede forbedringer i hele vores stack – fra forskning og inferens til vores agentbaserede harness. GPT‑5.6 har spillet en central rolle i mange af disse forbedringer, og det gør os optimistiske med hensyn til, hvor hurtigt optimeringerne vil accelerere. Vi vil fortsat gennemføre større optimeringer på områder som kerneoptimering sideløbende med grundlæggende forbedringer af vores stack. Vi ser frem til at give disse løbende forbedringer under motorhjelmen videre til vores brugere og kunder i form af mere bredt tilgængelig og omkostningseffektiv intelligens.

En særlig tak til Matthew Ferrari, Philippe Tillet, Ahmed Ibrahim, Joe Gershenson og Steve Coffey fra vores tekniske stab for deres bidrag til dette indlæg.