वेगवान Agent Loops का महत्त्वाचे आहेत

agent-style workflows लक्षणीयरीत्या वेगवान करण्यासाठी OpenAI ने आपल्या Responses API मागील plumbing पुन्हा मांडले असल्याचे सांगितले. complex tasks दरम्यान tools, models, आणि API calls सतत पुढे-मागे होत असताना वापरकर्त्यांचा प्रतीक्षा वेळ कमी करणे हा या बदलाचा उद्देश आहे.

२२ एप्रिल रोजी प्रसिद्ध झालेल्या technical post मध्ये कंपनीने स्पष्ट केले की Codex सारख्या systems ला एकच assignment पूर्ण करण्यासाठी डझनावधी sequential requests लागू शकतात: model पुढे काय करायचे ते ठरवतो, client side वर एक tool चालते, परिणाम API कडे पाठवला जातो, आणि हा cycle पुन्हा सुरू होतो. अशा pattern मध्ये छोटेसुद्धा overhead पटकन जमा होतो.

OpenAI नुसार, inference स्वतःच वेगवान होत गेल्यामुळे performance problem अधिक स्पष्ट झाली. 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 ला तीन broad stages मध्ये विभागते: API service work, model inference, आणि client-side time. tools execute व्हायला हवे आणि context assemble व्हायला हवा म्हणून client side अजूनही महत्त्वाचा आहे, पण कंपनीच्या मते 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 करून extra network hops कमी करणे, आणि safety stack च्या काही भागांना गती देणे यांचा समावेश होता, जेणेकरून काही conversations जलद classify होतील.

कंपनीनुसार, या बदलांमुळे time to first token मध्ये जवळपास 45% सुधारणा झाली. पण OpenAI म्हणते की नवीन inference stack चे speed gains पूर्णपणे दिसण्यासाठी तेही पुरेसे नव्हते.

Sakana AI bets AI that improves itself can break the compute arms race of frontier labs
More in AI & Robotics

साकाना एआयने पुनरावर्ती स्व-सुधारणा पुढे नेण्यासाठी प्रयोगशाळा स्थापन केली

साकाना एआयने पुनरावर्ती स्व-सुधारणेसाठी एक समर्पित प्रयोगशाळा तयार केली आहे, असा युक्तिवाद करत की स्वतःची पायाभरणी सुधारू शकणाऱ्या एआय प्रणाली संगणकीय शस्त्रस्पर्धेला पर्याय देऊ शकतात.

Read article

WebSocket Shift

मोठा बदल architectural होता: वेगवेगळ्या synchronous API calls च्या मालिकेऐवजी WebSockets वापरून Responses API शी persistent connection ठेवणे. प्रत्यक्षात याचा अर्थ client आणि API संपूर्ण agent loop दरम्यान connected राहू शकतात, request state वारंवार तोडण्याची आणि पुन्हा तयार करण्याची गरज राहत नाही.

Persistent sessions मुळे connection शीच उपयुक्त माहिती जोडून ठेवता आली, असे OpenAI म्हणते. त्यामुळे repeated setup work कमी झाले आणि turns दरम्यान context अधिक कार्यक्षमतेने reuse करता आला. परिणामी end-to-end agent loop speed मध्ये सुमारे 40% सुधारणा झाली, असे कंपनीने सांगितले.

वापरकर्त्यांसाठी याचे महत्त्व सरळ आहे. जर एखाद्या coding किंवा research agent ला काम पूर्ण करण्यासाठी अनेक tool calls लागल्या, तर प्रत्येक cycle मधील overhead कमी केल्याने फक्त एका stage ला वेग देण्यापेक्षा अधिक परिणाम होऊ शकतो. एकेकाळी actions मधे अडकलेला workflow आता 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 इतके वेगवान होत आहे की आजूबाजूच्या systems perceived product quality ठरवत आहेत. अशा वातावरणात model पटकन विचार करू शकतो, पण orchestration layers मागे पडल्या तर अनुभव अजूनही संथ वाटू शकतो.

Codex पलीकडे का महत्त्वाचे आहे

OpenAI ने समस्या Codex च्या उदाहरणातून स्पष्ट केली असली, तरी परिणाम कोणत्याही 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 अनेक वर्षे better reasoning आणि मोठ्या context windows वर भर देत आले आहेत. पण आता ते systems engineering मध्येही स्पर्धा करत आहेत: throughput, responsiveness, safety latency, आणि external tools सोबत model ला loop मध्ये किती कार्यक्षमतेने ठेवता येते यावर.

OpenAI चा संदेश असा आहे की model भोवतीची infrastructure आता स्वतः एक product feature आहे. inference speeds वाढत राहिल्यास, हे आणखी खरे ठरेल.

मोठा संकेत

खोल takeaway फक्त इतकाच नाही की WebSockets repeated synchronous calls पेक्षा वेगवान आहेत. मुद्दा असा आहे की agent products real-time software systems मध्ये परिपक्व होत आहेत, ज्यांचे performance APIs, caches, safety layers, आणि tool runtimes यांच्या coordination वर अवलंबून आहे.

ही update फक्त engineering footnote नाही. AI usability मधील पुढचे gains model steps मधील friction कमी करण्यातून येऊ शकतात, प्रत्येक individual step अधिक स्मार्ट करण्यातूनच नव्हे. agentic systems अधिक लांब आणि गुंतागुंतीच्या tasks हाताळू लागल्यावर, हेच फरक ठरवू शकते की ती experimental वाटतील की operational.

हा article OpenAI च्या reporting वर आधारित आहे. मूळ लेख वाचा.

Originally published on openai.com