OpenAI கூறுவதன்படி, Persistent WebSocket Sessions Agent Loop Latency-ஐ சுமார் 40% குறைத்தன

வேகமான Agent Loops ஏன் முக்கியம்

agent-style workflows-ஐ குறிப்பிடத்தக்க அளவில் வேகப்படுத்துவதற்காக தனது Responses API-க்குப் பின்னுள்ள plumbing-ஐ OpenAI மீளமைத்துள்ளதாக கூறுகிறது. complex tasks நடக்கும் போது tools, models, மற்றும் API calls மீண்டும் மீண்டும் முன்னும் பின்னுமாகச் செல்லும் நிலையில், பயனர்கள் காத்திருக்கும் நேரத்தை குறைப்பதே இந்த மாற்றத்தின் நோக்கம்.

ஏப்ரல் 22 அன்று வெளியிடப்பட்ட ஒரு technical post-இல், Codex போன்ற systems ஒரு assignment-ஐ முடிக்க பல dozen sequential requests தேவைப்படலாம் என்று நிறுவனம் விளக்கியது: model அடுத்ததாக என்ன செய்ய வேண்டும் என்பதைத் தீர்மானிக்கிறது, client side-இல் ஒரு tool இயங்குகிறது, அதன் முடிவு API-க்கு அனுப்பப்படுகிறது, பின்னர் அந்த cycle மீண்டும் நடக்கிறது. அந்த pattern-இல் சிறிய overhead கூட விரைவாகச் சேர்ந்து பெரிதாகிறது.

OpenAI-யின் கூற்றுப்படி, inference தானாகவே வேகமானதால் performance பிரச்சினை மேலும் தெளிவாகப் பார்க்கப்பட்டது. Responses API-இல் இருந்த earlier flagship models சுமார் 65 tokens per second வேகத்தில் இயங்கின என்று நிறுவனம் கூறியது. GPT-5.3-Codex-Spark-க்காக, Cerebras hardware-ஐ பயன்படுத்தி 1,000 tokens per second-ஐ விட அதிகமான வேகத்தை OpenAI இலக்காக வைத்தது. model generation அந்த அளவு வேகமான பிறகு, loop-இன் மெதுவான பகுதிகளை மறைத்துவைப்பது கடினமானது.

Inference Bottleneck-இலிருந்து API Bottleneck-க்கு

OpenAI agent latency-யை மூன்று broad stages-ஆகப் பிரிக்கிறது: API service work, model inference, மற்றும் client-side time. tools இயங்க வேண்டும், context அமைக்கப்பட வேண்டும் என்பதால் client side இன்னும் முக்கியம் தான், ஆனால் API layer itself ஒரு முக்கிய bottleneck ஆக மாறியதாக நிறுவனம் கூறுகிறது.

அந்த மாற்றம் ஒரு வேறுபட்ட optimization strategy-யைத் தேவைப்படுத்தியது. GPU throughput-ஐ மட்டும் கவனிப்பதற்குப் பதிலாக, request path முழுவதிலும் friction-ஐ நீக்கத் தொடங்கியதாக OpenAI கூறுகிறது. சுமார் 2025 நவம்பரில், Responses API-க்கு நிறுவனம் ஒரு performance sprint-ஐ தொடங்கியது. இதில் rendered tokens மற்றும் model configuration-ஐ memory-யில் cache செய்வது, inference services-ஐ மேலும் நேரடியாக call செய்து கூடுதல் network hops-ஐ குறைப்பது, மற்றும் சில conversations-ஐ வேகமாக classify செய்ய safety stack-இன் பகுதிகளை வேகப்படுத்துவது ஆகியவை அடங்கும்.

இந்த மாற்றங்கள் time to first token-ஐ கிட்டத்தட்ட 45% மேம்படுத்தின என்று நிறுவனம் கூறுகிறது. ஆனால் புதிய inference stack-இன் speed gains-ஐ முழுமையாக வெளிப்படுத்த இது இன்னும் போதுமானதாக இல்லை என்று OpenAI சொல்கிறது.

WebSocket மாற்றம்

முக்கியமான மாற்றம் architectural ஆனது: பல separate synchronous API calls-ஐ, WebSockets-ஐ பயன்படுத்தும் persistent connection மூலம் Responses API-க்கு மாற்றியது. நடைமுறையில், இதன் பொருள் client மற்றும் API முழு agent loop-இலும் இணைந்தே இருக்க முடியும்; ஒவ்வொரு முறையும் request state-ஐ கலைத்து மீண்டும் உருவாக்க வேண்டியதில்லை.

Persistent sessions மூலம் connection-இன் உட்பகுதியில் பயனுள்ள தகவல்களை வைத்திருக்க முடிந்ததாக OpenAI கூறுகிறது. இதனால் repeated setup work குறைந்தது, மேலும் turns-க்கிடையே context-ஐ system மேலும் திறமையாக reuse செய்ய முடிந்தது. அதன் விளைவாக end-to-end agent loop speed-இல் சுமார் 40% மேம்பாடு கிடைத்ததாக நிறுவனம் கூறுகிறது.

பயனர்களுக்கு இதன் முக்கியத்துவம் நேரடியானது. ஒரு coding அல்லது research agent ஒரு job-ஐ முடிக்க பல tool calls தேவைப்பட்டால், ஒவ்வொரு cycle-இலும் overhead-ஐ குறைப்பது ஒரு stage-ஐ மட்டும் வேகப்படுத்துவதைவிட பெரிய தாக்கத்தை ஏற்படுத்தலாம். முன்னர் actions-க்கு இடையில் சிக்கியதுபோல் தோன்றிய workflow, இப்போது live interaction-க்கு நெருக்கமாக உணரப்படலாம்.

OpenAI எதை Optimize செய்தது

• Connection-scoped caching, அதனால் expensive 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 சிறந்த reasoning மற்றும் பெரிய context windows-ஐ வலியுறுத்தி வந்தனர். ஆனால் இப்போது அவர்கள் systems engineering-இலும் போட்டியிடுகின்றனர்: throughput, responsiveness, safety latency, மற்றும் external tools-உடன் model-ஐ loop-இல் எவ்வளவு திறமையாக வைத்திருக்க முடிகிறது என்பதில்.

Model-ஐச் சுற்றியுள்ள infrastructure இப்போது தனக்குள்ளேயே ஒரு product feature என்று OpenAI-யின் செய்தி கூறுகிறது. 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-இல் அடுத்த கட்ட முன்னேற்றம் model steps-க்கிடையேயான friction-ஐ குறைப்பதிலிருந்து வரலாம், ஒவ்வொரு individual step-ஐ மேலும் smarter ஆக்குவதிலிருந்து மட்டும் அல்ல என்பதற்கான ஒரு அறிகுறி இது. agentic systems நீளமான மற்றும் சிக்கலான tasks-ஐ கையாளத் தொடங்கும்போது, அவை experimental போலத் தோன்றுமா அல்லது operational போலத் தோன்றுமா என்பதைக் இந்த வேறுபாடு தீர்மானிக்கலாம்.

இந்த கட்டுரை OpenAI வழங்கிய reporting-ஐ அடிப்படையாகக் கொண்டது. மூலக் கட்டுரையைப் படிக்கவும்.