हमने छह महीनों में तत्पर वॉइस AI के लिए रीयलटाइम सिस्टम कैसे बनाया

वॉइस AI के लिए यह जानना जितना आसान लगता है कि कब बोलना है, असल में उतना है नहीं. लोग एक सेकंड से भी कम समय में सहजता से एक-दूसरे को बोलने का अवसर देते हैं, लेकिन पुराने वॉइस AI सिस्टम इस लय के साथ नहीं चल पाते थे. उनकी बारी-आधारित संरचना टर्न डिटेक्टर कहे जाने वाले छोटे मॉडल पर निर्भर थी, जिनका काम बेहद कठिन था: बहुत जल्दी अनुमान लगाने पर उपयोगकर्ता की बात कटती थी और देर से लगाने पर प्रतिक्रिया सुस्त लगती थी. डिटेक्टर के निर्णय लेने के बाद ही कहीं अधिक बड़ा LLM काम शुरू कर सकता था.

हमारी तीसरी पीढ़ी का वॉइस सिस्टम GPT‑Live⁠ ऑडियो पाथ से टर्न डिटेक्टर को हटा देता है. इसका वॉइस मॉडल फ़ुल-डुप्लेक्स है, यानी यह एक ही समय में सुन और बोल सकता है. इससे अलग डिटेक्टर की आवश्यकता समाप्त होती है और बातचीत अधिक तात्कालिक तथा स्वाभाविक लगती है. गहन रीज़निंग या टूल के उपयोग की आवश्यकता होने पर GPT‑Live बातचीत का प्रवाह रोके बिना GPT‑5.5 जैसे हमारे अत्याधुनिक मॉडल से भी सहायता ले सकता है. ये क्षमताएँ मिलकर GPT‑Live को बातचीत की तत्परता और इंटेलिजेंस का अभूतपूर्व संयोजन देती हैं.

इस अनुभव को बड़े पैमाने पर देने के लिए कम विलंब हेतु अनुकूलित नई सिस्टम संरचना बनानी पड़ी. सामान्य अनुरोध-प्रतिक्रिया इन्फ़रेंस के विपरीत, हमारा सिस्टम आने वाले ऑडियो को वॉइस मॉडल में और उससे निकलने वाली वाणी को उपयोगकर्ता तक स्ट्रीम करता है, जबकि कार्य-सौंपने को अलग असिंक्रोनस पाथ पर सँभालता है. पिछले छह महीनों में हमने मॉडल इन्फ़रेंस, संदर्भ प्रबंधन और मीडिया परिवहन को नए सिरे से बनाया, ताकि वाणी का प्रवाह शुरू से अंत तक सहज बना रहे.

यह संरचना मुख्य वॉइस पाथ और ऐप्लिकेशन तर्क के बीच एक स्पष्ट सीमा भी बनाती है. इससे तत्परता प्रभावित किए बिना ऐप्लिकेशन के व्यवहार को अनुकूलित करना आसान होता है. यह आधार ChatGPT वॉइस में क्षमताओं की बढ़ती शृंखला को शक्ति देता है. इनमें हाल में शुरू हुई ChatGPT डेस्कटॉप ऐप से अपने कंप्यूटर को नियंत्रित करने और एजेंटों का समन्वय करने की क्षमता शामिल है.

इस लेख में हम बताएँगे कि पुराने बारी-आधारित सिस्टम हमारी आवश्यकताएँ क्यों पूरी नहीं कर सके और हमने हर परत पर तत्परता के लिए नया सिस्टम कैसे बनाया. हम स्थितिपूर्ण इन्फ़रेंस, गतिशील संदर्भ प्रबंधन, असिंक्रोनस कार्य-सौंपने और प्रोटोकॉल-स्तरीय अनुकूलन पर चर्चा करेंगे, जो मिलकर GPT‑Live को सचमुच सजीव बनाते हैं.

पुरानी वॉइस संरचनाओं को टेक्स्ट LLM की बारी-आधारित प्रकृति विरासत में मिली थी, लेकिन उनमें हर बारी टेक्स्ट के बजाय अलग ऑडियो खंड के रूप में होती थी. क्रमबद्ध सिस्टम में वाणी-से-पाठ, LLM और पाठ-से-वाणी की प्रक्रियाएँ एक के बाद एक चलती थीं. इस क्रम से विलंब बढ़ा और स्वर तथा गति जैसे संकेत अनदेखे हुए.

स्पीच-टू-स्पीच मॉडल ने ऑडियो को सीधे संसाधित करके इस तरीके को बेहतर बनाया. मॉडल को वाणी समझने और उत्पन्न करने का मूल प्रशिक्षण देने से वह प्रतिलेखन में खो जाने वाले विवरण बचा सका और अधिक तेज़ी से प्रतिक्रिया दे सका. लेकिन इन्फ़रेंस कब शुरू हो सकता है, यह तय करने के लिए सिस्टम अब भी टर्न डिटेक्टर पर निर्भर था. मॉडल ने संवाद का अधिक हिस्सा सँभाला, लेकिन संवाद बारी-आधारित ही रहा.

GPT‑Live बातचीत का नियंत्रण वॉइस मॉडल को देता है: ऑडियो मॉडल के भीतर और बाहर बहता है, जबकि गहन रीज़निंग तथा टूल का उपयोग असिंक्रोनस रूप से होता है. सिस्टम का मुख्य काम मीडिया चक्र को बिना रुकावट जारी रखना है. अत्याधुनिक मॉडल को इस्तेमाल करने और बातचीत को स्थायी रूप से सहेजने जैसे अन्य काम सजीव पाथ से बाहर होते हैं.

इस मीडिया चक्र को बिना रुकावट जारी रखना हमेशा आसान नहीं होता. परिवहन, प्रसंस्करण या इन्फ़रेंस में कोई भी विलंब सुनाई देने वाला विराम या विकार बन सकता है. पुराना बारी-आधारित सिस्टम ऑडियो खंड के पहुँचने के समय में थोड़ा अंतर सह सकता था. लेकिन सजीव मीडिया सिस्टम को हर ऑडियो फ़्रेम तय समय पर पहुँचाना होता है.

ChatGPT वॉइस और Realtime API पर पहले किए गए काम ने हमें महत्वपूर्ण आधार दिया. हम पहले ही अपने सिस्टम में ऑडियो और वीडियो को सीधे अंदर-बाहर स्ट्रीम करने के लिए अपने वॉइस आधारभूत ढाँचे का पुनर्निर्माण कर चुके थे⁠, जिससे विलंब कम और अधिक पूर्वानुमेय हुआ. GPT‑Live ने इस डिज़ाइन को और आगे बढ़ाया. निरंतर बातचीत के लिए बने नए स्थितिपूर्ण इन्फ़रेंस सिस्टम के माध्यम से मीडिया को सीधे मॉडल तक स्ट्रीम किया गया.

हालाँकि, स्ट्रीमिंग इन्फ़रेंस समाधान का केवल एक हिस्सा था. उत्पादन परिवेश में इसे अच्छी तरह चलाने के लिए हमें क्लाइंट से इन्फ़रेंस स्टैक तक भरोसेमंद ऑडियो डिलीवरी सुनिश्चित करनी थी और स्थितिपूर्णता की चुनौतियाँ सँभालनी थीं.

हमने शुरुआत में ही मीडिया प्रवाह को ऐप्लिकेशन और कारोबारी तर्क से स्पष्ट रूप से अलग करने का निर्णय लिया. ऑडियो क्लाइंट और वॉइस मॉडल के बीच एक समर्पित तेज़ पाथ से जाता है. कार्य-सौंपना, टूल का उपयोग और ऐप्लिकेशन के अन्य काम असिंक्रोनस RPC सीमा के पीछे होते हैं. धीमा टूल कॉल या बैकएंड सेवा अपने परिणाम में देरी कर सकती है, लेकिन मीडिया का प्रवाह नहीं रोक सकती.

यह विभाजन अनुकूलन के लिए सिस्टम को एक स्पष्ट सीमा भी देता है. ऐप्लिकेशन अपने टूल, नीतियाँ और बैकएंड व्यवहार बदल सकते हैं, बिना ऑडियो का प्रवाह बनाए रखने वाले मीडिया फ़्रंटएंड को प्रभावित किए. सजीव पाथ छोटा, पूर्वानुमेय और रीयलटाइम में होने वाले आवश्यक काम पर केंद्रित रहता है.

हमने पुराने Python asyncio कार्यान्वयन की जगह मीडिया फ़्रंटएंड और इन्फ़रेंस तर्क को Go में लिखा. इससे फ़्रेम डिलीवरी की सहजता काफ़ी बेहतर हुई और नए सिस्टम का p95 पुराने सिस्टम के p50 के बराबर हो गया.

WebRTC परिवहन का आधार प्रदान करता है. इसे कम-विलंब वाले मीडिया के लिए बनाया गया है और यह पैकेट हानि, घड़ी के विचलन तथा क्लाइंट कनेक्शन में बदलाव के दौरान भी चलता रह सकता है. पैकेट देर से पहुँचें तो WebRTC अंतराल रोकने के लिए ऑडियो को हल्का खींच सकता है, फिर रीयलटाइम से दोबारा मेल बैठाने के लिए प्लेबैक को थोड़ी देर तेज़ कर सकता है.

पूरे सिस्टम में बफ़रिंग और अवरोध कम करके हम एक सेकंड से भी कम की वह तत्परता दे सकते हैं जिसकी लोग बातचीत में अपेक्षा करते हैं.

स्थितिपूर्ण इन्फ़रेंस के अपने परिचालन समझौते होते हैं. वॉइस सत्र लंबे समय तक सक्रिय रह सकता है, लेकिन उसका संदर्भ लगातार बढ़ता है और माँग के अनुसार मॉडल इंस्टेंस शुरू तथा बंद होते रहते हैं.

इन चिंताओं के समाधान के लिए हमने मॉडल इंस्टेंसों के बीच निर्बाध हस्तांतरण की व्यवस्था बनाई. बदलाव की आवश्यकता होने पर हम मौजूदा इंस्टेंस के साथ प्रतिस्थापन मॉडल इंस्टेंस को तैयार कर सकते हैं, उसमें वर्तमान सत्र संदर्भ पहले से भर सकते हैं, दोनों पर समानांतर इन्फ़रेंस चला सकते हैं और नया इंस्टेंस पूरी तरह तैयार होने पर उस पर जा सकते हैं.

यही मूल व्यवस्था गतिशील संदर्भ कम्पैक्शन में भी सहायक है. बातचीत जारी रहने पर उसका संचित संदर्भ अंततः मॉडल की संदर्भ सीमा से अधिक हो सकता है. कम्पैक्शन संदर्भ का आकार घटाकर उसे सीमा में ला सकता है, लेकिन इस प्रक्रिया में समय लगता है. और चूँकि यह पिछले संदर्भ को बदलता है, इसलिए मॉडल का कुंजी-मान (KV) कैश भी अमान्य हो जाता है, जिसमें पहले संसाधित टोकन की अटेंशन कुंजियाँ और मान संग्रहीत होते हैं. उस स्थिति को दोबारा बनाने के लिए नया प्रीफ़िल चाहिए, जिससे अतिरिक्त विलंब होता है.

इसके बजाय, हम कम्पैक्शन को एक और प्रबंधित बदलाव मानते हैं. मूल मॉडल इंस्टेंस बातचीत जारी रखता है, जबकि सिस्टम संदर्भ का कम्पैक्शन करता है और नए संदर्भ के साथ प्रतिस्थापन मॉडल इंस्टेंस तैयार करता है. उस इंस्टेंस के तैयार होते ही हम मीडिया में कोई रुकावट डाले बिना उस पर जा सकते हैं. इससे सिस्टम लंबी कॉल को संभाल सकता है और आवश्यकता पड़ने पर कम्पैक्शन कर सकता है.

भारी काम सजीव पाथ से बाहर रहता है, इसलिए हस्तांतरण के दौरान भी बातचीत की लय नहीं टूटती.

मौजूदा अत्याधुनिक मॉडल को इस्तेमाल करने की GPT‑Live की क्षमता इसे बहुत शक्तिशाली बनाती है और प्रभावी रूप से “बोलने” को गहन “चिंतन” से अलग कर देती है. लेकिन इस दो-मॉडल संरचना को एक ही सिस्टम जैसा अनुभव कराने के लिए दो संबंधित इंजीनियरिंग समस्याएँ हल करनी पड़ीं.

पहला, परिणाम इतनी जल्दी मिलने चाहिए कि जारी बातचीत में उपयोगी हों. इसलिए हमें रूटिंग और प्रॉम्प्ट प्रसंस्करण से लेकर इन्फ़रेंस तथा टूल कॉल तक पूरे कार्य-सौंपने वाले पाथ का विलंब घटाना पड़ा. साथ ही, उत्पाद के अन्य सिस्टम को अब भी अलग-अलग संदेश चाहिए, इसलिए जारी बातचीत को उनके समझने योग्य रूप में प्रस्तुत करना पड़ा.

कार्य सौंपे जाने पर हम उस समय को घटाते हैं जिसमें अत्याधुनिक मॉडल बातचीत के लिए कुछ उपयोगी तैयार करता है. जब अत्याधुनिक मॉडल रीज़निंग या टूल का उपयोग करता है, तब वॉइस मॉडल थोड़ी देर बातचीत आगे बढ़ा सकता है, लेकिन अनिश्चित रूप से धीमी प्रतिक्रिया को छिपा नहीं सकता. इसलिए हमने रूटिंग, प्रॉम्प्ट प्रसंस्करण, इन्फ़रेंस और टूल कॉल सहित पूरे कार्य-सौंपने के चक्र को तत्परता बजट का हिस्सा माना.

पहला अनुकूलन यह है कि कार्य सौंपने का अनुरोध आने से पहले ही अत्याधुनिक मॉडल और उसके आवश्यक टूल तैयार कर दिए जाएँ. वॉइस सत्र शुरू होने पर ऐप्लिकेशन सर्वर अत्याधुनिक मॉडल के लिए इन्फ़रेंस सत्र बनाता है और उसमें आरंभिक बातचीत का संदर्भ पहले से भरता है. इससे पहले सौंपे गए अनुरोध से पूर्व प्रॉम्प्ट पूरी तरह संसाधित हो जाता है.

फिर हम वॉइस बातचीत की पूरी अवधि में उस इन्फ़रेंस सत्र को उपलब्ध रखते हैं और अगले अनुरोधों के लिए स्थिर सत्र संबद्धता का उपयोग करते हैं. प्रॉम्प्ट कैशिंग के साथ ये तकनीकें विलंब घटाती हैं, जबकि वर्कर की विफलता से उबरना आसान बना रहता है.

रीज़निंग प्रयास, आउटपुट सीमा, टूल स्कीमा और मॉडल-टूल के बीच आवागमन भी उपयोगी परिणाम मिलने के समय को प्रभावित करते हैं. तेज़ प्रतिक्रियाओं के लिए हमने इन्हें समायोजित किया. कार्य-सौंपने वाले पाथ पर आवश्यक काम घटाकर हमने वॉइस मॉडल को अपने अत्याधुनिक मॉडल के परिणाम तुरंत शामिल करने योग्य बनाया.

वॉइस मॉडल निरंतर वाणी स्ट्रीम पर काम करता है, लेकिन उसके आसपास के कई सिस्टम अब भी उपयोगकर्ता और सहायक के अलग-अलग संवाद-चरणों पर चलते हैं. इनमें ChatGPT का बातचीत इंटरफ़ेस और हमारे विश्लेषण तथा सुरक्षा आधारभूत ढाँचे के कुछ हिस्से शामिल हैं. इसलिए ऐप्लिकेशन सर्वर आपस में घुली-मिली और कभी-कभी अस्पष्ट बातचीत को अलग-अलग संदेशों में बाँटता है.

ऑडियो आने पर सर्वर आंशिक प्रतिलेख और समय संकेतों से अनुमान लगाता है कि कौन बोल रहा है, फिर संदेशों की कतार बनाता है. सबसे नया संदेश अस्थायी रहता है. अधिक वाणी आने पर उसका पाठ, समय और वक्ता-निर्धारण बदल सकता है. जब कोई वक्ता इतनी देर तक बोल चुका हो कि निर्धारण भरोसेमंद हो जाए, तो सर्वर संबंधित संदेश को अंतिम रूप देता है.

वक्ताओं का एक साथ बोलना इसे अधिक जटिल बनाता है. उपयोगकर्ता के बोलते समय सहायक की संक्षिप्त स्वीकृति, जैसे “हूँ-हूँ” या “ठीक है”, को आवश्यक रूप से अलग संदेश नहीं बनना चाहिए. लेकिन सहायक की सार्थक दखल को अक्सर अलग संदेश बनना चाहिए. इसी तरह, उपयोगकर्ता के बीच में बोलने पर भी हम प्रदर्शित सहायक प्रतिक्रियाओं की सुसंगति को प्राथमिकता देते हैं.

हर विभाजन नीति में नवीनता और निश्चितता के बीच समझौता होता है. बहुत जल्दी अंतिम रूप देने से इतिहास खंडित और क्रम अस्थिर होता है. बहुत देर करने से प्रतिलेख और उन पर निर्भर सुविधाओं में देरी होती है. इसलिए सिस्टम बातचीत के दो संबंधित दृश्य रखता है: वर्तमान स्थिति का अनुमानित दृश्य और कही गई बातों का प्रामाणिक रिकॉर्ड. ऐप्लिकेशन इंटरफ़ेस में बातचीत का दृश्य अपडेट सँभाल सकता है, इसलिए वह अनुमानित दृश्य का उपयोग करता है. लेकिन विश्लेषण पाइपलाइन में दर्ज करने के लिए अंतिम प्रतिलेख चाहिए.

इससे ChatGPT के बाकी हिस्सों को सजीव वॉइस पाथ पर बारी-बारी से बोलने का नियम थोपे बिना बातचीत का स्थिर दृश्य मिलता है.

उपयोगकर्ता के बटन पर क्लिक करते ही तत्परता की शुरुआत हो जाती है. GPT‑Live में बातचीत शुरू होने से पहले सिस्टम को मीडिया पाथ स्थापित करके मॉडल में ऑडियो भेजना शुरू करना होता है. इससे आरंभिक क्रम का हर हिस्सा निर्णायक पाथ पर आ जाता है.

जैसा ऊपर बताया गया है, WebRTC एक मज़बूत रीयलटाइम आधार देता है, लेकिन सामान्य WebRTC सत्र शुरू करने के लिए आश्चर्यजनक रूप से कई प्रोटोकॉल हैंडशेक और नेटवर्क आवागमन चाहिए. WebRTC उस दौर से पहले का है जब QUIC जैसे बाद के प्रोटोकॉल को नेटवर्क आवागमन घटाने पर केंद्रित करके बनाया गया. इसलिए साथ उपयोग किए जाने पर इसके अंतर्निहित प्रोटोकॉल कभी-कभी एक ही काम दोहराते हैं. उदाहरण के लिए, हर प्रोटोकॉल में अपना सेवा-अवरोध आक्रमण रोकने वाला तंत्र था, भले ही पूरे WebRTC स्टैक के संदर्भ में उसकी आवश्यकता न हो.

हमने स्टैक का विश्लेषण करके WebRTC Abridged Roundtrip Protocol (WARP⁠(एक नई विंडो में खुलेगा)) बनाया, जो मीडिया और डेटा का आरंभ छह नेटवर्क आवागमन से घटाकर केवल एक कर देता है. WARP यह काम पुराने संस्करणों से संगत प्रोटोकॉल सुधारों के समूह से करता है: ICE पर DTLS हैंडशेक साथ भेजना (SPED⁠(एक नई विंडो में खुलेगा)), अधिक तेज़ DTLS 1.3⁠(एक नई विंडो में खुलेगा) हैंडशेक का उपयोग, SCTP हैंडशेक की पूर्व-सहमति (SNAP⁠(एक नई विंडो में खुलेगा)) और DCEP⁠(एक नई विंडो में खुलेगा) के उपयोग के बजाय डेटा चैनलों की पूर्व-सहमति.

हमने WebRTC समुदाय के सहयोगियों के साथ काम करके WARP को खुले विनिर्देशों के समूह के रूप में बनाया, ताकि व्यापक तंत्र भी इस काम से लाभ उठा सके. हम IETF के TSVWG कार्य समूह के माध्यम से प्रस्तावों को आगे बढ़ा रहे हैं. WARP समर्थन libwebrtc और Pion दोनों में जोड़ा जा चुका है, जबकि अन्य WebRTC कार्यान्वयनों में भी प्रयास जारी हैं.

मीडिया हैंडशेक को अनुकूलित करने के बाद एक विलंब शेष था: WebRTC के कनेक्ट होने से पहले SDP पैरामीटर साझा करने के लिए उपयोग किया जाने वाला सिग्नलिंग आदान-प्रदान. उस आदान-प्रदान को निर्णायक पाथ से हटाने के लिए हमने इंस्टेंट कनेक्ट नामक प्रणाली बनाई. यह सर्वर क्षमता आरक्षित किए बिना और मौजूदा WebRTC कार्यान्वयनों में कोई बदलाव किए बिना इन पैरामीटर पर पहले ही सहमति बना लेती है.

इंस्टेंट कनेक्ट मानक सिग्नलिंग प्रवाह के साथ चलता है. पहले से तय पैरामीटर मान्य हों, तो पहला मीडिया पैकेट आते ही सर्वर सत्र को साकार कर सकता है. वे पुराने या अमान्य हों, तो सिग्नलिंग प्रवाह पहले ही चल रहा होता है, इसलिए क्लाइंट बिना अतिरिक्त विलंब के उस पर लौट सकता है.

इंस्टेंट कनेक्ट और WARP मिलकर उपयोगकर्ता की मंशा से सजीव मीडिया प्रवाह शुरू होने तक का समय बहुत घटा देते हैं. SDP आदान-प्रदान निर्णायक पाथ से बाहर होने और WARP द्वारा परिवहन हैंडशेक समेटे जाने से क्लाइंट अब केवल एक UDP पैकेट से सत्र शुरू कर सकता है. सर्वर तुरंत प्रतिक्रिया दे सकता है, जिससे बाकी सिस्टम वह काम शुरू कर देता है जो उपयोगकर्ता के लिए वास्तव में मायने रखता है: सुनना और जवाब देना.

कोई सिस्टम कागज़ पर तेज़ दिख सकता है, फिर भी वास्तविक वॉइस ट्रैफ़िक में अटक सकता है. GPT‑Live को उपयोगकर्ताओं से बातचीत कराने से पहले, हमने एक मूक परीक्षण किया. इसमें उत्पादन परिवेश के ChatGPT वॉइस सत्रों का छोटा और धीरे-धीरे बढ़ता हिस्सा मौजूदा एडवांस्ड वॉइस मोड अनुभव और हमारे नए सिस्टम, दोनों तक भेजा गया. एडवांस्ड वॉइस मोड हमेशा की तरह उपयोगकर्ताओं को सेवा देता रहा, जबकि शैडो पाथ ने केवल-पढ़ने योग्य मोड में इन्फ़रेंस चलाया. इससे उपयोगकर्ताओं को सुनाई देने वाली सामग्री बदले बिना सिस्टम को वास्तविक क्लाइंट, नेटवर्क, सत्र अवधि और भौगोलिक वितरण के बीच आज़माया जा सका.

शुरुआती सीखों में एक यह थी कि क्षमता को केवल GPU थ्रूपुट के आधार पर नहीं आँका जा सकता. वॉइस सत्र खुले रहते हैं और लगातार फ़्रेम भेजते हैं, इसलिए CPU-पक्ष के स्ट्रीम हैंडलर, कतारें और नेटवर्क पाथ भी इन्फ़रेंस के साथ उसी अनुपात में बढ़ने चाहिए. वास्तविक लोड में एक सहायक घटक हमारे लोड परीक्षण के अनुमान से पहले ही अपनी सीमा पर पहुँच गया. इससे इन्फ़रेंस अनुरोध जमा होने लगे और विलंब लगातार बढ़ता गया. हमने क्षमता से जुड़ा सवाल “एक GPU कितने अनुरोध संभाल सकता है?” से बदलकर “हर फ़्रेम को तय समय पर रखते हुए सिस्टम एक साथ कितने सत्र चला सकता है?” कर दिया.

परीक्षण ने भौगोलिक स्थिति को भी प्रमुख चिंता बना दिया. किसी सत्र को दूर स्थित क्षमता तक भेजने से आरंभ और स्ट्रीमिंग के दौरान कई चरणों पर विलंब बढ़ सकता है. हमने क्षेत्रीय क्षमता और ट्रैफ़िक-निर्देशन कॉन्फ़िगरेशन के साथ मॉडल रोलआउट का सत्यापन शुरू किया, फिर स्रोत की भौगोलिक स्थिति के अनुसार विलंब का विश्लेषण किया. इन्फ़रेंस को उपयोगकर्ताओं के करीब लाने से मदद मिली, लेकिन इससे व्यापक सीख भी पुष्ट हुई: शुरू से अंत तक तत्परता केवल मॉडल सर्वर पर नहीं, पाथ की हर सेवा पर निर्भर करती है.

कुछ अन्य विफलताएँ केवल वास्तविक सत्र जीवनचक्र में सामने आईं. लंबे समय तक चलने वाले सत्रों ने मेमोरी और स्थायित्व पर दबाव उजागर किया. दोबारा कनेक्ट होने पर कम्पैक्शन और स्थिति की बहाली की परीक्षा हुई. क्लाइंट के सामान्य रूप से डिस्कनेक्ट होने पर शटडाउन हैंडशेक की प्रतिस्पर्धी स्थितियाँ सामने आईं. छोटे लोड परीक्षणों में ये समस्याएँ शायद ही दिखीं, क्योंकि ये समय, संचित स्थिति और सेवाओं की सीमाओं के पार होने वाले व्यवहार पर निर्भर थीं.

अंततः, उत्पादन परिवेश में परीक्षण ने हमें निगरानी और रोलआउट नियंत्रण बेहतर करने के लिए बाध्य किया. हमें ऐसे मेट्रिक मिले जो विलंब के अलग-अलग स्रोतों को मिला देते थे, ऐसे डैशबोर्ड मिले जिनके समग्र आँकड़े अलग-अलग अस्वस्थ इंजन छिपा देते थे, और परीक्षण किए गए तथा तैनात सिस्टम के कॉन्फ़िगरेशन में अंतर मिला. इसके समाधान में हमने अधिक विस्तृत टेलीमेट्री, प्रमाणित कॉन्फ़िगरेशन से सत्यापन, चरणबद्ध विस्तार और अलग-अलग पाथ को तुरंत पृथक या बंद करने की क्षमता जोड़ी. मूक परीक्षण लॉन्च का शुरुआती पूर्वाभ्यास बन गया. इससे न केवल यह पता चला कि सिस्टम कितना ट्रैफ़िक स्वीकार कर सकता है, बल्कि यह भी कि हम विफलता का कितनी जल्दी पता लगाकर उसे सीमित कर सकते हैं और उससे उबर सकते हैं.

GPT‑Live को ChatGPT के पैमाने तक पहुँचाने के लिए एक मूल सिद्धांत पर आधारित बिल्कुल नया सिस्टम बनाना पड़ा: आवाज़ का प्रवाह जारी रहना चाहिए. स्ट्रीमिंग इन्फ़रेंस फ़ुल-डुप्लेक्स मॉडल को लगातार ऑडियो देता रहता है. एक समर्पित मीडिया पाथ फ़्रेम की भरोसेमंद डिलीवरी सुनिश्चित करता है. असिंक्रोनस कार्य-सौंपने से गहन चिंतन समानांतर रूप से चलता है. अनुकूलित परिवहन उपयोगकर्ता तक पूरे अनुभव को तत्पर बनाए रखता है.

GPT‑Live के पीछे की संरचना पहले ही रीयलटाइम संवाद के लिए एक व्यापक प्लेटफ़ॉर्म बन रही है. बातचीत से एजेंट-आधारित समन्वय तक विस्तार करते ChatGPT वॉइस को यही शक्ति देता है और आगामी GPT‑Live API का आधार भी यही होगा. समय के साथ, इससे वॉइस अनुभव अधिक डिवाइस, ऐप और माध्यमों तक फैल सकेंगे, जबकि वॉइस बातचीत को सजीव बनाने वाली तात्कालिकता बनी रहेगी.

अगर आप ऐसी ही इंजीनियरिंग समस्याएँ हल करना चाहते हैं, तो हमारे साथ काम करें⁠.