વૉઇસ 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 ની ક્ષમતા તેને ઘણી શક્તિ આપે છે અને “વાત કરવાનું” વધુ ઊંડા “વિચારવાથી” અસરકારક રીતે અલગ કરે છે. પરંતુ બે મોડલના આ આર્કિટેક્ચરને એક જ સિસ્ટમ જેવું અનુભવાય તે માટે એન્જિનિયરિંગની બે સંબંધિત સમસ્યાઓ ઉકેલવી પડી.
સઘન કાર્ય માટે કામગીરીની સોંપણી
GPT-Live ઝડપી, સ્વાભાવિક પ્રતિસાદો પ્રદાન કરે છે, જ્યારે GPT-5.5 બેકગ્રાઉન્ડમાં સર્ચનું કામ સંભાળે છે
પહેલું, ચાલુ સંવાદમાં ઉપયોગી બને એટલા ઝડપથી પરિણામો પાછાં આવવા જરૂરી છે, તેથી રૂટિંગ અને પ્રોમ્પ્ટ પ્રોસેસિંગથી લઈને ઇન્ફરન્સ તથા ટૂલ કૉલ સુધીના સમગ્ર સોંપણી પાથમાં વિલંબ ઘટાડવો પડ્યો. સાથે જ, પ્રોડક્ટમાં અન્યત્ર આવેલી સિસ્ટમોને હજુ પણ અલગ સંદેશાની જરૂર હોય છે, તેથી ચાલુ વાતચીતને તેઓ સમજી શકે એવા સ્વરૂપમાં અમારે રજૂ કરવી પડી.
સોંપણી મોકલાય ત્યારે અત્યાધુનિક મોડલ વાતચીત માટે ઉપયોગી કંઈક આપે ત્યાં સુધીનો સમય ઘટાડવા અમે ઑપ્ટિમાઇઝ કરીએ છીએ. અત્યાધુનિક મોડલ રિઝનિંગ કરે અથવા ટૂલ વાપરે ત્યારે વૉઇસ મોડલ થોડા સમય માટે સંવાદ ચાલુ રાખી શકે છે, પરંતુ અત્યંત ધીમા પ્રતિભાવને છુપાવી શકતું નથી. તેથી અમે રૂટિંગ, પ્રોમ્પ્ટ પ્રોસેસિંગ, ઇન્ફરન્સ અને ટૂલ કૉલ સહિત સમગ્ર સોંપણી લૂપને પ્રતિભાવશીલતા માટે ઉપલબ્ધ સમયનો ભાગ ગણ્યો.
પહેલું ઑપ્ટિમાઇઝેશન સોંપણીની વિનંતી થાય તે પહેલાં અત્યાધુનિક મોડલ અને તેને જરૂરી કોઈપણ ટૂલ તૈયાર કરવાનું છે. વૉઇસ સેશન શરૂ થાય ત્યારે ઍપ્લિકેશન સર્વર અત્યાધુનિક મોડલ માટે ઇન્ફરન્સ સેશન બનાવે છે અને તેમાં વાતચીતનો પ્રારંભિક સંદર્ભ પ્રીફિલ કરે છે. આથી પહેલી સોંપેલી વિનંતી પહેલાં પ્રોમ્પ્ટ સંપૂર્ણપણે પ્રોસેસ થઈ જાય છે.
પછી અમે વોઇસ કન્વર્સેશન્સ ચાલે ત્યાં સુધી એ ઇન્ફરન્સ સેશન ઉપલબ્ધ રાખીએ છીએ અને અનુગામી વિનંતીઓ માટે સ્થિર સેશન એફિનિટી વાપરીએ છીએ. પ્રોમ્પ્ટ કૅશિંગ સાથે આ તકનીકો વિલંબ સુધારે છે અને સાથે વર્કરની ખામીમાંથી સરળતાથી પુનઃસ્થાપિત થવાની ક્ષમતા જાળવે છે.
રિઝનિંગ માટેનો પ્રયત્ન, આઉટપુટ મર્યાદા, ટૂલ સ્કીમા અને મોડલ તથા ટૂલ વચ્ચેનું આવનજાવન પણ વાતચીતને ઉપયોગી પરિણામ ક્યારે મળે તેના પર અસર કરે છે. વધુ ઝડપી પ્રતિભાવો માટે અમે આ પરિબળોને ગોઠવ્યાં છે. સોંપણી પાથ પર જરૂરી કામ ઘટાડીને અમે વૉઇસ મોડલને અમારાં અત્યાધુનિક મોડલનાં પરિણામો ઝડપથી સામેલ કરવા સક્ષમ બનાવ્યું.
વૉઇસ મોડલ વાણીના સતત પ્રવાહ પર કામ કરતું હોવા છતાં તેની આસપાસની ઘણી સિસ્ટમો હજુ વપરાશકર્તા અને સહાયકના વારાઓ પર કામ કરે છે. તેમાં ChatGPTનું વાતચીત ઇન્ટરફેસ તથા અમારા વિશ્લેષણ અને સુરક્ષા ઇન્ફ્રાસ્ટ્રક્ચરના કેટલાક ભાગો સામેલ છે. તેથી ઍપ્લિકેશન સર્વર એકબીજા પર ચઢતી અને ક્યારેક અસ્પષ્ટ વાતચીતને અલગ સંદેશામાં વહેંચે છે.
ઑડિયો આવતો જાય તેમ સર્વર આંશિક લિપ્યંતરણ અને સમયસંકેતો વડે કોણ બોલી રહ્યું છે તે નક્કી કરે છે અને સંદેશાની કતાર બનાવે છે. સૌથી નવો સંદેશ કામચલાઉ રહે છે. વધુ વાણી આવે તેમ તેનું લખાણ, સમય અને વક્તાની ઓળખ, બધું બદલાઈ શકે છે. વક્તા પૂરતો લાંબો સમય બોલે અને ઓળખ વિશ્વસનીય બને પછી સર્વર સંબંધિત સંદેશને અંતિમ સ્વરૂપ આપે છે.
વક્તાઓ એકસાથે બોલે ત્યારે આ વધુ જટિલ બને છે. વપરાશકર્તા બોલતો હોય ત્યારે સહાયકની ટૂંકી સ્વીકૃતિ, (જેમ કે “હં હં” કે “ઠીક છે”), જરૂરી નથી કે અલગ સંદેશ બને. જોકે, સહાયકનો સાર્થક હસ્તક્ષેપ ઘણી વાર અલગ સંદેશ બનવો જોઈએ. તે જ રીતે, વપરાશકર્તા વચ્ચે બોલે ત્યારે પણ અમે દર્શાવાતા સહાયકના પ્રતિભાવોની સુસંગતતાને પ્રાથમિકતા આપીએ છીએ.
દરેક વિભાજન નીતિ તાજગી અને નિશ્ચિતતા વચ્ચે સમાધાન કરે છે. બહુ વહેલું નક્કી કરવાથી ઇતિહાસ વિખંડિત થાય અને ક્રમ અસ્થિર બને છે. બહુ રાહ જોવાથી લિપ્યંતરણ અને તેના પર આધારિત સુવિધાઓ મોડાં પડે છે. તેથી સિસ્ટમ વાતચીતનાં બે સંબંધિત દૃશ્યો જાળવે છે: વર્તમાન સ્થિતિનું અંદાજિત દૃશ્ય અને જે કહેવાયું તેનો અધિકૃત રેકોર્ડ. ઍપ્લિકેશન ઇન્ટરફેસમાં વાતચીતનું દૃશ્ય અપડેટ સંભાળી શકે છે, તેથી તે અંદાજિત દૃશ્ય વાપરે છે. પરંતુ વિશ્લેષણ પાઇપલાઇનમાં નોંધ કરવા માટે અંતિમ લિપ્યંતરણ જરૂરી છે.
આનાથી લાઇવ વૉઇસ પાથ પર વારાફરતી બોલવાની મર્યાદા લાદ્યા વિના બાકીના ChatGPTને સંવાદનું સ્થિર દૃશ્ય મળે છે.
વપરાશકર્તા બટન પર ક્લિક કરે ત્યારથી જ પ્રતિભાવશીલતા શરૂ થાય છે. GPT‑Live માં વાતચીત શરૂ થાય તે પહેલાં સિસ્ટમે મીડિયા પાથ સ્થાપિત કરીને મોડલમાં ઑડિયો આપવાનું શરૂ કરવું પડે છે. આથી શરૂઆતના ક્રમનો દરેક ભાગ નિર્ણાયક પાથ પર આવે છે.
ઉપર જણાવ્યા મુજબ WebRTC મજબૂત રિયલટાઇમ પાયો આપે છે, પરંતુ સામાન્ય WebRTC સેશન શરૂ કરવા આશ્ચર્યજનક રીતે ઘણા પ્રોટોકૉલ હૅન્ડશેક અને નેટવર્ક રાઉન્ડ ટ્રિપ જરૂરી છે. QUIC જેવા પછીના પ્રોટોકૉલને આકાર આપનારા રાઉન્ડ ટ્રિપ ઘટાડવાના અભિગમ પહેલાં WebRTC બન્યું હતું. પરિણામે, સાથે વપરાય ત્યારે તેના અંતર્ગત પ્રોટોકૉલ ક્યારેક એક જ કામ ફરી કરે છે. દાખલા તરીકે, સંપૂર્ણ WebRTC સ્ટૅકના સંદર્ભમાં જરૂર ન હોય ત્યારે પણ દરેક પ્રોટોકૉલમાં પોતાની 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 પરિમાણો વહેંચવા માટે થતો સિગ્નલિંગ સંવાદ. આ સંવાદને નિર્ણાયક પાથમાંથી દૂર કરવા અમે ઇન્સ્ટન્ટ કનેક્ટ નામની પદ્ધતિ વિકસાવી. તે સર્વરની ક્ષમતા અનામત રાખ્યા વિના અને હાલના WebRTC અમલીકરણોમાં કોઈ ફેરફાર કર્યા વિના આ પરિમાણોની અગાઉથી વાટાઘાટ કરે છે.
ઇન્સ્ટન્ટ કનેક્ટ પ્રમાણભૂત સિગ્નલિંગ પ્રવાહની સાથે ચાલે છે. અગાઉથી નક્કી કરેલા પરિમાણો માન્ય હોય તો પહેલું મીડિયા પૅકેટ આવતાં જ સર્વર સેશન સાકાર કરી શકે છે. તે જૂના કે અમાન્ય હોય તો સિગ્નલિંગ પ્રવાહ પહેલેથી ચાલુ હોય છે, તેથી ક્લાયન્ટ કોઈ વધારાના વિલંબ વિના વૈકલ્પિક પદ્ધતિ અપનાવી શકે છે.
ઇન્સ્ટન્ટ કનેક્ટ અને WARP સાથે મળીને વપરાશકર્તાના ઇરાદાથી લાઇવ મીડિયા પ્રવાહ શરૂ થવા સુધીનો સમય નોંધપાત્ર રીતે ઘટાડે છે. SDP સંવાદ નિર્ણાયક પાથની બહાર હોવાથી અને WARP ટ્રાન્સપોર્ટ હૅન્ડશેકને સંક્ષિપ્ત કરતું હોવાથી ક્લાયન્ટ હવે એક જ UDP પૅકેટથી સેશન શરૂ કરી શકે છે. સર્વર તરત પ્રતિભાવ આપી શકે છે, જેથી બાકીની સિસ્ટમ વપરાશકર્તાને ખરેખર મહત્વના કામ, એટલે કે સાંભળવા અને જવાબ આપવાનું, શરૂ કરી શકે છે.
કાગળ પર સિસ્ટમ ઝડપી લાગી શકે છે, છતાં વાસ્તવિક વૉઇસ ટ્રાફિકમાં અટકી શકે છે. GPT‑Live ને વપરાશકર્તાઓ સાથે વાત કરવા દેતાં પહેલાં, અમે એક નિઃશબ્દ પરીક્ષણ કર્યું. તેમાં પ્રોડક્શનનો ChatGPT વૉઇસ સેશનોનો નાનો અને ધીમે ધીમે વધતો હિસ્સો હાલના એડવાન્સ્ડ વૉઇસ મોડના અનુભવ તથા અમારી નવી સિસ્ટમ, બંને તરફ મોકલ્યો. એડવાન્સ્ડ વૉઇસ મોડ વપરાશકર્તાઓને રાબેતા મુજબ સેવા આપતો રહ્યો, જ્યારે શૅડો પાથમાં ફક્ત વાંચી શકાય તેવા મોડમાં ઇન્ફરન્સ ચાલતું રહ્યું. આ રીતે વપરાશકર્તાઓ જે સાંભળતા હતા તેમાં ફેરફાર કર્યા વિના સિસ્ટમ વાસ્તવિક ક્લાયન્ટ, નેટવર્ક, સેશનની અવધિ અને ભૌગોલિક વિતરણના સંપર્કમાં આવી.
શરૂઆતમાં શીખવા મળેલી બાબતોમાંથી એક એ હતી કે ક્ષમતાને માત્ર GPU થ્રૂપુટના આધારે માપી શકાય નહીં. વૉઇસ સેશનો ખુલ્લા રહે છે અને સતત ફ્રેમ મોકલે છે, તેથી CPU તરફના સ્ટ્રીમ હૅન્ડલર, કતારો અને નેટવર્ક પાથ પણ ઇન્ફરન્સની સાથે વિસ્તરી શકે તે જરૂરી છે. વાસ્તવિક લોડ હેઠળ એક સહાયક ઘટક અમારા લોડ પરીક્ષણના અંદાજ કરતાં વહેલો તેની મર્યાદાએ પહોંચ્યો. પરિણામે ઇન્ફરન્સ વિનંતીઓ એકઠી થઈ અને વિલંબ વધતો ગયો. અમે ક્ષમતા અંગેનો પ્રશ્ન “એક GPU કેટલી વિનંતીઓ સંભાળી શકે?”માંથી બદલીને “દરેક ફ્રેમને સમયસર રાખીને સિસ્ટમ એકસાથે કેટલા સેશનો ચલાવી શકે?” કર્યો.
આ પરીક્ષણે ભૌગોલિક સ્થાનને પણ મુખ્ય મુદ્દો બનાવ્યો. સેશનને દૂરની ક્ષમતા તરફ મોકલવાથી શરૂઆત અને સ્ટ્રીમિંગ દરમિયાન અનેક તબક્કે વિલંબ વધી શકે છે. અમે મોડલ રોલઆઉટને પ્રાદેશિક ક્ષમતા અને ટ્રાફિક-નિર્દેશનના કન્ફિગરેશન સાથે ચકાસવાનું શરૂ કર્યું અને પછી સ્રોતના ભૌગોલિક સ્થાન પ્રમાણે વિલંબનું વિશ્લેષણ કર્યું. ઇન્ફરન્સને વપરાશકર્તાઓની નજીક લાવવાથી મદદ મળી, પણ તેનાથી એક વ્યાપક પાઠ પણ સ્પષ્ટ થયો: શરૂઆતથી અંત સુધીની પ્રતિભાવશીલતા માત્ર મોડલ સર્વર પર નહીં, પાથમાંની દરેક સેવા પર આધારિત છે.
બીજી ખામીઓ માત્ર સેશનના વાસ્તવિક જીવનચક્ર દરમિયાન જ દેખાઈ. લાંબા સમય સુધી ચાલતા સેશનોએ મેમરી અને નિરંતરતા પરનું દબાણ ઉજાગર કર્યું. ફરી જોડાવાની પ્રક્રિયાએ કૉમ્પેક્શન અને સ્થિતિ પુનઃસ્થાપનની કસોટી કરી. ક્લાયન્ટના સામાન્ય ડિસ્કનેક્શનથી શટડાઉન હૅન્ડશેકમાં રહેલી રેસ સ્થિતિ સામે આવી. ટૂંકા લોડ પરીક્ષણોમાં આ સમસ્યાઓ ભાગ્યે જ દેખાતી, કારણ કે તે સમય, સંચિત સ્થિતિ અને સેવાઓની સીમાઓ પારના વર્તન પર આધારિત હતી.
છેવટે, પ્રોડક્શન પરીક્ષણે અમને અવલોકનક્ષમતા અને રોલઆઉટ નિયંત્રણો સુધારવા મજબૂર કર્યા. અમને એવા મેટ્રિક્સ મળ્યા જે વિલંબના જુદા સ્રોતોને એકમાં ભેળવતા હતા, એવા ડૅશબોર્ડ મળ્યા જેમના એકંદર આંકડા અલગ-અલગ અસ્વસ્થ એન્જિનને છુપાવતા હતા અને પરીક્ષણ કરેલી તથા તૈનાત સિસ્ટમો વચ્ચે કન્ફિગરેશનનો તફાવત પણ મળ્યો. તેના પ્રતિભાવમાં અમે વધુ સૂક્ષ્મ ટેલિમેટ્રી, વિશ્વસનીય હોવાનું જાણીતું હોય એવા કન્ફિગરેશન સામે ચકાસણી, તબક્કાવાર વધારો અને અલગ-અલગ પાથને ઝડપથી અલાયદા કરવાની કે નિષ્ક્રિય કરવાની ક્ષમતા ઉમેર્યાં. આ નિઃશબ્દ પરીક્ષણ શરૂઆતનું લોન્ચ રિહર્સલ બન્યું. તેમાં માત્ર સિસ્ટમ કેટલો ટ્રાફિક સ્વીકારી શકે તેની નહીં, પણ અમે કેટલી ઝડપથી ખામી શોધી શકીએ, કાબૂમાં લઈ શકીએ અને તેમાંથી પુનઃસ્થાપિત થઈ શકીએ તેની પણ કસોટી થઈ.
GPT‑Live ને ChatGPTના સ્તર સુધી વિસ્તૃત કરવા માટે એક મૂળભૂત સિદ્ધાંત પર આધારિત સાવ નવી સિસ્ટમ જરૂરી હતી: વૉઇસનો પ્રવાહ ચાલુ રહેવો જોઈએ. સ્ટ્રીમિંગ ઇન્ફરન્સ ફુલ-ડુપ્લેક્સ મોડલને સતત ઑડિયો પૂરું પાડે છે. સમર્પિત મીડિયા પાથ ફ્રેમની વિશ્વસનીય ડિલિવરી સુનિશ્ચિત કરે છે. અસિંક્રોનસ સોંપણીથી વધુ ઊંડું વિચારકાર્ય સમાંતરે ચાલી શકે છે. સુધારેલું ટ્રાન્સપોર્ટ વપરાશકર્તા સુધી સમગ્ર અનુભવને પ્રતિભાવશીલ રાખે છે.
GPT‑Live પાછળનું આર્કિટેક્ચર રિયલટાઇમ સંવાદ માટે વધુ વ્યાપક પ્લેટફોર્મ બની રહ્યું છે. ChatGPT વૉઇસ વાતચીતથી આગળ વધીને એજન્ટ આધારિત સંકલન સુધી વિસ્તરે છે ત્યારે આ આર્કિટેક્ચર તેને શક્તિ આપે છે અને આગામી GPT‑Live APIનો પાયો પણ બનશે. સમય જતાં તે વૉઇસ અનુભવોને વધુ ઉપકરણો, ઍપ અને માધ્યમોમાં વિસ્તરવા દેશે, છતાં વોઇસ કન્વર્સેશન્સને જીવંત બનાવતી તાત્કાલિકતા જળવાઈ રહેશે.
જો તમે આવા એન્જિનિયરિંગ પડકારો ઉકેલવા માંગતા હોવ, તો અમારી સાથે કામ કરો.
