OpenAI बड़े पैमाने पर low-latency voice AI कैसे उपलब्ध कराता है

 (openai.com)
3 पॉइंट द्वारा GN⁺ 7 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenAI ने 90 करोड़ से अधिक साप्ताहिक सक्रिय उपयोगकर्ताओं को प्राकृतिक voice conversation देने के लिए standard WebRTC behavior को बनाए रखते हुए internal packet routing को relay + transceiver संरचना में फिर से डिज़ाइन किया
  • WebRTC, ICE, DTLS/SRTP, codec negotiation, RTCP quality control, echo cancellation और jitter buffering को standardize करता है, इसलिए यह browser·mobile app·server के बीच low-latency continuous audio stream प्रोसेसिंग के लिए उपयुक्त है
  • OpenAI के ज़्यादातर session ऐसे 1:1 session हैं जिनमें 1 उपयोगकर्ता और 1 मॉडल, या 1 application और 1 real-time agent बातचीत करते हैं, इसलिए multi-party call के लिए बने SFU की तुलना में transceiver मॉडल latency और scalability के लिए अधिक उपयुक्त था
  • Kubernetes में session per 1 UDP port expose करने वाला WebRTC मॉडल बड़े public port range, load balancer configuration, health check, firewall policy और rollout safety को जटिल बनाता था, इसलिए छोटी और fixed UDP surface की ज़रूरत थी
  • relay, पहले STUN packet के ICE ufrag में मौजूद routing hint से owner transceiver को ढूँढकर packet forward करता है, और transceiver ICE·DTLS·SRTP·session lifecycle को own करके standard WebRTC compatibility और दुनिया भर में पास के ingress path, दोनों को बनाए रखता है

low-latency voice AI की आवश्यकताएँ

  • voice AI तब प्राकृतिक लगता है जब बातचीत बोलने की गति से चलती है, और network latency awkward silence, कटे हुए interruption, और interruption पर देर से प्रतिक्रिया के रूप में तुरंत दिखाई देती है
  • OpenAI के scale पर 90 करोड़ से अधिक साप्ताहिक सक्रिय उपयोगकर्ताओं के लिए global reachability, session शुरू होते ही बोल पाने लायक fast connection setup, कम और stable media round-trip time, कम jitter और packet loss की ज़रूरत होती है
  • ChatGPT voice, Realtime API, conversational workflow के agents, और वे सभी model जिन्हें उपयोगकर्ता के बोलते समय audio प्रोसेस करना होता है, इस latency profile से प्रभावित होते हैं
  • OpenAI ने client के standard WebRTC behavior को बनाए रखते हुए internal packet routing बदलने के लिए WebRTC stack को relay + transceiver separation structure में फिर से डिज़ाइन किया

WebRTC क्यों चुना गया

  • WebRTC, browser, mobile app और server के बीच low-latency audio·video·data भेजने के लिए एक open standard है, और client-server real-time system की foundation के रूप में भी उपयुक्त है
  • WebRTC, ICE के माध्यम से connection setup और NAT traversal, DTLS/SRTP encrypted transport, codec negotiation, RTCP quality control, और echo cancellation व jitter buffering जैसी client capabilities को standardize करता है
  • WebRTC के बिना, हर client को NAT environment में connection establish करना, media encryption, codec negotiation, और network change handling अलग से हल करना पड़ता
  • AI product में एक महत्वपूर्ण गुण यह है कि audio continuous stream के रूप में आता है, इसलिए पूरे user upload के खत्म होने का इंतज़ार किए बिना transcription, inference, tool calling और speech generation शुरू की जा सकती है
  • यही अंतर यह तय करता है कि कोई system conversational महसूस होगा या push-to-talk जैसा
  • OpenAI ने mature open source implementations और standards work वाले WebRTC ecosystem पर निर्माण किया, और Justin Uberti तथा Sean DuBois के foundational work की वजह से low-level transport, encryption और congestion control को फिर से बनाए बिना verified media infrastructure पर build कर सका

SFU की जगह transceiver चुनने वाली संरचना

  • जब SFU सही होता है

    • SFU एक media server है जो हर participant के WebRTC stream को लेकर उसे दूसरे participant तक चुनिंदा रूप से forward करता है
    • SFU मॉडल में हर participant के लिए अलग WebRTC connection terminate किया जाता है, और AI भी session में एक और participant के रूप में जुड़ता है
    • group call, classroom, और collaborative meeting जैसे मूल रूप से multi-party product के लिए SFU उपयुक्त हो सकता है
    • audio codec, RTCP message, data channel, recording, और per-stream policy को एक ही जगह रखा जा सकता है
    • client-to-AI product में भी signal processing, media routing, recording, observability, और आगे चलकर human handoff या participant जोड़ने जैसे विस्तार को एक ही system में reuse किया जा सकता है, इसलिए यह अक्सर default starting point बनता है

  • OpenAI का workload

    • OpenAI के ज़्यादातर session 1:1 session हैं, जिनमें 1 उपयोगकर्ता और 1 मॉडल, या 1 application और 1 real-time agent बातचीत करते हैं
    • traffic का यह रूप हर turn की latency के प्रति संवेदनशील है, इसलिए transceiver मॉडल चुना गया
    • transceiver मॉडल में WebRTC edge service client connection terminate करने के बाद media और event को model inference, transcription, speech generation, tool usage और orchestration के लिए simple internal protocol में बदल देती है
    • transceiver ही एकमात्र service है जो ICE connectivity check, DTLS handshake, SRTP encryption key, और session lifecycle सहित WebRTC session state को own करती है
    • session state को एक जगह रखने से session ownership समझना आसान होता है, और backend service को WebRTC peer की तरह नहीं बल्कि सामान्य service की तरह scale किया जा सकता है

शुरुआती implementation और Kubernetes में सामने आई सीमाएँ

  • OpenAI का पहला implementation Pion आधारित एक single Go service था, जो signaling और media termination दोनों संभालता था
  • यह transceiver service ChatGPT voice, Realtime API के WebRTC endpoint, और कई research project को चलाती थी
  • operational स्तर पर transceiver, signaling में SDP negotiation, codec selection, ICE credential, और session setup संभालता था
  • media में यह downstream WebRTC connection terminate करता था, और inference व orchestration के लिए backend service के साथ upstream connection बनाए रखता था
  • OpenAI इस service को Kubernetes पर चलाना चाहता था, जहाँ demand के अनुसार इसे scale up/down किया जा सके और hosts के बीच move कराया जा सके
  • पुराना session per 1 port WebRTC मॉडल Kubernetes environment के साथ फिट नहीं बैठता था, क्योंकि बड़े public UDP port range को expose, secure और maintain करना पड़ता था
  • high concurrency पर session per 1 port का मतलब था बहुत बड़ा UDP port range expose और manage करना
  • cloud load balancer और Kubernetes service, प्रति service दसियों हज़ार public UDP port को ध्यान में रखकर डिज़ाइन नहीं किए गए हैं, और port range बढ़ने पर load balancer config, health check, firewall policy और rollout safety जटिल हो जाते हैं
  • बड़ा UDP port range externally reachable surface बढ़ाता है और network policy audit को कठिन बनाता है, इसलिए security के लिए भी यह प्रतिकूल है
  • Kubernetes में pod लगातार जोड़े, हटाए और reschedule किए जाते हैं, इसलिए अगर हर pod को बड़ा और stable port range reserve व advertise करना पड़े तो elasticity कमज़ोर हो जाती है

single port और session ownership की समस्या

  • कई WebRTC system port count की समस्या कम करने के लिए प्रति server single UDP port और application-level demultiplexing का उपयोग करते हैं
  • प्रति server single port design port count कम करता है, लेकिन पूरे fleet में हर session की ownership बनाए रखने की दूसरी समस्या पैदा करता है
  • ICE और DTLS stateful protocol हैं, इसलिए जिस process ने session बनाया है उसी को उस session के packet लगातार मिलने चाहिए, ताकि वह connectivity check validate कर सके, DTLS handshake पूरा कर सके, SRTP decrypt कर सके, और ICE restart जैसे बाद के session change संभाल सके
  • अगर उसी session के packet किसी दूसरे process तक पहुँच जाएँ, तो setup fail हो सकता है या media टूट सकता है
  • OpenAI का लक्ष्य था public internet पर सिर्फ छोटी और fixed UDP surface expose करना, और साथ ही हर packet को उस transceiver तक route करना जो संबंधित WebRTC session को own करता है

  • जिन approaches पर विचार किया गया

    • session-wise unique IP:port direct client-server media path देता है और data path में forwarding layer नहीं होती, लेकिन इसके लिए session per 1 public UDP port चाहिए, और बड़ा port range Kubernetes·cloud load balancer·security के लिए उपयुक्त नहीं है
    • server-wise unique IP:port session-wise exposure की तुलना में public UDP footprint को बहुत छोटा करता है और एक shared socket कई session को demultiplex कर सकती है, लेकिन shared load-balancing fleet में पहला packet गलत instance तक पहुँच सकता है, इसलिए packet को deterministic रूप से owner process तक भेजने की विधि चाहिए
    • TURN relay में client को सिर्फ TURN relay address और port तक पहुँचना होता है, और edge पर policy centralized की जा सकती है, लेकिन TURN allocation setup round-trip बढ़ाता है और TURN server के बीच allocation move या recovery अभी भी कठिन रहती है
    • stateless forwarder + stateful terminator वाली OpenAI की relay + transceiver संरचना छोटी public UDP footprint बनाए रखती है और transceiver पूरे WebRTC session को own करता है, लेकिन media के owner transceiver तक पहुँचने से पहले एक forwarding hop बढ़ जाता है और relay व transceiver के बीच custom coordination की ज़रूरत होती है

relay + transceiver architecture

  • OpenAI द्वारा deploy की गई संरचना packet routing और protocol termination को अलग करती है
  • signaling, session setup के लिए transceiver तक पहुँचती है, जबकि media पहले relay में आती है
  • relay, छोटी public footprint वाली एक lightweight UDP forwarding layer है, और transceiver उसके पीछे मौजूद stateful WebRTC endpoint है
  • relay media को decrypt नहीं करता, ICE state machine नहीं चलाता, और codec negotiation में भाग नहीं लेता
  • relay केवल उतना packet metadata पढ़ता है जितना destination चुनने के लिए पर्याप्त हो, और packet को session-owning transceiver तक forward कर देता है
  • transceiver अब भी normal WebRTC flow देखता है और पूरी protocol state को own करता है
  • client के नज़रिए से WebRTC session नहीं बदलता

पहले packet की routing और ICE ufrag का उपयोग

  • इस संरचना का core यह है कि relay packet path के भीतर ही पहले client packet को route करता है
  • WebRTC session में पहले से एक protocol-native routing hook होता है, और वही ICE username fragment, यानी ufrag है
  • ufrag एक छोटा identifier है जो session setup के दौरान exchange होता है और STUN connectivity check में फिर से carry किया जाता है
  • OpenAI server-side ufrag को इस तरह generate करता है कि relay उससे destination cluster और owner transceiver का अनुमान लगाने लायक routing metadata निकाल सके
  • signaling के दौरान transceiver session state allocate करता है और SDP answer में shared relay VIP और UDP port लौटाता है
  • VIP relay fleet के आगे का virtual IP address है, जो port के साथ मिलकर कई relay instance के पीछे भी client को 203.0.113.10:3478 जैसा एक single stable destination देता है
  • client का पहला media-path packet आमतौर पर STUN binding request होता है, और ICE इसका उपयोग यह verify करने के लिए करता है कि advertised address तक packet पहुँच सकती है या नहीं
  • relay पहले STUN packet से server ufrag पढ़ता है, routing hint decode करता है, और packet को session-owning transceiver तक forward करने भर के लिए ही parse करता है
  • हर transceiver session per one socket की जगह एक shared UDP socket पर receive करता है, जो internal IP:port से बँधा हुआ operating system endpoint होता है
  • relay जब client source IP:port से transceiver destination तक session बना देता है, तो उसके बाद DTLS, RTP और RTCP packet उसी session के भीतर flow करते हैं और ufrag को दोबारा decode करने की ज़रूरत नहीं पड़ती
  • relay का session न्यूनतम state के साथ रखा जाता है, जिसमें packet forwarding के लिए in-memory session, monitoring counter, और session expiry व cleanup के लिए timer शामिल होते हैं
  • relay restart होकर session खो भी दे, तो अगला STUN packet ufrag routing hint के ज़रिए session को फिर से बना देता है
  • path स्थापित हो जाने के बाद Redis cache <client IP + Port, transceiver IP + Port> mapping को रखती है, जिससे अगला STUN packet आने से पहले भी जल्दी recovery संभव होती है

Global Relay और नज़दीकी ingress path

  • public UDP surface को छोटी और stable address·port count तक सीमित करने के बाद, OpenAI इसी relay pattern को दुनिया भर में deploy कर सका
  • Global Relay भौगोलिक रूप से वितरित relay ingress point fleet है, जो वही packet-forwarding behavior implement करती है
  • व्यापक geographic ingress से user packet को पहले public internet पर दूर के region तक जाने की ज़रूरत नहीं पड़ती, बल्कि वे geography और network topology के हिसाब से पास के relay से OpenAI network में प्रवेश करते हैं, जिससे पहला client-to-OpenAI hop छोटा होता है
  • यह approach traffic के backbone तक पहुँचने से पहले होने वाली latency, jitter और avoidable loss burst को कम करती है
  • OpenAI signaling में Cloudflare geo और proximity steering का उपयोग करता है, ताकि शुरुआती HTTP या WebSocket request पास के transceiver cluster तक पहुँचे
  • request context, session location और client को advertise किए जाने वाले Global Relay ingress point को तय करता है
  • SDP answer, Global Relay address देता है, और ufrag में इतनी जानकारी होती है कि Global Relay media को निर्दिष्ट cluster तक route कर सके और relay उसे destination transceiver तक पहुँचा सके
  • geo-steered signaling और Global Relay को साथ उपयोग करने से setup और media दोनों को पास के entry path पर रखा जाता है, जबकि session एक ही transceiver पर pinned रहता है
  • यह संरचना signaling और पहले ICE connectivity check के round-trip time को कम करती है, जिससे उपयोगकर्ता को बोलना शुरू करने से पहले कम इंतज़ार करना पड़ता है

relay implementation कैसे किया गया

  • relay service Go में लिखी गई और जानबूझकर इसकी implementation scope को सीमित रखा गया
  • Linux पर kernel networking stack network interface से UDP packet लेकर socket तक पहुँचाता है, और relay userspace में चलने वाली सामान्य Go process के रूप में socket से packet header पढ़ता है
  • relay थोड़ा flow state update करता है और WebRTC terminate किए बिना packet forward कर देता है
  • OpenAI ने userspace process द्वारा network queue को सीधे poll करने वाले kernel-bypass framework का उपयोग नहीं किया, क्योंकि उसके अनुसार इससे operational complexity बढ़ सकती थी

  • मुख्य design choices

    • protocol termination नहीं: relay सिर्फ STUN header और ufrag parse करता है, और उसके बाद DTLS, RTP, RTCP के लिए cached state का उपयोग कर packet को opaque बनाए रखता है
    • क्षणिक state: flow state और observability के लिए client address से transceiver destination तक जाने वाला छोटा, short-timeout वाला in-memory map रखा जाता है
    • horizontal scalability: कई relay instance load balancer के पीछे parallel चलते हैं, और क्योंकि relay state hard WebRTC state नहीं है, restart के समय traffic drop कम और flow recovery तेज़ रहती है

  • efficiency measures

    • SO_REUSEPORT एक Linux socket option है जो कई relay worker को एक ही machine पर एक ही UDP port से bind करने देता है, और kernel incoming packet को workers में बाँट देता है ताकि single read loop bottleneck से बचा जा सके
    • runtime.LockOSThread हर UDP-reading goroutine को किसी खास OS thread पर pin करता है
    • SO_REUSEPORT और thread pinning को साथ उपयोग करने पर एक ही flow के packet का उसी CPU core पर बने रहने का रुझान होता है, जिससे cache locality बेहतर होती है और context switching कम होती है
    • pre-allocated buffer और minimal copy, parsing व allocation overhead कम करते हैं और Go की garbage collection से बचने में मदद करते हैं
    • इस implementation ने अपेक्षाकृत छोटे relay footprint के साथ OpenAI के global real-time media traffic को संभाला, इसलिए OpenAI ने kernel bypass path चुनने के बजाय सरल design बनाए रखा

परिणाम और सीख

  • इस architecture ने हज़ारों UDP port expose किए बिना Kubernetes में WebRTC media चलाना संभव बनाया
  • छोटी और fixed UDP surface ने security और load balancing को आसान बनाया, और infrastructure को बड़े public port range reserve किए बिना scale करने दिया
  • इस design ने client के standard WebRTC behavior को संरक्षित रखा और पुष्टि की कि OpenAI workload में SFU-रहित design default रूप से उपयुक्त था
  • ज़्यादातर session point-to-point हैं, latency-sensitive हैं, और जब inference service को WebRTC peer की तरह काम नहीं करना पड़ता तो उसे scale करना आसान होता है
  • complexity को हर backend service या custom client behavior में फैलाने के बजाय एक पतली routing layer में रखना अधिक उपयुक्त था
  • protocol-native field में routing metadata encode करके deterministic first-packet routing, छोटी public UDP footprint, और दुनिया भर में उपयोगकर्ताओं के पास ingress रखने की flexibility हासिल हुई

  • विशेष रूप से महत्वपूर्ण विकल्प

    • edge पर protocol semantics को बनाए रखना: client standard WebRTC का ही उपयोग करता रहता है, इसलिए browser और mobile interoperability बनी रहती है
    • कठिन session state को एक जगह रखना: transceiver ICE, DTLS, SRTP, और session lifecycle को own करता है, जबकि relay सिर्फ packet forward करता है
    • setup में पहले से मौजूद जानकारी से routing: ICE ufrag hot-path lookup dependency के बिना first-packet routing hook देता है
    • kernel bypass से पहले common case optimization को प्राथमिकता: SO_REUSEPORT, thread pinning, और low-allocation parsing के साथ सावधानी से बनाई गई सीमित Go implementation OpenAI workload के लिए पर्याप्त थी
    • real-time voice AI तब काम करता है जब infrastructure latency को महसूस होने से रोक दे, और OpenAI ने client की WebRTC expectations बदले बिना WebRTC की deployment shape बदलने का रास्ता चुना

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 7 시간 전
Hacker News की राय

  • OpenAI ने मेरे काम वाली लाइब्रेरी Pion के use case को सामने रखा, इसके लिए बहुत आभार
    अगर आप WebRTC से परिचित नहीं हैं, तो यह काफ़ी दिलचस्प क्षेत्र है, और मैं इसके काम करने के तरीके को समझाने वाली किताब WebRTC for the Curious पर भी काम कर रहा हूँ
    https://github.com/pion/webrtc
    https://webrtcforthecurious.com

    • मैं Pion इस्तेमाल कर रहा हूँ। लेकिन मुझे जिज्ञासा है कि क्या OpenAI का यह approach सच में ज़रूरी था
      ऐसा लगा कि voice AI setup में जो हिस्सा पहले से ही तेज़ है, उसे और घटाने के लिए complexity बहुत बढ़ा दी गई। तेज़ models और सटीक voice activity detection (VAD), WebRTC transport time को बारीकी से tweak करने की तुलना में कहीं ज़्यादा महत्वपूर्ण लगते हैं
    • पूरी किताब ऑनलाइन डालने के लिए धन्यवाद
      पहले मैंने इसका कुछ हिस्सा इसलिए पढ़ा था क्योंकि WebRTC data channel के ज़रिए database से browser client तक CLI के माध्यम से data भेजने का एक विचार था, और इससे समझ आया कि यह मेरे use case के लिए सही नहीं होगा। आखिर में मैंने centralized control plane और WebSocket का इस्तेमाल किया
      फिर भी WebRTC data channel + zero-copy Apache Arrow ArrayBuffer + duckdb WASM के संयोजन से कुछ मज़ेदार किया जा सकता है, ऐसा लगता है, बस अभी तक क्या किया जाए यह समझ नहीं आया
    • थोड़ी अलग बात है, लेकिन मैं यह जानना चाहता हूँ कि पूरा codebase nested src folders की बजाय root directory में रखने की वजह क्या है
      इससे README तक पहुँचना काफ़ी मुश्किल हो जाता है

  • कम latency, implementation के लिहाज़ से फ़ायदे से ज़्यादा एक दर्द जैसी लगती है
    जब आप बस हल्की-फुल्की बातचीत करना चाहते हैं, तो इंसान स्वाभाविक रूप से थोड़ी देर रुकता है, लेकिन GPT उसे “बात ख़त्म हो गई” समझकर तुरंत बोलना शुरू कर देता है
    उम्र बढ़ने के साथ मुझे मनचाहा शब्द ढूँढने में ज़्यादा समय लगता है, और ऐसे तेज़ voice GPT मदद से ज़्यादा चिढ़ पैदा करते हैं। बोलने से पहले पूरे वाक्य को दिमाग़ में तैयार रखना पड़ता है, जो बिल्कुल स्वाभाविक नहीं है

    • यहाँ latency के दो अलग स्तर आपस में मिल रहे हैं
      लेख में जिस latency की बात है, वह audio stream की transport latency है, जबकि इस स्थिति वाली latency ज़्यादा इस बात के करीब है कि audio stream के भीतर response कितनी जल्दी शुरू होता है
    • मैंने भी यह झेला है और यह सच में बहुत परेशान करता है
      ऐसा दबाव बनता है कि सोच अभी पूरी नहीं हुई फिर भी बोलते रहना है, इसलिए यह काफ़ी अस्वाभाविक लगता है। अगर आप सही शब्द ढूँढ रहे हों, तो उसके लिए मौका मिलना चाहिए
      मेरे हिसाब से समाधान ज़्यादा latency वाला protocol नहीं, बल्कि pauses को ज़्यादा समझदारी से handle करना है। latency कम हो तो user के बीच में बोलने पर bot तुरंत चुप हो सकता है
    • voice conversations में मैं इसे कहता हूँ कि किसी खास code word के इस्तेमाल से पहले बिल्कुल जवाब न दे, या सिर्फ “ठीक है” कहे
      यह perfect नहीं है, लेकिन कम दखल देता है
    • यह लेख में बताई गई latency से ज़्यादा voice activity detection (VAD) से जुड़ी बात है
    • यह मुश्किल समस्या है। bot को लगातार बोलने से रोकने के लिए मैं अनजाने में filler expressions जोड़ने लगता हूँ
      और ऐसा भी लगता है कि इसकी ज़्यादातर बुद्धिमत्ता समस्या पर सोचने की बजाय विश्वसनीय सुनाई देने में खर्च होती है। जैसे, “हाँ, बिल्कुल। मैं समझता हूँ कि आप ऐसा क्यों चाहते हैं…”। शायद समय-सीमा होती है और voice processing ज़्यादा महँगी होती है। text responses असली काम पर ज़्यादा समय लगाते हैं

  • “साप्ताहिक सक्रिय उपयोगकर्ता 90 करोड़ से अधिक” से स्पष्टतः ChatGPT के कुल users की बात हो रही है, और उनमें से voice features इस्तेमाल करने वालों का अनुपात शायद काफ़ी छोटा होगा
    ऐसे आँकड़े इस तरह के व्यावसायिक फ़ैसलों को प्रभावित करते हैं कि समस्या पर hardware और software optimization कितना लगाया जाए

    • सही है। शायद इसलिए उन्होंने “reach” शब्द इस्तेमाल किया
      यानी feature को वास्तव में इस्तेमाल करने से अलग, उन सभी users की संख्या जो इसके संपर्क में आ सकते हैं

  • इसे साझा करना वाकई अच्छा है, लेकिन यह याद रखना चाहिए कि OpenAI के realtime audio models अभी भी क्षमता के लिहाज़ से 4o परिवार के स्तर पर ही हैं
    फिर भी वे काफ़ी उपयोगी हैं, और अफ़सोस की बात है कि इस क्षेत्र में कोई वास्तविक competitor नहीं है। वास्तविक बातचीत जैसा अनुभव, ideas और concepts को व्यक्त करने में बहुत मददगार रहा है
    यह ध्यान में रखने लायक है कि अब यह launch के समय जैसा frontier model नहीं रहा। अगर Sam यह देख रहे हों, तो उम्मीद है कि वे नया realtime audio model जारी करेंगे

    • OpenAI के realtime/voice mode में voice वाला हिस्सा शानदार है, लेकिन नवीनतम models की तुलना में यह काफ़ी कमज़ोर है और अक्सर वही बातें दोहराता है
      Google का Gemini flash live 3.1 बेहतर है, खासकर API के ज़रिए इस्तेमाल करने पर। इसमें tool calling भी है, और अगर आप खुद setup करें तो इसे दूसरे, ज़्यादा स्मार्ट LLMs से भी जोड़ा जा सकता है, साथ ही reasoning level भी सेट किया जा सकता है। ऊँचा reasoning level भी realtime के काफ़ी करीब रहता है, और Google Search के आधार पर जवाबों को बेहतर बनाया जा सकता है। अगर आपको two-way voice पसंद है, तो अभी शायद यह सबसे अच्छा विकल्प है, और आप इसे AI Studio में आज़मा सकते हैं

  • जो लोग इस क्षेत्र में आना चाहते हैं, उनके लिए pipecat एक अच्छा open source repository और community है
    https://github.com/pipecat-ai/pipecat

    • काश मुझे Pipecat के बारे में बहुत पहले पता चल गया होता
      मुझे इसका पता कुछ हफ़्ते पहले ही चला, और Gemma 4 के release के बाद से मैं Gemma 4 + Kokoro TTS + Whisper के साथ पूरी तरह local पर चलने वाला voice assistant शुरू से बना रहा हूँ: https://github.com/pncnmnp/strawberry
      Pipecat का smart turn model, voice activity detection (VAD) के लिए वाकई बहुत अच्छा है: https://huggingface.co/pipecat-ai/smart-turn-v3

  • अगर बेहतर models ज़्यादा सोचने के बाद जवाब देते हैं, तो response के लिए थोड़ा ज़्यादा इंतज़ार करना भी ठीक है
    बस उन्हें interruption को अच्छे से support करना चाहिए, 1 सेकंड रुकते ही जवाब देना शुरू नहीं कर देना चाहिए, और समझदारी से तय करना चाहिए कि मेरी बात सच में ख़त्म हुई या नहीं

  • यह सिर्फ latency की समस्या नहीं भी हो सकती
    अगर users को voice conversation में बनाए रखा जाए, तो ऐसा training data मिल सकता है जो text से कभी नहीं मिल सकता। इसलिए क्या उन्होंने SFU की जगह transceiver approach चुना और multi-party conversation को ज़्यादातर नज़रअंदाज़ करना उन्हें स्वीकार्य लगा?

  • क्या इसे इस तरह पढ़ना चाहिए कि OpenAI अब WebRTC/audio के लिए LiveKit का इस्तेमाल नहीं करता?

    • ऐसा ही लगता है
      इस architecture में LiveKit server शायद वैसा नहीं है जैसा वे चाहते थे। लेख में SFU पर चर्चा भी लगभग यही कहती है। हालाँकि client SDK में अभी भी काफ़ी उपयोगी चीज़ें हैं

  • अगर stream के दौरान transceiver crash हो जाए, तो active session कैसे recover होगा?
    क्या system नए WebRTC session में context को अपने-आप फिर से स्थापित करता है?

    • अभी तो नहीं, लेकिन इस तरह के तरीके से यह संभव है: https://github.com/pion/webrtc-zero-downtime-restart
      आप पूरा WebRTC state save या pause कर सकते हैं और फिर अगले process में उसे revive कर सकते हैं

  • अगर आप दोस्त बनाना चाहते हैं, तो किसी भी रूप में club या meetup में शामिल होना ज़्यादा बेहतर रहेगा