აგენტური სამუშაო ნაკადების დაჩქარება WebSocket-ებით Responses API-ში

როცა Codex-ს სთხოვთ შეცდომის გასწორებას, ის თქვენს კოდის ბაზაში ეძებს შესაბამის ფაილებს, კითხულობს მათ კონტექსტის შესაქმნელად, ასწორებს და უშვებს ტესტებს, რათა გადაამოწმოს, იმუშავა თუ არა შესწორებამ. შიდა დონეზე ეს ნიშნავს ათეულობით ორმხრივ Responses API მოთხოვნას: განსაზღვროს მოდელის შემდეგი მოქმედება, გაუშვას ინსტრუმენტი თქვენს კომპიუტერზე, ინსტრუმენტის შედეგი ისევ API-ში გაგზავნოს და გაიმეოროს.

ყველა ეს მოთხოვნა შეიძლება ჯამში გადაიქცეს წუთებად, რომლის განმავლობაშიც მომხმარებლები ელოდებიან, სანამ Codex რთულ ამოცანებს დაასრულებს. დაყოვნების თვალსაზრისით, Codex აგენტის ციკლი დროის უმეტეს ნაწილს სამ ძირითად ეტაპზე ხარჯავს: API სერვისებში მუშაობაზე (მოთხოვნების ვალიდაციასა და დამუშავებაზე), მოდელის ინფერენციაზე და კლიენტის მხარეს დროსზე (ინსტრუმენტების გაშვება და მოდელის კონტექსტის აგება). ინფერენცია არის ეტაპი, როცა მოდელი GPU-ებზე მუშაობს ახალი token-ების გენერირებისთვის. წარსულში GPU-ებზე LLM ინფერენციის გაშვება აგენტური ციკლის ყველაზე ნელი ნაწილი იყო, ამიტომ API სერვისის ზედნადები ხარჯის დაფარვა მარტივი იყო. რაც უფრო ჩქარდება ინფერენცია, მით უფრო შესამჩნევი ხდება აგენტური გაშლისას დაგროვილი API ზედნადები.

ამ პოსტში ავხსნით, როგორ გავხადეთ API-ის გამოყენებით აგენტის ციკლები ბოლოდან ბოლომდე 40%-ით უფრო სწრაფი, რათა მომხმარებლებს ეგრძნოთ ინფერენციის სიჩქარის ნახტომი წამში 65-დან თითქმის 1,000 token-მდე. ამას მივაღწიეთ ქეშირებით, ზედმეტი ქსელური გადასვლების მოცილებით, ჩვენი უსაფრთხოების სტეკის გაუმჯობესებით პრობლემების სწრაფად აღსანიშნავად და — რაც ყველაზე მნიშვნელოვანია — Responses API-სთან მუდმივი კავშირის შექმნით, იმის ნაცვლად, რომ სინქრონული API გამოძახებების სერია გაგვეკეთებინა.

Responses API-ში წინა ფლაგმანური მოდელები, როგორიცაა GPT‑5 და GPT‑5.2, დაახლოებით წამში 65 token-ით (TPS) მუშაობდნენ. სწრაფი კოდირების მოდელის, GPT‑5.3‑Codex‑Spark‑ის გაშვებისას, ჩვენი მიზანი იყო სიდიდის რიგით უფრო მაღალი სიჩქარე: 1,000 TPS-ზე მეტი, რაც შესაძლებელი გახდა LLM ინფერენციისთვის ოპტიმიზებული სპეციალიზებული Cerebras აპარატურით. იმისთვის, რომ მომხმარებლებს ამ ახალი მოდელის ნამდვილი სიჩქარე ეგრძნოთ, API-ის ზედნადები ხარჯი უნდა შეგვემცირებინა.

2025 წლის ნოემბრისთვის Responses API-ზე წარმადობის სპრინტი დავიწყეთ და ერთი მოთხოვნის კრიტიკული გზის დაყოვნებაზე მრავალი ოპტიმიზაცია დავნერგეთ:

• მეხსიერებაში დარენდერებული token-ებისა და მოდელის კონფიგურაციის ქეშირება, რათა მრავალსვლიანი პასუხებისთვის აგვერიდებინა ძვირადღირებული ტოკენიზაცია და ქსელური გამოძახებები
• ქსელური გადასვლების დაყოვნების შემცირება შუალედურ სერვისებთან გამოძახებების მოცილებით (მაგალითად, გამოსახულების დამუშავების გარჩევადობა) და უშუალოდ ინფერენციის სერვისის გამოძახებით
• უსაფრთხოების სტეკის გაუმჯობესება, რათა გარკვეულ კლასიფიკატორებს საუბრები უფრო სწრაფად აღენიშნათ

ამ გაუმჯობესებებით პირველი token-მდე დროის (TTFT) თითქმის 45%-იანი გაუმჯობესება ვნახეთ — რაც ასახავს, რამდენად სწრაფად რეაგირებს API — მაგრამ ეს გაუმჯობესებებიც კი ჯერ კიდევ საკმარისად სწრაფი არ იყო GPT‑5.3‑Codex‑Spark‑ისთვის. ამ გაუმჯობესებების მიუხედავად, Responses API-ის ზედნადები ხარჯი მოდელის სიჩქარესთან შედარებით მაინც ზედმეტად დიდი იყო — ანუ მომხმარებლებს უწევდათ ჩვენი API-ის CPU-ების ლოდინი, სანამ მოდელს მომწოდებელი GPU-ებით ისარგებლებდნენ.

უფრო ღრმა პრობლემა სტრუქტურული იყო: Codex-ის თითოეულ მოთხოვნას დამოუკიდებლად ვეპყრობოდით და ყოველ მომდევნო მოთხოვნაზე საუბრის მდგომარეობასა და სხვა მრავალჯერ გამოყენებად კონტექსტს თავიდან ვამუშავებდით. მაშინაც კი, როცა საუბრის დიდი ნაწილი არ შეცვლილა, მაინც ვიხდიდით სრულ ისტორიასთან დაკავშირებული სამუშაოს ფასს. რაც უფრო გრძელი ხდებოდა საუბარი, მით უფრო ძვირი ხდებოდა ეს განმეორებითი დამუშავება.

დიზაინის გასამკაცრებლად, ტრანსპორტის პროტოკოლი თავიდან გადავხედეთ: შეგვეძლო თუ არა მუდმივი კავშირის შენარჩუნება და მდგომარეობის ქეშირება, იმის ნაცვლად, რომ ყოველ მომდევნო მოთხოვნაზე HTTP-ით ახალი კავშირი დაგვემყარებინა და საუბრის სრული ისტორია გაგვეგზავნა? იდეა იყო გაგვეგზავნა მხოლოდ ის ახალი ინფორმაცია, რომელსაც ვალიდაცია და დამუშავება სჭირდება, ხოლო მრავალჯერ გამოყენებადი მდგომარეობა კავშირის სიცოცხლის განმავლობაში მეხსიერებაში დაგვეკეშირებინა. ეს ზედმეტი განმეორებითი სამუშაოსგან წარმოშობილ ზედნადებ ხარჯს შეამცირებდა.

განვიხილეთ რამდენიმე განსხვავებული მიდგომა, მათ შორის WebSocket-ები და gRPC ორმხრივი სტრიმინგი. WebSocket-ები ავირჩიეთ, რადგან, როგორც მარტივი შეტყობინებების ტრანსპორტის პროტოკოლი, მომხმარებლებს Responses API-ის შეყვანისა და გამოტანის ფორმების შეცვლა არ დასჭირდებოდათ. ის დეველოპერებისთვის მოსახერხებელი იყო და ჩვენს არსებულ არქიტექტურას მცირე დარღვევით ერგებოდა.

WebSocket-ის პირველმა პროტოტიპმა Responses API-ის დაყოვნებასთან დაკავშირებით ჩვენი წარმოდგენა შეცვალა. Codex გუნდის ინჟინერმა, რომელსაც API სტეკის მასშტაბით ღრმა ექსპერტიზა ჰქონდა, პროტოტიპი მოამზადა ღამით გაშვებული Codex აგენტით.

ამ პროტოტიპში აგენტური გაშლები მოდელირებული იყო როგორც ერთი ხანგრძლივად მიმდინარე Response. asyncio-ს შესაძლებლობების გამოყენებით, Responses API ინსტრუმენტის გამოძახების სემპლირების შემდეგ ასინქრონულად ბლოკირდებოდა სემპლირების ციკლში და Responses API კლიენტს უკან უგზავნიდა response.done მოვლენას. ინსტრუმენტის გამოძახების შესრულების შემდეგ, კლიენტები უკან აგზავნიდნენ response.append მოვლენას ინსტრუმენტის შედეგით, რაც სემპლირების ციკლს ხსნიდა და მოდელს გაგრძელების საშუალებას აძლევდა.

ამის ანალოგიაა ლოკალური ინსტრუმენტის გამოძახების განთავსებულ ინსტრუმენტის გამოძახებად აღქმა. როცა მოდელი ვებძებნას იძახებს, ინფერენციის ციკლი ბლოკირდება, იძახებს ვებძებნის სერვისს და სერვისის პასუხს მოდელის კონტექსტში ათავსებს. ჩვენს დიზაინში იგივე გავაკეთეთ; ოღონდ დისტანციური სერვისის გამოძახების ნაცვლად, მოდელის ინსტრუმენტის გამოძახება WebSocket-ით კლიენტს უკან გავუგზავნეთ. როცა კლიენტი პასუხობდა, კლიენტის ინსტრუმენტის გამოძახების პასუხს კონტექსტში ვათავსებდით და სემპლირებას ვაგრძელებდით.

ეს დიზაინი უკიდურესად ეფექტური იყო, რადგან აგენტის გაშლის განმავლობაში განმეორებით API სამუშაოს აცილებდა. წინასაინფერენციო სამუშაოს ერთხელ შესრულება შეგვეძლო, ინსტრუმენტის შესრულებაზე პაუზა გაგვეკეთებინა და პოსტინფერენციო სამუშაო ერთხელ, ბოლოს შეგვესრულებინა.

სამწუხაროდ, ამას მოჰყვა ნაკლებად ნაცნობი და უფრო რთული API ფორმა. გვინდოდა, დეველოპერებს WebSocket-ის მხარდაჭერა ისე დაემატებინათ, რომ თავიანთი API ინტეგრაცია ახალი ინტერაქციის რეჟიმის გარშემო თავიდან არ გადაეწერათ.

გაშვებული ვერსიისთვის ნაცნობ ფორმას დავუბრუნდით: ისევ გამოიყენეთ response.create იმავე body-ით და საუბრის კონტექსტის გასაგრძელებლად გამოიყენეთ previous_response_id წინა პასუხის მდგომარეობიდან.

WebSocket კავშირზე სერვერი ინახავს კავშირის მასშტაბის, მეხსიერებაში არსებულ ქეშს წინა პასუხის მდგომარეობისთვის. როცა მომდევნო response.create შეიცავს previous_response_id-ს, ამ მდგომარეობას ქეშიდან ვიღებთ სრული საუბრის თავიდან აგების ნაცვლად.

ეს დაკეშილი მდგომარეობა მოიცავს:

• წინა response ობიექტს
• წინა შეყვანისა და გამოტანის ელემენტებს
• ინსტრუმენტების განსაზღვრებებსა და სახელთა სივრცეებს
• მრავალჯერ გამოყენებად სემპლირების არტეფაქტებს, როგორიცაა ადრე დარენდერებული token-ები

მეხსიერებაში არსებული წინა პასუხის მდგომარეობის ხელახალი გამოყენებით რამდენიმე მსხვილი ოპტიმიზაციის დანერგვა შევძელით:

• ზოგიერთი უსაფრთხოების კლასიფიკატორისა და მოთხოვნის ვალიდატორის ისე მუშაობა, რომ მხოლოდ ახალ შეყვანას ამუშავებდნენ და არა ყოველ ჯერზე მთელ ისტორიას
• მეხსიერებაში დარენდერებული token-ების ქეშის შენარჩუნება, რომელსაც ვუმატებთ, რათა ზედმეტი ტოკენიზაცია გამოვტოვოთ
• მოთხოვნებს შორის ჩვენი წარმატებული მოდელის განსაზღვრის/მარშრუტიზაციის ლოგიკის ხელახალი გამოყენება
• არამბლოკირებელი პოსტინფერენციო სამუშაოების, როგორიცაა ბილინგი, მომდევნო მოთხოვნებთან გადაფარვა

მიზანი იყო მაქსიმალურად მივახლოვებოდით მინიმალური ზედნადები ხარჯის მქონე პროტოტიპს, მაგრამ ისეთი API ფორმით, რომელიც დეველოპერებს უკვე ესმოდათ და რომლის გარშემოც უკვე ჰქონდათ სისტემა აგებული.

WebSocket რეჟიმის აგებაზე ორთვიანი სპრინტის შემდეგ, ალფა გავუშვით კოდირების აგენტებზე მომუშავე წამყვან სტარტაპებთან, რათა ის საკუთარ ინფრასტრუქტურაში დაენერგათ და ტრაფიკი უსაფრთხოდ გაეზარდათ. ალფა მომხმარებლებს ის ძალიან მოეწონათ და თავიანთ აგენტურ სამუშაო ნაკადებში 40%-მდე გაუმჯობესება⁠(იხსნება ახალ ფანჯარაში) დააფიქსირეს. ალფიდან მიღებული დადებითი უკუკავშირის გათვალისწინებით, გასაშვებად მზად ვიყავით.

გაშვების შედეგები მყისიერი იყო. Codex-მა სწრაფად გადაიტანა Responses API ტრაფიკის უმეტესი ნაწილი WebSocket რეჟიმზე და დაყოვნების მნიშვნელოვანი გაუმჯობესება ნახა. GPT‑5.3‑Codex‑Spark‑ისთვის ჩვენს 1,000 TPS მიზანს მივაღწიეთ და 4,000 TPS-მდე პიკური ნახტომებიც ვნახეთ, რაც აჩვენებდა, რომ Responses API რეალურ საწარმოო ტრაფიკში ბევრად უფრო სწრაფ ინფერენციასაც ეწეოდა. გავლენა სწრაფად გამოჩნდა დეველოპერების საზოგადოებაშიც:

• Codex-მა სწრაფად გადაიტანა საკუთარი ტრაფიკის უმეტესი ნაწილი WebSocket-ებზე. Codex-ის მომხმარებლები, რომლებიც იყენებენ უახლეს მოდელებს, როგორიცაა GPT‑5.3‑Codex⁠(იხსნება ახალ ფანჯარაში), GPT‑5.4⁠(იხსნება ახალ ფანჯარაში) და სხვა, ყველანი სარგებლობენ WebSocket რეჟიმის აჩქარებით.
• Vercel-მა WebSocket რეჟიმი AI SDK-ში დაამატა და დაინახა, რომ დაყოვნება 40%-მდე⁠(იხსნება ახალ ფანჯარაში) შემცირდა.
• Cline-ის მრავალფაილიანი სამუშაო ნაკადები 39%-ით უფრო სწრაფია⁠(იხსნება ახალ ფანჯარაში).
• Cursor-ში OpenAI მოდელები 30%-მდე უფრო სწრაფი⁠(იხსნება ახალ ფანჯარაში) გახდა.

WebSocket რეჟიმი Responses API-ში 2025 წლის მარტში მისი გაშვების შემდეგ ერთ-ერთი ყველაზე მნიშვნელოვანი ახალი შესაძლებლობაა. იდეიდან საწარმოო გარემოში გაშვებამდე სულ რამდენიმე კვირაში მივედით OpenAI-ის API და Codex გუნდებს შორის მჭიდრო თანამშრომლობის წყალობით. ეს არა მხოლოდ დრამატულად ამცირებს აგენტის გაშლის დაყოვნებას, არამედ მხარს უჭერს შემმუშავებლების მზარდ საჭიროებასაც: რაც უფრო სწრაფი ხდება მოდელის ინფერენცია, მით უფრო უნდა აჩქარდეს ინფერენციის გარშემო არსებული სერვისები და სისტემებიც, რათა ეს სარგებელი მომხმარებლებს გადაეცეს.