Bagaimana OpenAI menghadirkan AI suara latensi rendah dalam skala besar

 (openai.com)
3 poin oleh GN⁺ 7 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • OpenAI merancang ulang stack WebRTC-nya menjadi arsitektur relay + transceiver untuk menyediakan percakapan suara yang natural bagi lebih dari 900 juta pengguna aktif mingguan, sambil tetap mempertahankan perilaku WebRTC standar di sisi klien
  • WebRTC menstandarkan ICE, DTLS/SRTP, negosiasi codec, kontrol kualitas RTCP, penghapusan echo, dan buffering jitter, sehingga cocok untuk menangani aliran audio kontinu berlatensi rendah antara browser, aplikasi mobile, dan server
  • Karena sebagian besar sesi OpenAI adalah sesi 1:1 antara satu pengguna dan satu model, atau satu aplikasi dan satu agen real-time, model transceiver dinilai lebih cocok untuk latensi dan skalabilitas dibanding SFU yang ditujukan untuk panggilan multipihak
  • Model WebRTC yang mengekspos satu port UDP per sesi di Kubernetes membuat rentang port publik besar, konfigurasi load balancer, health check, kebijakan firewall, dan keamanan rollout menjadi rumit, sehingga dibutuhkan permukaan UDP yang kecil dan tetap
  • Relay menggunakan petunjuk routing yang disimpan di ICE ufrag pada paket STUN pertama untuk menemukan transceiver pemilik dan meneruskan paket, sementara transceiver memiliki ICE, DTLS, SRTP, dan lifecycle sesi agar kompatibilitas WebRTC standar serta jalur ingress terdekat secara global tetap terjaga

Persyaratan AI suara latensi rendah

  • AI suara terasa natural ketika percakapan bergerak secepat laju bicara, dan latensi jaringan langsung terlihat lewat jeda canggung, interupsi yang terpotong, atau respons terhadap interupsi yang terlambat
  • Pada skala OpenAI, dibutuhkan jangkauan global untuk lebih dari 900 juta pengguna aktif mingguan, setup koneksi yang cepat agar pengguna bisa berbicara segera setelah sesi dimulai, waktu pulang-pergi media yang rendah dan stabil, serta jitter dan packet loss yang rendah
  • Karakteristik latensi ini memengaruhi ChatGPT voice, Realtime API, agen dalam alur kerja percakapan, dan model yang harus memproses audio saat pengguna masih berbicara
  • OpenAI merancang ulang stack WebRTC dengan struktur terpisah relay + transceiver untuk mengubah routing paket internal sambil mempertahankan perilaku WebRTC standar di sisi klien

Mengapa memilih WebRTC

  • WebRTC adalah standar terbuka untuk mengirim audio, video, dan data berlatensi rendah antara browser, aplikasi mobile, dan server, serta cocok sebagai fondasi sistem real-time client-server
  • WebRTC menstandarkan setup koneksi dan traversal NAT melalui ICE, transport terenkripsi DTLS/SRTP, negosiasi codec, kontrol kualitas RTCP, serta fitur klien seperti penghapusan echo dan buffering jitter
  • Tanpa WebRTC, setiap klien harus menangani sendiri pembentukan koneksi di lingkungan NAT, enkripsi media, negosiasi codec, dan respons terhadap perubahan jaringan
  • Karakteristik penting untuk produk AI adalah audio datang sebagai aliran kontinu, sehingga transkripsi, inferensi, pemanggilan tool, dan pembuatan suara dapat dimulai tanpa menunggu seluruh unggahan pengguna selesai
  • Perbedaan inilah yang membedakan sistem yang terasa percakapan interaktif dari sistem yang terasa seperti push-to-talk
  • OpenAI membangun di atas ekosistem WebRTC, termasuk implementasi open-source yang matang dan kerja standardisasi, dan berkat fondasi dari Justin Uberti serta Sean DuBois, mereka bisa membangun di atas infrastruktur media yang sudah teruji tanpa harus membuat ulang transport tingkat rendah, enkripsi, dan kontrol kemacetan

Arsitektur yang memilih transceiver alih-alih SFU

  • Saat SFU cocok digunakan

    • SFU adalah server media yang menerima stream WebRTC dari tiap partisipan lalu meneruskannya secara selektif ke partisipan lain
    • Dalam model SFU, koneksi WebRTC dari setiap partisipan diakhiri secara terpisah, dan AI juga bergabung sebagai partisipan lain dalam sesi
    • SFU dapat cocok untuk produk yang secara inheren multipihak, seperti panggilan grup, kelas, atau rapat kolaboratif
    • Codec audio, pesan RTCP, data channel, perekaman, dan kebijakan per stream dapat dipusatkan di satu tempat
    • Bahkan pada produk client-ke-AI, SFU mudah menjadi titik awal default karena pemrosesan sinyal, routing media, perekaman, observabilitas, dan perluasan masa depan seperti handoff ke manusia atau penambahan partisipan dapat digunakan ulang dalam satu sistem

  • Beban kerja OpenAI

    • Sebagian besar sesi OpenAI adalah sesi 1:1 antara satu pengguna dan satu model, atau satu aplikasi dan satu agen real-time
    • Karena pola trafik ini sensitif terhadap latensi di setiap giliran percakapan, OpenAI memilih model transceiver
    • Dalam model transceiver, layanan edge WebRTC mengakhiri koneksi klien lalu mengubah media dan event menjadi protokol internal sederhana untuk inferensi model, transkripsi, pembuatan suara, penggunaan tool, dan orkestrasi
    • Transceiver adalah satu-satunya layanan yang memiliki status sesi WebRTC, termasuk pemeriksaan koneksi ICE, handshake DTLS, kunci enkripsi SRTP, dan lifecycle sesi
    • Dengan menempatkan status sesi di satu tempat, kepemilikan sesi menjadi lebih mudah dipahami, dan layanan backend dapat diskalakan seperti layanan biasa tanpa harus berperilaku seperti peer WebRTC

Implementasi awal dan batasan yang ditemui di Kubernetes

  • Implementasi pertama OpenAI adalah satu layanan Go berbasis Pion yang menangani pemrosesan sinyal sekaligus terminasi media
  • Layanan transceiver ini menjalankan ChatGPT voice, endpoint WebRTC pada Realtime API, dan berbagai proyek riset
  • Secara operasional, transceiver menangani negosiasi SDP, pemilihan codec, kredensial ICE, dan setup sesi pada bagian signaling
  • Pada bagian media, ia mengakhiri koneksi WebRTC downstream dan mempertahankan koneksi upstream dengan layanan backend untuk inferensi dan orkestrasi
  • OpenAI ingin menjalankan layanan ini di atas Kubernetes agar dapat diskalakan naik-turun sesuai perubahan permintaan dan dipindahkan antar host
  • Model WebRTC tradisional satu port per sesi tidak cocok dengan lingkungan Kubernetes dan mengharuskan rentang besar port UDP publik untuk diekspos, diamankan, dan dipelihara
  • Pada concurrency tinggi, satu port per sesi berarti harus mengekspos dan mengelola rentang port UDP yang sangat besar
  • Load balancer cloud dan layanan Kubernetes tidak dirancang dengan asumsi puluhan ribu port UDP publik per layanan, dan semakin besar rentang port, semakin rumit konfigurasi load balancer, health check, kebijakan firewall, dan keamanan rollout
  • Rentang port UDP yang besar juga merugikan dari sisi keamanan karena memperluas permukaan yang dapat dijangkau dari luar dan mempersulit audit kebijakan jaringan
  • Di Kubernetes, pod terus ditambah, dihapus, dan dijadwalkan ulang; bila tiap pod harus memesan dan mengiklankan rentang port besar yang stabil, elastisitas sistem menjadi rapuh

Masalah port tunggal dan kepemilikan sesi

  • Banyak sistem WebRTC mengurangi masalah jumlah port dengan memakai satu port UDP per server dan demultipleksing di level aplikasi
  • Desain satu port per server memang mengurangi jumlah port, tetapi menimbulkan masalah kedua: menjaga kepemilikan setiap sesi di seluruh fleet
  • ICE dan DTLS adalah protokol stateful, sehingga proses yang membuat sesi harus terus menerima paket sesi itu untuk memverifikasi pemeriksaan koneksi, menyelesaikan handshake DTLS, mendekripsi SRTP, dan menangani perubahan sesi berikutnya seperti ICE restart
  • Jika paket dari sesi yang sama tiba di proses yang berbeda, setup bisa gagal atau media bisa rusak
  • Tujuan OpenAI adalah mengekspos hanya permukaan UDP yang kecil dan tetap ke internet publik sambil tetap merutekan semua paket ke transceiver yang memiliki sesi WebRTC terkait

  • Pendekatan yang ditinjau

    • IP:port unik per sesi memberikan jalur media client-server langsung tanpa lapisan forwarding pada jalur data, tetapi membutuhkan satu port UDP publik per sesi dan rentang port besar yang tidak cocok untuk Kubernetes, load balancer cloud, dan keamanan
    • IP:port unik per server jauh lebih kecil jejak UDP publiknya dibanding eksposur per sesi dan satu socket bersama dapat mendemultipleks banyak sesi, tetapi pada fleet load balancing bersama, paket pertama bisa tiba di instance yang salah sehingga dibutuhkan cara deterministik untuk mengirimnya ke proses pemilik sesi
    • TURN relay hanya mengharuskan klien menjangkau alamat dan port TURN relay, dan kebijakan bisa dipusatkan di edge, tetapi allocation TURN menambah round-trip saat setup dan pemindahan atau pemulihan allocation antar server TURN tetap sulit
    • Arsitektur OpenAI berupa stateless forwarder + stateful terminator, yaitu relay + transceiver, menjaga footprint UDP publik tetap kecil dan membiarkan transceiver memiliki seluruh sesi WebRTC, tetapi menambah satu hop forwarding sebelum media mencapai transceiver pemilik dan memerlukan koordinasi kustom antara relay dan transceiver

Arsitektur relay + transceiver

  • Arsitektur yang dideploy OpenAI memisahkan routing paket dan terminasi protokol
  • Signaling mencapai transceiver untuk setup sesi, sementara media masuk lebih dulu ke relay
  • Relay adalah lapisan forwarding UDP ringan dengan footprint publik kecil, sedangkan transceiver adalah endpoint WebRTC stateful di belakangnya
  • Relay tidak mendekripsi media, tidak menjalankan state machine ICE, dan tidak ikut dalam negosiasi codec
  • Relay hanya membaca metadata paket yang cukup untuk memilih tujuan, lalu meneruskan paket ke transceiver yang memiliki sesi
  • Transceiver tetap melihat alur WebRTC yang normal dan memiliki semua status protokol
  • Dari sudut pandang klien, sesi WebRTC tidak berubah

Routing paket pertama dan pemanfaatan ICE ufrag

  • Inti arsitektur ini adalah relay merutekan paket klien pertama langsung di jalur paket itu sendiri
  • Sesi WebRTC sudah memiliki hook routing native pada protokol, yaitu ICE username fragment atau ufrag
  • Ufrag adalah pengenal singkat yang dipertukarkan saat setup sesi dan dibawa kembali pada pemeriksaan koneksi STUN
  • OpenAI menghasilkan ufrag sisi server dengan metadata routing yang cukup agar relay dapat menyimpulkan cluster tujuan dan transceiver pemilik
  • Saat signaling, transceiver mengalokasikan status sesi dan mengembalikan SDP answer yang berisi relay VIP bersama dan port UDP
  • VIP adalah alamat IP virtual di depan fleet relay, yang bila dipasangkan dengan port memberi klien satu tujuan stabil seperti 203.0.113.10:3478 meskipun ada banyak instance relay di belakangnya
  • Paket pertama pada media path dari klien biasanya berupa STUN binding request, dan ICE menggunakannya untuk memverifikasi bahwa paket dapat mencapai alamat yang diiklankan
  • Relay mem-parsing STUN pertama hanya sejauh perlu untuk membaca ufrag server, mendekode petunjuk routing, dan meneruskan paket ke transceiver pemilik sesi
  • Setiap transceiver menerima lewat shared UDP socket—endpoint sistem operasi yang terikat ke IP:port internal—bukan satu socket per sesi
  • Setelah relay membuat sesi dari source IP:port klien ke tujuan transceiver, paket DTLS, RTP, dan RTCP berikutnya mengalir dalam sesi itu tanpa perlu mendekode ulang ufrag
  • Status sesi pada relay dijaga seminimal mungkin: hanya sesi in-memory untuk forwarding paket, counter monitoring, serta timer untuk kedaluwarsa dan pembersihan sesi
  • Jika relay restart dan kehilangan sesi, paket STUN berikutnya akan membuat ulang sesi menggunakan petunjuk routing dari ufrag
  • Setelah jalur terbentuk, Redis cache menyimpan mapping <client IP + Port, transceiver IP + Port> sehingga pemulihan bisa lebih cepat bahkan sebelum paket STUN berikutnya datang

Global Relay dan jalur masuk yang lebih dekat

  • Setelah mengurangi permukaan UDP publik menjadi alamat dan port yang kecil serta stabil, OpenAI dapat menyebarkan pola relay yang sama secara global
  • Global Relay adalah fleet ingress relay yang tersebar secara geografis dan menerapkan perilaku packet-forwarding yang sama
  • Ingress geografis yang luas memungkinkan paket pengguna masuk ke jaringan OpenAI melalui relay yang dekat secara geografis dan topologi jaringan, alih-alih terlebih dahulu menyeberangi internet publik ke region yang jauh, sehingga hop pertama klien-ke-OpenAI menjadi lebih pendek
  • Pendekatan ini mengurangi latensi, jitter, dan burst loss yang sebenarnya bisa dihindari sebelum trafik mencapai backbone
  • OpenAI menggunakan geo dan proximity steering dari Cloudflare pada signaling agar permintaan HTTP atau WebSocket awal mencapai cluster transceiver terdekat
  • Konteks permintaan menentukan lokasi sesi dan ingress point Global Relay yang akan diiklankan ke klien
  • SDP answer memberikan alamat Global Relay, dan ufrag memuat cukup informasi agar Global Relay dapat merutekan media ke cluster yang ditentukan lalu relay meneruskannya ke transceiver tujuan
  • Dengan menggabungkan signaling yang di-geo-steer dan Global Relay, setup maupun media sama-sama ditempatkan pada jalur masuk terdekat sambil tetap mengikat sesi ke satu transceiver
  • Struktur ini mengurangi round-trip untuk signaling dan pemeriksaan koneksi ICE pertama, sehingga langsung mengurangi waktu tunggu sebelum pengguna bisa mulai berbicara

Cara relay diimplementasikan

  • Layanan relay ditulis dalam Go dan sengaja dijaga tetap sempit ruang lingkup implementasinya
  • Di Linux, kernel networking stack menerima paket UDP dari antarmuka jaringan dan mengirimkannya ke socket, lalu relay sebagai proses Go biasa di userspace membaca header paket dari socket
  • Relay memperbarui sedikit flow state dan meneruskan paket tanpa mengakhiri WebRTC
  • OpenAI tidak memakai kernel-bypass framework yang membuat proses userspace melakukan polling langsung pada network queue untuk packet rate lebih tinggi, karena pendekatan itu dinilai menambah kompleksitas operasional

  • Pilihan desain utama

    • Tanpa terminasi protokol: relay hanya mem-parsing header STUN dan ufrag, lalu untuk DTLS, RTP, dan RTCP berikutnya memakai state yang di-cache sehingga paket diperlakukan sebagai opaque
    • Status sementara: relay mempertahankan map in-memory kecil dengan timeout singkat dari alamat klien ke tujuan transceiver untuk flow state dan observabilitas
    • Skalabilitas horizontal: banyak instance relay berjalan paralel di belakang load balancer, dan karena state relay bukan hard WebRTC state, restart hanya menyebabkan drop trafik kecil dan pemulihan flow yang cepat

  • Langkah optimasi

    • SO_REUSEPORT adalah opsi socket Linux yang memungkinkan banyak worker relay bind ke port UDP yang sama pada mesin yang sama, lalu kernel membagi paket masuk ke para worker untuk menghindari bottleneck satu read loop
    • runtime.LockOSThread mengunci setiap goroutine pembaca UDP ke thread OS tertentu
    • Dengan memakai SO_REUSEPORT dan thread pinning bersama, paket dari flow yang sama cenderung tetap di core CPU yang sama, sehingga cache locality membaik dan context switching berkurang
    • Buffer yang dialokasikan di awal dan penyalinan minimal menurunkan overhead parsing dan alokasi, serta membantu menghindari garbage collection Go
    • Karena implementasi ini mampu menangani trafik media real-time global OpenAI dengan footprint relay yang relatif kecil, OpenAI memilih mempertahankan desain yang lebih sederhana tanpa menempuh jalur kernel bypass

Hasil dan pelajaran

  • Arsitektur ini memungkinkan menjalankan media WebRTC di Kubernetes tanpa harus mengekspos ribuan port UDP
  • Permukaan UDP yang kecil dan tetap mempermudah keamanan dan load balancing, serta memungkinkan infrastruktur diskalakan tanpa harus memesan rentang besar port publik
  • Desain ini mempertahankan perilaku WebRTC standar di sisi klien dan menegaskan bahwa desain tanpa SFU adalah default yang tepat untuk beban kerja OpenAI
  • Sebagian besar sesi bersifat point-to-point dan sensitif terhadap latensi, serta layanan inferensi lebih mudah diskalakan bila tidak harus berperilaku seperti peer WebRTC
  • Lebih tepat menempatkan kompleksitas pada lapisan routing yang tipis daripada pada semua layanan backend atau perilaku klien kustom
  • Dengan mengenkode metadata routing ke field yang native bagi protokol, OpenAI memperoleh routing paket pertama yang deterministik, footprint UDP publik yang kecil, dan fleksibilitas untuk menempatkan ingress dekat dengan pengguna di seluruh dunia

  • Pilihan yang sangat penting

    • Mempertahankan semantik protokol di edge: klien tetap menggunakan WebRTC standar, sehingga interoperabilitas browser dan mobile tetap terjaga
    • Menjaga session state yang sulit di satu tempat: transceiver memiliki ICE, DTLS, SRTP, dan lifecycle sesi, sementara relay hanya meneruskan paket
    • Routing memakai informasi yang sudah ada saat setup: ICE ufrag menyediakan hook routing paket pertama tanpa ketergantungan lookup pada hot path
    • Memprioritaskan optimasi common case dibanding kernel bypass: implementasi Go yang sempit dengan penggunaan hati-hati atas SO_REUSEPORT, thread pinning, dan parsing beralokasi rendah sudah cukup untuk beban kerja OpenAI
    • AI suara real-time bekerja ketika infrastruktur membuat latensi terasa tidak ada, dan OpenAI memilih mengubah cara WebRTC dideploy tanpa mengubah perilaku yang diharapkan klien dari WebRTC

Bacaan terkait

1 komentar

 
GN⁺ 7 jam lalu
Komentar Hacker News

  • Terima kasih banyak kepada OpenAI karena telah menampilkan use case untuk library Pion yang saya kerjakan
    Kalau belum terlalu paham WebRTC, ini bidang yang cukup menarik, dan saya juga sedang mengerjakan buku yang menjelaskan cara kerjanya, WebRTC for the Curious
    https://github.com/pion/webrtc
    https://webrtcforthecurious.com

    • Saya menggunakan Pion. Tapi saya penasaran apakah pendekatan OpenAI ini benar-benar diperlukan
      Rasanya mereka menambah kompleksitas besar-besaran demi memangkas bagian yang sebenarnya sudah termasuk cepat dalam stack AI suara. Model yang cepat dan deteksi aktivitas suara (VAD) yang akurat tampaknya jauh lebih penting daripada menyetel waktu transmisi WebRTC secara sangat halus
    • Terima kasih sudah menaruh seluruh bukunya secara online
      Dulu saya pernah punya ide mengirim data dari database ke klien browser lewat CLI menggunakan WebRTC data channel, jadi saya sempat membaca sebagian isinya, lalu jadi paham bahwa itu tidak terlalu cocok untuk kebutuhan saya. Akhirnya saya memakai control plane tersentralisasi dan WebSocket
      Meski begitu, kombinasi WebRTC data channel + Apache Arrow ArrayBuffer tanpa copy + duckdb WASM terasa seperti bisa dipakai membuat sesuatu yang menarik, hanya saja saya belum menemukan apa itu
    • Agak di luar topik, tapi saya penasaran kenapa seluruh codebase ditaruh di direktori root alih-alih dalam folder src bertingkat
      Jadi jauh lebih susah untuk masuk ke README

  • Latensi rendah lebih terasa sebagai penderitaan daripada keunggulan implementasi
    Saat ingin mengobrol santai, orang secara alami berhenti sebentar, tetapi GPT menganggap itu sebagai “sudah selesai bicara” lalu langsung mulai ngoceh
    Seiring bertambah usia, saya butuh lebih banyak waktu untuk menemukan kata yang ingin saya ucapkan, dan voice GPT yang secepat ini lebih menjengkelkan daripada membantu. Saya jadi harus menyusun seluruh kalimat di kepala sebelum mulai bicara, dan itu sama sekali tidak terasa alami

    • Ada dua lapisan latensi yang berbeda tercampur di sini
      Latensi yang dibahas artikel ini adalah latensi transmisi pada stream audio itu sendiri, sedangkan latensi dalam situasi ini lebih dekat ke seberapa cepat sistem mulai merespons di dalam stream audio
    • Saya juga pernah mengalaminya dan memang sangat menyebalkan
      Muncul tekanan untuk terus bicara padahal saya belum selesai berpikir, jadi terasa cukup tidak alami. Kalau sedang mencari kata yang tepat, kita butuh kesempatan untuk menemukannya
      Menurut saya solusinya bukan protokol dengan latensi lebih tinggi, melainkan penanganan jeda yang lebih cerdas. Jika latensinya rendah, bot bisa langsung berhenti bicara saat pengguna menyela
    • Dalam percakapan suara, saya menyuruhnya untuk jangan menjawab sama sekali sampai saya memakai kata kode tertentu, atau cukup mengatakan “baik”
      Tidak sempurna, tapi jadi lebih jarang menyela
    • Ini lebih terkait dengan deteksi aktivitas suara (VAD) daripada latensi yang dibahas dalam artikel
    • Ini masalah yang sulit. Tanpa sadar saya jadi menambahkan ungkapan filler supaya bot tidak mulai ngoceh
      Dan sepertinya sebagian besar kecerdasannya dipakai bukan untuk memikirkan masalah, melainkan untuk terdengar meyakinkan. Semacam, “Ya, tentu. Saya paham kenapa Anda menginginkan itu…” Mungkin karena ada batasan waktu dan pemrosesan suara lebih mahal. Respons teks menghabiskan lebih banyak waktu untuk tugas itu sendiri

  • “Lebih dari 900 juta pengguna aktif mingguan” jelas tampaknya mengacu pada total pengguna ChatGPT, dan proporsi yang memakai fitur suara mungkin jauh lebih kecil
    Angka seperti ini memengaruhi keputusan bisnis, misalnya seberapa besar optimisasi hardware dan software yang layak dituangkan ke masalah ini

    • Betul. Mungkin itu sebabnya mereka memakai istilah “reach”
      Artinya total pengguna yang bisa terekspos ke fitur tersebut, terlepas dari apakah mereka benar-benar memakainya

  • Senang melihat mereka berbagi, tetapi perlu diingat bahwa model audio real-time OpenAI masih bertahan di level keluarga 4o dari sisi kemampuan
    Meski begitu tetap sangat berguna, dan sayang sekali belum ada pesaing nyata di bidang ini. Pengalaman yang terasa seperti percakapan sungguhan sangat membantu dalam mengekspresikan ide dan konsep
    Patut diingat bahwa, tidak seperti saat pertama dirilis, sekarang ini bukan lagi model paling depan. Kalau Sam melihat ini, semoga dia merilis model audio real-time yang baru

    • Di realtime/voice mode OpenAI, bagian suara-nya luar biasa, tetapi dibanding model terbaru, modelnya sendiri cukup bodoh dan sering mengulang hal yang sama
      Gemini flash live 3.1 dari Google lebih baik, terutama jika dipakai lewat API. Ia juga bisa melakukan tool calling, dan kalau dirakit sendiri bisa dihubungkan ke LLM lain yang lebih pintar, dengan level penalaran yang juga bisa diatur. Bahkan level penalaran tinggi pun masih cukup dekat dengan real-time, dan jawaban bisa diperkuat dengan pencarian Google. Jika Anda menyukai suara dua arah, ini mungkin pilihan terbaik saat ini, dan bisa dicoba di AI Studio

  • Kalau ingin masuk ke bidang ini, pipecat adalah repositori open source dan komunitas yang bagus
    https://github.com/pipecat-ai/pipecat

  • Kalau model yang lebih baik menjawab setelah berpikir lebih lama, saya tidak masalah menunggu respons lebih lama
    Asalkan dukungan interupsi bagus, tidak langsung mulai menjawab hanya karena saya berhenti 1 detik, dan bisa menilai dengan cerdas apakah saya benar-benar sudah selesai bicara

  • Ini mungkin bukan sekadar masalah latensi
    Jika pengguna dipertahankan dalam percakapan suara, Anda bisa mendapatkan data pelatihan yang tidak akan pernah didapat dari teks. Jadi mungkin itulah alasan mereka memilih pendekatan transceiver alih-alih SFU dan pada dasarnya mengabaikan percakapan multipihak

  • Apakah ini berarti OpenAI sekarang tidak lagi memakai LiveKit untuk WebRTC/audio?

    • Kelihatannya begitu
      Dalam arsitektur ini, server LiveKit tampaknya memang bukan bentuk yang mereka inginkan. Sebenarnya pembahasan SFU di artikel itu juga kurang lebih mengatakan hal yang sama. Tapi di sisi klien, SDK-nya masih punya banyak hal yang berguna

  • Jika transceiver crash di tengah stream, bagaimana sesi aktif dipulihkan?
    Apakah sistem secara otomatis membangun ulang konteks di sesi WebRTC yang baru?

  • Kalau ingin mencari teman, menurut saya lebih baik ikut klub atau komunitas dalam bentuk apa pun