ఆరు నెలల్లో వేగంగా స్పందించే వాయిస్ 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 సంభాషణ 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 ప్యాకెట్‌తో సెషన్‌ను ప్రారంభించగలదు. సర్వర్ వెంటనే స్పందించగలదు. దీంతో మిగతా సిస్టమ్ వినియోగదారుకు నిజంగా ముఖ్యమైన వినడం, ప్రతిస్పందించడం అనే పనిని ప్రారంభించగలదు.

ఒక సిస్టమ్ కాగితంపై వేగంగా కనిపించినా, వాస్తవ వాయిస్ ట్రాఫిక్‌లో నిలిచిపోవచ్చు. GPT‑Liveను వినియోగదారులతో మాట్లాడనివ్వడానికి ముందు, ప్రొడక్షన్ ChatGPT వాయిస్ సెషన్‌లలో కొద్దిగా మొదలై క్రమంగా పెరిగే వాటాను ప్రస్తుత అడ్వాన్స్డ్ వాయిస్ మోడ్ అనుభవానికి, మా కొత్త సిస్టమ్‌కు రెండింటికీ మళ్లిస్తూ నిశ్శబ్ద పరీక్ష నిర్వహించాం. అడ్వాన్స్డ్ వాయిస్ మోడ్ యథావిధిగా వినియోగదారులకు సేవలందిస్తుండగా, షాడో మార్గం రీడ్-ఓన్లీ మోడ్‌లో ఇన్‌ఫరెన్స్‌ను అమలు చేసింది. వినియోగదారులకు వినిపించేది మార్చకుండానే, ఇది సిస్టమ్‌ను వాస్తవ క్లయింట్లు, నెట్‌వర్క్‌లు, సెషన్ నిడివులు, భౌగోళిక పంపిణీకి గురిచేసింది.

సామర్థ్యాన్ని కేవలం GPU థ్రూపుట్‌గా చూడలేమనేది మాకు తొలుత తెలిసిన పాఠాల్లో ఒకటి. వాయిస్ సెషన్‌లు తెరిచే ఉండి నిరంతరం ఫ్రేమ్‌లను పంపుతాయి. కాబట్టి ఇన్‌ఫరెన్స్‌తోపాటు CPU వైపు స్ట్రీమ్ హ్యాండ్లర్లు, క్యూలు, నెట్‌వర్క్ మార్గాలు కూడా తగినంతగా విస్తరించాలి. వాస్తవ లోడ్‌లో, మా లోడ్ పరీక్ష అంచనాలకంటే ముందే ఒక సహాయక భాగం పూర్తి సామర్థ్యానికి చేరడంతో ఇన్‌ఫరెన్స్ అభ్యర్థనలు పేరుకుపోయి, లేటెన్సీ మరింత పెరిగింది. సామర్థ్యానికి సంబంధించిన ప్రశ్నను “ఒక GPU ఎన్ని అభ్యర్థనలను నిర్వహించగలదు?” నుంచి “ప్రతి ఫ్రేమ్‌ను సమయానికి ఉంచుతూ సిస్టమ్ ఏకకాలంలో ఎన్ని సెషన్‌లను కొనసాగించగలదు?”గా మార్చాం.

ఈ పరీక్ష భౌగోళిక స్థానాన్ని కూడా అత్యంత ముఖ్యమైన అంశంగా మార్చింది. సెషన్‌ను దూర ప్రాంత సామర్థ్యానికి మళ్లిస్తే ప్రారంభం, స్ట్రీమింగ్ సమయంలో అనేక దశల్లో ఆలస్యం పెరగవచ్చు. మోడల్ విడుదలలను ప్రాంతీయ సామర్థ్యం, ట్రాఫిక్ మళ్లింపు కాన్ఫిగరేషన్‌తో కలిపి ధ్రువీకరించడం ప్రారంభించాం. ఆపై మూల భౌగోళిక ప్రాంతం ఆధారంగా లేటెన్సీని విడదీసి పరిశీలించాం. ఇన్‌ఫరెన్స్‌ను వినియోగదారులకు దగ్గరగా తరలించడం ఉపయోగపడింది. అయితే సమగ్ర స్పందన వేగం మోడల్ సర్వర్‌పైనే కాకుండా మార్గంలోని ప్రతి సేవపైనా ఆధారపడుతుందనే విస్తృత పాఠాన్ని ఇది మరింత బలపరిచింది.

మరికొన్ని వైఫల్యాలు వాస్తవిక సెషన్ జీవితచక్రాల్లో మాత్రమే బయటపడ్డాయి. దీర్ఘకాలం నడిచే సెషన్‌లు మెమరీ, పర్సిస్టెన్స్‌పై ఒత్తిడిని బయటపెట్టాయి. మళ్లీ కనెక్ట్ కావడం కాంపాక్షన్, స్థితి పునరుద్ధరణలను పరీక్షించింది. సాధారణ క్లయింట్ డిస్‌కనెక్షన్‌లు షట్‌డౌన్ హ్యాండ్‌షేక్‌లోని రేస్ కండిషన్‌లను బయటపెట్టాయి. ఈ సమస్యలు సమయం, పేరుకుపోయిన స్థితి, సేవల సరిహద్దులు దాటిన ప్రవర్తనపై ఆధారపడటం వల్ల చిన్న లోడ్ పరీక్షల్లో అరుదుగా కనిపించాయి.

చివరగా, ప్రొడక్షన్ పరీక్ష మా పర్యవేక్షణ సామర్థ్యాన్ని, విడుదల నియంత్రణలను మెరుగుపరచాల్సిన అవసరాన్ని కలిగించింది. వేర్వేరు లేటెన్సీ మూలాలను కలిపేసే మెట్రిక్‌లు, సమగ్ర గణాంకాల వల్ల సమస్యాత్మక ఇంజిన్‌లు కనిపించకుండా పోయే డ్యాష్‌బోర్డ్‌లు, పరీక్షించిన సిస్టమ్‌లకు అమలు చేసిన సిస్టమ్‌లకు మధ్య కాన్ఫిగరేషన్ వ్యత్యాసాలను గుర్తించాం. దీనికి ప్రతిస్పందనగా మరింత సూక్ష్మమైన టెలిమెట్రీ, సరిగ్గా పనిచేస్తాయని తెలిసిన కాన్ఫిగరేషన్‌లతో ధ్రువీకరణ, దశలవారీ పెంపు, విడివిడి మార్గాలను వేగంగా వేరుచేసే లేదా నిలిపివేసే సామర్థ్యాన్ని జోడించాం. ఈ నిశ్శబ్ద పరీక్ష ముందస్తు ప్రారంభ రిహార్సల్‌గా మారింది. సిస్టమ్ ఎంత ట్రాఫిక్‌ను స్వీకరించగలదనే దానికే కాకుండా, వైఫల్యాన్ని ఎంత వేగంగా గుర్తించి, అదుపుచేసి, దాని నుంచి కోలుకోగలమనే దానికీ ఇది పరీక్షగా నిలిచింది.

GPT‑Liveను ChatGPT స్థాయికి తీసుకురావడానికి ఒక మౌలిక సూత్రం చుట్టూ నిర్మించిన పూర్తిగా కొత్త సిస్టమ్ అవసరమైంది: వాయిస్ ప్రవాహం ఆగకూడదు. స్ట్రీమింగ్ ఇన్‌ఫరెన్స్ ఫుల్-డ్యూప్లెక్స్ మోడల్‌కు నిరంతరం ఆడియోను అందిస్తుంది. ప్రత్యేక మీడియా మార్గం ఫ్రేమ్‌ల విశ్వసనీయ డెలివరీని నిర్ధారిస్తుంది. అసింక్రోనస్ డెలిగేషన్ మరింత లోతైన ఆలోచనను సమాంతరంగా కొనసాగనిస్తుంది. ఆప్టిమైజ్ చేసిన రవాణా వినియోగదారు వరకు అనుభవం వేగంగా స్పందించేలా ఉంచుతుంది.

GPT‑Live వెనుక ఉన్న ఆర్కిటెక్చర్ ఇప్పటికే రియల్‌టైమ్ పరస్పర చర్యలకు విస్తృత ప్లాట్‌ఫారమ్‌గా మారుతోంది. ChatGPT వాయిస్ సంభాషణ నుంచి ఏజెంట్ ఆధారిత సమన్వయానికి విస్తరిస్తుండగా దీనికి ఇదే శక్తినిస్తోంది. త్వరలో రానున్న GPT‑Live APIకి కూడా ఇదే పునాది కానుంది. కాలక్రమంలో, వాయిస్ సంభాషణను ప్రత్యక్షంగా అనిపించే తక్షణత్వాన్ని కోల్పోకుండా మరిన్ని పరికరాలు, యాప్‌లు, మోడాలిటీలకు వాయిస్ అనుభవాలను విస్తరించేందుకు ఇది వీలు కల్పిస్తుంది.

మీరు ఇలాంటి ఇంజినీరింగ్ సమస్యలను పరిష్కరించాలనుకుంటే, మాతో కలిసి పనిచేయండి⁠.