Aģentisku darbplūsmu paātrināšana ar WebSockets Responses API

Kad tu palūdz Codex novērst kļūdu, tas pārskata tavu koda bāzi, lai atrastu atbilstošos failus, nolasa tos konteksta izveidei, veic labojumus un izpilda testus, lai pārbaudītu, vai kļūda ir novērsta. Aizkulisēs tas nozīmē desmitiem savstarpēju Responses API pieprasījumu: noteikt nākamo modeļa darbību, izpildīt rīku tavā datorā, nosūtīt rīka rezultātu atpakaļ uz API un atkārtot šo procesu.

Visi šie pieprasījumi kopā var veidot minūtes, kuras lietotāji pavada, gaidot, kamēr Codex pabeidz sarežģītus uzdevumus. No latentuma viedokļa Codex aģenta cikls lielāko daļu laika pavada trīs galvenajos posmos: darbā API pakalpojumos (pieprasījumu validēšana un apstrāde), modeļa inferencē un klienta puses laikā (rīku izpilde un modeļa konteksta veidošana). Inference ir posms, kur modelis darbojas uz GPU, lai ģenerētu jaunas tekstvienības. Agrāk lielo valodas modeļu (LVM) inference uz GPU bija lēnākais aģentiskā cikla posms, tāpēc API pakalpojumu pieskaitāmās izmaksas bija viegli noslēpt. Taču, inference kļūstot ātrākai, kopējais API pieskaitāmais laiks aģentiskā izpildē kļūst daudz pamanāmāks.

Šajā rakstā skaidrosim, kā mēs panācām, ka aģentu cikli, izmantojot API, kļuva par 40 % ātrāki no sākuma līdz beigām, ļaujot lietotājiem sajust inference ātruma pieaugumu no 65 līdz gandrīz 1000 tekstvienībām sekundē. Mēs to panācām, izmantojot kešatmiņu, novēršot nevajadzīgus tīkla starpsoļus, uzlabojot drošības mehānismus, lai ātri identificētu problēmas, un – pats svarīgākais – izveidojot iespēju uzturēt pastāvīgu savienojumu ar Responses API, nevis veikt virkni sinhronu API pieprasījumu.

Responses API iepriekšējie pamatmodeļi, piemēram, GPT‑5 un GPT‑5.2, darbojās ar aptuveni 65 tekstvienībām sekundē (TPS). Izlaižot GPT‑5.3‑Codex‑Spark – ātru kodēšanas modeli –, mūsu mērķis bija panākt kārtas lieluma pieaugumu: vairāk nekā 1000 TPS, ko nodrošina specializēta Cerebras aparatūra, kas optimizēta LVM inferences vajadzībām. Lai lietotāji varētu pilnībā izjust šī jaunā modeļa ātrumu, mums bija jāsamazina API pieskaitāmās izmaksas. 

Apmēram 2025. gada novembrī mēs uzsākām veiktspējas uzlabošanas sprintu Responses API, ieviešot vairākas optimizācijas, kas samazina viena pieprasījuma kritiskā ceļa latentumu: 

• Kešatmiņā saglabājot jau ģenerētās tekstvienības un modeļa konfigurāciju, lai vairāku soļu sarunās izvairītos no dārgas dalīšanas tekstvienībās un tīkla pieprasījumiem
• Samazinot tīkla aizturi, likvidējot starpservisu izsaukumus (piemēram, attēlu apstrādes posmus) un veicot tiešus izsaukumus uz inference servisu
• Uzlabojot drošības mehānismus, lai noteiktus klasifikatorus varētu darbināt ātrāk un operatīvāk identificēt problemātiskas sarunas

Ar šiem uzlabojumiem mēs sasniedzām gandrīz 45 % uzlabojumu laikā līdz pirmajai tekstvienībai (TTFT), kas atspoguļo, cik atsaucīgs šķiet API, taču ar to joprojām nepietika GPT‑5.3‑Codex‑Spark vajadzībām. Pat pēc šiem uzlabojumiem Responses API pieskaitāmās izmaksas joprojām bija pārāk lielas attiecībā pret modeļa ātrumu – tas nozīmē, ka lietotājiem nācās gaidīt uz CPU, kas apstrādā API, pirms tie varēja izmantot GPU, kas nodrošina modeli.

Dziļākā problēma bija strukturāla: katru Codex pieprasījumu mēs apstrādājām kā neatkarīgu, katrā turpmākajā pieprasījumā atkārtoti apstrādājot sarunas stāvokli un citu atkārtoti izmantojamu kontekstu. Pat ja lielākā daļa sarunas nebija mainījusies, mēs joprojām maksājām par visu vēsturiski saistīto apstrādi. Sarunām kļūstot garākām, šī atkārtotā apstrāde kļuva arvien dārgāka.

Lai uzlabotu arhitektūru, mēs pārdomājām transporta protokolu: vai varam uzturēt pastāvīgu savienojumu un kešot stāvokli, nevis katram turpmākajam pieprasījumam izveidot jaunu HTTP savienojumu un nosūtīt visu sarunas vēsturi? Ideja bija nosūtīt tikai jauno informāciju, kurai nepieciešama validācija un apstrāde, bet atkārtoti izmantojamo stāvokli glabāt atmiņā visā savienojuma darbības laikā. Tas samazinātu pieskaitāmās izmaksas, kas rodas no lieka darba.

Mēs apsvērām vairākas pieejas, tostarp WebSockets un gRPC divvirzienu straumēšanu. Galu galā izvēlējāmies WebSockets, jo kā vienkāršs ziņojumu transporta protokols tas neprasa lietotājiem mainīt Responses API ievades un izvades struktūru. Tas ir ērts izstrādātājiem un labi iekļāvās mūsu esošajā arhitektūrā ar minimālām izmaiņām.

Pirmais WebSocket prototips mainīja mūsu priekšstatu par iespējamo Responses API latentumu. Kāds Codex komandas inženieris ar padziļinātām zināšanām par visu API steku izveidoja prototipu, darbinot Codex aģentu nakts laikā.

Šajā prototipā aģentiskā izpilde tika modelēta kā viena ilgstoša Response. Izmantojot asyncio iespējas, Responses API asinhroni apturēja izpildi paraugošanas ciklā pēc rīka izsaukuma izvēles un nosūtīja klientam response.done notikumu. Pēc rīka izpildes klienti nosūtīja atpakaļ response.append notikumu ar rīka rezultātu, kas atbloķēja paraugošanas ciklu un ļāva modelim turpināt darbu.

Šeit var izmantot analoģiju ar lokālu rīka izsaukumu kā ar hostētu rīka izsaukumu. Kad modelis izsauc tīmekļa meklēšanu, inference cikls tiek apturēts, tiek izsaukts tīmekļa meklēšanas serviss, un tā rezultāts tiek ievietots modeļa kontekstā. Mūsu pieejā mēs darījām to pašu, tikai tā vietā, lai izsauktu attālu servisu, mēs nosūtījām modeļa rīka izsaukumu klientam atpakaļ pa WebSocket savienojumu. Kad klients atbildēja, mēs iekļāvām klienta rīka izsaukuma atbildi kontekstā un turpinājām veikt paraugošanu.

Šis risinājums bija ļoti efektīvs, jo tas novērsa atkārtotu API darbu visā aģenta izpildes ciklā. Mēs varējām veikt pirms-inference darbības vienu reizi, apturēt izpildi rīka darbībām un pēc-inference apstrādi veikt tikai vienu reizi beigās.

Tomēr tas radīja arī trūkumu – API kļuva mazāk ierasta un sarežģītāka. Mūsu mērķis bija ļaut izstrādātājiem pievienot WebSocket atbalstu, nepārrakstot visu API integrāciju jaunam mijiedarbības modelim.

Izlaistajā versijā mēs atgriezāmies pie pazīstamas pieejas: turpināt izmantot response.create ar to pašu pieprasījuma struktūru un izmantot previous_response_id, lai turpinātu sarunas kontekstu no iepriekšējās atbildes stāvokļa.

WebSocket savienojumā serveris uztur savienojuma līmeņa, atmiņā glabātu iepriekšējo atbilžu stāvokļa kešatmiņu. Kad turpmākais response.create pieprasījums ietver previous_response_id, mēs šo stāvokli iegūstam no kešatmiņas, nevis no jauna veidojam visu sarunas vēsturi.

Šajā kešotajā stāvoklī ietilpst:

• Iepriekšējais atbildes objekts
• Iepriekšējie ievades un izvades elementi
• Rīku definīcijas un nosaukumtelpas
• Atkārtoti izmantojami paraugošanas artefakti, piemēram, iepriekš renderētās tekstvienības

Atkārtoti izmantojot atmiņā saglabāto iepriekšējās atbildes stāvokli, mēs varējām ieviest vairākas būtiskas optimizācijas:

• Daļu mūsu drošības klasifikatoru un pieprasījumu validācijas loģikas pielāgot tā, lai tā apstrādā tikai jauno ievadi, nevis visu vēsturi katru reizi
• Uzturēt atmiņā kešatmiņu ar jau renderētajām tekstvienībām, ko varam papildināt, tādējādi izvairoties no liekas dalīšanas tekstvienībās
• Atkārtoti izmantot jau strādājošo modeļa izvēles un maršrutēšanas loģiku starp pieprasījumiem 
• Pārklāt nebloķējošus pēcinference procesus, piemēram, norēķinus, ar nākamajiem pieprasījumiem

Mērķis bija pēc iespējas pietuvoties prototipam ar minimālām pieskaitāmajām izmaksām, vienlaikus saglabājot API formu, ko izstrādātāji jau pazīst un izmanto.

Pēc divu mēnešu sprinta, izstrādājot WebSocket režīmu, mēs palaidām alfa versiju ar vadošajiem kodēšanas aģentu jaunuzņēmumiem, lai tie varētu to integrēt savā infrastruktūrā un droši palielināt datplūsmu. Alfa lietotāji bija ļoti apmierināti, ziņojot par līdz pat 40 % uzlabojumiem⁠(atveras jaunā logā) savās aģentiskajās darbplūsmās. Ņemot vērā pozitīvās atsauksmes, mēs bijām gatavi publiskai palaišanai.

Rezultāti bija tūlītēji. Codex ātri pārcēla lielāko daļu Responses API datplūsmas uz WebSocket režīmu, panākot būtiskus latentuma uzlabojumus. GPT‑5.3‑Codex‑Spark gadījumā mēs sasniedzām mērķi – 1000 TPS – un novērojām uzplūdus līdz pat 4000 TPS, kas apliecina, ka Responses API spēj sekot daudz ātrākai inference arī reālas produkcijas slodzes apstākļos. Ietekme ātri kļuva redzama arī izstrādātāju kopienā:

• Codex ātri pārcēla lielāko daļu savas datplūsmas uz WebSockets. Codex lietotāji, kuri izmanto jaunākos modeļus, piemēram, GPT‑5.3‑Codex⁠(atveras jaunā logā), GPT‑5.4⁠(atveras jaunā logā), un jaunākus, gūst labumu no WebSocket režīma nodrošinātā ātruma pieauguma.
• Vercel integrēja WebSocket režīmu savā AI SDK un novēroja latentuma samazinājumu līdz pat 40 %⁠(atveras jaunā logā).
• Cline vairāku failu darbplūsmas kļuva par 39 % ātrākas⁠(atveras jaunā logā).
• OpenAI modeļi Cursor vidē kļuva līdz pat 30 % ātrāki⁠(atveras jaunā logā).

WebSocket režīms ir viena no nozīmīgākajām jaunajām Responses API iespējām kopš tā palaišanas 2025. gada martā. No idejas līdz darbībai produkcijā mēs nonācām tikai dažu nedēļu laikā, cieši sadarbojoties OpenAI API un Codex komandām. Tas ne tikai būtiski uzlabo aģentu izpildes latentumu, bet arī atbilst augošai izstrādātāju vajadzībai: līdz ar to, ka modeļu inference kļūst arvien ātrāka, arī apkārtējām sistēmām un servisiem jāspēj paātrināties, lai šos ieguvumus nodotu lietotājiem.