Cara kami membina sistem masa nyata untuk AI suara responsif dalam enam bulan

Bagi AI suara, mengetahui waktu untuk bercakap lebih sukar daripada yang disangka. Manusia bertukar giliran bercakap dengan mudah dalam masa kurang daripada sesaat, tetapi sistem AI suara terdahulu tidak mampu mengikuti rentak ini. Seni bina berasaskan giliran bergantung pada model kecil yang dikenali sebagai pengesan giliran, dengan tugas yang sukar: meneka terlalu awal menyebabkan percakapan pengguna terputus; meneka terlalu lewat pula menjadikan respons terasa lembap. LLM yang jauh lebih besar hanya boleh mula bekerja setelah pengesan membuat keputusan.

GPT‑Live⁠, sistem suara generasi ketiga kami, mengeluarkan pengesan giliran daripada laluan audio. Model suaranya bersifat dupleks penuh, yang bermaksud model itu boleh mendengar dan bercakap pada masa yang sama. Ini menghapuskan keperluan untuk pengesan berasingan dan menjadikan perbualan terasa lebih spontan serta semula jadi. Apabila penaakulan yang lebih mendalam atau penggunaan alat diperlukan, GPT‑Live juga boleh merujuk model perbatasan kami seperti GPT‑5.5 tanpa mengganggu aliran perbualan. Gabungan keupayaan ini memberikan GPT‑Live tahap respons dan kecerdasan perbualan yang belum pernah dicapai sebelum ini.

Menyediakan pengalaman ini pada skala besar memerlukan seni bina sistem baharu yang dioptimumkan untuk kependaman rendah. Tidak seperti inferens permintaan-respons biasa, sistem kami menstrim audio masuk ke dalam model suara dan pertuturan keluar kembali kepada pengguna, sambil mengendalikan penugasan melalui laluan tak segerak yang berasingan. Sepanjang enam bulan lalu, kami mengolah semula inferens model, pengurusan konteks dan pengangkutan media untuk memastikan pertuturan mengalir lancar dari hujung ke hujung.

Seni bina ini turut mewujudkan sempadan yang jelas antara laluan suara teras dengan logik aplikasi. Ini memudahkan penyesuaian tingkah laku aplikasi tanpa menjejaskan tahap respons. Asas ini menguasakan semakin banyak keupayaan dalam ChatGPT Suara, termasuk ciri yang baru dilancarkan untuk mengawal komputer anda dan menyelaraskan ejen anda dalam aplikasi desktop ChatGPT.

Dalam siaran ini, kami akan menerangkan sebab sistem berasaskan giliran terdahulu tidak dapat memenuhi keperluan kami serta cara kami mereka bentuk sistem baharu agar responsif pada setiap lapisan. Kami akan membincangkan inferens berkeadaan, pengurusan konteks dinamik, penugasan tak segerak dan pengoptimuman pada peringkat protokol semuanya bekerjasama untuk menjadikan GPT‑Live terasa benar-benar langsung.

Seni bina suara terdahulu mewarisi sifat LLM teks yang berasaskan giliran, tetapi setiap giliran diwakili sebagai gumpalan audio berasingan dan bukannya teks. Dalam sistem berjujukan, pertuturan kepada teks, LLM dan teks kepada pertuturan masing-masing dijalankan secara bersiri. Urutan ini menambah kependaman dan mengabaikan petunjuk seperti nada serta rentak.

Model pertuturan kepada pertuturan menambah baik pendekatan ini dengan memproses audio secara langsung. Melatih model untuk memahami dan menghasilkan pertuturan secara natif membolehkannya mengekalkan butiran yang hilang semasa transkripsi dan memberikan respons dengan lebih cepat. Namun, sistem masih bergantung pada pengesan giliran untuk menentukan waktu inferens boleh bermula. Model mengendalikan lebih banyak aspek interaksi, tetapi interaksi itu masih berasaskan giliran.

GPT‑Live memberikan kawalan perbualan kepada model suara: audio mengalir masuk dan keluar daripada model, manakala penaakulan yang lebih mendalam serta penggunaan alat berlaku secara tak segerak. Tugas utama sistem ialah mengekalkan gelung media tanpa gangguan. Kerja lain, seperti menggunakan model perbatasan dan mengekalkan perbualan, berlaku di luar laluan langsung.

Memastikan gelung media ini tidak terputus bukanlah sesuatu yang mudah. Sebarang kelewatan dalam pengangkutan, pemprosesan atau inferens boleh menghasilkan jeda atau hingar yang dapat didengar. Sistem berasaskan giliran sebelum ini boleh menerima sedikit perbezaan waktu ketibaan gumpalan audio. Namun, sistem media langsung perlu menghantar setiap bingkai audio mengikut jadual.

Usaha terdahulu pada ChatGPT Suara dan Realtime API memberikan asas penting kepada kami. Kami telah pun membina semula infrastruktur suara kami⁠ untuk menstrim audio dan video secara langsung ke dalam dan ke luar sistem dengan kependaman yang lebih rendah serta lebih mudah diramal. GPT‑Live mengembangkan reka bentuk itu dengan menstrim media hingga ke model melalui sistem inferens berkeadaan baharu yang dibina untuk perbualan berterusan.

Namun, inferens penstriman hanyalah sebahagian daripada penyelesaiannya. Untuk memastikan sistem berfungsi dengan baik dalam persekitaran produksi, kami juga perlu menjamin penghantaran audio yang andal dari klien ke tindanan inferens dan menangani cabaran sistem berkeadaan.

Salah satu keputusan awal kami ialah memisahkan aliran media secara khusus daripada logik aplikasi dan perniagaan. Audio bergerak antara klien dengan model suara melalui laluan pantas khusus. Penugasan, penggunaan alat dan kerja aplikasi lain berlaku di sebalik sempadan RPC tak segerak. Panggilan alat atau perkhidmatan bahagian belakang yang perlahan boleh melambatkan hasilnya sendiri, tetapi tidak boleh menyekat aliran media.

Pemisahan ini turut menyediakan sempadan yang jelas untuk penyesuaian sistem. Aplikasi boleh mengubah alat, dasar dan tingkah laku bahagian belakang tanpa menjejaskan bahagian hadapan media yang memastikan audio terus bergerak. Laluan langsung kekal ringkas, mudah diramal dan tertumpu pada kerja yang mesti dilakukan dalam masa nyata.

Kami menulis bahagian hadapan media dan logik inferens dalam Go, menggantikan pelaksanaan Python asyncio terdahulu. Ini meningkatkan kelancaran penghantaran bingkai dengan ketara, apabila p95 sistem baharu menyamai p50 sistem terdahulu.

WebRTC menyediakan asas pengangkutan. WebRTC direka untuk media berkependaman rendah dan boleh terus beroperasi apabila berlaku kehilangan paket, hanyutan jam serta perubahan sambungan klien. Jika paket tiba lewat, WebRTC boleh meregangkan audio secara halus untuk mengelakkan jurang, kemudian mempercepat main balik seketika bagi kembali seiring dengan masa nyata.

Dengan meminimumkan penimbalan dan sekatan di seluruh sistem, kami dapat memberikan tindak balas bawah satu saat yang diharapkan manusia daripada perbualan.

Inferens berkeadaan mempunyai kompromi operasinya tersendiri. Sesi suara mungkin kekal aktif untuk tempoh yang lama, tetapi konteksnya terus berkembang dan tika model dimulakan atau dihentikan mengikut permintaan.

Untuk menangani perkara ini, kami membina mekanisme penyerahan yang lancar merentas tika model. Apabila peralihan diperlukan, kami boleh menyediakan tika model gantian bersama tika sedia ada, mempramuatkannya dengan konteks sesi semasa, menjalankan inferens pada kedua-duanya secara serentak dan beralih apabila tika baharu benar-benar sedia.

Mekanisme asas yang sama turut menyokong pemadatan konteks dinamik. Apabila perbualan berterusan, konteks terkumpulnya akhirnya boleh melebihi had konteks model. Pemadatan boleh mengecilkan konteks agar mematuhi had, tetapi operasi ini mengambil masa. Oleh sebab operasi itu mengubah konteks terdahulu, operasi tersebut turut membatalkan cache nilai-kunci (KV) model, yang menyimpan kunci dan nilai perhatian daripada token yang diproses sebelum ini. Pembinaan semula keadaan itu memerlukan pramuat baharu, lalu menambah kelewatan.

Sebaliknya, kami mengendalikan pemadatan sebagai satu lagi peralihan terurus. Sementara tika model asal terus berbual, sistem memadatkan konteks dan menyediakan tika model gantian dengan konteks baharu. Setelah tika itu sedia, kami boleh beralih kepadanya tanpa sebarang gangguan media. Ini membolehkan sistem menyokong panggilan berpanjangan dengan melakukan pemadatan apabila perlu.

Kerja berat kekal di luar laluan langsung, jadi perbualan terus lancar walaupun semasa penyerahan.

Keupayaan GPT‑Live menggunakan model perbatasan sedia ada memberikannya banyak kuasa, dengan memisahkan proses “bercakap” daripada “berfikir” secara lebih mendalam. Namun, untuk menjadikan seni bina dua model ini terasa seperti satu sistem, kami perlu menyelesaikan dua masalah kejuruteraan yang berkaitan.

Pertama, hasil mesti diterima dengan cukup cepat agar berguna dalam perbualan yang sedang berlangsung. Oleh itu, kami perlu meminimumkan kependaman di seluruh laluan penugasan, daripada penghalaan dan pemprosesan prom hingga inferens dan panggilan alat. Pada masa yang sama, sistem lain dalam produk masih memerlukan mesej berasingan, jadi kami perlu mewakili perbualan yang sedang berlangsung dalam bentuk yang dapat difahami oleh sistem tersebut.

Apabila penugasan dihantar, kami mengoptimumkan masa sehingga model perbatasan menghasilkan sesuatu yang berguna untuk perbualan. Model suara boleh meneruskan perbualan seketika semasa model perbatasan menaakul atau menggunakan alat, tetapi tidak dapat menyembunyikan tindak balas yang terlalu perlahan. Oleh itu, kami menganggap seluruh gelung penugasan—penghalaan, pemprosesan prom, inferens dan panggilan alat—sebagai sebahagian daripada belanjawan masa tindak balas.

Pengoptimuman pertama ialah menyediakan model perbatasan dan segala alat yang diperlukan sebelum penugasan diminta. Apabila sesi suara bermula, pelayan aplikasi mencipta sesi inferens untuk model perbatasan dan mempramuatkannya dengan konteks awal perbualan, sekali gus memastikan prom telah diproses sepenuhnya sebelum permintaan penugasan pertama.

Kami kemudian mengekalkan ketersediaan sesi inferens itu sepanjang perbualan suara dan menggunakan perkaitan sesi yang stabil untuk permintaan seterusnya. Bersama caching prom, teknik ini mengurangkan kependaman di samping memastikan kegagalan pekerja mudah dipulihkan.

Usaha penaakulan, had output, skema alat dan perjalanan pergi balik antara model dengan alat turut mempengaruhi masa perbualan menerima hasil yang berguna, lalu kami melaraskan semua faktor ini untuk mempercepat respons. Dengan meminimumkan kerja yang diperlukan pada laluan penugasan, kami membolehkan model suara menerapkan hasil daripada model perbatasan kami dengan cepat.

Walaupun model suara beroperasi pada strim pertuturan berterusan, banyak sistem di sekelilingnya masih beroperasi berdasarkan giliran pengguna dan pembantu, termasuk UI perbualan ChatGPT serta sebahagian infrastruktur analitis dan keselamatan kami. Oleh itu, pelayan aplikasi menguraikan perbualan yang bertindih dan kadangkala kabur kepada mesej berasingan.

Apabila audio diterima, pelayan menggunakan transkrip separa dan isyarat masa untuk mengenal pasti penutur yang sedang bercakap dan membina baris gilir mesej. Mesej terbaharu kekal sementara; teks, masa dan penetapan penuturnya boleh berubah apabila lebih banyak pertuturan diterima. Setelah seseorang penutur bercakap cukup lama untuk membolehkan penetapan dibuat dengan yakin, pelayan memuktamadkan mesej berkenaan.

Pertindihan suara penutur menjadikan proses ini lebih rumit. Pengakuan ringkas daripada pembantu semasa pengguna sedang bercakap (misalnya, “mm hmm” atau “okay”) tidak semestinya perlu menjadi mesej tersendiri. Namun, celahan pembantu yang mengandungi maklumat penting biasanya perlu dijadikan mesej tersendiri. Begitu juga, kami mengutamakan kesinambungan respons pembantu yang dipaparkan walaupun pengguna bercakap di tengah-tengahnya.

Setiap dasar pensegmenan mengimbangi kesegeraan dengan kepastian. Memuktamadkan terlalu awal menghasilkan sejarah yang terpecah-pecah dan susunan yang tidak stabil; menunggu terlalu lama pula melambatkan transkrip serta ciri yang bergantung padanya. Oleh itu, sistem mengekalkan dua paparan perbualan yang berkaitan: paparan spekulatif bagi keadaan semasa dan rekod muktamad tentang perkara yang telah dikatakan. Paparan perbualan dalam UI aplikasi boleh mengendalikan kemas kini, jadi paparan itu menggunakan pandangan spekulatif. Namun, pengelogan ke dalam saluran analitis memerlukan transkrip muktamad.

Ini memberikan bahagian lain ChatGPT paparan perbualan yang stabil tanpa mengenakan sistem giliran pada laluan suara langsung.

Tahap respons mula dirasai sebaik sahaja pengguna mengklik butang. Dengan GPT‑Live, sistem mesti mewujudkan laluan media dan mula menyalurkan audio melalui model sebelum perbualan boleh bermula. Ini meletakkan setiap bahagian urutan permulaan pada laluan kritikal.

Seperti yang dinyatakan di atas, WebRTC menyediakan asas masa nyata yang kukuh, tetapi memulakan sesi WebRTC biasa memerlukan banyak jabat tangan protokol dan perjalanan pergi balik rangkaian. WebRTC dibangunkan sebelum tumpuan terhadap pengurangan perjalanan pergi balik yang membentuk protokol lebih baharu seperti QUIC. Akibatnya, protokol asasnya kadangkala mengulangi kerja apabila digunakan bersama. Sebagai contoh, setiap protokol menyertakan mekanisme anti-DoS sendiri, walaupun mekanisme itu tidak diperlukan dalam konteks tindanan WebRTC penuh.

Kami menganalisis tindanan tersebut dan membangunkan WebRTC Abridged Roundtrip Protocol (WARP⁠(dibuka dalam tetingkap baru)), yang mengurangkan permulaan media dan data daripada enam perjalanan pergi balik rangkaian kepada hanya satu. WARP mencapai ini melalui beberapa penambahbaikan protokol yang serasi dengan versi terdahulu: menumpangkan jabat tangan DTLS pada ICE (SPED⁠(dibuka dalam tetingkap baru)), menggunakan jabat tangan DTLS 1.3⁠(dibuka dalam tetingkap baru) yang lebih pantas, melakukan prarundingan jabat tangan SCTP (SNAP⁠(dibuka dalam tetingkap baru)) dan melakukan prarundingan saluran data dan bukannya menggunakan DCEP⁠(dibuka dalam tetingkap baru).

Kami mereka bentuk WARP sebagai satu set spesifikasi terbuka bersama rakan usaha sama daripada komuniti WebRTC supaya ekosistem yang lebih luas dapat memanfaatkan usaha ini. Kami sedang memajukan cadangan ini melalui kumpulan kerja TSVWG IETF. Sokongan WARP sudah ditambahkan pada libwebrtc dan Pion, manakala usaha untuk pelaksanaan WebRTC lain sedang dijalankan.

Selepas mengoptimumkan jabat tangan media, satu kelewatan yang masih ketara ialah pertukaran isyarat untuk berkongsi parameter SDP sebelum WebRTC dapat bersambung. Untuk mengeluarkan pertukaran itu daripada laluan kritikal, kami membangunkan sistem yang kami namakan Instant Connect. Sistem ini merundingkan parameter tersebut lebih awal tanpa menempah kapasiti pelayan dan tanpa sebarang perubahan pada pelaksanaan WebRTC sedia ada.

Instant Connect berjalan seiring dengan aliran isyarat standard. Jika parameter yang dirundingkan lebih awal itu sah, pelayan boleh merealisasikan sesi apabila paket media pertama tiba. Jika parameter itu lapuk atau tidak sah, aliran isyarat sudah pun berjalan, jadi klien boleh kembali kepada kaedah biasa tanpa kependaman tambahan.

Bersama-sama, Instant Connect dan WARP mengurangkan masa antara niat pengguna dengan aliran media langsung secara mendadak. Dengan pertukaran SDP dikeluarkan daripada laluan kritikal dan WARP memendekkan jabat tangan pengangkutan, klien kini boleh memulakan sesi menggunakan satu paket UDP sahaja. Pelayan boleh memberikan respons serta-merta, lalu membolehkan bahagian lain sistem mula melakukan perkara yang benar-benar penting kepada pengguna: mendengar dan menjawab.

Sistem mungkin kelihatan pantas secara teori tetapi masih boleh tersekat apabila mengendalikan trafik suara sebenar. Sebelum membenarkan GPT‑Live berbual dengan pengguna, kami menjalankan ujian senyap yang menghalakan sebahagian kecil sesi ChatGPT Suara dalam persekitaran produksi yang ditingkatkan secara beransur-ansur kepada pengalaman mod suara lanjutan sedia ada dan sistem baharu kami. Mod suara lanjutan terus melayani pengguna seperti biasa, manakala laluan bayangan menjalankan inferens dalam mod baca sahaja. Ini mendedahkan sistem kepada klien, rangkaian, tempoh sesi dan taburan geografi sebenar tanpa mengubah perkara yang didengar oleh pengguna.

Antara pengajaran pertama yang diperoleh ialah kapasiti tidak boleh dinilai berdasarkan daya pemprosesan GPU semata-mata. Sesi suara kekal terbuka dan menghantar bingkai secara berterusan, maka pengendali strim pada CPU, baris gilir dan laluan rangkaian mesti diskalakan seiring dengan inferens. Di bawah beban sebenar, satu komponen sokongan mencapai kapasiti maksimum lebih awal daripada anggaran ujian beban kami, menyebabkan permintaan inferens terkumpul dan kependaman terus bertambah. Kami mengubah persoalan kapasiti daripada “Berapa banyak permintaan yang boleh dikendalikan oleh GPU?” kepada “Berapa banyak sesi serentak yang boleh ditampung oleh sistem sambil memastikan setiap bingkai dihantar mengikut jadual?”

Ujian ini turut menjadikan faktor geografi sebagai keutamaan utama. Menghalakan sesi kepada kapasiti yang jauh boleh menambah kelewatan pada beberapa peringkat semasa permulaan dan penstriman. Kami mula mengesahkan pelancaran model bersama-sama kapasiti serantau dan konfigurasi penghalaan trafik, kemudian menganalisis kependaman mengikut geografi sumber. Memindahkan inferens lebih dekat kepada pengguna membantu, tetapi turut mengukuhkan pengajaran yang lebih luas: tahap respons hujung ke hujung bergantung pada setiap perkhidmatan dalam laluan, bukan pelayan model sahaja.

Kegagalan lain hanya muncul sepanjang kitar hayat sesi yang realistik. Sesi yang berjalan lama mendedahkan tekanan pada memori dan pengekalan data. Penyambungan semula menguji pemadatan dan pemulihan keadaan. Pemutusan sambungan klien yang biasa mendedahkan keadaan perlumbaan dalam jabat tangan penutupan. Masalah ini jarang muncul dalam ujian beban singkat kerana bergantung pada masa, keadaan yang terkumpul dan tingkah laku merentas sempadan perkhidmatan.

Akhir sekali, ujian dalam persekitaran produksi memaksa kami menambah baik kebolehcerapan dan kawalan pelancaran. Kami menemui metrik yang mencampuradukkan pelbagai punca kependaman, papan pemuka dengan data agregat yang menyembunyikan enjin individu yang bermasalah serta perbezaan konfigurasi antara sistem yang diuji dengan sistem yang digunakan. Sebagai tindak balas, kami menambah telemetri yang lebih terperinci, pengesahan terhadap konfigurasi yang terbukti baik, peningkatan berperingkat serta keupayaan untuk mengasingkan atau menyahdayakan laluan individu dengan cepat. Ujian senyap itu menjadi raptai awal pelancaran bukan sahaja untuk menentukan jumlah trafik yang boleh diterima oleh sistem, tetapi juga seberapa cepat kami dapat mengesan, membendung dan memulihkan kegagalan.

Membawa GPT‑Live ke skala ChatGPT memerlukan sistem serba baharu yang dibina berteraskan satu prinsip asas: suara mesti terus mengalir. Inferens penstriman terus membekalkan audio kepada model dupleks penuh. Laluan media khusus memastikan penghantaran bingkai yang andal. Penugasan tak segerak membolehkan proses pemikiran yang lebih mendalam berjalan serentak. Pengangkutan yang dioptimumkan memastikan pengalaman kekal responsif hingga sampai kepada pengguna.

Seni bina di sebalik GPT‑Live sudah mula berkembang menjadi platform yang lebih luas untuk interaksi masa nyata. Seni bina ini menguasakan ChatGPT Suara ketika fungsinya berkembang daripada perbualan kepada penyelarasan berasaskan ejen, dan akan menjadi asas kepada API GPT‑Live yang akan datang. Dari semasa ke semasa, seni bina ini akan membolehkan pengalaman suara merangkumi lebih banyak peranti, aplikasi dan modaliti tanpa menjejaskan tindak balas segera yang menjadikan perbualan suara terasa langsung.

Jika inilah jenis masalah kejuruteraan yang ingin anda selesaikan, sertai kami⁠.