Cara kami membangun sistem real-time untuk AI suara responsif dalam enam bulan

Bagi AI suara, mengetahui kapan harus berbicara ternyata tidak semudah kedengarannya. Manusia bergantian berbicara dengan mudah dalam sepersekian detik, tetapi sistem AI suara sebelumnya tidak mampu mengikuti ritme ini. Arsitektur berbasis gilirannya mengandalkan model kecil yang disebut pendeteksi giliran, dengan tugas yang serba sulit: menebak terlalu cepat akan memotong ucapan pengguna; terlalu lambat akan membuat respons terasa lesu. LLM yang jauh lebih besar baru dapat mulai bekerja setelah pendeteksi membuat keputusan.

GPT‑Live⁠, sistem suara generasi ketiga kami, menghapus pendeteksi giliran dari jalur audio. Model suaranya menggunakan dupleks penuh, yang berarti dapat mendengarkan dan berbicara secara bersamaan. Dengan demikian, pendeteksi terpisah tidak lagi diperlukan dan percakapan terasa lebih langsung serta alami. Saat membutuhkan penalaran lebih mendalam atau penggunaan alat, GPT‑Live juga dapat berkonsultasi dengan model terdepan kami, seperti GPT‑5.5, tanpa mengganggu alur percakapan. Gabungan kemampuan ini memberi GPT‑Live perpaduan responsivitas percakapan dan kecerdasan yang belum pernah ada sebelumnya.

Menghadirkan pengalaman ini dalam skala besar membutuhkan arsitektur sistem baru yang dioptimalkan untuk latensi rendah. Tidak seperti inferensi permintaan-respons pada umumnya, sistem kami melakukan streaming audio masuk ke model suara dan mengirimkan kembali ujaran kepada pengguna, sementara delegasi ditangani melalui jalur asinkron terpisah. Selama enam bulan terakhir, kami merombak inferensi model, pengelolaan konteks, dan transportasi media agar ujaran mengalir lancar dari ujung ke ujung.

Arsitektur ini juga menciptakan batas yang jelas antara jalur suara inti dan logika aplikasi. Dengan demikian, perilaku aplikasi mudah disesuaikan tanpa memengaruhi responsivitas. Fondasi ini mendukung semakin banyak kemampuan di ChatGPT Suara, termasuk kemampuan yang baru diluncurkan untuk mengontrol komputer dan mengoordinasikan agen Anda di aplikasi desktop ChatGPT.

Dalam artikel ini, kami akan menjelaskan mengapa sistem berbasis giliran sebelumnya tidak dapat memenuhi kebutuhan kami dan bagaimana kami merekayasa sistem baru agar responsif di setiap lapisan. Kami akan membahas inferensi yang memiliki status, pengelolaan konteks dinamis, delegasi asinkron, dan pengoptimalan tingkat protokol—semuanya bekerja bersama agar GPT‑Live benar-benar terasa langsung.

Arsitektur suara terdahulu mewarisi sifat berbasis giliran dari LLM teks, tetapi setiap giliran direpresentasikan sebagai sekumpulan audio terpisah, bukan teks. Dalam sistem berantai, pengubah ujaran ke teks, LLM, dan pengubah teks ke ujaran dijalankan secara berurutan. Urutan ini menambah latensi dan mengabaikan isyarat seperti nada serta tempo.

Model speech-to-speech menyempurnakan pendekatan ini dengan memproses audio secara langsung. Melatih model agar memahami dan menghasilkan ujaran secara native memungkinkannya mempertahankan detail yang hilang dalam transkripsi dan merespons lebih cepat. Namun, sistem masih mengandalkan pendeteksi giliran untuk menentukan kapan inferensi dapat dimulai. Model menangani lebih banyak bagian interaksi, tetapi interaksi tersebut tetap berbasis giliran.

GPT‑Live memberi model suara kendali atas percakapan: audio mengalir masuk dan keluar dari model, sementara penalaran yang lebih mendalam dan penggunaan alat berlangsung secara asinkron. Tugas utama sistem adalah mempertahankan loop media tanpa gangguan. Pekerjaan lain, seperti memanggil model terdepan dan menyimpan percakapan secara persisten, dilakukan di luar jalur langsung.

Menjaga loop media ini tetap berjalan tanpa gangguan tidak selalu mudah. Penundaan pada transportasi, pemrosesan, atau inferensi dapat terdengar sebagai jeda atau artefak audio. Sistem berbasis giliran sebelumnya masih dapat menoleransi sedikit variasi waktu kedatangan sekumpulan audio. Namun, sistem media langsung harus mengirimkan setiap frame audio tepat waktu.

Pengembangan terdahulu pada ChatGPT Suara dan Realtime API memberi kami fondasi penting. Kami telah membangun ulang infrastruktur suara kami⁠ agar dapat melakukan streaming audio dan video langsung ke dan dari sistem kami dengan latensi yang lebih rendah dan lebih dapat diprediksi. GPT‑Live mengembangkan desain tersebut lebih lanjut dengan melakukan streaming media hingga ke model melalui sistem inferensi baru yang memiliki status dan dirancang untuk percakapan berkelanjutan.

Namun, inferensi streaming hanyalah sebagian dari solusinya. Agar berfungsi dengan baik di lingkungan produksi, kami juga harus memastikan audio dikirim secara andal dari klien ke tumpukan inferensi serta mengatasi tantangan sistem yang memiliki status.

Salah satu keputusan awal kami adalah memisahkan aliran media secara khusus dari logika aplikasi dan bisnis. Audio bergerak antara klien dan model suara melalui jalur cepat khusus. Delegasi, penggunaan alat, dan pekerjaan aplikasi lainnya berlangsung di balik batas RPC asinkron. Panggilan alat atau layanan backend yang lambat dapat menunda hasilnya sendiri, tetapi tidak dapat menghambat aliran media.

Pemisahan ini juga memberi sistem batas yang jelas untuk penyesuaian. Aplikasi dapat mengubah alat, kebijakan, dan perilaku backend tanpa memengaruhi frontend media yang bertanggung jawab menjaga audio tetap mengalir. Jalur langsung tetap ringkas, dapat diprediksi, dan berfokus pada pekerjaan yang harus dilakukan secara real-time.

Kami menulis frontend media dan logika inferensi dalam Go untuk menggantikan implementasi Python asyncio sebelumnya. Hal ini sangat meningkatkan kelancaran pengiriman frame; p95 sistem baru setara dengan p50 sistem sebelumnya.

WebRTC menyediakan fondasi transportasi. WebRTC dirancang untuk media berlatensi rendah dan dapat terus beroperasi meski terjadi kehilangan paket, penyimpangan jam, dan perubahan koneksi klien. Jika paket tiba terlambat, WebRTC dapat sedikit meregangkan audio untuk mencegah celah, lalu mempercepat pemutaran sejenak agar kembali mengejar waktu nyata.

Dengan meminimalkan buffering dan pemblokiran di seluruh sistem, kami dapat menghadirkan respons dalam waktu kurang dari satu detik, seperti yang diharapkan manusia dalam percakapan.

Inferensi yang memiliki status membawa konsekuensi operasional tersendiri. Sesi suara dapat tetap aktif dalam waktu lama, tetapi konteksnya terus bertambah, sementara instans model dimulai dan dihentikan sesuai permintaan.

Untuk mengatasi masalah tersebut, kami membangun mekanisme serah terima yang mulus antarinstans model. Ketika transisi diperlukan, kami dapat menyiapkan instans model pengganti di samping instans yang ada, mengisinya terlebih dahulu dengan konteks sesi saat ini, menjalankan inferensi pada keduanya secara paralel, lalu beralih setelah instans baru benar-benar siap.

Mekanisme dasar yang sama juga mendukung pemadatan konteks dinamis. Seiring berjalannya percakapan, akumulasi konteksnya pada akhirnya dapat melampaui batas konteks model. Pemadatan dapat mengurangi ukuran konteks agar sesuai dengan batas tersebut, tetapi prosesnya membutuhkan waktu. Karena mengubah konteks sebelumnya, proses ini juga membatalkan cache nilai-kunci (KV) model, yang menyimpan kunci dan nilai atensi dari token yang telah diproses. Membangun ulang status tersebut memerlukan pengisian awal baru, sehingga menambah penundaan.

Sebagai gantinya, kami memperlakukan pemadatan sebagai transisi lain yang dikelola. Sementara instans model asli terus mengobrol, sistem memadatkan konteks dan menyiapkan instans model pengganti dengan konteks baru. Setelah instans tersebut siap, kami dapat beralih tanpa mengganggu media. Dengan demikian, sistem dapat mendukung panggilan berdurasi panjang dan melakukan pemadatan kapan pun diperlukan.

Pekerjaan berat tetap berada di luar jalur langsung, sehingga percakapan tetap lancar bahkan saat serah terima berlangsung.

Kemampuan GPT‑Live memanggil model terdepan yang ada memberinya kekuatan besar karena secara efektif memisahkan proses “berbicara” dari “berpikir” lebih mendalam. Namun, agar arsitektur dua model ini terasa seperti satu sistem, kami harus memecahkan dua masalah rekayasa yang saling terkait.

Pertama, hasil harus kembali cukup cepat agar berguna dalam percakapan yang sedang berlangsung. Karena itu, kami harus meminimalkan latensi di seluruh jalur delegasi, mulai dari perutean dan pemrosesan prompt hingga inferensi dan panggilan alat. Pada saat yang sama, sistem lain dalam produk masih memerlukan pesan terpisah, sehingga kami harus merepresentasikan percakapan yang berlangsung dalam bentuk yang dapat mereka pahami.

Saat delegasi dikirim, kami mengoptimalkan waktu hingga model terdepan menghasilkan sesuatu yang berguna bagi percakapan. Model suara dapat menjaga percakapan tetap berjalan sejenak saat model terdepan melakukan penalaran atau menggunakan alat, tetapi tidak dapat menyamarkan respons yang terlalu lambat. Karena itu, kami memasukkan seluruh loop delegasi—perutean, pemrosesan prompt, inferensi, dan panggilan alat—ke dalam anggaran responsivitas.

Pengoptimalan pertama adalah menyiapkan model terdepan dan semua alat yang dibutuhkannya sebelum delegasi diminta. Saat sesi suara dimulai, server aplikasi membuat sesi inferensi untuk model terdepan dan mengisinya terlebih dahulu dengan konteks awal percakapan, sehingga prompt telah diproses sepenuhnya sebelum permintaan delegasi pertama.

Kami lalu menjaga sesi inferensi tersebut tetap tersedia selama percakapan suara berlangsung dan menggunakan afinitas sesi yang stabil untuk permintaan berikutnya. Bersama caching prompt, teknik-teknik ini mengurangi latensi sekaligus menjaga agar kegagalan worker tetap mudah dipulihkan.

Upaya penalaran, batas output, skema alat, serta perjalanan bolak-balik antara model dan alat juga memengaruhi kapan percakapan menerima hasil yang berguna, sehingga kami menyesuaikan faktor-faktor ini untuk mempercepat respons. Dengan meminimalkan pekerjaan di jalur delegasi, kami memungkinkan model suara memanfaatkan hasil dari model terdepan kami dengan cepat.

Meskipun model suara memproses aliran ujaran berkelanjutan, banyak sistem di sekitarnya masih bekerja berdasarkan giliran pengguna dan asisten, termasuk UI percakapan ChatGPT serta sebagian infrastruktur analitik dan keamanan kami. Karena itu, server aplikasi mengurai percakapan yang tumpang tindih dan terkadang ambigu menjadi pesan-pesan terpisah.

Saat audio masuk, server menggunakan transkrip parsial dan sinyal waktu untuk menyimpulkan siapa yang sedang berbicara serta menyusun antrean pesan. Pesan terbaru tetap bersifat sementara; teks, waktu, dan penetapan pembicaranya dapat berubah saat lebih banyak ujaran masuk. Setelah seseorang berbicara cukup lama sehingga atribusinya dapat diandalkan, server memfinalisasi pesan terkait.

Ucapan pembicara yang tumpang tindih membuat proses ini lebih rumit. Tanggapan singkat dari asisten saat pengguna sedang berbicara (misalnya “mm hmm,” atau “okay”) tidak harus menjadi pesan tersendiri. Namun, interupsi asisten yang bermakna sering kali perlu menjadi pesan tersendiri. Demikian pula, kami mengutamakan koherensi respons asisten yang ditampilkan meskipun pengguna berbicara di tengah respons.

Setiap kebijakan segmentasi harus menyeimbangkan kebaruan dengan kepastian. Memfinalisasi terlalu dini menghasilkan riwayat yang terpecah dan urutan yang tidak stabil; menunggu terlalu lama menunda transkrip dan fitur yang bergantung padanya. Karena itu, sistem mempertahankan dua tampilan percakapan yang saling terkait: tampilan spekulatif untuk status saat ini dan catatan otoritatif tentang apa yang telah diucapkan. Tampilan percakapan di UI aplikasi dapat menangani pembaruan, sehingga menggunakan tampilan spekulatif. Namun, pencatatan ke pipeline analitik memerlukan transkrip final.

Dengan demikian, bagian lain ChatGPT memperoleh tampilan percakapan yang stabil tanpa memaksakan pergantian giliran pada jalur suara langsung.

Responsivitas dimulai begitu pengguna mengeklik tombol. Dengan GPT‑Live, sistem harus membuat jalur media dan mulai memasukkan audio melalui model sebelum percakapan dapat dimulai. Artinya, setiap bagian dari urutan awal berada di jalur kritis.

Seperti disebutkan di atas, WebRTC menyediakan fondasi real-time yang kuat. Namun, memulai sesi WebRTC standar ternyata memerlukan cukup banyak handshake protokol dan perjalanan bolak-balik jaringan. WebRTC hadir sebelum fokus pada pengurangan perjalanan bolak-balik membentuk protokol yang lebih baru seperti QUIC. Akibatnya, protokol-protokol dasarnya terkadang mengulang pekerjaan saat digunakan bersama. Misalnya, setiap protokol memiliki mekanisme anti-DoS sendiri, meskipun tidak diperlukan dalam konteks keseluruhan tumpukan WebRTC.

Kami menganalisis tumpukan tersebut dan mengembangkan WebRTC Abridged Roundtrip Protocol (WARP⁠(terbuka di jendela baru)), yang mengurangi proses awal media dan data dari enam perjalanan bolak-balik jaringan menjadi hanya satu. WARP mewujudkannya melalui serangkaian peningkatan protokol yang kompatibel dengan versi sebelumnya: menumpangkan handshake DTLS di atas ICE (SPED⁠(terbuka di jendela baru)), menggunakan handshake DTLS 1.3⁠(terbuka di jendela baru) yang lebih cepat, melakukan prapegosiasian handshake SCTP (SNAP⁠(terbuka di jendela baru)), dan melakukan prapegosiasian saluran data alih-alih menggunakan DCEP⁠(terbuka di jendela baru).

Kami merancang WARP sebagai rangkaian spesifikasi terbuka bersama para kolaborator dari komunitas WebRTC, agar ekosistem yang lebih luas dapat memanfaatkan pekerjaan ini. Kami mengajukan proposal ini melalui kelompok kerja TSVWG di IETF. Dukungan WARP juga telah ditambahkan ke libwebrtc dan Pion, sementara penerapannya pada implementasi WebRTC lain sedang berlangsung.

Setelah mengoptimalkan handshake media, masih ada satu penundaan yang menonjol: pertukaran sinyal untuk membagikan parameter SDP sebelum WebRTC dapat terhubung. Untuk mengeluarkan pertukaran tersebut dari jalur kritis, kami mengembangkan teknologi yang kami sebut Instant Connect. Teknologi ini menegosiasikan parameter tersebut sebelumnya tanpa mencadangkan kapasitas server dan tanpa mengubah implementasi WebRTC yang ada.

Instant Connect berjalan berdampingan dengan alur pensinyalan standar. Jika parameter yang dinegosiasikan sebelumnya valid, server dapat mewujudkan sesi saat paket media pertama tiba. Jika parameter tersebut kedaluwarsa atau tidak valid, alur pensinyalan sudah berjalan sehingga klien dapat beralih ke metode cadangan tanpa latensi tambahan.

Bersama-sama, Instant Connect dan WARP mengurangi secara drastis waktu dari niat pengguna hingga media mulai mengalir langsung. Setelah pertukaran SDP dikeluarkan dari jalur kritis dan WARP meringkas handshake transportasi, klien kini dapat memulai sesi hanya dengan satu paket UDP. Server dapat langsung merespons sehingga bagian sistem lainnya dapat mulai melakukan pekerjaan yang benar-benar dibutuhkan pengguna: mendengarkan dan menanggapi.

Sebuah sistem bisa tampak cepat di atas kertas, tetapi tetap tersendat saat menangani lalu lintas suara nyata. Sebelum mengizinkan GPT‑Live mengobrol dengan pengguna, kami menjalankan pengujian senyap yang mengarahkan sebagian kecil sesi ChatGPT Suara di lingkungan produksi—yang ditingkatkan secara bertahap—ke pengalaman mode suara tingkat lanjut yang sudah ada sekaligus ke sistem baru kami. Mode suara tingkat lanjut tetap melayani pengguna seperti biasa, sementara jalur bayangan menjalankan inferensi dalam mode baca-saja. Dengan demikian, sistem menangani klien, jaringan, durasi sesi, dan distribusi geografis nyata tanpa mengubah apa yang didengar pengguna.

Salah satu pelajaran pertama yang kami peroleh adalah bahwa kapasitas tidak dapat diukur hanya berdasarkan throughput GPU. Sesi suara tetap terbuka dan terus mengirim frame, sehingga pengelola stream di sisi CPU, antrean, dan jalur jaringan harus diskalakan seiring dengan inferensi. Di bawah beban nyata, sebuah komponen pendukung mencapai titik jenuh lebih awal daripada perkiraan pengujian beban kami, sehingga permintaan inferensi menumpuk dan latensi makin membesar. Kami mengubah pertanyaan tentang kapasitas dari “Berapa banyak permintaan yang dapat ditangani GPU?” menjadi “Berapa banyak sesi serentak yang dapat ditopang sistem sambil memastikan setiap frame tetap sesuai jadwal?”

Pengujian tersebut juga menjadikan faktor geografis sebagai perhatian utama. Mengarahkan sesi ke kapasitas yang jauh dapat menambah penundaan pada beberapa titik selama proses awal dan streaming. Kami mulai memvalidasi peluncuran model bersama kapasitas regional dan konfigurasi pengarah lalu lintas, lalu menguraikan latensi berdasarkan geografi sumber. Memindahkan inferensi lebih dekat ke pengguna membantu, tetapi juga menegaskan pelajaran yang lebih luas: responsivitas menyeluruh bergantung pada setiap layanan di sepanjang jalur, bukan hanya server model.

Kegagalan lain hanya muncul dalam siklus hidup sesi yang realistis. Sesi berdurasi panjang menimbulkan tekanan pada memori dan persistensi. Penyambungan ulang menguji pemadatan dan pemulihan status. Pemutusan koneksi klien biasa mengungkap kondisi balapan dalam proses handshake penonaktifan. Masalah-masalah ini jarang muncul dalam pengujian beban singkat karena bergantung pada waktu, akumulasi status, dan perilaku yang melintasi batas layanan.

Terakhir, pengujian produksi memaksa kami meningkatkan observabilitas dan kontrol peluncuran. Kami menemukan metrik yang mencampuradukkan berbagai sumber latensi, dasbor dengan data agregat yang menyembunyikan mesin individual bermasalah, serta penyimpangan konfigurasi antara sistem yang diuji dan diterapkan. Sebagai tanggapan, kami menambahkan telemetri yang lebih terperinci, validasi terhadap konfigurasi yang terbukti baik, peningkatan bertahap, serta kemampuan untuk mengisolasi atau menonaktifkan setiap jalur dengan cepat. Pengujian senyap ini menjadi geladi awal peluncuran, bukan hanya untuk mengetahui besarnya lalu lintas yang mampu diterima sistem, tetapi juga seberapa cepat kami dapat mendeteksi, membatasi, dan memulihkan kegagalan.

Menghadirkan GPT‑Live pada skala ChatGPT membutuhkan sistem baru yang dibangun berdasarkan satu prinsip mendasar: suara harus terus mengalir. Inferensi streaming terus memasok audio ke model dupleks penuh. Jalur media khusus memastikan frame dikirim secara andal. Delegasi asinkron memungkinkan proses berpikir yang lebih mendalam berjalan secara paralel. Transportasi yang dioptimalkan menjaga pengalaman tetap responsif hingga sampai ke pengguna.

Arsitektur di balik GPT‑Live telah berkembang menjadi platform yang lebih luas untuk interaksi real-time. Arsitektur ini mendukung ChatGPT Suara seiring perkembangannya dari percakapan menjadi koordinasi berbasis agen, dan akan menjadi fondasi bagi API GPT‑Live mendatang. Seiring waktu, arsitektur ini akan memungkinkan pengalaman suara menjangkau lebih banyak perangkat, aplikasi, dan modalitas tanpa mengorbankan kesegeraan yang membuat percakapan suara terasa langsung.

Jika Anda ingin memecahkan masalah rekayasa seperti ini, bergabunglah dengan kami⁠.