Paano kami bumuo ng realtime system para sa mabilis tumugon na voice AI sa loob ng anim na buwan

Para sa voice AI, mas mahirap kaysa inaakala ang malaman kung kailan magsasalita. Walang kahirap-hirap na nagpapalitan ang mga tao sa loob ng isang bahagi ng segundo, ngunit hindi makasabay sa ritmong ito ang mga dating voice AI system. Umasa ang turn-based na architecture ng mga ito sa maliliit na modelong tinatawag na turn detector, na may mahirap na gawain: masyadong maagang manghula at mapuputol ang user; masyadong huli at tila mabagal ang tugon. Makapagsisimula lamang ang mas malaking LLM pagkatapos magdesisyon ang detector.

Inaalis ng GPT‑Live⁠, ang aming ikatlong henerasyong voice system, ang turn detector mula sa audio path. Full-duplex ang voice model nito, ibig sabihin, maaari itong makinig at magsalita nang sabay. Inaalis nito ang pangangailangan sa hiwalay na detector at ginagawang mas agaran at natural ang pag-uusap. Kapag kailangan ng mas malalim na pangangatwiran o paggamit ng tool, maaari ring kumonsulta ang GPT‑Live sa aming mga frontier na modelo, gaya ng GPT‑5.5, nang hindi pinatitigil ang daloy ng pag-uusap. Dahil sa mga kakayahang ito, naibibigay ng GPT‑Live ang walang kapantay na kombinasyon ng mabilis na pagtugon sa usapan at intelligence.

Kinailangan ng bagong system architecture na na-optimize para sa mababang latency upang maibigay ang karanasang ito sa malaking scale. Hindi gaya ng karaniwang request-response inference, ini-stream ng aming system ang papasok na audio sa voice model at ang palabas na pagsasalita pabalik sa user, habang pinangangasiwaan ang delegasyon sa hiwalay na asynchronous path. Sa nakalipas na anim na buwan, binago namin ang inference ng modelo, pamamahala ng context, at media transport upang manatiling maayos ang daloy ng pagsasalita mula simula hanggang dulo.

Lumilikha rin ang architecture ng malinaw na hangganan sa pagitan ng pangunahing voice path at application logic. Dahil dito, madaling i-customize ang gawi ng application nang hindi naaapektuhan ang bilis ng pagtugon. Pinapagana ng pundasyong ito ang lumalawak na hanay ng mga kakayahan sa ChatGPT Voice, kabilang ang bagong kakayahang kontrolin ang iyong computer at i-coordinate ang iyong mga agent sa ChatGPT desktop app.

Sa post na ito, ipaliliwanag namin kung bakit hindi natugunan ng mga dating turn-based na system ang aming mga pangangailangan at kung paano namin binuo ang bagong system upang mabilis tumugon sa bawat layer. Tatalakayin namin ang stateful inference, dynamic na pamamahala ng context, asynchronous na delegasyon, at protocol-level optimization—na magkakasamang ginagawang tunay na live ang GPT‑Live.

Namana ng mga dating voice architecture ang turn-based na katangian ng mga text LLM, ngunit ang bawat turn ay kinakatawan bilang hiwalay na audio blob sa halip na teksto. Sa mga cascaded system, sunod-sunod na gumagana ang speech-to-text, LLM, at text-to-speech. Nagdagdag ng latency ang pagkakasunod-sunod na ito at binalewala ang mga pahiwatig gaya ng tono at bilis ng pagsasalita.

Pinahusay ng mga speech-to-speech na modelo ang paraang ito sa pamamagitan ng direktang pagproseso ng audio. Dahil sinanay ang modelo na likas na umunawa at bumuo ng pagsasalita, napanatili nito ang mga detalyeng nawawala sa transcription at nakatugon ito nang mas mabilis. Ngunit umaasa pa rin ang system sa turn detector upang magpasya kung kailan maaaring magsimula ang inference. Mas malaking bahagi ng interaksyon ang pinangasiwaan ng modelo, ngunit nanatiling turn-based ang interaksyon.

Ipinauubaya ng GPT‑Live sa voice model ang kontrol sa pag-uusap: dumadaloy ang audio papasok at palabas ng modelo, habang asynchronous na nangyayari ang mas malalim na pangangatwiran at paggamit ng tool. Pangunahing tungkulin ng system na panatilihin ang walang patid na media loop. Ang iba pang gawain, gaya ng paggamit ng mga frontier na modelo at pagpapanatili ng pag-uusap, ay nangyayari sa labas ng live path.

Hindi laging madaling panatilihing walang patid ang media loop na ito. Anumang delay sa transport, pagproseso, o inference ay maaaring maging naririnig na paghinto o artifact. Kaya ng dating turn-based na system ang kaunting pagkakaiba sa oras ng pagdating ng isang audio blob. Gayunman, kailangang maihatid ng live media system ang bawat audio frame sa tamang oras.

Nagbigay sa amin ng mahalagang pundasyon ang naunang trabaho sa ChatGPT Voice at Realtime API. Muli na naming binuo ang aming voice infrastructure⁠ upang direktang mag-stream ng audio at video papasok at palabas sa aming mga system nang may mas mababa at mas mahuhulaang latency. Pinalawak pa ng GPT‑Live ang disenyong iyon, na nag-stream ng media hanggang sa modelo sa pamamagitan ng bagong stateful inference system na binuo para sa tuloy-tuloy na pag-uusap.

Gayunman, bahagi lamang ng solusyon ang streaming inference. Para gumana ito nang maayos sa production, kinailangan din naming tiyakin ang maaasahang paghahatid ng audio mula client hanggang inference stack at tugunan ang mga hamon ng statefulness.

Isa sa mga una naming desisyon ang malinaw na paghihiwalay ng daloy ng media mula sa application at business logic. Dumadaloy ang audio sa pagitan ng client at voice model sa isang nakalaang mabilis na path. Nangyayari ang delegasyon, paggamit ng tool, at iba pang gawain ng application sa likod ng isang asynchronous RPC boundary. Maaaring maantala ng mabagal na tool call o backend service ang sarili nitong resulta, ngunit hindi nito mapatitigil ang daloy ng media.

Nagbibigay rin ang paghihiwalay na ito ng malinaw na hangganan para sa pag-customize ng system. Maaaring baguhin ng mga application ang kanilang mga tool, patakaran, at gawi ng backend nang hindi naaapektuhan ang media frontend na nagpapanatili sa daloy ng audio. Nananatiling maliit, mahuhulaan, at nakatuon ang live path sa gawaing kailangang mangyari nang realtime.

Isinulat namin sa Go ang media frontend at inference logic, na pumalit sa dating Python implementation ng asyncio. Malaki ang ibinuti ng kinis ng paghahatid ng frame: ang p95 ng bagong system ay kapantay ng p50 ng dating system.

WebRTC ang nagsisilbing pundasyon ng transport. Dinisenyo ito para sa low-latency na media at patuloy itong gumagana sa kabila ng packet loss, clock drift, at mga pagbabago sa koneksyon ng client. Kung huli ang dating ng mga packet, maaaring bahagyang pahabain ng WebRTC ang audio upang maiwasan ang mga puwang, saka saglit na pabilisin ang playback upang makahabol sa realtime.

Sa pagbawas ng buffering at blocking sa buong system, naibibigay namin ang sub-second na bilis ng pagtugon na inaasahan ng tao sa pag-uusap.

May sarili ring mga operational tradeoff ang stateful inference. Maaaring manatiling aktibo nang matagal ang isang voice session, ngunit patuloy na lumalaki ang context nito at nagsisimula o humihinto ang mga instance ng modelo ayon sa demand.

Upang tugunan ang mga ito, bumuo kami ng tuloy-tuloy na mekanismo ng handoff sa pagitan ng mga instance ng modelo. Kapag kailangan ang transition, maaari naming ihanda ang pamalit na instance ng modelo kasabay ng kasalukuyan, i-prefill ito gamit ang kasalukuyang context ng session, magpatakbo ng inference sa dalawa nang sabay, at lumipat kapag handang-handa na ang bagong instance.

Sinusuportahan din ng parehong pangunahing mekanismo ang dynamic context compaction. Habang nagpapatuloy ang pag-uusap, maaaring lumampas kalaunan ang naipong context nito sa context limit ng modelo. Maaaring paliitin ng compaction ang context upang magkasya sa limitasyon, ngunit nangangailangan ng oras ang prosesong ito. At dahil binabago nito ang dating context, pinapawalang-bisa rin nito ang key-value (KV) cache ng modelo, na nag-iimbak ng mga attention key at value mula sa mga token na naproseso na. Nangangailangan ng bagong prefill ang muling pagbuo sa state na iyon, kaya nagdaragdag ito ng delay.

Sa halip, itinuturing naming isa pang pinamamahalaang transition ang compaction. Habang patuloy na nakikipag-chat ang orihinal na instance ng modelo, kino-compact ng system ang context at naghahanda ng pamalit na instance ng modelo gamit ang bagong context. Kapag handa na ang instance na iyon, maaari kaming lumipat nang walang anumang pagkaantala sa media. Dahil dito, nasusuportahan ng system ang mga pangmatagalang tawag at nagsasagawa ng compaction kapag kailangan.

Nananatiling wala sa live path ang mabibigat na gawain, kaya kahit sa handoff ay hindi napuputol ang daloy ng pag-uusap.

Malaki ang naidudulot na kakayahan ng GPT‑Live na gumamit ng mga kasalukuyang frontier na modelo, dahil epektibo nitong pinaghihiwalay ang “pagsasalita” mula sa mas malalim na “pag-iisip.” Ngunit upang magmukhang iisang system ang architecture na ito na may dalawang modelo, kinailangang lutasin ang dalawang magkaugnay na problema sa engineering.

Una, kailangang bumalik agad ang mga resulta upang magamit sa nagpapatuloy na usapan, kaya kinailangan naming bawasan ang latency sa buong delegation path—mula pagruta at pagproseso ng prompt hanggang inference at mga tool call. Kasabay nito, kailangan pa rin ng ibang mga system sa produkto ang magkakahiwalay na mensahe, kaya kinailangan naming ilarawan ang nagpapatuloy na pag-uusap sa paraang nauunawaan nila.

Kapag ipinadala ang delegasyon, ino-optimize namin ang oras hanggang makagawa ang frontier na modelo ng isang bagay na kapaki-pakinabang sa pag-uusap. Maaaring panatilihin sandali ng voice model ang daloy ng usapan habang nangangatuwiran o gumagamit ng mga tool ang isang frontier na modelo, ngunit hindi nito maikukubli ang labis na bagal na tugon. Kaya itinuring naming bahagi ng nakalaang oras para sa pagtugon ang buong delegation loop—pagruta, pagproseso ng prompt, inference, at mga tool call.

Ang unang optimization ay ihanda ang frontier na modelo at anumang tool na kailangan nito bago hilingin ang delegasyon. Kapag nagsimula ang voice session, gumagawa ang application server ng inference session para sa frontier na modelo at pine-prefill ito gamit ang paunang context ng pag-uusap, upang lubos nang naproseso ang prompt bago ang unang naka-delegate na request.

Pagkatapos, pinananatili naming available ang inference session na iyon sa buong voice conversation at gumagamit kami ng stable session affinity para sa mga susunod na request. Kasama ng prompt caching, pinapabuti ng mga paraang ito ang latency habang nananatiling madaling makabawi mula sa failure ng worker.

Naaapektuhan din ng antas ng pangangatwiran, mga limitasyon sa output, tool schema, at mga round trip sa pagitan ng modelo at tool kung kailan makatatanggap ng kapaki-pakinabang na resulta ang pag-uusap, kaya inayos namin ang mga ito para sa mas mabilis na tugon. Sa pagbawas ng gawaing kailangan sa delegation path, mabilis na naisasama ng voice model ang mga resulta mula sa aming mga frontier na modelo.

Bagama't tuloy-tuloy na stream ng pagsasalita ang pinoproseso ng voice model, marami sa mga system sa paligid nito ang gumagamit pa rin ng mga turn ng user at assistant, kabilang ang conversation UI ng ChatGPT at ilang bahagi ng aming analytics at safety infrastructure. Kaya hinihiwa-hiwalay ng application server ang magkakapatong at kung minsan ay malabong pag-uusap upang maging magkakahiwalay na mensahe.

Habang dumarating ang audio, gumagamit ang server ng mga bahagyang transcript at timing signal upang matukoy kung sino ang nagsasalita at bumuo ng queue ng mga mensahe. Pansamantala pa ang pinakabagong mensahe; maaaring magbago ang teksto, timing, at pagtukoy sa nagsasalita habang may dumarating pang pagsasalita. Kapag sapat nang matagal na nagsalita ang isang speaker upang maging maaasahan ang pagtukoy, fina-finalize ng server ang kaukulang mensahe.

Mas nagiging kumplikado ito kapag nagsasapawan ang mga speaker. Ang maikling pagkilala ng assistant habang nagsasalita ang user (hal., “mm-hmm” o “okay”) ay hindi kailangang maging hiwalay na mensahe. Gayunman, kadalasang dapat maging hiwalay na mensahe ang isang makabuluhang pagsingit ng assistant. Gayundin, inuuna namin ang pagiging magkakaugnay ng ipinapakitang mga tugon ng assistant kahit magsalita ang user sa gitna.

Sa bawat patakaran sa segmentation, may kapalit ang pagiging bago at katiyakan. Kapag masyadong maagang nag-finalize, nagiging pira-piraso ang history at pabago-bago ang pagkakasunod-sunod; kapag masyadong matagal naghintay, naaantala ang mga transcript at feature na nakadepende rito. Kaya nagpapanatili ang system ng dalawang magkaugnay na view ng pag-uusap: isang pansamantalang view ng kasalukuyang state at isang opisyal na tala ng sinabi. Kayang humawak ng mga update ang conversation view sa UI ng application, kaya ginagamit nito ang pansamantalang view. Ngunit kailangan ng pinal na transcript para sa pag-log sa analytics pipeline.

Nagbibigay ito sa iba pang bahagi ng ChatGPT ng matatag na view ng usapan nang hindi ipinipilit ang salitan sa live voice path.

Nagsisimula ang mabilis na pagtugon sa sandaling i-click ng user ang button. Sa GPT‑Live, kailangang maitatag ng system ang media path at magsimulang magpasok ng audio sa modelo bago magsimula ang pag-uusap. Dahil dito, nasa critical path ang bawat bahagi ng startup sequence.

Gaya ng nabanggit sa itaas, nagbibigay ang WebRTC ng matibay na realtime na pundasyon, ngunit nakakagulat na maraming protocol handshake at network round trip ang kailangan upang magsimula ng karaniwang WebRTC session. Nauna ang WebRTC sa pagbibigay-diin sa pagbawas ng mga round trip na humubog sa mga sumunod na protocol gaya ng QUIC. Dahil dito, kung minsan ay inuulit ng mga underlying protocol nito ang trabaho kapag pinagsama-sama. Halimbawa, may sariling mekanismong anti-DoS ang bawat protocol, kahit hindi ito kailangan sa konteksto ng buong WebRTC stack.

Sinuri namin ang stack at binuo ang WebRTC Abridged Roundtrip Protocol (WARP⁠(magbubukas sa bagong window)), na nagpapababa sa startup ng media at data mula anim na network round trip tungo sa isa lamang. Nagagawa ito ng WARP sa pamamagitan ng mga backward-compatible na pagpapahusay sa protocol: pagsabay sa DTLS handshake sa ICE (SPED⁠(magbubukas sa bagong window)), paggamit ng mas mabilis na DTLS 1.3⁠(magbubukas sa bagong window) handshake, paunang pag-negotiate sa SCTP handshake (SNAP⁠(magbubukas sa bagong window)), at paunang pag-negotiate sa mga data channel sa halip na gumamit ng DCEP⁠(magbubukas sa bagong window).

Dinisenyo namin ang WARP bilang hanay ng mga bukas na specification, katuwang ang mga collaborator mula sa komunidad ng WebRTC, upang makinabang sa gawaing ito ang mas malawak na ecosystem. Isinusulong namin ang mga panukala sa TSVWG working group ng IETF, at naidagdag na ang suporta sa WARP sa libwebrtc at Pion, habang nagpapatuloy ang pagsisikap sa iba pang WebRTC implementation.

Matapos i-optimize ang media handshake, may isang natitirang delay na kapansin-pansin: ang signaling exchange na ginagamit upang ibahagi ang mga SDP parameter bago makakonekta ang WebRTC. Upang alisin ang exchange na iyon sa critical path, binuo namin ang tinatawag naming Instant Connect. Pauna nitong nine-negotiate ang mga parameter nang hindi nagrereserba ng kapasidad ng server at nang walang pagbabago sa mga kasalukuyang WebRTC implementation.

Gumagana ang Instant Connect kasabay ng karaniwang signaling flow. Kung valid ang mga paunang na-negotiate na parameter, mabubuo ng server ang session pagdating ng unang media packet. Kung luma o invalid ang mga ito, nagpapatuloy na ang signaling flow, kaya makababalik ang client sa karaniwang paraan nang walang dagdag na latency.

Kapag pinagsama, lubos na pinaiikli ng Instant Connect at WARP ang oras mula sa intensyon ng user hanggang sa live na daloy ng media. Dahil wala na sa critical path ang SDP exchange at pinaiikli ng WARP ang transport handshake, maaari na ngayong magsimula ang client ng session gamit ang iisang UDP packet. Makakatugon agad ang server, kaya makapagsisimula ang iba pang bahagi ng system sa gawaing talagang mahalaga sa user: makinig at tumugon.

Maaaring mukhang mabilis sa papel ang isang system ngunit tumigil kapag totoong voice traffic na ang hinahawakan nito. Bago namin hayaang makipag-chat ang GPT‑Live sa mga user, nagsagawa kami ng tahimik na pagsubok na nagruta ng maliit at unti-unting lumalaking bahagi ng mga production session ng ChatGPT Voice sa kasalukuyang Advanced na Voice Mode at sa bago naming system. Patuloy na nagserbisyo sa mga user ang Advanced na Voice Mode gaya ng dati, habang nagpapatakbo ng inference sa read-only mode ang shadow path. Dahil dito, nasubukan ang system sa mga totoong client, network, haba ng session, at heograpikong distribusyon nang hindi binabago ang naririnig ng mga user.

Isa sa mga unang aral ay hindi sapat ang GPU throughput bilang sukatan ng kapasidad. Nananatiling bukas at tuloy-tuloy na nagpapadala ng mga frame ang mga voice session, kaya kailangang sumabay sa pag-scale ng inference ang mga CPU-side stream handler, queue, at network path. Sa totoong load, mas maagang umabot sa kapasidad ang isang pansuportang component kaysa sa hula ng aming mga load test, kaya naipon ang mga inference request at lalo pang lumaki ang latency. Binago namin ang tanong tungkol sa kapasidad mula sa “Ilang request ang kayang pangasiwaan ng isang GPU?” at naging “Ilang sabay-sabay na session ang kayang panatilihin ng system habang nasa iskedyul ang bawat frame?”

Ipinakita rin ng pagsubok na dapat maging pangunahing konsiderasyon ang heograpiya. Maaaring magdagdag ng delay sa ilang bahagi ng startup at streaming ang pagruta ng session sa malayong kapasidad. Sinimulan naming sabay na i-validate ang mga rollout ng modelo, panrehiyong kapasidad, at configuration ng pagruta ng traffic, saka sinuri ang latency ayon sa pinagmumulang lokasyon. Nakatulong ang paglapit ng inference sa mga user, ngunit pinagtibay rin nito ang mas malawak na aral: nakasalalay ang end-to-end na bilis ng pagtugon sa bawat serbisyo sa path, hindi lang sa server ng modelo.

May iba pang mga failure na lumitaw lamang sa makatotohanang lifecycle ng session. Inilantad ng mga pangmatagalang session ang pressure sa memory at persistence. Nasubukan ng mga muling pagkonekta ang compaction at pagpapanumbalik ng state. Inilantad ng mga karaniwang pagdiskonekta ng client ang mga race condition sa shutdown handshake. Bihirang lumitaw ang mga problemang ito sa maiikling load test dahil nakadepende ang mga ito sa oras, naipong state, at gawi sa pagitan ng mga hangganan ng serbisyo.

Sa huli, pinilit kami ng production testing na pahusayin ang observability at mga kontrol sa rollout. Nakakita kami ng mga metric na pinagsasama ang magkakaibang pinagmumulan ng latency, mga dashboard na ikinukubli ng aggregate data ang mga indibidwal na engine na may problema, at configuration drift sa pagitan ng sinubukan at na-deploy na mga system. Bilang tugon, nagdagdag kami ng mas detalyadong telemetry, validation laban sa mga subok na configuration, unti-unting ramp, at kakayahang mabilis na ihiwalay o i-disable ang bawat path. Ang tahimik na pagsubok ay naging maagang ensayo para sa paglulunsad—hindi lang para malaman kung gaanong traffic ang kayang tanggapin ng system, kundi pati kung gaano kabilis naming matutukoy, makokontrol, at mareresolba ang failure.

Upang maabot ng GPT‑Live ang scale ng ChatGPT, kinailangan ang isang ganap na bagong system na nakabatay sa isang pangunahing prinsipyo: dapat tuloy-tuloy ang daloy ng boses. Patuloy na nagsusuplay ng audio sa full-duplex na modelo ang streaming inference. Tinitiyak ng nakalaang media path ang maaasahang paghahatid ng mga frame. Dahil sa asynchronous na delegasyon, maaaring sabay na isagawa ang mas malalim na pag-iisip. Pinananatili ng na-optimize na transport ang mabilis na pagtugon hanggang sa user.

Ang architecture sa likod ng GPT‑Live ay nagiging mas malawak nang platform para sa realtime na interaksyon. Pinapagana nito ang ChatGPT Voice habang lumalawak ito mula sa pag-uusap tungo sa agentic coordination, at ito rin ang magiging pundasyon ng paparating na GPT‑Live API. Sa paglipas ng panahon, magbibigay-daan ito sa mga voice experience sa mas maraming device, app, at modality nang hindi isinasakripisyo ang agarang tugon na nagbibigay-buhay sa voice conversation.

Kung ganitong mga problema sa engineering ang gusto mong lutasin, magtrabaho kasama namin⁠.