Përshpejtimi i flukseve të punës agjentike me WebSockets në API-në e Përgjigjeve

Kur i kërkon Codex-it të rregullojë një gabim, ai skanon bazën tënde të kodit për skedarë përkatës, i lexon ato për të ndërtuar kontekstin, bën ndryshime dhe ekzekuton teste për të verifikuar që rregullimi funksionoi. Në prapaskenë, kjo do të thotë dhjetëra kërkesa vajtje-ardhje te Responses API: përcakto veprimin e ardhshëm të modelit, ekzekuto një mjet në kompjuter, dërgo output-in e mjetit përsëri te API dhe përsëriteni.

Të gjitha këto kërkesa mund të rrisin minutazhin që përdoruesit shpenzojnë duke pritur që Codex-i të përfundojë detyra komplekse. Nga perspektiva e latencës, cikli i agjentit Codex shpenzon pjesën më të madhe të kohës së tij në tre faza kryesore:  punën në shërbimet API (për të vërtetuar dhe përpunuar kërkesat), inferencën e modelit dhe kohën në anën e klientit (ekzekutimin e mjeteve dhe ndërtimin e kontekstit të modelit). Inferenca është faza ku modeli ekzekutohet në GPU për të gjeneruar tokenë të rinj. Në të kaluarën, ekzekutimi i inferencës së LLM-ve në GPU ishte pjesa më e ngadaltë e ciklit të agjentit, kështu që mbingarkesa e shërbimit API ishte e lehtë për t’u fshehur. Ndërsa inferenca bëhet më e shpejtë, mbingarkesa kumulative e API-së nga një rollout agjentik bëhet shumë më e dukshme.

Në këtë postim, do të shpjegojmë se si i bëmë ciklet e agjentit duke përdorur API-në 40% më të shpejta nga fillimi në fund, duke u mundësuar përdoruesve të përjetojnë rritjen e shpejtësisë së inferencës nga 65 në pothuajse 1,000 token; në sekondë. Këtë e trajtuam përmes ruajtjes në memorien e përkohshme, duke eliminuar kalimet e panevojshme në rrjet, duke përmirësuar shtresën tonë të sigurisë për të sinjalizuar shpejt problemet dhe—më e rëndësishmja—duke ndërtuar një mënyrë për të krijuar një lidhje të qëndrueshme me Responses API, në vend që të duhej të bënim një seri thirrjesh sinkrone të API-së.

Në API-në Responses, modelet kryesore të mëparshme si GPT‑5 dhe GPT‑5.2 funksiononin me afërsisht 65 tokenë për sekondë (TPS). Për prezantimin e GPT‑5.3‑Codex‑Spark, një model i shpejtë për kodim, synimi ynë ishte një rritje dhjetëfish: mbi 1,000 TPS, i mundësuar nga hardueri i specializuar Cerebras, i optimizuar për inferencën e LLM-ve. Për t'u siguruar që përdoruesit të përjetonin shpejtësinë e vërtetë të këtij modeli të ri, duhej të reduktonim mbingarkesën e API-së. 

Rreth nëntorit të vitit 2025, nisëm një sprint të performancës në Responses API, duke sjellë shumë optimizime në latencën e rrugës kritike për një kërkesë të vetme: 

• Ruajtja në memorien specifike e tokenëve të renderuar dhe e konfigurimit të modelit në memorie për të anashkaluar tokenizimin e kushtueshëm dhe thirrjet e rrjetit për përgjigje me shumë kthesa
• Reduktimi i latencës së hop-eve të rrjetit duke eliminuar thirrjet ndaj shërbimeve ndërmjetëse (p.sh., rezolucioni i përpunimit të imazhit) dhe duke thirrur drejtpërdrejt shërbimin e inferencës.
• Po përmirësonim paketën tonë të sigurisë që të mund të ekzekutonim klasifikues të caktuar për të sinjalizuar bisedat më shpejt

Me këto përmirësime, pamë një rritje prej pothuajse 45% në kohën deri te token-i i parë (TTFT)—që tregon sa reaguese duket API-ja—por këto përmirësime ende nuk ishin mjaftueshëm të shpejta për GPT‑5.3‑Codex‑Spark. Edhe me këto përmirësime, mbingarkesa e Responses API ishte tepër e madhe krahasuar me shpejtësinë e modelit—kjo do të thotë se përdoruesit duhej të prisnin që CPU-të të ekzekutonin API-në tonë përpara se të përdornin GPU-të që shërbenin modelin.

Problemi më i thellë ishte strukturor: e trajtonim çdo kërkesë të Codex si të pavarur, duke përpunuar gjendjen e bisedës dhe kontekstin tjetër të ripërdorshëm në çdo kërkesë pasuese. Edhe kur pjesa më e madhe e bisedës nuk kishte ndryshuar, ne paguanim ende për punë të lidhur me historikun e plotë. Ndërsa bisedat bëheshin më të gjata, ai përpunim i përsëritur bëhej më i kushtueshëm.

Për ta përmirësuar dizajnin, rishqyrtuam protokollin e transportit: a mund të mbanim një lidhje të vazhdueshme dhe të ruanim gjendjen në cache, në vend që të krijonim një lidhje të re përmes HTTP-së dhe të dërgonim historinë e plotë të bisedës për çdo kërkesë pasuese? Ideja ishte që të dërgohej vetëm çdo informacion i ri që kërkonte validim dhe përpunim, dhe të ruhej në memorje gjendja e ripërdorshme për kohëzgjatjen e lidhjes. Kjo do ta reduktonte mbingarkesën nga puna e tepërt.

Ne morëm parasysh disa qasje të ndryshme, duke përfshirë WebSockets dhe transmetim dykahësh me gRPC. Vendosëm të përdorim WebSockets sepse, si një protokoll i thjeshtë për transportin e mesazheve, përdoruesve nuk do t’u duhej të ndryshonin formatet e input dhe output të Responses API. Ishte miqësore për zhvilluesit dhe përshtatej me arkitekturën tonë ekzistuese me pak ndërprerje.

Prototipi i parë WebSocket ndryshoi atë që mendonim se ishte e mundur për vonesën e Responses API. Një inxhinier në ekipin e Codex, me ekspertizë të thellë në të gjithë strukturën e API-së, krijoi një prototip duke përdorur një agjent Codex gjatë natës.

Në atë prototip, rollout-et agjentike u modeluan si një Response e vetme me kohëzgjatje të gjatë. Duke përdorur veçoritë e asyncio, Responses API do të bllokohej në mënyrë asinkrone në ciklin e mostrimit pasi të mostrohej një thirrje mjeti, dhe Responses API do t’i dërgonte klientit një event response.done. Pas ekzekutimit të thirrjes së mjetit, klientët do të dërgonin përsëri një event response.append me rezultatin e mjetit, gjë që zhbllokoi ciklin e mostrimit dhe e lejoi model të vazhdonte.

Një analogji këtu është trajtimi i thirrjes lokale të mjetit si një thirrje të mjetit të strehuar. Kur modeli thërret kërkimin në internet, cikli i inferencës bllokohet, thërret një shërbim kërkimi në internet dhe vendos përgjigjen e shërbimit në kontekstin e model. Në projektimin tonë, bëmë të njëjtën gjë; por në vend që të thërrisnim një shërbim në distancë, e dërguam thirrjen e mjetit të model përsëri te klienti përmes WebSocket. Kur klienti u përgjigj, ne vendosëm përgjigjen e thirrjes së mjetit të klientit në kontekst dhe vazhduam të gjeneronim.

Ky projektim ishte jashtëzakonisht efektiv sepse eliminoi punën e përsëritur me API gjatë zbatimit të një agjent. Mund të bënim punë para inferencës një herë, të ndalonim për ekzekutimin e mjeteve dhe të bënim punë pas inferencës një herë në fund.

Fatkeqësisht, kjo na kushtoi strukturën e një API-je më pak të njohur dhe më të ndërlikuar. Ne donim që zhvilluesit të mund të shtonin mbështetje për WebSocket pa pasur nevojë të rishkruanin integrimin e tyre me API-n rreth një mënyre të re ndërveprimi.

Për versionin që lançuam, u kthyem te një formë e njohur: vazhdoni të përdorni response.create me të njëjtin trup dhe përdorni previous_response_id për të vazhduar kontekstin e bisedës nga gjendja e përgjigjes së mëparshme.

Në një lidhje WebSocket, serveri mban një cache në memorie, në nivel lidhjeje, të gjendjes së mëparshme të përgjigjes. Kur një response.create pasues përfshin previous_response_id, ne marrim atë gjendje nga cache në vend që ta rindërtojmë të gjithë bisedën nga e para.

Gjendja e ruajtur në memorien e përkohshme përfshin:

• Objektin i mëparshëm response
• Artikujt e mëparshëm të hyrjeve dhe daljeve
• Përkufizime mjetesh dhe hapësira emrash
• Artefakte të ripërdorshme për mostrim, si p.sh. tokenë të renderuar më parë

Duke ripërdorur gjendjen e mëparshme të përgjigjes në memorie, arritëm të realizonim disa optimizime të mëdha:

• Po bëjmë që disa nga klasifikuesit tanë të sigurisë dhe validuesit e kërkesave të përpunojnë vetëm hyrjen e re, jo të gjithë historikun çdo herë
• Mbajtja e një memorjeje të përkohshme (cache) me token të renderuar, të cilës i shtojmë vazhdimisht për të shmangur tokenizimin e panevojshëm
• Ripërdorimi i logjikës sonë të suksesshme të zgjidhjes/drejtimit të modelit në kërkesa të ndryshme 
• Mbivendosja e punës pas inferencës që nuk bllokon, si faturimi, me kërkesat pasuese

Qëllimi ishte t’i afroheshim sa më shumë prototipit me ngarkesë minimale, por me një strukturë API-je që zhvilluesit e kuptonin tashmë dhe mbi të cilën kishin ndërtuar.

Pas një sprinti dy-mujor për ndërtimin e modalitetit WebSocket, ne lançuam një version alfa me startup-et kryesore të agjentëve të kodimit, në mënyrë që ata ta integrojnë atë në infrastrukturën e tyre dhe të rrisin trafikun në mënyrë të sigurt. Përdoruesit alfa e pëlqyen shumë, duke raportuar deri në 40% përmirësime⁠(hapet në një dritare të re) në flukset e tyre të punës agjentike. Duke marrë parasysh reagimet pozitive nga alfa, ishim gati për ta hedhur në treg.

Rezultatet e lançimit ishin të menjëhershme. Codex-i kaloi shpejt shumicën e trafikut të tyre të Responses API në modalitetin WebSocket, duke parë përmirësime të ndjeshme në vonesë. Për GPT‑5.3‑Codex‑Spark, arritëm objektivin tonë prej 1,000 TPS dhe pamë rritje të menjëhershme deri në 4,000 TPS, duke treguar se Responses API mund të përballonte inferencë shumë më të shpejtë në trafik real prodhimi. Ndikimi u shfaq shpejt edhe në komunitetin e zhvilluesve:

• Codex-i kaloi me shpejtësi pjesën më të madhe të trafikut të tij në WebSockets. Përdoruesit e Codex që përdorin model më të fundit si GPT‑5.3‑Codex⁠(hapet në një dritare të re), GPT‑5.4⁠(hapet në një dritare të re), dhe më gjerë përfitojnë nga rritja e shpejtësisë së modalitetit WebSocket.
• Vercel integroi modalitetin WebSocket në AI SDK dhe pa që vonesa u ul me deri në 40%⁠(hapet në një dritare të re).
• Flukset e punës me shumë skedarë të Cline janë 39% më të shpejtë⁠(hapet në një dritare të re).
• Modelet e OpenAI në Cursor u bënë deri në 30% më të shpejta⁠(hapet në një dritare të re).

Modaliteti WebSocket është një nga aftësitë e reja më domethënëse në Responses API që nga lançimi i saj në mars 2025. Kaluan nga ideja në funksionim në prodhim brenda vetëm pak javësh, përmes bashkëpunimit të ngushtë midis ekipeve të API-t të OpenAI dhe Codex-it. Jo vetëm që përmirëson ndjeshëm latencën e nxjerrjes në përdorim të agjentit, por gjithashtu mbështet një nevojë në rritje për zhvilluesit: ndërsa inferenca e modelit bëhet më e shpejtë, shërbimet dhe sistemet që e rrethojnë inferencën duhet gjithashtu të përshpejtohen për t’ua transferuar këto përfitime përdoruesve.