ছয় মাসে সাড়া দিতে সক্ষম ভয়েস AI-এর জন্য আমরা যেভাবে রিয়েলটাইম সিস্টেম তৈরি করেছি

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

আমাদের তৃতীয় প্রজন্মের ভয়েস সিস্টেম GPT‑Live⁠ অডিও পথ থেকে টার্ন ডিটেক্টর সরিয়ে দেয়. এর ভয়েস মডেল ফুল-ডুপ্লেক্স, অর্থাৎ এটি একই সময়ে শুনতে ও বলতে পারে. এর ফলে আলাদা ডিটেক্টরের প্রয়োজন থাকে না এবং কথোপকথন আরও তাৎক্ষণিক ও স্বাভাবিক মনে হয়. গভীর রিজনিং বা টুল ব্যবহারের দরকার হলে GPT‑Live কথোপকথনের প্রবাহ না থামিয়েই GPT‑5.5‑এর মতো আমাদের অত্যাধুনিক মডেলগুলোর পরামর্শ নিতে পারে. একসঙ্গে, এসব সক্ষমতা GPT‑Live‑কে কথোপকথনের দ্রুত সাড়া এবং বুদ্ধিমত্তার এক অভূতপূর্ব সমন্বয় দেয়.

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

আর্কিটেকচারটি মূল ভয়েস পথ এবং অ্যাপ্লিকেশন লজিকের মধ্যে একটি পরিষ্কার সীমানাও তৈরি করে. এতে সাড়া দেওয়ার ক্ষমতাকে প্রভাবিত না করেই অ্যাপ্লিকেশনের আচরণ কাস্টমাইজ করা সহজ হয়. এই ভিত্তি ChatGPT ভয়েসে বাড়তে থাকা নানা সক্ষমতাকে শক্তি দেয়, যার মধ্যে ChatGPT ডেস্কটপ অ্যাপে সদ্য চালু হওয়া আপনার কম্পিউটার নিয়ন্ত্রণ এবং আপনার এজেন্টগুলো সমন্বয় করার সক্ষমতাও রয়েছে.

এই পোস্টে আমরা ব্যাখ্যা করব কেন আগের টার্ন-ভিত্তিক সিস্টেমগুলো আমাদের প্রয়োজন মেটাতে পারেনি এবং কীভাবে আমরা প্রতিটি স্তরে সাড়াদানক্ষমতার জন্য নতুন সিস্টেমটি প্রকৌশল করেছি. আমরা স্টেটফুল ইনফারেন্স, ডায়নামিক কনটেক্সট ম্যানেজমেন্ট, অ্যাসিঙ্ক্রোনাস ডেলিগেশন এবং প্রোটোকল-স্তরের অপ্টিমাইজেশন নিয়ে আলোচনা করব—যেগুলো একসঙ্গে কাজ করে GPT‑Live‑কে সত্যিকারের লাইভ মনে করায়.

আগের ভয়েস আর্কিটেকচারগুলো টেক্সট LLM-এর টার্ন-ভিত্তিক স্বভাব উত্তরাধিকারসূত্রে পেয়েছিল, তবে প্রতিটি টার্ন টেক্সটের বদলে আলাদা অডিও ব্লব হিসেবে উপস্থাপিত হতো. ক্যাসকেডেড সিস্টেমে speech-to-text, LLM এবং text-to-speech ধারাবাহিকভাবে চলত. এই ক্রম লেটেন্সি বাড়াত এবং স্বর ও কথার গতি মতো সংকেত উপেক্ষা করত.

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

GPT‑Live কথোপকথনের নিয়ন্ত্রণ ভয়েস মডেলের হাতে দেয়: অডিও মডেলের ভেতরে ও বাইরে প্রবাহিত হয়, আর গভীর রিজনিং ও টুল ব্যবহার অ্যাসিঙ্ক্রোনাসভাবে ঘটে. সিস্টেমের প্রধান কাজ হলো একটি বিঘ্নহীন মিডিয়া লুপ বজায় রাখা. অত্যাধুনিক মডেল আহ্বান করা এবং কথোপকথন সংরক্ষণ করার মতো অন্যান্য কাজ লাইভ পথের বাইরে ঘটে.

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

ChatGPT ভয়েস এবং Realtime API নিয়ে আগের কাজ আমাদের একটি গুরুত্বপূর্ণ ভিত্তি দিয়েছিল. আমরা ইতিমধ্যেই আমাদের ভয়েস অবকাঠামো নতুন করে তৈরি করেছিলাম⁠, যাতে কম এবং আরও পূর্বানুমেয় লেটেন্সিতে আমাদের সিস্টেমে অডিও ও ভিডিও সরাসরি স্ট্রিম করা যায়. GPT‑Live সেই নকশাকে আরও এগিয়ে নিয়েছে, ধারাবাহিক কথোপকথনের জন্য তৈরি নতুন স্টেটফুল ইনফারেন্স সিস্টেমের মাধ্যমে মিডিয়াকে মডেল পর্যন্ত পুরো পথ স্ট্রিম করে.

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

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

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

আমরা মিডিয়া ফ্রন্টএন্ড ও ইনফারেন্স লজিক Go-তে লিখেছি, আগের Python asyncio ইমপ্লিমেন্টেশনকে প্রতিস্থাপন করে. এতে ফ্রেম ডেলিভারির মসৃণতা উল্লেখযোগ্যভাবে উন্নত হয়েছে; নতুন সিস্টেমের p95 আগের সিস্টেমের p50-এর সমান হয়েছে.

WebRTC ট্রান্সপোর্টের ভিত্তি দেয়. এটি কম লেটেন্সির মিডিয়ার জন্য নকশা করা, এবং প্যাকেট লস, ক্লক ড্রিফট ও ক্লায়েন্ট সংযোগ বদল হলেও চলতে পারে. প্যাকেট দেরিতে পৌঁছালে WebRTC ফাঁক রোধ করতে অডিও সামান্য প্রসারিত করতে পারে, তারপর বাস্তব সময়ে ফিরে আসতে প্লেব্যাক অল্প সময়ের জন্য দ্রুত করে.

পুরো সিস্টেমে বাফারিং ও ব্লকিং কমিয়ে আমরা কথোপকথনে মানুষ যে সাব-সেকেন্ড সাড়া আশা করে তা দিতে পারি.

স্টেটফুল ইনফারেন্সের নিজস্ব অপারেশনাল সমঝোতা আছে. একটি ভয়েস সেশন দীর্ঘ সময় সক্রিয় থাকতে পারে, কিন্তু এর কনটেক্সট ক্রমাগত বাড়ে, আর চাহিদা অনুযায়ী মডেল ইনস্ট্যান্স চালু ও বন্ধ হয়.

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

একই মৌলিক ব্যবস্থা ডায়নামিক কনটেক্সট সংকোচনও সমর্থন করে. কথোপকথন চলতে থাকলে তার জমে থাকা কনটেক্সট এক সময় মডেলের কনটেক্সট সীমা ছাড়িয়ে যেতে পারে. সংকোচন কনটেক্সটের আকার কমিয়ে সীমার মধ্যে আনতে পারে, কিন্তু এই কাজটি সময়সাপেক্ষ. আর এটি অতীত কনটেক্সট বদলে দেয় বলে, মডেলের কী-ভ্যালু (KV) ক্যাশও অকার্যকর করে, যেখানে আগে প্রক্রিয়াকৃত টোকেনের attention keys ও values সংরক্ষিত থাকে. সেই স্টেট আবার তৈরি করতে নতুন প্রিফিল দরকার হয়, ফলে অতিরিক্ত বিলম্ব যোগ হয়.

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

ভারী কাজ লাইভ পথের বাইরে থাকে, তাই হ্যান্ডঅফের সময়ও কথোপকথনের ছন্দ এক মুহূর্তও নষ্ট হয় না.

বিদ্যমান অত্যাধুনিক মডেলগুলো আহ্বান করার GPT‑Live‑এর সক্ষমতা এটিকে অনেক শক্তি দেয়; কার্যত “কথা বলা”কে গভীর “চিন্তা করা” থেকে আলাদা করে. কিন্তু এই দুই-মডেল আর্কিটেকচারকে একটি সিস্টেমের মতো অনুভব করাতে, সম্পর্কিত দুটি প্রকৌশল সমস্যা সমাধান করতে হয়েছে.

প্রথমত, চলমান কথোপকথনে কাজে লাগার মতো দ্রুত ফলাফল ফিরতে হবে, তাই রাউটিং ও প্রম্পট প্রসেসিং থেকে শুরু করে ইনফারেন্স ও টুল কল পর্যন্ত পুরো ডেলিগেশন পথে লেটেন্সি কমাতে হয়েছে. একই সময়ে, পণ্যের অন্য অংশের সিস্টেমগুলোর এখনও পৃথক বার্তা দরকার, তাই চলমান কথোপকথনকে তাদের বোঝার মতো রূপে উপস্থাপন করতে হয়েছে.

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

প্রথম অপ্টিমাইজেশন হলো ডেলিগেশন চাওয়ার আগেই অত্যাধুনিক মডেল এবং তার প্রয়োজনীয় যেকোনো টুল প্রস্তুত করা. ভয়েস সেশন শুরু হলে, অ্যাপ্লিকেশন সার্ভার অত্যাধুনিক মডেলের জন্য একটি ইনফারেন্স সেশন তৈরি করে এবং প্রাথমিক কথোপকথন কনটেক্সট দিয়ে সেটি প্রিফিল করে, যাতে প্রথম ডেলিগেটেড অনুরোধের আগেই প্রম্পট পুরোপুরি প্রসেস করা থাকে.

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

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

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

অডিও আসার সঙ্গে সঙ্গে, সার্ভার আংশিক ট্রান্সক্রিপ্ট ও টাইমিং সিগন্যাল ব্যবহার করে কোন বক্তার পালা চলছে তা অনুমান করে এবং বার্তার একটি কিউ তৈরি করে. সবচেয়ে নতুন বার্তাটি অস্থায়ী থাকে; আরও কথা আসার সঙ্গে সঙ্গে তার টেক্সট, সময় এবং বক্তা নির্ধারণ—সবই বদলাতে পারে. কোনো বক্তা যথেষ্ট সময় ধরে পালা ধরে রাখলে এবং অ্যাট্রিবিউশন নির্ভরযোগ্য হলে, সার্ভার সংশ্লিষ্ট বার্তাটি চূড়ান্ত করে.

বক্তাদের কথা ওভারল্যাপ করলে বিষয়টি আরও জটিল হয়. ব্যবহারকারী কথা বলার সময় অ্যাসিস্ট্যান্টের ছোট স্বীকৃতি (যেমন “হুঁ,” বা “ঠিক আছে”) সব সময় আলাদা বার্তা হওয়া উচিত নয়. তবে অর্থবহ কোনো অ্যাসিস্ট্যান্ট হস্তক্ষেপ প্রায়ই আলাদা বার্তা হওয়া উচিত. একইভাবে, ব্যবহারকারী মাঝখানে কথা বললেও প্রদর্শিত অ্যাসিস্ট্যান্ট প্রতিক্রিয়ায় আমরা সামঞ্জস্যকে অগ্রাধিকার দিই.

প্রতিটি সেগমেন্টেশন নীতিই নতুনত্বের বিনিময়ে নিশ্চিততা বেছে নেয়. খুব তাড়াতাড়ি কমিট করলে ইতিহাস খণ্ডিত হয় এবং ক্রম অস্থির হয়; খুব বেশি অপেক্ষা করলে ট্রান্সক্রিপ্ট এবং তার ওপর নির্ভরশীল ফিচারগুলো বিলম্বিত হয়. তাই সিস্টেম কথোপকথনের দুটি সম্পর্কিত ভিউ রাখে: বর্তমান অবস্থার একটি অনুমাননির্ভর ভিউ এবং কী বলা হয়েছে তার একটি কর্তৃত্বপূর্ণ রেকর্ড. অ্যাপ্লিকেশন UI-তে কথোপকথন ভিউ আপডেট সামলাতে পারে, তাই এটি অনুমাননির্ভর ভিউ ব্যবহার করে. কিন্তু অ্যানালিটিক্স পাইপলাইনে লগ করতে চূড়ান্ত ট্রান্সক্রিপ্ট দরকার.

এতে লাইভ ভয়েস পথে পালা নেওয়ার নিয়ম চাপিয়ে না দিয়েই ChatGPT‑এর বাকি অংশ কথোপকথনের একটি স্থিতিশীল ভিউ পায়.

ব্যবহারকারী বোতামে ক্লিক করার মুহূর্ত থেকেই সাড়াদানক্ষমতা শুরু হয়. GPT‑Live-এ কথোপকথন শুরু হওয়ার আগে সিস্টেমকে মিডিয়া পথ স্থাপন করতে এবং মডেলের মধ্য দিয়ে অডিও পাঠানো শুরু করতে হয়. তাতে স্টার্টআপ ক্রমের প্রতিটি অংশ ক্রিটিক্যাল পথে চলে আসে.

উপরে যেমন বলা হয়েছে, WebRTC রিয়েলটাইমের জন্য শক্ত ভিত্তি দেয়, কিন্তু একটি সাধারণ WebRTC সেশন শুরু করতে আশ্চর্যজনক সংখ্যক প্রোটোকল হ্যান্ডশেক ও নেটওয়ার্ক রাউন্ড ট্রিপ দরকার হয়. QUIC-এর মতো পরবর্তী প্রোটোকলগুলোকে যে রাউন্ড ট্রিপ কমানোর মনোযোগ গড়ে তুলেছে, WebRTC তার আগের. ফলে একসঙ্গে ব্যবহার করলে এর অন্তর্নিহিত প্রোটোকলগুলো কখনও কখনও একই কাজ পুনরাবৃত্তি করে. উদাহরণস্বরূপ, পূর্ণ WebRTC স্ট্যাকের প্রেক্ষাপটে প্রয়োজন না থাকলেও প্রতিটি প্রোটোকলে নিজস্ব anti-DoS ব্যবস্থা ছিল.

আমরা স্ট্যাকটি বিশ্লেষণ করে WebRTC Abridged Roundtrip Protocol (WARP⁠(একটি নতুন উইন্ডোতে খোলে)) তৈরি করেছি, যা মিডিয়া ও ডেটা স্টার্টআপকে ছয়টি নেটওয়ার্ক রাউন্ড ট্রিপ থেকে মাত্র একটিতে নামিয়ে আনে. WARP এটি করে ব্যাকওয়ার্ড-কম্প্যাটিবল প্রোটোকল উন্নতির একটি সেট দিয়ে: ICE-এর ওপর DTLS হ্যান্ডশেক পিগিব্যাক করা (SPED⁠(একটি নতুন উইন্ডোতে খোলে)), দ্রুততর DTLS 1.3⁠(একটি নতুন উইন্ডোতে খোলে) হ্যান্ডশেক ব্যবহার করা, SCTP হ্যান্ডশেক আগে থেকে নেগোশিয়েট করা (SNAP⁠(একটি নতুন উইন্ডোতে খোলে)), এবং DCEP⁠(একটি নতুন উইন্ডোতে খোলে) ব্যবহারের বদলে ডেটা চ্যানেল আগে থেকেই নেগোশিয়েট করা.

আমরা WebRTC কমিউনিটির সহযোগীদের সঙ্গে কাজ করে WARP-কে ওপেন স্পেসিফিকেশনের একটি সেট হিসেবে নকশা করেছি, যাতে বৃহত্তর ইকোসিস্টেম এই কাজ থেকে উপকৃত হতে পারে. আমরা IETF-এর TSVWG ওয়ার্কিং গ্রুপের মাধ্যমে প্রস্তাবগুলো এগিয়ে নিচ্ছি, এবং libwebrtc ও Pion—দুটিতেই ইতিমধ্যে WARP সাপোর্ট যোগ হয়েছে; অন্য WebRTC ইমপ্লিমেন্টেশনেও কাজ চলছে.

মিডিয়া হ্যান্ডশেক অপ্টিমাইজ করার পর একটি বাকি বিলম্ব বিশেষভাবে চোখে পড়ে: WebRTC সংযোগের আগে SDP প্যারামিটার ভাগ করতে ব্যবহৃত সিগন্যালিং বিনিময়. সেই বিনিময়কে ক্রিটিক্যাল পথ থেকে সরাতে আমরা যা Instant Connect বলি তা তৈরি করেছি. এটি সার্ভার সক্ষমতা রিজার্ভ না করে এবং বিদ্যমান WebRTC ইমপ্লিমেন্টেশনে কোনো পরিবর্তন না এনে এসব প্যারামিটার আগেভাগে নেগোশিয়েট করে.

Instant Connect স্ট্যান্ডার্ড সিগন্যালিং ফ্লোর পাশাপাশি চলে. আগে থেকে নেগোশিয়েট করা প্যারামিটার বৈধ হলে, প্রথম মিডিয়া প্যাকেট পৌঁছানোর সময় সার্ভার সেশনটি বাস্তবে তৈরি করতে পারে. সেগুলো পুরোনো বা অবৈধ হলে, সিগন্যালিং ফ্লো ইতিমধ্যেই চলতে থাকে, তাই ক্লায়েন্ট অতিরিক্ত লেটেন্সি ছাড়াই ফলব্যাক করতে পারে.

একসঙ্গে, Instant Connect এবং WARP ব্যবহারকারীর ইচ্ছা থেকে লাইভ মিডিয়া প্রবাহ শুরু হওয়ার সময় নাটকীয়ভাবে কমিয়ে দেয়. SDP বিনিময় ক্রিটিক্যাল পথের বাইরে এবং WARP ট্রান্সপোর্ট হ্যান্ডশেক সংকুচিত করায়, ক্লায়েন্ট এখন একটি UDP প্যাকেট দিয়েই সেশন শুরু করতে পারে. সার্ভার সঙ্গে সঙ্গে সাড়া দিতে পারে, ফলে সিস্টেমের বাকি অংশ ব্যবহারকারীর সত্যিকারের গুরুত্বপূর্ণ কাজ—শোনা এবং সাড়া দেওয়া—শুরু করতে পারে.

কাগজে-কলমে কোনো সিস্টেম দ্রুত মনে হলেও বাস্তব ভয়েস ট্র্যাফিকের চাপের মধ্যে থমকে যেতে পারে. GPT‑Live-কে ব্যবহারকারীদের সঙ্গে চ্যাট করতে দেওয়ার আগে, আমরা একটি নীরব পরীক্ষা চালিয়েছিলাম যেখানে প্রোডাকশন ChatGPT ভয়েস সেশনের ছোট এবং ধীরে ধীরে বাড়তে থাকা একটি অংশ বিদ্যমান অ্যাডভান্সড ভয়েস মোড অভিজ্ঞতা এবং আমাদের নতুন সিস্টেম—দুই জায়গাতেই রাউট করা হয়েছিল. অ্যাডভান্সড ভয়েস মোড আগের মতোই ব্যবহারকারীদের সেবা দিতে থাকে, আর শ্যাডো পথে ইনফারেন্স চলছিল রিড-অনলি মোডে. এতে ব্যবহারকারীরা যা শুনতেন তা না বদলিয়েই সিস্টেমটি বাস্তব ক্লায়েন্ট, নেটওয়ার্ক, সেশনের দৈর্ঘ্য এবং ভৌগোলিক বণ্টনের মুখোমুখি হয়েছে.

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

পরীক্ষাটি ভৌগোলিক অবস্থানকেও প্রথম সারির বিবেচনায় নিয়ে আসে. কোনো সেশনকে দূরের সক্ষমতায় রাউট করলে স্টার্টআপ ও স্ট্রিমিংয়ের সময় কয়েকটি ধাপে বিলম্ব যোগ হতে পারে. আমরা আঞ্চলিক সক্ষমতা ও ট্র্যাফিক-স্টিয়ারিং কনফিগারেশনের সঙ্গে মডেল রোলআউট যাচাই করতে শুরু করি, এরপর উৎস ভৌগোলিক অঞ্চল অনুযায়ী লেটেন্সি ভেঙে দেখি. ইনফারেন্সকে ব্যবহারকারীদের কাছাকাছি আনলে উপকার হয়েছে, তবে এটি বৃহত্তর শিক্ষাটিও আরও স্পষ্ট করেছে: এন্ড-টু-এন্ড সাড়া দেওয়ার ক্ষমতা শুধু মডেল সার্ভারের ওপর নয়, পথের প্রতিটি সার্ভিসের ওপর নির্ভর করে.

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

শেষ পর্যন্ত, প্রোডাকশন টেস্টিং আমাদের অবজারভেবিলিটি ও রোলআউট নিয়ন্ত্রণ উন্নত করতে বাধ্য করেছে. আমরা এমন মেট্রিক পেয়েছি যা লেটেন্সির বিভিন্ন উৎসকে একসঙ্গে মিশিয়ে ফেলত, এমন ড্যাশবোর্ড পেয়েছি যার সামষ্টিক মান আলাদা অস্বাস্থ্যকর ইঞ্জিনগুলো আড়াল করত, এবং পরীক্ষিত ও ডিপ্লয় করা সিস্টেমের মধ্যে কনফিগারেশন ড্রিফট দেখেছি. এর জবাবে আমরা আরও সূক্ষ্ম টেলিমেট্রি, পরিচিত ভালো কনফিগারেশনের বিপরীতে যাচাই, ধাপে ধাপে র্যাম্প, এবং আলাদা পথ দ্রুত বিচ্ছিন্ন বা নিষ্ক্রিয় করার সক্ষমতা যোগ করেছি. নীরব পরীক্ষাটি প্রাথমিক লঞ্চ মহড়ায় পরিণত হয়েছিল—শুধু সিস্টেম কত ট্র্যাফিক নিতে পারে তা নয়, ব্যর্থতা কত দ্রুত শনাক্ত, সীমাবদ্ধ এবং কাটিয়ে উঠতে পারি সেটিও বোঝার জন্য.

GPT‑Live-কে ChatGPT‑এর স্কেলে আনতে একটি মৌলিক নীতিকে কেন্দ্র করে একেবারে নতুন সিস্টেম দরকার ছিল: ভয়েসের প্রবাহ থামানো যাবে না. স্ট্রিমিং ইনফারেন্স ফুল-ডুপ্লেক্স মডেলে অডিও সরবরাহ বজায় রাখে. একটি নিবেদিত মিডিয়া পথ নির্ভরযোগ্য ফ্রেম ডেলিভারি নিশ্চিত করে. অ্যাসিঙ্ক্রোনাস ডেলিগেশন গভীর চিন্তাকে সমান্তরালে চালাতে দেয়. অপ্টিমাইজ করা ট্রান্সপোর্ট অভিজ্ঞতাকে ব্যবহারকারী পর্যন্ত পুরো পথজুড়ে সাড়াদানক্ষম রাখে.

GPT‑Live-এর পেছনের আর্কিটেকচার ইতিমধ্যেই রিয়েলটাইম ইন্টারঅ্যাকশনের জন্য আরও বিস্তৃত প্ল্যাটফর্ম হয়ে উঠছে. এটি ChatGPT ভয়েসকে শক্তি দেয়, যা কথোপকথন থেকে এজেন্টিক সমন্বয়ে বিস্তৃত হচ্ছে, এবং আসন্ন GPT‑Live API-এর ভিত্তি হবে. সময়ের সঙ্গে সঙ্গে, এটি ভয়েস অভিজ্ঞতাকে আরও বেশি ডিভাইস, অ্যাপ এবং মোডালিটি জুড়ে বিস্তৃত করতে দেবে, তবে ভয়েস কনভার্সেশন্সকে লাইভ মনে করায় যে তাৎক্ষণিকতা, তা হারাবে না.

আপনি যদি এমন ধরনের প্রকৌশল সমস্যা সমাধান করতে চান, আমাদের সঙ্গে কাজ করুন⁠.