सहा महिन्यांत प्रतिसादक्षम व्हॉइस 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 अंमलबजावणीऐवजी आम्ही मीडिया फ्रंटएंड आणि इन्फरन्स लॉजिक ChatGPT Go मध्ये लिहिला. यामुळे फ्रेम डिलिव्हरीमधील सुरळीतपणा लक्षणीयरीत्या सुधारला. नव्या प्रणालीचे p95 आधीच्या प्रणालीच्या p50 इतके झाले.

WebRTC वाहतुकीचा पाया पुरवते. हे कमी-विलंब असलेल्या माध्यमांसाठी तयार केले आहे, आणि पॅकेट लॉस, क्लॉक ड्रिफ्ट व क्लायंट कनेक्शनमधील बदलांमधूनही ते कार्यरत राहू शकते. जर पॅकेट्स उशिरा आले, तर WebRTC ऑडिओमध्ये खंड पडू नये म्हणून त्याला हळुवारपणे ताणू शकते, आणि नंतर रिअल टाइममध्ये परत येण्यासाठी प्लेबॅकचा वेग क्षणभर वाढवू शकते.

संपूर्ण प्रणालीतील बफरिंग आणि अडथळे कमीत कमी करून आम्ही संभाषणात अपेक्षित असलेला एका सेकंदापेक्षा कमी प्रतिसादवेग देऊ शकतो.

स्टेटफुल इन्फरन्सचे स्वतःचे कार्यात्मक तोटे आहेत. एक व्हॉइस सेशन दीर्घकाळ सक्रिय राहू शकते, परंतु त्याचा संदर्भ सतत वाढत राहतो आणि मागणीनुसार मॉडेल इन्स्टन्स सुरू आणि बंद होत राहतात.

या समस्यांचे निराकरण करण्यासाठी, आम्ही मॉडेल इन्स्टन्समध्ये एक अखंड हस्तांतरण यंत्रणा तयार केली आहे. जेव्हा संक्रमणाची आवश्यकता असते, तेव्हा आम्ही विद्यमान मॉडेल इन्स्टन्ससोबतच एक पर्यायी मॉडेल इन्स्टन्स तयार ठेवू शकतो, त्यात सध्याचा सेशन कॉन्टेक्स्ट आधीच भरू शकतो, दोघांवर समांतरपणे इन्फरन्स चालवू शकतो आणि नवीन इन्स्टन्स पूर्णपणे तयार झाल्यावर हस्तांतरण करू शकतो.

हीच मूलभूत यंत्रणा गतिशील संदर्भ कॉम्पॅक्शनलाही समर्थ करते. संभाषण पुढे जात असताना त्याचा जमा झालेला संदर्भ अखेरीस मॉडेलच्या संदर्भ मर्यादेपलीकडे जाऊ शकतो. कॉम्पॅक्शन संदर्भाचा आकार मर्यादेत बसवू शकते, पण या प्रक्रियेला वेळ लागतो. ते मागील संदर्भ बदलत असल्याने मॉडेलचा की-व्हॅल्यू (KV) कॅशेही अवैध होतो. या कॅशेमध्ये आधी प्रक्रिया केलेल्या टोकनच्या अटेंशन की आणि व्हॅल्यू साठवल्या जातात. ती स्थिती पुन्हा तयार करण्यासाठी नव्याने प्रिफील करावे लागते, ज्यामुळे आणखी विलंब होतो.

त्याऐवजी, आम्ही कॉम्पॅक्शनला आणखी एक व्यवस्थापित संक्रमण मानतो. मूळ मॉडेल उदाहरण संभाषण सुरू ठेवत असताना प्रणाली संदर्भाचे कॉम्पॅक्शन करते आणि नव्या संदर्भासह बदली मॉडेल उदाहरण तयार करते. ते उदाहरण तयार झाल्यावर आम्ही मीडियात कोणताही खंड न पडता त्याकडे वळू शकतो. यामुळे प्रणाली गरजेनुसार कॉम्पॅक्शन करत दीर्घकाळ चालणाऱ्या कॉलना समर्थन देऊ शकते.

महत्त्वाची कामे लाइव्ह पाथवर होत नाहीत, त्यामुळे हस्तांतरणाच्या वेळीसुद्धा संभाषणात कोणताही व्यत्यय येत नाही.

GPT‑Live ची विद्यमान अत्याधुनिक मॉडेल्सचा वापर करण्याची क्षमता त्याला प्रचंड सामर्थ्य देते, ज्यामुळे “संवाद” आणि सखोल “थिंकिंग” हे प्रभावीपणे वेगळे होतात. परंतु, या दोन-मॉडेल आर्किटेक्चरला एका प्रणालीसारखे वाटावे यासाठी दोन संबंधित अभियांत्रिकी समस्या सोडवणे आवश्यक होते.

सर्वप्रथम, चालू असलेल्या देवाणघेवाणीत उपयुक्त ठरण्यासाठी परिणाम पुरेशा वेगाने परत मिळणे आवश्यक होते, त्यामुळे आम्हाला राउटिंग आणि प्रॉम्प्ट प्रोसेसिंगपासून ते इन्फरन्स आणि टूल कॉल्सपर्यंतच्या संपूर्ण डेलीगेशन मार्गावरील विलंब कमी करावा लागला. त्याच वेळी, उत्पादनातील इतर सिस्टीम्सना स्वतंत्र संदेशांची आवश्यकता असते, म्हणून आम्हाला चालू असलेला संवाद त्यांना समजू शकेल अशा स्वरूपात सादर करावा लागला.

जेव्हा एखादे डेलिगेशन पाठवले जाते, तेव्हा अत्याधुनिक मॉडेल संभाषणासाठी काहीतरी उपयुक्त निर्माण करेपर्यंत लागणाऱ्या वेळेसाठी आम्ही ऑप्टिमाइझ करतो. अत्याधुनिक मॉडेल तर्क करत असताना किंवा टूल्सचा वापर करत असताना व्हॉइस मॉडेल थोडक्यात देवाणघेवाण चालू ठेवू शकते, परंतु ते अनियंत्रितपणे मंद प्रतिसाद लपवू शकत नाही. त्यामुळे आम्ही संपूर्ण डेलिगेशन लूपचे—रूटिंग, प्रॉम्प्ट प्रोसेसिंग, इन्फरन्स आणि टूल कॉल्स—यांना प्रतिसादक्षमतेच्या अंदाजपत्रकाचा भाग मानले.

पहिले ऑप्टिमायझेशन म्हणजे डेलीगेशनची विनंती करण्यापूर्वी अत्याधुनिक मॉडेल आणि त्याला आवश्यक असलेली कोणतीही टूल्स सेट करणे. जेव्हा व्हॉइस सेशन सुरू होते, तेव्हा ॲप्लिकेशन सर्व्हर अत्याधुनिक मॉडेलसाठी एक इन्फरन्स सेशन तयार करतो आणि त्यात सुरुवातीचा संभाषण संदर्भ आधीच भरतो, जेणेकरून पहिल्या डेलीगेटेड विनंतीपूर्वी प्रॉम्प्टवर पूर्णपणे प्रक्रिया झाली आहे याची खात्री होते.

त्यानंतर आम्ही ते इन्फरन्स सेशन व्हॉइस कन्वर्सेशन्सच्या कालावधीसाठी उपलब्ध ठेवतो आणि पुढील विनंत्यांसाठी स्टेबल सेशन ॲफिनिटीचा वापर करतो. प्रॉम्प्ट कॅशिंगसह, ही तंत्रे विलंब सुधारतात, तसेच वर्करच्या चुका सहजपणे दुरुस्त करता येतो.

रीझनिंगचा प्रयत्न, आउटपुट मर्यादा, टूलच्या स्कीमा आणि मॉडेल-टूल फेऱ्यांचाही संभाषणाला उपयुक्त निकाल कधी मिळतो यावर परिणाम होतो. जलद प्रतिसादांसाठी आम्ही हे घटक समायोजित केले. डेलिगेशन मार्गावरील आवश्यक काम कमीत कमी करून आम्ही व्हॉइस मॉडेलला आमच्या अत्याधुनिक मॉडेलचे निकाल वेगाने समाविष्ट करणे शक्य केले.

जरी व्हॉइस मॉडेल भाषणाच्या अखंड प्रवाहावर चालत असले तरी, त्याच्याशी संबंधित अनेक प्रणाली अजूनही वापरकर्ता आणि सहाय्यकाच्या टर्ननुसार चालतात, ज्यात ChatGPT चा संभाषण UI आणि आमच्या विश्लेषण व सुरक्षा पायाभूत सुविधांचे काही भाग समाविष्ट आहेत. त्यामुळे ॲप्लिकेशन सर्व्हर एकमेकांत मिसळलेल्या, कधीकधी संदिग्ध संभाषणाचे स्वतंत्र संदेशांमध्ये विभाजन करतो.

ऑडिओ येत असताना कोणता वक्ता बोलत आहे हे ठरवण्यासाठी सर्व्हर अपूर्ण ट्रान्सक्रिप्ट आणि वेळेचे संकेत वापरतो व संदेशांची रांग तयार करतो. सर्वांत नवा संदेश तात्पुरता राहतो. अधिक भाषण येत असताना त्याचा मजकूर, वेळ आणि वक्त्याची नेमणूक हे सर्व बदलू शकते. वक्त्याने विश्वासार्ह ओळख पटण्याइतका वेळ बोलणे सुरू ठेवल्यावर सर्व्हर संबंधित संदेश अंतिम करतो.

स्पीकर ओव्हरलॅपमुळे हे अधिक गुंतागुंतीचे होते. वापरकर्ता बोलत असताना असिस्टंटकडून आलेली एखादी छोटीशी पोचपावती (उदा. “हम्म,” किंवा “ठीक आहे”) हा एक स्वतंत्र संदेश बनणे आवश्यक नाही. तथापि, असिस्टंटने मध्येच केलेला एखादा महत्त्वपूर्ण उद्गार अनेकदा तसा बनला पाहिजे. त्याचप्रमाणे, वापरकर्ता मध्येच बोलत असला तरीही, आम्ही असिस्टंटच्या दर्शवलेल्या प्रतिसादांमधील सुसंगततेला प्राधान्य देतो.

प्रत्येक सेगमेंटेशन पॉलिसी निश्चिततेसाठी ताजेपणाचा त्याग करते. खूप लवकर निश्चिती केल्यास विखंडित इतिहास आणि अस्थिर क्रमवारी निर्माण होते; खूप जास्त वेळ थांबल्यास ट्रान्सक्रिप्ट्स आणि त्यावर अवलंबून असलेल्या फीचर्सना विलंब होतो. त्यामुळे, सिस्टम संभाषणाचे दोन संबंधित व्ह्यूज सांभाळते: सध्याच्या स्थितीचा एक अनुमानित व्ह्यू आणि काय बोलले गेले याची एक अधिकृत नोंद. ॲप्लिकेशन UI मधील संभाषण व्ह्यू अपडेट्स हाताळू शकतो, म्हणून तो अनुमानित व्ह्यू वापरतो. परंतु ॲनालिटिक्स पाइपलाइनमध्ये लॉगिंग करण्यासाठी अंतिम ट्रान्सक्रिप्टची आवश्यकता असते.

यामुळे लाइव्ह व्हॉइस मार्गावर पाळी-पाळीने बोलण्याचे बंधन न लादता उर्वरित ChatGPT ला संवादाचे स्थिर रूप मिळते.

वापरकर्त्याने बटण क्लिक करताच प्रतिसाद सुरू होतो. GPT‑Live मध्ये, संभाषण सुरू होण्यापूर्वी सिस्टमला मीडिया मार्ग स्थापित करावा लागतो आणि मॉडेलमधून ऑडिओ पाठवणे सुरू करावे लागते. त्यामुळे स्टार्टअप सिक्वेन्सचा प्रत्येक भाग अत्यंत महत्त्वाचा ठरतो.

वर नमूद केल्याप्रमाणे, WebRTC रिअलटाइमसाठी मजबूत पाया पुरवते. पण सामान्य WebRTC सत्र सुरू करण्यासाठी आश्चर्यकारक संख्येने प्रोटोकॉल हँडशेक आणि नेटवर्क फेऱ्या कराव्या लागतात. QUIC सारख्या नंतरच्या प्रोटोकॉलना आकार देणाऱ्या नेटवर्क फेऱ्या कमी करण्याच्या उद्दिष्टापूर्वी WebRTC विकसित झाले होते. त्यामुळे त्याचे मूलभूत प्रोटोकॉल एकत्र वापरल्यावर कधीकधी एकच काम पुन्हा करतात. उदाहरणार्थ, संपूर्ण WebRTC स्टॅकच्या संदर्भात गरज नसतानाही प्रत्येक प्रोटोकॉलमध्ये स्वतःची DoS-विरोधी यंत्रणा होती.

आम्ही या संचाचे विश्लेषण करून WebRTC संक्षिप्त फेरी प्रोटोकॉल (WARP⁠(नवीन विंडोमध्ये उघडेल)) विकसित केला. तो मीडिया आणि डेटाचा प्रारंभ सहा नेटवर्क फेऱ्यांवरून केवळ एका फेरीवर आणतो. WARP मागील आवृत्त्यांशी सुसंगत असलेल्या प्रोटोकॉल सुधारणांच्या संचाने हे साध्य करते: ICE वर DTLS हँडशेक जोडणे (SPED⁠(नवीन विंडोमध्ये उघडेल)), अधिक वेगवान DTLS 1.3⁠(नवीन विंडोमध्ये उघडेल) हँडशेक वापरणे, SCTP हँडशेकची पूर्ववाटाघाटी करणे (SNAP⁠(नवीन विंडोमध्ये उघडेल)) आणि DCEP⁠(नवीन विंडोमध्ये उघडेल) वापरण्याऐवजी डेटा चॅनेलची पूर्ववाटाघाटी करणे.

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

मीडिया हँडशेक व ऑप्टिमाइझ केल्यानंतर एक उरलेला विलंब ठळकपणे दिसला: WebRTC जोडण्यापूर्वी SDP मापदंड सामायिक करण्यासाठी वापरली जाणारी सिग्नलिंग देवाणघेवाण. ही देवाणघेवाण निर्णायक मार्गावरून काढण्यासाठी आम्ही इन्स्टंट कनेक्ट असे नाव दिलेली पद्धत विकसित केली. ती सर्व्हर क्षमता राखीव न ठेवता आणि विद्यमान WebRTC अंमलबजावण्यांमध्ये बदल न करता या मापदंडांवर आधीच वाटाघाटी करते.

इन्स्टंट कनेक्ट मानक सिग्नलिंग प्रवाहाबरोबरच चालते. जर पूर्व-वाटाघाटी केलेले पॅरामीटर्स वैध असतील, तर पहिले मीडिया पॅकेट आल्यावर सर्व्हर सेशन कार्यान्वित करू शकतो. जर ते कालबाह्य किंवा अवैध असतील, तर सिग्नलिंग प्रवाह आधीच सुरू झालेला असतो, त्यामुळे क्लायंट कोणत्याही अतिरिक्त विलंबाशिवाय मूळ स्थितीत परत येऊ शकतो.

इन्स्टंट कनेक्ट आणि WARP एकत्रितपणे वापरकर्त्याच्या उद्देशापासून थेट मीडिया प्रवाहापर्यंतचा वेळ मोठ्या प्रमाणात कमी करतात. SDP देवाणघेवाण निर्णायक मार्गाबाहेर गेल्यामुळे आणि WARP ने वहन हँडशेक संक्षिप्त केल्यामुळे क्लायंट आता एका UDP पॅकेटने सत्र सुरू करू शकतो. सर्व्हर तत्काळ प्रतिसाद देऊ शकतो, त्यामुळे उर्वरित प्रणाली वापरकर्त्याला खरोखर महत्त्वाचे असलेले ऐकण्याचे आणि प्रतिसाद देण्याचे काम सुरू करू शकते.

एखादी प्रणाली कागदावर वेगवान दिसत असली तरी प्रत्यक्ष व्हॉइस ट्रॅफिकच्या वेळी अडखळू शकते. GPTLive ला वापरकर्त्यांशी चॅट करण्याची परवानगी देण्यापूर्वी, आम्ही एक गुप्त चाचणी घेतली. या चाचणीत, प्रोडक्शनमधील ChatGPT व्हॉइस सेशन्सचा एक छोटा, हळूहळू वाढणारा वाटा सध्याच्या प्रगत व्हॉइस मोड अनुभवाकडे आणि आमच्या नवीन प्रणालीकडे, अशा दोन्हीकडे वळवण्यात आला. प्रगत व्हॉइस मोड नेहमीप्रमाणे वापरकर्त्यांना सेवा देत राहिला, तर शॅडो पाथने रीड-ओन्ली मोडमध्ये इन्फरन्स चालवला. यामुळे वापरकर्त्यांना ऐकू येणाऱ्या आवाजात कोणताही बदल न करता, प्रणाली प्रत्यक्ष क्लायंट्स, नेटवर्क्स, सेशनचा कालावधी आणि भौगोलिक वितरणाच्या संपर्कात आली.

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

या चाचणीमुळे भौगोलिक स्थानालाही सर्वोच्च प्राधान्य मिळाले. सेशनला दूरच्या क्षमतेकडे राउट केल्याने स्टार्टअप आणि स्ट्रीमिंग दरम्यान अनेक टप्प्यांवर विलंब होऊ शकतो. आम्ही प्रादेशिक क्षमता आणि ट्रॅफिक-स्टीअरिंग कॉन्फिगरेशनसह मॉडेल रोलआउट्सची पडताळणी करण्यास सुरुवात केली, आणि नंतर स्त्रोताच्या भौगोलिक स्थानानुसार विलंबाचे विश्लेषण केले. इन्फरन्सला वापरकर्त्यांच्या जवळ आणल्याने मदत झाली, पण त्यामुळे एक मोठी शिकवण अधिक दृढ केली: एंड-टू-एंड प्रतिसादक्षमता केवळ मॉडेल सर्व्हरवरच नव्हे, तर मार्गातील प्रत्येक सेवेवर अवलंबून असते.

इतर त्रुटी केवळ वास्तविक सेशनच्या जीवनचक्रातच दिसून आल्या. दीर्घकाळ चालणाऱ्या सेशन्समुळे मेमरी आणि पर्सिस्टन्सवरील दबाव उघड झाला. पुन्हा कनेक्ट केल्याने कॉम्पॅक्शन आणि स्टेट रिस्टोरेशनची प्रक्रिया पार पडली. सामान्य क्लायंट डिस्कनेक्टमुळे शटडाउन हँडशेकमधील रेसेस उघड झाल्या. या समस्या लहान लोड टेस्टमध्ये क्वचितच दिसून आल्या, कारण त्या वेळ, जमा झालेली स्थिती आणि सर्व्हिसच्या सीमांपलीकडील वर्तनावर अवलंबून होत्या.

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

GPT‑Live ला ChatGPT स्तरावर आणण्यासाठी एका संपूर्ण नवीन प्रणालीची आवश्यकता होती, जी एका मूलभूत तत्त्वावर आधारित होती: आवाज प्रवाहित झालाच पाहिजे. स्ट्रीमिंग इन्फरन्समुळे फुल-डुप्लेक्स मॉडेलला ऑडिओचा पुरवठा सतत होत राहतो. एक समर्पित मीडिया पाथ विश्वसनीय फ्रेम डिलिव्हरीची खात्री देतो. असिंक्रोनस डेलीगेशनमुळे सखोल विचार समांतरपणे चालू राहतो. ऑप्टिमाइझ्ड ट्रान्सपोर्टमुळे वापरकर्त्यापर्यंत पोहोचण्यापर्यंतचा अनुभव प्रतिसादात्मक राहतो.

GPT‑Live मागील रचना रिअलटाइम संवादासाठी आधीच अधिक व्यापक प्लॅटफॉर्म बनत आहे. ChatGPT व्हॉइस संभाषणापासून एजंट-सदृश समन्वयापर्यंत विस्तारत असताना ही रचना त्याला समर्थ करते आणि आगामी GPT‑Live API चा आधारही बनेल. कालांतराने, व्हॉइस कन्वर्सेशन्स जिवंत वाटण्यामागील तत्काळपणा न गमावता ती व्हॉइस अनुभवांना अधिक डिव्हाइसेस, ॲप्स आणि माध्यमप्रकारांपर्यंत विस्तारू देईल.

तुम्हाला अशाच प्रकारच्या अभियांत्रिकी समस्या सोडवायच्या असतील, तर आमच्यासोबत काम करा⁠.