Արագացնելով ագենտային աշխատանքային հոսքերը WebSockets-ի միջոցով Պատասխանների API-ում

Երբ Codex-ին խնդրում եք շտկել սխալը, այն սկանավորում է ձեր կոդային բազան՝ համապատասխան ֆայլերը գտնելու համար, կարդում է դրանք համատեքստ ստեղծելու համար, փոփոխություններ է կատարում և թեստավորում է՝ համոզվելու, որ շտկումը հաջողվել է։ Ըստ էության դա ենթադրում է Պատասխանների API-ի տասնյակ փոխադարձ հարցումներ․ որոշել մոդելի հաջորդ գործողությունը, գործարկել գործիքը ձեր համակարգչում, գործիքի արդյունքը հետ ուղարկել API-ին և կրկնել։

Այս բոլոր հարցումները կարող են կազմել մի քանի րոպե, որոնք օգտատերերը ծախսում են սպասելով, որ Codex-ը ավարտի բարդ առաջադրանքները։ Ուշացման տեսանկյունից Codex ագենտի ցիկլը իր ժամանակի մեծ մասը ծախսում է երեք հիմնական փուլերում՝ API ծառայություններում աշխատանքը (հարցումները վավերացնելու և մշակելու համար), մոդելի ինֆերենսը և հաճախորդի կողմի ժամանակը (գործիքները գործարկելը և մոդելի համատեքստը կառուցելը)։ Ինֆերենսը այն փուլն է, երբ մոդելն աշխատում է GPU-ների վրա՝ նոր թոքեններ գեներացնելու համար։ Անցյալում GPU-ների վրա LLM ինֆերենսի գործարկումը ագենտային ցիկլի ամենադանդաղ մասն էր, ուստի API ծառայության հավելյալ ծախսերը հեշտ էր քողարկել։ Քանի որ ինֆերենսը դառնում է ավելի արագ, ագենտային ներդրման դեպքում API-ի կուտակային հավելյալ ծախսը դառնում է շատ ավելի նկատելի։

Այս գրառման մեջ կբացատրենք, թե ինչպես API-ի միջոցով ագենտի ցիկլերը ամբողջ գործընթացի մասշտաբով 40%-ով ավելի արագ դարձրեցինք՝ թույլ տալով օգտատերերին զգալ ինֆերենսի արագության աճը՝ վայրկյանում 65-ից մինչև գրեթե 1,000 թոքեն։ Մենք դրան հասանք քեշավորման միջոցով, վերացնելով ավելորդ ցանցային միջանկյալ անցումները, բարելավելով մեր անվտանգության համակարգը՝ խնդիրներն արագ հայտնաբերելու համար և, ամենակարևորը, ստեղծելով Պատասխանների API-ի հետ մշտական կապ հաստատելու միջոց՝ սինխրոն API կանչերի շարք կատարելու անհրաժեշտության փոխարեն։

Պատասխանների API-ում GPT‑5 և GPT‑5.2‑ի նման նախորդ ֆլագմանային մոդելներն աշխատում էին վայրկյանում մոտ 65 թոքեն (TPS) արագությամբ։ GPT‑5.3‑Codex‑Spark‑ի՝ արագ կոդավորման մոդելի գործարկման համար մեր նպատակը մեկ կարգով ավելի արագ արդյունք ապահովելն էր․ ավելի քան 1,000 TPS, ինչը հնարավոր է դարձել LLM ինֆերենսի համար օպտիմալացված Cerebras-ի մասնագիտացված սարքավորման շնորհիվ։ Որպեսզի համոզվենք, որ օգտատերերը կարող են զգալ այս նոր մոդելի իրական արագությունը, մենք ստիպված էինք նվազեցնել API-ի հավելյալ ծախսերը։ 

2025 թվականի նոյեմբերին մենք Պատասխանների API-ի վրա գործարկեցինք արդյունավետության սպրինտ՝ կատարելով բազմաթիվ օպտիմալացումներ մեկ հարցման համար կրիտիկական ուղու ուշացման մեջ. 

• Արտածված թոքենների և մոդելի կազմաձևի քեշավորում հիշողության մեջ՝ բազմափուլ պատասխանների համար ծախսատար թոքենիզացիան և ցանցային կանչերը շրջանցելու համար
• Ցանցային հանգույցների միջև հապաղման նվազեցում՝ վերացնելով միջանկյալ ծառայություններին կատարվող կանչերը (օրինակ՝ պատկերների մշակման լուծաչափը) և անմիջապես դիմելով ինֆերենսի ծառայությանը
• Մենք բարելավում ենք մեր անվտանգության համակարգը, որպեսզի կարողանանք գործարկել որոշ դասակարգիչներ՝ խոսակցությունները ավելի արագ նշելու համար

Այս բարելավումների շնորհիվ մենք գրանցեցինք առաջին թոքենին հասնելու ժամանակի (TTFT) գրեթե 45% բարելավում, ինչը ցույց է տալիս API-ի արձագանքման արագությունը, սակայն այդ բարելավումները դեռևս բավարար արագ չէին GPT‑5.3‑Codex‑Spark‑ի համար։ Նույնիսկ այս բարելավումներով, Պատասխանների API-ի վերադիր ծախսերը չափազանց մեծ էին մոդելի արագության համեմատ, այսինքն՝ օգտատերերը ստիպված էին սպասել API-ն գործարկող CPU-ներին, նախքան կկարողանային օգտվել մոդելը սպասարկող GPU-ներից։

Ավելի խորը խնդիրը կառուցվածքային էր․ մենք Codex-ի յուրաքանչյուր հարցում դիտարկում էինք որպես անկախ՝ յուրաքանչյուր հաջորդ հարցման դեպքում մշակելով խոսակցության վիճակը և վերօգտագործելի այլ համատեքստը։ Նույնիսկ երբ զրույցի մեծ մասը չէր փոխվել, մենք միևնույն է վճարում էինք ամբողջական պատմության հետ կապված աշխատանքի համար։ Քանի որ զրույցներն ավելի երկար էին դառնում, այդ կրկնվող մշակումը ավելի ծախսատար էր դառնում։

Դիզայնն ավելի հստակ դարձնելու համար մենք վերաիմաստավորեցինք տրանսպորտային պրոտոկոլը․ արդյո՞ք կարող էինք պահպանել մշտական կապ և քեշավորել վիճակը՝ այլ ոչ թե HTTP-ով ամեն հաջորդ հարցման համար նոր կապ հաստատել և ուղարկել զրույցի ամբողջ պատմությունը։ Գաղափարն այն էր, որ ուղարկվի միայն ցանկացած նոր տեղեկատվություն, որը պահանջում է վավերացում և մշակում, իսկ վերօգտագործվող վիճակը պահվի հիշողության մեջ կապի ողջ տևողության ընթացքում։ Սա կնվազեցներ կրկնակի աշխատանքի ավելորդ ծախսերը։

Մենք դիտարկել ենք մի քանի տարբեր մոտեցումներ, այդ թվում՝ WebSockets և gRPC-ի երկկողմանի հոսքային փոխանցումը։ Մենք ընտրեցինք WebSockets, քանի որ որպես հաղորդագրությունների փոխանցման պարզ արձանագրություն՝ օգտատերերը ստիպված չէին լինի փոխել իրենց Պատասխանների API-ի մուտքի և ելքի կառուցվածքները։ Այն նախատեսված էր ծրագրավորողների համար և քիչ խափանումներով տեղավորվում էր մեր առկա ճարտարապետության մեջ։

Առաջին WebSocket նախատիպը փոխեց մեր պատկերացումները Պատասխանների API-ի ուշացման հնարավորությունների մասին։ Codex թիմի ինժեներներից մեկը, որն ուներ API փաթեթի շրջանակում խորը փորձագիտություն, գիշերվա ընթացքում գործարկելով Codex ագենտ՝ նախատիպ ստեղծեց։

Այդ նախատիպում ագենտային գործարկումները մոդելավորվում էին որպես մեկ երկարատև Պատասխան։ Օգտագործելով asyncio -ի հնարավորությունները՝ Պատասխանների API-ն գործիքի կանչի նմուշառումից հետո նմուշառման ցիկլում ասինխրոն կերպով կբլոկավորվեր, և Պատասխանների API-ն response.done իրադարձությունը հետ կուղարկեր հաճախորդին։ Գործիքի կանչը կատարելուց հետո հաճախորդները հետ կուղարկեին response.append իրադարձություն՝ գործիքի արդյունքով, ինչը ապաշրջափակում էր նմուշառման ցիկլը և թույլ էր տալիս մոդելին շարունակել։

Այստեղ կարելի է զուգահեռ անցկացնել՝ տեղային գործիքի կանչը դիտարկելով որպես հոսթավորված գործիքի կանչ։ Երբ մոդելը կատարում է վեբ որոնում, եզրահանգման ցիկլը դադարում է, կանչում է վեբ որոնման ծառայություն և ծառայության պատասխանը տեղադրում է մոդելի համատեքստում։ Մեր նախագծում մենք նույնն արեցինք, սակայն հեռավար ծառայություն կանչելու փոխարեն մոդելի գործիքի կանչը WebSocket-ով հետ ուղարկեցինք հաճախորդին։ Երբ հաճախորդը պատասխանեց, մենք հաճախորդի գործիքի կանչի պատասխանը տեղադրեցինք համատեքստում և շարունակեցինք նմուշառումը։

Այս նախագիծը չափազանց արդյունավետ էր, քանի որ ագենտի ներդրման ողջ ընթացքում վերացրեց API-ի հետ կրկնվող աշխատանքը։ Մենք կարող էինք մեկ անգամ կատարել ինֆերենսից առաջ անհրաժեշտ աշխատանքը, դադար տալ գործիքի կատարման համար, և վերջում մեկ անգամ կատարել ինֆերենսից հետո անհրաժեշտ աշխատանքը։

Ցավոք, սա տեղի ունեցավ ավելի քիչ ծանոթ և ավելի բարդ API կառուցվածքի հաշվին։ Մենք ցանկանում էինք, որ ծրագրավորողները կարողանան հեշտությամբ ավելացնել WebSocket-ի աջակցությունը՝ առանց իրենց API ինտեգրումը նոր փոխգործակցության եղանակին համապատասխան վերաշարադրելու։

Մեր թողարկած տարբերակի համար մենք վերադարձանք ծանոթ ձևաչափին․ շարունակեք օգտագործել response.create -ը նույն պարունակությամբ և կիրառեք previous_response_id -ը՝ զրույցի համատեքստը նախորդ պատասխանի վիճակից շարունակելու համար։

WebSocket կապի դեպքում սերվերը պահում է կապի շրջանակով սահմանված՝ օպերատիվ հիշողության մեջ գտնվող նախորդ պատասխանի վիճակի քեշ։ Երբ հաջորդող response.create -ը ներառում է previous_response_id, մենք այդ վիճակը քեշից ստանում ենք՝ ամբողջ զրույցը զրոյից վերակառուցելու փոխարեն։

Այդ քեշավորված վիճակը ներառում է՝

• Նախորդ response օբյեկտը
• Նախորդ մուտքային և ելքային տարրեր
• Գործիքների սահմանումներ և անվանատարածքներ
• Վերօգտագործվող նմուշառման արտեֆակտներ, ինչպիսիք են նախկինում արտապատկերված թոքենները

Հիշողության մեջ պահված նախորդ պատասխանի վիճակը կրկին օգտագործելով՝ մենք կարողացանք իրականացնել մի քանի էական օպտիմալացումներ՝

• Դարձնելով մեր անվտանգության դասակարգիչներից և հարցումների վավերացուցիչներից մի քանիսն այնպես, որ մշակեն միայն նոր մուտքային տվյալները, ոչ թե ամեն անգամ ամբողջ պատմությունը
• Արտածված թոքենների հիշողության մեջ պահվող քեշ, որին մենք ավելացնում ենք, որպեսզի կարողանանք բաց թողնել ավելորդ թոքենիզացիան
• Մեր հաջողված մոդելի լուծման/ուղղորդման տրամաբանության վերօգտագործումը հարցումների միջև 
• Վճարարկման նման չարգելափակող՝ եզրակացությունից հետո կատարվող աշխատանքը համընկեցնել հաջորդ հարցումների հետ

Նպատակն էր հնարավորինս մոտենալ նվազագույն ծախսերով նախատիպին՝ ունենալով API-ի այնպիսի կառուցվածք, որը ծրագրավորողներն արդեն հասկանում էին և որի շուրջ կառուցել էին իրենց լուծումները։

WebSocket ռեժիմի ստեղծման վրա երկամսյա ինտենսիվ աշխատանքի փուլից հետո մենք գործարկեցինք ալֆա տարբերակ՝ կոդավորման ագենտների ոլորտի առաջատար ստարտափների հետ, որպեսզի նրանք կարողանան ինտեգրել այն իրենց ենթակառուցվածքում և անվտանգ կերպով աստիճանաբար մեծացնեն տրաֆիկը։ Ալֆա օգտատերերը շատ հավանեցին այն՝ հայտնելով իրենց ագենտային աշխատանքային հոսքերում մինչև 40% բարելավումների մասին⁠(բացվում է նոր պատուհանում)։ Ալֆա տարբերակի վերաբերյալ դրական արձագանքները հաշվի առնելով՝ մենք պատրաստ էինք գործարկել։

Մեկնարկի արդյունքներն անմիջապես եղան։ Codex-ը արագորեն իր Պատասխանների API-ի տրաֆիկի մեծ մասը տեղափոխեց WebSocket ռեժիմ, ինչի արդյունքում գրանցվեցին հապաղման զգալի բարելավումներ։ GPT‑5.3‑Codex‑Spark‑ի համար մենք հասանք մեր 1,000 TPS թիրախին և արձանագրեցինք մինչև 4,000 TPS պիկեր, ինչը ցույց տվեց, որ Պատասխանների API-ն կարող էր համընթաց աշխատել շատ ավելի արագ ինֆերենսի հետ իրական արտադրական տրաֆիկի պայմաններում։ Ազդեցությունն արագորեն նկատվեց նաև ծրագրավորողների համայնքում՝

• Codex-ը արագորեն իրենց թրաֆիկի մեծ մասը տեղափոխեց WebSockets տեխնոլոգիայի վրա։ Codex-ի օգտատերերը, որոնք աշխատում են վերջին մոդելներով, ինչպիսիք են GPT‑5.3‑Codex⁠(բացվում է նոր պատուհանում), GPT‑5.4⁠(բացվում է նոր պատուհանում), և ավելին, բոլորը օգտվում են WebSocket ռեժիմի արագության բարելավումից։
• Vercel-ը WebSocket ռեժիմը ինտեգրեց AI SDK-ի մեջ, և հապաղումը նվազել է մինչև 40%-ով⁠(բացվում է նոր պատուհանում)։
• Cline-ի բազմաֆայլ աշխատանքային հոսքերը 39%-ով ավելի արագ են⁠(բացվում է նոր պատուհանում)։
• OpenAI մոդելները Cursor-ում դարձան մինչև 30% ավելի արագ⁠(բացվում է նոր պատուհանում)։

Պատասխանների API-ում WebSocket ռեժիմը 2025 թ. մարտին դրա գործարկումից ի վեր ամենանշանակալի նոր հնարավորություններից մեկն է։ OpenAI-ի API և Codex թիմերի սերտ համագործակցության շնորհիվ մենք գաղափարից մինչև արտադրական միջավայրում գործարկում հասանք ընդամենը մի քանի շաբաթում։ Այն ոչ միայն կտրուկ բարելավում է ագենտների ներդրման ուշացումը, այլև աջակցում է ծրագրավորողների աճող կարիքին. քանի որ մոդելի ինֆերենսն ավելի արագ է դառնում, ինֆերենսը շրջապատող ծառայություններն ու համակարգերը նույնպես պետք է արագանան, որպեսզի այդ ձեռքբերումները փոխանցվեն օգտատերերին։