Carane kita nggawe sistem wektu nyata kanggo AI swara responsif sajrone nem wulan

Kanggo AI swara, ngerti kapan kudu ngomong luwih angel tinimbang sing katon. Manungsa bisa gantian ngomong kanthi lancar sajrone sapérangan sadetik, nanging sistem AI swara sadurunge ora bisa ngetutake irama iki. Arsitektur adhedhasar gilirane ngandelake model cilik sing diarani detektor giliran, sing ngadhepi tugas angel: yen ngira kesusu, pangguna kepotong; yen kasep, respons krasa alon. LLM sing luwih gedhe lagi bisa miwiti pakaryan sawise detektor nggawe keputusan.

GPT‑Live⁠, sistem swara generasi katelu kita, mbusak detektor giliran saka jalur audio. Model swarane full-duplex, tegesé bisa ngrungokake lan ngomong bebarengan. Iki ngilangi kabutuhan detektor kapisah lan ndadekake pacelathon krasa luwih langsung lan alami. Nalika mbutuhake nalar sing luwih jero utawa panggunaan alat, GPT‑Live uga bisa njaluk pitulungan model tercanggih kita, kayata GPT‑5.5, tanpa ngganggu aliran pacelathon. Gabungan kemampuan iki menehi GPT‑Live responsivitas lan kecerdasan pacelathon sing durung tau ana sadurunge.

Kanggo nyedhiyakake pengalaman iki ing skala gedhe, dibutuhake arsitektur sistem anyar sing dioptimalake kanggo latensi cendhek. Ora kaya inferensi panjaluk-respons lumrah, sistem kita nindakake streaming audio mlebu menyang model swara lan wicara metu bali menyang pangguna, dene delegasi ditangani liwat jalur asinkron kapisah. Sajrone nem wulan kepungkur, kita ngrancang maneh inferensi model, pangelolaan konteks, lan transportasi media supaya wicara mili lancar saka wiwitan nganti pungkasan.

Arsitektur iki uga nggawe wates sing cetha antarane jalur swara inti lan logika aplikasi. Kanthi mangkono, prilaku aplikasi gampang dikustomisasi tanpa mengaruhi kacepetan respons. Dhasar iki nguwasani manéka kemampuan ChatGPT Voice sing terus tuwuh, kalebu kemampuan anyar kanggo ngontrol komputer lan ngoordinasi agen sampeyan ing aplikasi desktop ChatGPT.

Ing tulisan iki, kita bakal njlentrehake sebab sistem adhedhasar giliran sadurunge ora bisa nyukupi kabutuhan kita lan carane sistem anyar direkayasa supaya responsif ing saben lapisan. Kita bakal ngrembug inferensi sing nduweni status, pangelolaan konteks dinamis, delegasi asinkron, lan optimisasi tingkat protokol, sing kabeh makarya bebarengan supaya GPT‑Live krasa temenan langsung.

Arsitektur swara sadurunge marisi pola adhedhasar giliran saka LLM teks, nanging saben giliran diwujudake minangka gumpalan audio kapisah, dudu teks. Ing sistem kaskade, wicara-menyang-teks, LLM, lan teks-menyang-wicara dilakokake kanthi urut. Urutan iki nambah latensi lan ora nggatekake tandha kayata intonasi lan tempo.

Model wicara menyang wicara ningkatake pendekatan iki kanthi ngolah audio kanthi langsung. Nglatih model supaya bisa mangerteni lan ngasilake wicara kanthi asli ndadekake model bisa njaga rincian sing ilang nalika transkripsi lan nanggapi luwih cepet. Nanging, sistem isih ngandelake detektor giliran kanggo mutusake kapan inferensi bisa diwiwiti. Model nangani luwih akeh bagean interaksi, nanging interaksine isih adhedhasar giliran.

GPT‑Live maringi model swara kendhali pacelathon: audio mili mlebu lan metu saka model, dene nalar sing luwih jero lan panggunaan alat lumaku kanthi asinkron. Tugas utama sistem yaiku njaga loop media supaya ora pedhot. Pakaryan liyane, kayata ngundang model tercanggih lan nyimpen pacelathon kanthi permanen, ditindakake ing njaba jalur langsung.

Njaga loop media iki supaya ora pedhot ora mesthi gampang. Sembarang wektu tundha ing transportasi, pangolahan, utawa inferensi bisa dadi jeda utawa artefak sing keprungu. Sistem adhedhasar giliran sadurunge isih bisa nanggung variasi wektu tekane gumpalan audio. Nanging, sistem media langsung kudu ngirim saben frame audio miturut jadwal.

Pakaryan sadurunge ing ChatGPT Voice lan Realtime API wis menehi dhasar penting kanggo kita. Kita wis mbangun maneh infrastruktur swara⁠ supaya audio lan video bisa di-stream langsung mlebu lan metu saka sistem kanthi latensi luwih cendhek lan luwih bisa diprakirakake. GPT‑Live ngembangake rancangan kasebut, kanthi streaming media nganti tekan model liwat sistem inferensi anyar sing nduweni status lan dirancang kanggo pacelathon tanpa kendhat.

Nanging, inferensi streaming mung salah siji bagean saka solusi. Supaya bisa mlaku apik ing produksi, kita uga kudu njamin pangiriman audio sing andal saka klien menyang tumpukan inferensi lan ngatasi tantangan sistem sing nduweni status.

Salah siji keputusan awal kita yaiku misahake aliran media saka logika aplikasi lan bisnis. Audio pindhah antarane klien lan model swara liwat jalur cepet khusus. Delegasi, panggunaan alat, lan pakaryan aplikasi liyane lumaku ing mburi wates RPC asinkron. Panggilan alat utawa layanan backend sing alon bisa nundha asile dhewe, nanging ora bisa ngalangi aliran media.

Pemisahan iki uga menehi wates sing cetha kanggo kustomisasi sistem. Aplikasi bisa ngowahi alat, kabijakan, lan prilaku backend tanpa mengaruhi frontend media sing tanggung jawab njaga audio terus mili. Jalur langsung tetep ringkes, bisa diprakirakake, lan fokus marang pakaryan sing kudu ditindakake ing wektu nyata.

Kita nulis frontend media lan logika inferensi nganggo Go kanggo ngganti implementasi Python asyncio sadurunge. Iki ndadekake pangiriman frame luwih lancar kanthi signifikan, kanthi p95 sistem anyar padha karo p50 sistem sadurunge.

WebRTC nyedhiyakake dhasar transportasi. WebRTC dirancang kanggo media latensi cendhek lan bisa terus lumaku sanajan ana paket ilang, penyimpangan jam, lan owah-owahan sambungan klien. Yen paket teka telat, WebRTC bisa manjangake audio sethithik supaya ora ana pedhot, banjur nyepetake puteran sedhela supaya bali selaras karo wektu nyata.

Kanthi nyilikake buffering lan pamblokiran ing saindenging sistem, kita bisa menehi respons kurang saka sadetik kaya sing dikarepake manungsa saka pacelathon.

Inferensi sing nduweni status duwe kompromi operasional dhewe. Sesi swara bisa tetep aktif suwe, nanging kontekse terus tuwuh, dene instans model diuripake lan dipateni miturut panjaluk.

Kanggo ngatasi prakara kasebut, kita nggawe mekanisme serah terima sing mulus antarane instans model. Nalika perlu transisi, kita bisa nyiapake instans model pangganti bebarengan karo instans sing wis ana, ngisi luwih dhisik nganggo konteks sesi saiki, nglakokake inferensi ing loro-lorone kanthi bebarengan, banjur ngalih nalika instans anyar wis siyap kanthi lengkap.

Mekanisme dhasar sing padha uga ndhukung kompaksi konteks dinamis. Nalika pacelathon terus lumaku, konteks sing numpuk pungkasane bisa ngluwihi wates konteks model. Kompaksi bisa nyuda ukuran konteks supaya cocog karo wates, nanging prosese mbutuhake wektu. Amarga ngowahi konteks sadurunge, proses iki uga mbatalake cache key-value (KV) model, sing nyimpen key lan value atensi saka token sing wis diproses. Mbangun maneh status kasebut mbutuhake prefill anyar, saengga nambah wektu tundha.

Mula, kompaksi kita anggep minangka transisi liyane sing dikelola. Nalika instans model asli terus ngobrol, sistem ngompaksi konteks lan nyiapake instans model pangganti nganggo konteks anyar. Sawise instans kasebut siyap, kita bisa ngalih tanpa ngganggu media. Kanthi mangkono, sistem bisa ndhukung panggilan suwene apa wae lan nindakake kompaksi saben dibutuhake.

Pakaryan abot tetep ana ing njaba jalur langsung, mula sanajan nalika serah terima, pacelathon ora nate pedhot.

Kemampuan GPT‑Live kanggo ngundang model tercanggih sing wis ana menehi daya gedhe, kanthi efektif misahake “ngomong” saka “mikir” sing luwih jero. Nanging, supaya arsitektur rong model iki krasa kaya siji sistem, kita kudu ngrampungake rong masalah rekayasa sing gegandhengan.

Kaping pisan, asil kudu bali cukup cepet supaya migunani sajrone pacelathon, mula kita kudu nyilikake latensi ing kabeh jalur delegasi, saka pangarahan lan pangolahan prompt nganti inferensi lan panggilan alat. Ing wektu sing padha, sistem liya ing produk isih mbutuhake pesen sing kapisah, mula pacelathon sing lagi lumaku kudu diwujudake ing format sing bisa dimangerteni sistem kasebut.

Nalika delegasi dikirim, kita ngoptimalake wektu nganti model tercanggih ngasilake bab sing migunani kanggo pacelathon. Model swara bisa njaga pacelathon terus lumaku sedhela nalika model tercanggih nindakake nalar utawa nggunakake alat, nanging ora bisa ndhelikake respons sing alon banget. Mula, kabeh loop delegasi—pangarahan, pangolahan prompt, inferensi, lan panggilan alat—kita lebokake ing anggaran wektu respons.

Optimisasi pisanan yaiku nyiyapake model tercanggih lan kabeh alat sing dibutuhake sadurunge delegasi dijaluk. Nalika sesi swara diwiwiti, server aplikasi nggawe sesi inferensi kanggo model tercanggih lan ngisi luwih dhisik nganggo konteks awal pacelathon, supaya prompt wis rampung diproses sadurunge panjaluk delegasi pisanan.

Sesi inferensi kasebut banjur tetep kasedhiya sajrone pacelathon swara, lan kita nggunakake afinitas sesi sing stabil kanggo panjaluk sabanjure. Bebarengan karo cache prompt, teknik iki nyuda latensi lan tetep nggampangake pamulihan yen worker gagal.

Upaya nalar, wates output, skema alat, lan perjalanan bolak-balik antarane model lan alat uga mengaruhi wektu tekane asil sing migunani, mula kabeh iki kita setel kanggo nyepetake respons. Kanthi nyilikake pakaryan ing jalur delegasi, model swara bisa kanthi cepet nggabungake asil saka model tercanggih kita.

Sanajan model swara ngolah stream wicara tanpa kendhat, akeh sistem ing sakupenge isih ngolah giliran pangguna lan asisten, kalebu UI pacelathon ChatGPT lan sapérangan infrastruktur analitik lan keamanan kita. Mula, server aplikasi ngurai pacelathon sing tumpang tindih lan kadhang ambigu dadi pesen-pesen sing kapisah.

Nalika audio teka, server nggunakake transkrip parsial lan sinyal wektu kanggo nyimpulake sapa sing lagi oleh giliran ngomong lan nggawe antrean pesen. Pesen paling anyar tetep sauntara; teks, wektu, lan penetapan penuture bisa owah nalika luwih akeh wicara teka. Sawise penutur terus ngomong cukup suwe nganti atribusine bisa dipercaya, server netepake pesen sing cocog.

Wicara antarpenutur sing tumpang tindih ndadekake proses iki luwih rumit. Tanggapan cekak saka asisten nalika pangguna lagi ngomong (umpamane “mm hmm,” utawa “okay”) ora mesthi kudu dadi pesen dhewe. Nanging, seselan asisten sing isine penting kerep kudu dadi pesen dhewe. Semono uga, kita ngutamakake koherensi respons asisten sing ditampilake sanajan pangguna ngomong ing satengahe.

Saben kabijakan segmentasi ngorbanake salah siji antarane kemutakhiran lan kepastian. Nemtokake pesen kesusu bakal ngasilake riwayat sing pecah lan urutan ora stabil; ngenteni kesuwen bakal nundha transkrip lan fitur sing gumantung marang transkrip kasebut. Mula, sistem njaga rong tampilan pacelathon sing gegandhengan: tampilan spekulatif babagan status saiki lan cathetan sah babagan apa sing diucapake. Tampilan pacelathon ing UI aplikasi bisa nangani pembaruan, mula nggunakake tampilan spekulatif. Nanging, pencatatan menyang pipeline analitik mbutuhake transkrip final.

Iki menehi bagean ChatGPT liyane tampilan pacelathon sing stabil tanpa meksa pola giliran ngomong ing jalur swara langsung.

Kacepetan respons diwiwiti nalika pangguna ngeklik tombol. Kanthi GPT‑Live, sistem kudu nggawe jalur media lan miwiti ngirim audio liwat model sadurunge pacelathon bisa diwiwiti. Iki ndadekake saben bagean saka urutan wiwitan mlebu jalur kritis.

Kaya sing kasebut ing ndhuwur, WebRTC nyedhiyakake dhasar wektu nyata sing kuwat, nanging miwiti sesi WebRTC standar mbutuhake handshake protokol lan perjalanan bolak-balik jaringan sing akehe nggumunake. WebRTC wis ana sadurunge fokus kanggo nyilikake perjalanan bolak-balik sing mbentuk protokol sabanjure kayata QUIC. Akibate, protokol dhasare kadhang mbaleni pakaryan nalika digunakake bebarengan. Contone, saben protokol duwe mekanisme anti-DoS dhewe, sanajan ora dibutuhake ing konteks tumpukan WebRTC lengkap.

Kita nganalisis tumpukan kasebut lan ngembangake WebRTC Abridged Roundtrip Protocol (WARP⁠(mbukak ing jendhela anyar)), sing nyuda wiwitan media lan data saka enem perjalanan bolak-balik jaringan dadi mung siji. WARP nggayuh iki liwat sakumpulan perbaikan protokol sing kompatibel karo versi sadurunge: numpangake handshake DTLS liwat ICE (SPED⁠(mbukak ing jendhela anyar)), nggunakake handshake DTLS 1.3⁠(mbukak ing jendhela anyar) sing luwih cepet, negosiasi handshake SCTP luwih dhisik (SNAP⁠(mbukak ing jendhela anyar)), lan negosiasi saluran data luwih dhisik tinimbang nggunakake DCEP⁠(mbukak ing jendhela anyar).

Kita ngrancang WARP minangka sakumpulan spesifikasi mbukak kanthi nyambut gawe bareng mitra saka komunitas WebRTC, supaya ekosistem sing luwih amba bisa entuk manfaat saka pakaryan iki. Kita ngembangake usulan kasebut liwat kelompok kerja TSVWG ing IETF, lan dhukungan WARP wis ditambahake menyang libwebrtc lan Pion, dene implementasi WebRTC liyane uga lagi ngupayakake.

Sawise ngoptimalake handshake media, isih ana siji wektu tundha sing katon cetha: ijol-ijolan sinyal kanggo nuduhake parameter SDP sadurunge WebRTC bisa nyambung. Kanggo mbusak ijol-ijolan kasebut saka jalur kritis, kita ngembangake apa sing diarani Sambungan Instan. Fitur iki negosiasi parameter kasebut luwih dhisik tanpa nyadhangake kapasitas server lan tanpa ngowahi implementasi WebRTC sing wis ana.

Sambungan Instan lumaku bebarengan karo aliran sinyal standar. Yen parameter sing wis dinegosiasikake luwih dhisik sah, server bisa nggawe sesi nalika paket media pisanan teka. Yen parameter wis lawas utawa ora sah, aliran sinyal wis lumaku, mula klien bisa bali menyang cara standar tanpa latensi tambahan.

Bebarengan, Sambungan Instan lan WARP nyuda kanthi drastis wektu saka maksud pangguna nganti media langsung wiwit mili. Kanthi ijol-ijolan SDP metu saka jalur kritis lan WARP nyirnakake handshake transportasi, klien saiki bisa miwiti sesi mung nganggo siji paket UDP. Server bisa langsung nanggapi, supaya bagean sistem liyane bisa miwiti pakaryan sing pancen dibutuhake pangguna: ngrungokake lan nanggapi.

Sistem bisa katon cepet ing rancangan, nanging isih bisa macet nalika ngadhepi lalu lintas swara nyata. Sadurunge GPT‑Live diidini ngobrol karo pangguna, kita nganakake tes bisu sing ngarahake sapérangan cilik sesi ChatGPT Voice ing produksi—sing ditambah sethithik-sethithik—menyang mode swara canggih sing wis ana lan sistem anyar kita. Mode swara canggih tetep nglayani pangguna kaya biyasa, dene jalur bayangan nglakokake inferensi ing mode mung-waca. Kanthi mangkono, sistem ngadhepi klien, jaringan, suwene sesi, lan distribusi geografis nyata tanpa ngowahi apa sing dirungokake pangguna.

Salah siji piwulang pisanan yaiku kapasitas ora bisa mung diukur saka kapasitas pangolahan GPU. Sesi swara terus mbukak lan ngirim frame tanpa kendhat, mula panangani stream ing CPU, antrean, lan jalur jaringan kudu bisa ditingkatake bebarengan karo inferensi. Nalika nampa beban nyata, salah siji komponen panyengkuyung kebak luwih awal tinimbang prakiraan tes beban, nyebabake panjaluk inferensi numpuk lan latensi saya mundhak. Pitakonan babagan kapasitas kita owahi saka “Pira panjaluk sing bisa ditangani GPU?”dadi “Pira sesi bebarengan sing bisa ditangani sistem kanthi tetep njaga saben frame lumaku miturut jadwal?””

Tes kasebut uga nuduhake yen faktor geografis kudu dadi kawigaten utama. Ngarahake sesi menyang kapasitas sing adoh bisa nambah wektu tundha ing sawetara titik nalika wiwitan lan streaming. Kita banjur ngesahake peluncuran model bebarengan karo kapasitas regional lan konfigurasi pangarah lalu lintas, banjur nglompokake latensi miturut geografi asal. Mindhah inferensi luwih cedhak karo pangguna pancen mbantu, nanging uga negesake piwulang sing luwih amba: kacepetan respons saka wiwitan nganti pungkasan gumantung marang saben layanan ing jalur kasebut, ora mung server model.

Kagagalan liyane mung katon sajrone siklus urip sesi sing nyata. Sesi sing lumaku suwe nuduhake tekanan ing memori lan persistensi. Panyambungan maneh nguji kompaksi lan pamulihan status. Pedhot sambungan klien sing lumrah nuduhake kahanan balapan ing handshake nalika mateni sistem. Masalah iki arang katon ing tes beban sing cekak amarga gumantung marang wektu, status sing numpuk, lan prilaku ngliwati wates antarane layanan.

Pungkasan, tes produksi meksa kita nambah observabilitas lan kontrol peluncuran. Kita nemokake metrik sing nyampur manéka sumber latensi, dasbor sing agregaté ndhelikake mesin individu sing ora sehat, lan panyimpangan konfigurasi antarane sistem sing dites lan sing diluncurake. Minangka tanggapan, kita nambah telemetri sing luwih rinci, validasi nganggo konfigurasi sing wis kabukten apik, peningkatan bertahap, lan kemampuan kanggo ngisolasi utawa mateni saben jalur kanthi cepet. Tes bisu kasebut dadi gladhen awal peluncuran, ora mung kanggo ngerti sepira akehe lalu lintas sing bisa ditampa sistem, nanging uga sepira cepete kita bisa ndeteksi, mbatesi, lan mulihake sistem saka kagagalan.

Nggawa GPT‑Live menyang skala ChatGPT mbutuhake sistem anyar sing dibangun adhedhasar siji prinsip utama: swara kudu terus mili. Inferensi streaming njaga supaya model full-duplex terus nampa audio. Jalur media khusus njamin pangiriman frame sing andal. Delegasi asinkron ngidini pamikiran sing luwih jero lumaku bebarengan. Transportasi sing dioptimalake njaga pengalaman tetep responsif nganti tekan pangguna.

Arsitektur ing mburine GPT‑Live wis wiwit dadi platform sing luwih amba kanggo interaksi wektu nyata. Arsitektur iki nguwasani ChatGPT Voice nalika berkembang saka pacelathon menyang koordinasi agentik, lan bakal dadi dhasar GPT‑Live API sing bakal teka. Suwe-suwe, arsitektur iki bakal ngidini pengalaman swara nyakup luwih akeh piranti, aplikasi, lan modalitas tanpa ngorbanake rasa langsung sing ndadekake pacelathon swara krasa nyata.

Yen iki kalebu masalah rekayasa sing pengin sampeyan rampungake, ayo nyambut gawe bareng kita⁠.