Responses API-এ WebSockets ব্যবহার করে এজেন্টিক ওয়ার্কফ্লো আরও দ্রুত কার্যকর করা

আপনি যখন Codex-কে একটি বাগ ঠিক করতে বলেন, তখন এটি আপনার কোডবেসে প্রাসঙ্গিক ফাইলগুলো খুঁজে দেখে, প্রেক্ষাপট বোঝার জন্য সেগুলো পড়ে, সম্পাদনা করে এবং সমাধানটি কাজ করেছে কি না যাচাই করতে টেস্ট চালায়. নেপথ্যে, এর অর্থ হলো Responses API-তে ডজন ডজন আদান-প্রদানের অনুরোধ: মডেলের পরবর্তী পদক্ষেপ নির্ধারণ করা, আপনার কম্পিউটারে একটি টুল চালানো, টুলের আউটপুট আবার API-তে পাঠানো এবং পুনরাবৃত্তি করা.

এই সব অনুরোধ মিলিয়ে Codex-এর জটিল কাজ সম্পন্ন করতে ব্যবহারকারীদের মিনিটের পর মিনিট অপেক্ষা করতে হতে পারে. লেটেন্সির দৃষ্টিকোণ থেকে, Codex এজেন্ট লুপ তার বেশিরভাগ সময় তিনটি প্রধান পর্যায়ে ব্যয় করে: API পরিষেবাগুলিতে কাজ করা (অনুরোধ যাচাই এবং প্রক্রিয়া করার জন্য), মডেল ইনফারেন্স এবং ক্লায়েন্ট-সাইডের সময় (টুল চালানো এবং মডেল কনটেক্সট তৈরি করা). ইনফারেন্স হলো সেই ধাপ যেখানে মডেল GPU-গুলিতে চলে এবং নতুন টোকেন তৈরি করে. অতীতে, GPU-তে LLM ইনফারেন্স চালানো এজেন্টিক লুপের সবচেয়ে ধীর অংশ ছিল, তাই API সার্ভিস ওভারহেড সহজেই আড়াল করা যেত. ইনফারেন্স দ্রুততর হওয়ার সঙ্গে সঙ্গে, একটি এজেন্টিক রোলআউট থেকে সৃষ্ট সামগ্রিক API ওভারহেড অনেক বেশি লক্ষণীয় হয়ে ওঠে.

এই পোস্টে, আমরা ব্যাখ্যা করব কিভাবে আমরা API ব্যবহার করে এজেন্ট লুপগুলোকে শুরু থেকে শেষ পর্যন্ত 40% দ্রুত করেছি, যার ফলে ব্যবহারকারীরা ইনফারেন্সের গতিতে 65 থেকে প্রায় 1,000 টোকেন প্রতি সেকেন্ডে পৌঁছানোর এই বড় উন্নতি অনুভব করতে পারেন. আমরা এটি বাস্তবায়ন করেছি ক্যাশিংয়ের মাধ্যমে, অপ্রয়োজনীয় নেটওয়ার্ক হপ দূর করে, সমস্যাগুলো দ্রুত শনাক্ত করার জন্য আমাদের সেফটি স্ট্যাক উন্নত করে এবং—সবচেয়ে গুরুত্বপূর্ণভাবে—একটি স্থায়ী Responses API সংযোগ তৈরি করার উপায় তৈরি করেছি, যাতে একের পর এক সিঙ্ক্রোনাস API কল করতে না হয়.

Responses API-তে, GPT‑5 এবং GPT‑5.2‑এর মতো আগের ফ্ল্যাগশিপ মডেলগুলো প্রতি সেকেন্ডে প্রায় 65 টোকেন (TPS) গতিতে চলত. GPT‑5.3‑Codex‑Spark‑এর উন্মোচনের জন্য, আমাদের লক্ষ্য ছিল এক অর্ডার অব ম্যাগনিটিউড দ্রুত হওয়া: 1,000 TPS-এরও বেশি, যা LLM ইনফারেন্সের জন্য অপ্টিমাইজ করা বিশেষায়িত Cerebras হার্ডওয়্যারের মাধ্যমে সম্ভব হয়েছে. দ্রুত কোডিং মডেল হিসেবে এটি বিশেষভাবে ডিজাইন করা হয়েছে. ব্যবহারকারীরা এই নতুন মডেলের প্রকৃত গতি অনুভব করতে পারেন তা নিশ্চিত করতে, আমাদের API ওভারহেড কমাতে হয়েছিল. 

2025 সালের নভেম্বরের দিকে, আমরা Responses API-তে একটি পারফরম্যান্স স্প্রিন্ট চালু করি, যেখানে একটি একক অনুরোধের জন্য ক্রিটিক্যাল-পাথ লেটেন্সিতে অনেক অপ্টিমাইজেশন বাস্তবায়ন করি: 

• মাল্টি-টার্ন প্রতিক্রিয়াগুলোর জন্য ব্যয়বহুল টোকেনাইজেশন এবং নেটওয়ার্ক কল এড়াতে রেন্ডার করা টোকেন এবং মডেল কনফিগারেশন মেমোরিতে ক্যাশ করা
• মধ্যবর্তী সার্ভিসগুলোতে কল বাদ দিয়ে (যেমন, ইমেজ প্রসেসিংয়ের রেজোলিউশন নির্ধারণ) এবং সরাসরি ইনফারেন্স সার্ভিসে কল করে নেটওয়ার্ক হপ লেটেন্সি কমানো
• নির্দিষ্ট কিছু ক্লাসিফায়ার চালিয়ে কথোপকথনগুলোকে আরও দ্রুত ফ্ল্যাগ করতে পারি, সে জন্য আমরা আমাদের সেফটি স্ট্যাক উন্নত করছি

এই উন্নতিগুলোর ফলে, আমরা প্রথম টোকেন পাওয়ার সময়ে (TTFT) প্রায় 45% উন্নতি দেখেছি—যা API কতটা দ্রুত সাড়া দেয় তা প্রতিফলিত করে—কিন্তু GPT‑5.3‑Codex‑Spark‑এর জন্য এই উন্নতিগুলোও এখনও যথেষ্ট দ্রুত ছিল না. এই উন্নতিগুলো সত্ত্বেও, Responses API-এর ওভারহেড মডেলের গতির তুলনায় খুব বেশি ছিল—অর্থাৎ, ব্যবহারকারীরা মডেলটি সার্ভ করা GPU-গুলো ব্যবহার করার আগে আমাদের API চালানো CPU-গুলোর জন্য অপেক্ষা করতে হতো.

আরও গভীর সমস্যাটি ছিল কাঠামোগত: আমরা প্রতিটি Codex অনুরোধকে স্বতন্ত্র হিসেবে বিবেচনা করেছি, ফলে প্রতিটি ফলো-আপ অনুরোধে কথোপকথনের অবস্থা এবং পুনর্ব্যবহারযোগ্য অন্যান্য প্রেক্ষাপট প্রক্রিয়াকরণ করেছি. যদিও কথোপকথনের বেশিরভাগ অংশ বদলায়নি, তবুও আমরা পুরো ইতিহাসের সঙ্গে সম্পর্কিত কাজের জন্য অর্থ পরিশোধ করেছি. কথোপকথন দীর্ঘ হওয়ার সঙ্গে সঙ্গে, সেই বারবার প্রক্রিয়াকরণ আরও ব্যয়বহুল হয়ে উঠেছিল.

ডিজাইনটিকে আরও উন্নত করতে, আমরা ট্রান্সপোর্ট প্রোটোকলটি পুনর্বিবেচনা করেছি: HTTP-এর মাধ্যমে প্রতিবার নতুন সংযোগ স্থাপন এবং পুরো কথোপকথনের ইতিহাস পাঠানোর পরিবর্তে, আমরা কি একটি স্থায়ী সংযোগ বজায় রেখে স্টেট ক্যাশে করতে পারি? ধারণাটি ছিল শুধুমাত্র যাচাইকরণ এবং প্রক্রিয়াকরণের জন্য প্রয়োজনীয় নতুন তথ্য পাঠানো এবং সংযোগের সময়কাল জুড়ে পুনঃব্যবহারযোগ্য স্টেট মেমরিতে ক্যাশ করা. এটি অপ্রয়োজনীয় কাজের কারণে সৃষ্ট ওভারহেড কমাবে.

আমরা WebSockets এবং gRPC দ্বিমুখী স্ট্রিমিংসহ কয়েকটি ভিন্ন পদ্ধতি বিবেচনা করেছি. আমরা WebSockets বেছে নিয়েছি কারণ এটি একটি সহজ বার্তা পরিবহন প্রোটোকল হিসেবে ব্যবহারকারীদের তাদের Responses API-এর ইনপুট ও আউটপুটের কাঠামো পরিবর্তন করতে হবে না. এটি ডেভেলপার-বান্ধব ছিল এবং খুব কম বিঘ্ন ঘটিয়েই আমাদের বিদ্যমান আর্কিটেকচারের সঙ্গে মানিয়ে গেছে.

প্রথম WebSocket প্রোটোটাইপ Responses API-এর লেটেন্সির ক্ষেত্রে আমরা কী সম্ভব বলে ভাবতাম, তা বদলে দিয়েছে. Codex টিমের একজন ইঞ্জিনিয়ার, যার API স্ট্যাক জুড়ে গভীর দক্ষতা রয়েছে, রাতভর একটি Codex এজেন্ট চালিয়ে একটি প্রোটোটাইপ তৈরি করেন.

সেই প্রোটোটাইপে, এজেন্টিক রোলআউটগুলোকে একটি একক দীর্ঘমেয়াদী Response হিসেবে মডেল করা হয়েছিল. asyncio ফিচারগুলো ব্যবহার করলে, একটি টুল কল স্যাম্পল হওয়ার পরে Responses API স্যাম্পলিং লুপে অ্যাসিঙ্ক্রোনাসভাবে ব্লক করত, এবং Responses API ক্লায়েন্টের কাছে response.done ইভেন্টটি ফেরত পাঠাত. টুল কলটি নির্বাহ করার পরে, ক্লায়েন্টরা টুলের ফলাফলসহ একটি response.append ইভেন্ট ফেরত পাঠাত, যা স্যাম্পলিং লুপকে আনব্লক করত এবং মডেলকে চালিয়ে যেতে দিত.

এখানে একটি উপমা হলো, লোকাল টুল কল-কে হোস্টেড টুল কল হিসেবে বিবেচনা করা. যখন মডেল ওয়েব সার্চ কল করে, তখন ইনফারেন্স লুপ থেমে যায়, একটি ওয়েব সার্চ পরিষেবাকে কল করে এবং পরিষেবার প্রতিক্রিয়াটি মডেলের কনটেক্সটে যুক্ত করে. আমাদের নকশায়, আমরা একই কাজ করেছি; তবে কোনো রিমোট সার্ভিস কল করার পরিবর্তে, আমরা মডেলের টুল কলটি WebSocket-এর মাধ্যমে ক্লায়েন্টের কাছে ফেরত পাঠিয়েছিলাম. ক্লায়েন্ট যখন প্রতিক্রিয়া জানায়, আমরা ক্লায়েন্টের টুল কলের প্রতিক্রিয়াটি কনটেক্সটে যুক্ত করি এবং স্যাম্পলিং চালিয়ে গেছি.

এই ডিজাইনটি অত্যন্ত কার্যকর ছিল, কারণ এটি একটি এজেন্ট রোলআউটজুড়ে পুনরাবৃত্ত API কাজ দূর করেছিল. আমরা একবার প্রিইনফারেন্সের কাজ করতে পারি, টুল এক্সিকিউশনের জন্য বিরতি দিতে পারি, এবং শেষে একবার পোস্টইনফারেন্সের কাজ করতে পারি.

দুর্ভাগ্যবশত, এর মূল্য হিসেবে একটি কম পরিচিত এবং আরও জটিল API কাঠামো এসেছে. আমরা চেয়েছিলাম ডেভেলপাররা যেন নতুন কোনো ইন্টারঅ্যাকশন মোডকে ঘিরে তাদের API ইন্টিগ্রেশন নতুন করে লিখতে না হয়েই সহজেই WebSocket সাপোর্ট যোগ করতে পারে.

আমরা যে সংস্করণটি চালু করেছি, তাতে আমরা একটি পরিচিত কাঠামোতে ফিরে এসেছি: একই বডি সহ response.create ব্যবহার করা এবং পূর্ববর্তী প্রতিক্রিয়ার অবস্থা থেকে কথোপকথনের প্রেক্ষাপট চালিয়ে যাওয়ার জন্য previous_response_id ব্যবহার করা.

একটি WebSocket সংযোগে, সার্ভার পূর্ববর্তী প্রতিক্রিয়ার অবস্থার একটি সংযোগ-সীমাবদ্ধ, ইন-মেমরি ক্যাশে সংরক্ষণ করে. যখন একটি পরবর্তী response.create -এ previous_response_id অন্তর্ভুক্ত থাকে, তখন আমরা পুরো কথোপকথন শুরু থেকে পুনর্গঠন করার পরিবর্তে ক্যাশ থেকে সেই স্টেট পুনরুদ্ধার করি.

সেই ক্যাশ করা অবস্থায় অন্তর্ভুক্ত রয়েছে:

• পূর্ববর্তী response অবজেক্ট
• পূর্ববর্তী ইনপুট ও আউটপুট উপাদানসমূহ
• টুল ডেফিনিশন এবং নেমস্পেস
• পুনঃব্যবহারযোগ্য স্যাম্পলিং আর্টিফ্যাক্ট, যেমন আগে রেন্ডার করা টোকেন

মেমোরিতে থাকা পূর্ববর্তী প্রতিক্রিয়া অবস্থা পুনরায় ব্যবহার করে, আমরা কয়েকটি বড় উন্নয়ন বাস্তবায়ন করতে পেরেছি:

• আমাদের কিছু সেফটি ক্লাসিফায়ার এবং রিকোয়েস্ট ভ্যালিডেটরকে প্রতিবার পুরো ইতিহাস প্রক্রিয়া না করে শুধুমাত্র নতুন ইনপুট প্রক্রিয়া করতে বলা হয়েছে
• রেন্ডার করা টোকেনগুলোর একটি ইন-মেমরি ক্যাশ ধরে রাখা, যাতে আমরা এতে যোগ করতে থাকি এবং অপ্রয়োজনীয় টোকেনাইজেশন এড়িয়ে যেতে পারি
• বিভিন্ন অনুরোধ জুড়ে আমাদের সফল মডেল সমাধান/রাউটিং লজিক পুনঃব্যবহার 
• বিলিংয়ের মতো নন-ব্লকিং পোস্ট-ইনফারেন্স কাজ, যা পরবর্তী অনুরোধগুলোর সঙ্গে ওভারল্যাপ করে

লক্ষ্য ছিল ন্যূনতম-ওভারহেড প্রোটোটাইপের যতটা সম্ভব কাছাকাছি পৌঁছানো, তবে এমন একটি API কাঠামোসহ যা ডেভেলপাররা ইতিমধ্যেই বুঝতেন এবং যার উপর ভিত্তি করে তৈরি করতেন.

WebSocket mode তৈরি করতে দুই মাসের স্প্রিন্টের পর, আমরা প্রধান কোডিং এজেন্ট স্টার্টআপগুলোর সঙ্গে একটি আলফা সংস্করণ চালু করি, যাতে তারা এটি তাদের অবকাঠামোর সঙ্গে একীভূত করতে পারে এবং নিরাপদে ধীরে ধীরে ট্র্যাফিক বাড়াতে পারে. আলফা ব্যবহারকারীরা এটি খুব পছন্দ করেছেন, এবং তাদের এজেন্টিক ওয়ার্কফ্লোতে 40% পর্যন্ত উন্নতি⁠(একটি নতুন উইন্ডোতে খোলে) রিপোর্ট করেছেন. ইতিবাচক আলফা ফিডব্যাকের ভিত্তিতে, আমরা চালু করতে প্রস্তুত ছিলাম.

লঞ্চের ফলাফল তাৎক্ষণিক ছিল. Codex দ্রুত তাদের Responses API ট্র্যাফিকের বেশিরভাগ WebSocket mode-এ স্থানান্তর করেছে, ফলে লেটেন্সিতে উল্লেখযোগ্য উন্নতি দেখা গেছে. GPT‑5.3‑Codex‑Spark‑এর ক্ষেত্রে, আমরা আমাদের 1,000 TPS লক্ষ্যমাত্রা অর্জন করেছি এবং 4,000 TPS পর্যন্ত স্পাইক দেখেছি, যা দেখায় যে Responses API বাস্তব প্রোডাকশন ট্র্যাফিকে আরও অনেক দ্রুত ইনফারেন্সের সঙ্গেও তাল মিলিয়ে চলতে পেরেছে. ডেভেলপার কমিউনিটিতেও এর প্রভাব দ্রুতই দেখা গিয়েছিল:

• Codex তাদের বেশিরভাগ ট্রাফিক দ্রুত WebSockets-এ স্থানান্তর করেছে. সর্বশেষ মডেল যেমন GPT‑5.3‑Codex⁠(একটি নতুন উইন্ডোতে খোলে) চালানো Codex ব্যবহারকারীরা, GPT‑5.4⁠(একটি নতুন উইন্ডোতে খোলে), এবং এর বাইরেও সবাই WebSocket mode-এর গতিবৃদ্ধির সুফল পায়.
• Vercel AI SDK-এ WebSocket mode সংযুক্ত করেছে এবং লেটেন্সি 40% পর্যন্ত⁠(একটি নতুন উইন্ডোতে খোলে) কমতে দেখেছে.
• Cline-এর মাল্টি-ফাইল ওয়ার্কফ্লো 39% দ্রুততর⁠(একটি নতুন উইন্ডোতে খোলে).
• Cursor-এ OpenAI মডেল সর্বোচ্চ 30% দ্রুততর হয়েছে⁠(একটি নতুন উইন্ডোতে খোলে).

WebSocket mode হলো মার্চ 2025-এ চালু হওয়ার পর থেকে Responses API-এর সবচেয়ে গুরুত্বপূর্ণ নতুন সক্ষমতাগুলোর একটি. OpenAI-এর API এবং Codex টিমের ঘনিষ্ঠ সহযোগিতার মাধ্যমে আমরা মাত্র কয়েক সপ্তাহের মধ্যেই ধারণা থেকে প্রোডাকশনে চালু হওয়া পর্যন্ত পৌঁছে গেছি. এটি শুধু এজেন্ট রোলআউট লেটেন্সি নাটকীয়ভাবে উন্নত করে না, বরং ডেভেলপারদের একটি ক্রমবর্ধমান প্রয়োজনও পূরণ করে: মডেল ইনফারেন্স যত দ্রুততর হচ্ছে, ইনফারেন্সকে ঘিরে থাকা সেবা ও সিস্টেমগুলোও তত দ্রুত হওয়া দরকার, যাতে এই উন্নতির সুফল ব্যবহারকারীদের কাছে পৌঁছে দেওয়া যায়.