Kiiremad agendipõhised töövood Responses API-s WebSocketsi abil

Kui palud Codexil parandada vea, skannib see sinu koodibaasi, et leida asjakohaseid faile, loeb neid konteksti loomiseks, teeb muudatusi ja käivitab teste, et kontrollida, kas parandus töötas. Pinna all tähendab see kümneid edasi-tagasi päringuid Responses API-ga: otsusta mudeli järgmine tegevus, käivita tööriist sinu arvutis, saada tööriista väljund tagasi API-le ja korda.

Kõik need päringud võivad kokku võtta minuteid, mille jooksul kasutajad ootavad Codexilt keerukate ülesannete lõpuleviimist. Latentsuse vaatenurgast veedab Codexi agenditsükkel suurema osa oma ajast kolmes peamises etapis: töötades API-teenustes (päringute valideerimiseks ja töötlemiseks), mudeli inferentsis ja kliendipoolses ajas (tööriistade käivitamine ja mudeli konteksti loomine). Inferents on etapp, kus mudel töötab graafikaprotsessoritel, et genereerida uusi tokeneid. Minevikus oli suure keelemudeli inferentsi käivitamine graafikaprotsessoritel agendipõhise tsükli kõige aeglasem osa, seega oli API-teenuse lisakulu lihtne varjata. Inferentsi kiiruse kasvades muutub agendipõhise väljarullimise kumulatiivne API lisakulu palju märgatavamaks.

Selles postituses selgitame, kuidas me tegime API-t kasutavad agenditsüklid otsast lõpuni 40% kiiremaks, võimaldades kasutajatel kogeda hüpet inferentsi kiiruses 65-lt peaaegu 1000 tokenini sekundis. Lähenesime sellele läbi puhverdamise, ebavajalike võrguhüpete elimineerimise, meie ohutuspinu täiustamise probleemide kiireks märgistamiseks ja—mis kõige tähtsam—luues viisi Responses API-ga püsiva ühenduse loomiseks, selle asemel et teha rida sünkroonseid API-kutseid.

Responses API-s töötasid eelmised lipulaevmudelid nagu GPT‑5 ja GPT‑5.2 umbes kiirusega 65 tokenit sekundis (TPS). GPT‑5.3‑Codex‑Sparki, kiire kodeerimismudeli turuletoomiseks oli meie eesmärk saavutada suurusjärgu võrra suurem kiirus: üle 1000 TPS-i, mida võimaldab LLM-inferentsi jaoks optimeeritud spetsiaalne Cerebrase riistvara. Tagamaks, et kasutajad saaksid kogeda selle uue mudeli tõelist kiirust, pidime vähendama API lisakulu. 

2025. aasta novembri paiku käivitasime Responses API jõudlussprindi, tuues sisse mitmeid optimeerimisi ühe päringu kriitilise raja latentsusesse: 

• Renderdatud tokenite ja mudeli konfiguratsiooni puhverdamine mälus, et jätta vahele kallis tokenisatsioon ja võrgukutsed mitme pöördega vastuste puhul
• Võrguhüppe latentsuse vähendamine, elimineerides kutsed vaheteenustele (näiteks pilditöötluse resolutsioon) ja tehes kutse otse inferentsiteenusele
• Oma ohutuspinu täiustamine, et saaksime teatud klassifikaatoreid käitada ja vestlusi kiiremini märgistada

Nende täiustustega nägime peaaegu 45% paranemist esimese tokenini kuluvas ajas (TTFT)—mis peegeldab seda, kui reageerivana API tundub—kuid need täiustused polnud GPT‑5.3‑Codex‑Sparki jaoks siiski piisavalt kiired. Isegi nende täiustustega oli Responses API lisakulu mudeli kiirusega võrreldes liiga suur—see tähendab, et kasutajad pidid ootama meie API-t jooksutavate keskprotsessorite taga, enne kui said kasutada mudelit teenindavaid graafikaprotsessoreid.

Sügavam probleem oli struktuurne: me käsitlesime iga Codexi päringut iseseisvana, töödeldes vestluse olekut ja muud korduvkasutatavat konteksti igas järelpäringus. Isegi siis, kui enamik vestlusest polnud muutunud, maksime me ikkagi kogu ajaloo töötlemise eest. Vestluste pikenedes muutus see korduv töötlemine üha kallimaks.

Disaini koondamiseks mõtlesime ümber transpordiprotokolli: kas me saaksime hoida püsivat ühendust ja puhverdada olekut, selle asemel et luua HTTP kaudu uus ühendus ja saata iga järelpäringu jaoks kogu vestlusajalugu? Idee oli saata ainult uut teavet, mis nõudis valideerimist ja töötlemist, ning puhverdada korduvkasutatav olek mälus kogu ühenduse eluea jooksul. See vähendaks liiase töö lisakulu.

Kaalusime mitut erinevat lähenemisviisi, sealhulgas WebSocketsi ja gRPC kahesuunalist voogedastust. Valisime WebSocketsi, sest kuna tegu on lihtsa sõnumiedastusprotokolliga, ei peaks kasutajad oma Responses API sisendi ja väljundi vorme muutma. See oli arendajasõbralik ja sobis meie olemasoleva arhitektuuriga ilma suuremate häireteta.

Esimene WebSocketsi prototüüp muutis meie arusaama sellest, mis on Responses API latentsuse osas võimalik. Üks Codexi meeskonna insener, kellel olid sügavad teadmised kogu API pinu kohta, pani öö jooksul Codexi agendi käivitamisega kokku prototüübi.

Selles prototüübis modelleeriti agendi väljarullimisi ühe pikaajalise vastusena. Kasutades asyncio funktsioone, blokeeris Responses API asünkroonselt valimitsükli pärast seda, kui tööriista kutse oli valitud, ja Responses API saatis kliendile tagasi response.done sündmuse. Pärast tööriista kutse täitmist saatsid kliendid tagasi response.append sündmuse koos tööriista tulemusega, mis deblokeeris valimitsükli ja lasi mudelil jätkata.

Siin on analoogiks lokaalse tööriistakutse käsitlemine hostitud tööriistakutsena. Kui mudel kutsub välja veebiotsingu, siis inferentsitsükkel blokeerub, kutsub välja veebiotsinguteenuse ja paneb teenuse vastuse mudeli konteksti. Meie disainis tegime sama asja; kuid kaugeteenuse väljakutsumise asemel saatsime mudeli tööriistakutse kliendile tagasi WebSocketi kaudu. Kui klient vastas, panime kliendi tööriistakutse vastuse konteksti ja jätkasime valimiga.

See disain oli äärmiselt tõhus, kuna see kõrvaldas korduva API töö agendi väljarullimise ajal. Saime teha inferentsieelset tööd üks kord, teha pausi tööriista täitmiseks ja teha inferentsijärgset tööd üks kord lõpus.

Kahjuks tuli selle hinnaks vähem tuttav ja keerulisem API vorm. Soovisime, et arendajad saaksid lisada WebSocketsi toe, ilma et nad peaksid oma API-integratsiooni uue suhtlusrežiimi jaoks ümber kirjutama.

Versiooni jaoks, mille turule tõime, lülitusime tagasi tuttava vormi juurde: kasuta endiselt response.create-i sama kehaga ja kasuta previous_response_id-d, et jätkata vestluse konteksti eelneva vastuse olekust.

WebSocketi ühendusel hoiab server eelmise vastuse oleku ühenduse ulatusega mälupuhvrit. Kui järelpäring response.create sisaldab previous_response_id-d, võtame selle oleku puhvrist, selle asemel et ehitada kogu vestlust nullist üles.

See puhverdatud olek sisaldab järgmist:

• Eelmine vastuse objekt
• Eelnevad sisendi ja väljundi üksused
• Tööriistade definitsioonid ja nimeruumid
• Korduvkasutatavad valimi artefaktid, näiteks eelnevalt renderdatud tokenid

Kasutades uuesti mälus olevat eelmise vastuse olekut, suutsime sisse viia mitmeid suuri optimeerimisi:

• Panime osad meie ohutusklassifikaatoritest ja päringute valideerijatest töötlema ainult uut sisendit, mitte iga kord kogu ajalugu
• Hoidsime mälus renderdatud tokenite puhvrit, millele saame uusi asju juurde lisada, et saaksime vahele jätta ebavajaliku tokenisatsiooni
• Taaskasutasime oma edukat mudeli resolutsiooni/suunamise loogikat päringute üleselt 
• Katsime mitteblokeeriva inferentsijärgse töö, näiteks arveldamise, järgnevate päringutega

Eesmärk oli jõuda võimalikult lähedale minimaalse lisakuluga prototüübile, kuid API vormiga, millest arendajad juba aru said ja mille ümber nad ehitasid.

Pärast kahekuulist sprinti WebSocketi režiimi ehitamisel käivitasime alfafaasi võtmetähtsusega kodeerimisagentide idufirmadega, et nad saaksid selle integreerida oma infrastruktuuri ja liiklust turvaliselt suurendada. Alfa-kasutajatele see meeldis, nad teatasid kuni 40% parendustest⁠(avaneb uues aknas) oma agendipõhistes töövoogudes. Arvestades positiivset alfa-tagasisidet, olime valmis turuletoomiseks.

Turuletoomise tulemused olid kohesed. Codex suunas kiiresti enamiku oma Responses API liiklusest WebSocketsi režiimile, nähes märkimisväärset latentsuse paranemist. GPT‑5.3‑Codex‑Sparki puhul saavutasime oma 1000 TPS-i sihtmärgi ja nägime kuni 4000 TPS-i puhanguid, näidates, et Responses API suudab reaalses tootmisliikluses palju kiirema inferentsiga sammu pidada. Mõju ilmnes kiiresti ka arendajate kogukonnas:

• Codex viis suurema osa oma liiklusest kiiresti WebSocketsile üle. Codexi kasutajad, kes käitasid uusimaid mudeleid nagu GPT‑5.3‑Codex⁠(avaneb uues aknas), GPT‑5.4⁠(avaneb uues aknas), ja edasisi mudeleid, saavad kõik kasu WebSocketi režiimi kiiruse kasvust.
• Vercel integreeris WebSocketi režiimi AI SDK-sse ja nägi latentsuse vähenemist kuni 40%⁠(avaneb uues aknas).
• Cline’i mitme faili töövood on 39% kiiremad⁠(avaneb uues aknas).
• OpenAI mudelid Cursoris muutusid kuni 30% võrra kiiremaks⁠(avaneb uues aknas).

WebSocketsi režiim on üks olulisimaid uusi võimekusi Responses API-s alates selle käivitamisest 2025. aasta märtsis. Jõudsime ideest tootmisse vaid paari nädalaga tänu OpenAI API ja Codexi meeskondade tihedale koostööle. See mitte ainult ei paranda märkimisväärselt agendi väljarullimise latentsust, vaid toetab ka arendajate kasvavat vajadust: mudeli inferentsi kiiruse kasvades peavad ka inferentsi ümbritsevad teenused ja süsteemid kiirenema, et need eelised kasutajateni jõuaksid.