तेज़ Agent Loops क्यों महत्वपूर्ण हैं
OpenAI का कहना है कि उसने अपनी Responses API के पीछे की plumbing को फिर से तैयार किया है ताकि agent-style workflows काफी तेज़ हो सकें। इसका उद्देश्य उन जटिल कार्यों के दौरान उपयोगकर्ताओं के इंतज़ार का समय कम करना है, जब tools, models, और API calls बार-बार आगे-पीछे होते रहते हैं।
22 अप्रैल को प्रकाशित एक तकनीकी पोस्ट में, कंपनी ने बताया कि Codex जैसी प्रणालियों को एक ही assignment पूरा करने के लिए दर्जनों sequential requests की ज़रूरत पड़ सकती है: model तय करता है कि अगला कदम क्या होगा, client side पर एक tool चलता है, परिणाम API को भेजा जाता है, और यह चक्र दोहराया जाता है। इस pattern में overhead का थोड़ा-सा हिस्सा भी जल्दी ही जमा हो जाता है।
OpenAI के अनुसार, performance की यह समस्या तब अधिक स्पष्ट हुई जब inference खुद तेज़ होने लगा। कंपनी ने कहा कि Responses API में earlier flagship models लगभग 65 tokens per second की गति से चलते थे। GPT-5.3-Codex-Spark के लिए OpenAI ने Cerebras hardware का उपयोग करते हुए 1,000 tokens per second से अधिक का लक्ष्य रखा। जब model generation इतनी तेज़ हो गई, तो loop के धीमे हिस्सों को छिपाना आसान नहीं रहा।
Inference Bottleneck से API Bottleneck तक
OpenAI agent latency को तीन व्यापक stages में बांटता है: API service work, model inference, और client-side time। Client side अभी भी महत्वपूर्ण है क्योंकि tools को execute करना होता है और context को assemble करना होता है, लेकिन कंपनी ने कहा कि API layer स्वयं एक महत्वपूर्ण bottleneck बन चुकी थी।
इस बदलाव ने optimization की एक अलग strategy को मजबूर किया। केवल GPU throughput पर ध्यान देने के बजाय, OpenAI का कहना है कि उसने request path के हर हिस्से में friction हटाना शुरू किया। लगभग नवंबर 2025 में, कंपनी ने Responses API पर एक performance sprint शुरू किया। इस काम में rendered tokens और model configuration को memory में cache करना, inference services को अधिक सीधे call करके अतिरिक्त network hops कम करना, और safety stack के कुछ हिस्सों को तेज़ करना शामिल था ताकि कुछ conversations को जल्दी classify किया जा सके।
कंपनी के अनुसार, इन बदलावों से time to first token में लगभग 45% सुधार हुआ। लेकिन OpenAI का कहना है कि यह उसके नए inference stack की speed gains को पूरी तरह सामने लाने के लिए अभी भी पर्याप्त नहीं था।
WebSocket की ओर बदलाव
सबसे बड़ा बदलाव architectural था: अलग-अलग synchronous API calls की एक श्रृंखला को WebSockets का उपयोग करते हुए Responses API के साथ एक persistent connection से बदलना। व्यवहारिक रूप से, इसका मतलब है कि client और API पूरे agent loop के दौरान जुड़े रह सकते हैं, बजाय इसके कि request state को बार-बार तोड़ा और फिर से बनाया जाए।
OpenAI का कहना है कि persistent sessions ने उसे उपयोगी जानकारी को सीधे connection से जोड़े रखने की अनुमति दी। इससे repeated setup work कम हुआ और system को turns के बीच context को अधिक कुशलता से reuse करने में मदद मिली। कंपनी के अनुसार, इसका परिणाम end-to-end agent loop speed में लगभग 40% सुधार के रूप में सामने आया।
उपयोगकर्ताओं के लिए इसका महत्व सीधा है। अगर किसी coding या research agent को काम पूरा करने के लिए कई tool calls की ज़रूरत होती है, तो हर cycle से overhead कम करना सिर्फ एक stage को तेज़ करने की तुलना में बड़ा असर डाल सकता है। जो workflow पहले actions के बीच अटका हुआ महसूस होता था, वह live interaction के ज़्यादा करीब लगने लगता है।
OpenAI ने क्या Optimize किया
- Connection-scoped caching, ताकि महंगे setup work को दोहराना न पड़े।
- API services और inference services के बीच कम अनावश्यक network hops।
- Moderation और classification pipeline के कुछ हिस्सों में तेज़ safety checks।
- कई-turn tool use की लागत कम करने के लिए एक persistent WebSocket channel।
OpenAI ने इस काम को उद्योग में हो रहे एक व्यापक बदलाव के जवाब के रूप में प्रस्तुत किया: inference इतना तेज़ हो रहा है कि आसपास की प्रणालियाँ increasingly product quality को निर्धारित कर रही हैं। ऐसे माहौल में, model तेज़ी से सोच सकता है, लेकिन अगर orchestration layers पीछे रह जाएँ, तो अनुभव फिर भी धीमा लग सकता है।
Codex से आगे इसका महत्व
हालाँकि OpenAI ने समस्या को Codex के उदाहरण से समझाया, इसके implications किसी भी tool-using agent तक फैलते हैं। Enterprise assistants, customer-service systems, research copilots, और software agents सभी एक लंबे model completion के बजाय कई छोटी interactions पर निर्भर करते हैं। इसलिए persistent sessions और कम orchestration overhead raw benchmark performance जितने ही महत्वपूर्ण हो सकते हैं।
यह post बदलते competitive landscape की भी एक झलक देती है। Model vendors वर्षों से बेहतर reasoning और बड़े context windows पर ज़ोर देते आए हैं। लेकिन increasingly, वे systems engineering पर भी प्रतिस्पर्धा कर रहे हैं: throughput, responsiveness, safety latency, और external tools के साथ model को loop में कितनी कुशलता से रखा जा सकता है।
OpenAI का संदेश यह है कि model के आसपास की infrastructure अब अपने आप में एक product feature है। अगर inference speeds आगे भी बढ़ती रहीं, तो यह बात और अधिक सच होती जाएगी।
बड़ा संकेत
गहरा takeaway सिर्फ यह नहीं है कि WebSockets repeated synchronous calls से तेज़ होते हैं। बात यह है कि agent products वास्तविक-time software systems में बदल रहे हैं, जिनका performance APIs, caches, safety layers, और tool runtimes के बीच coordination पर निर्भर करता है।
यह अपडेट केवल एक engineering footnote से अधिक है। यह संकेत है कि AI usability में अगली बढ़त model steps के बीच friction कम करने से आ सकती है, न कि सिर्फ हर individual step को smarter बनाने से। जैसे-जैसे agentic systems लंबे और अधिक जटिल tasks लेते जाएँगे, यही फर्क तय कर सकता है कि वे experimental लगेंगे या operational।
यह article OpenAI की reporting पर आधारित है। मूल लेख पढ़ें.
Originally published on openai.com