OpenAI pada 4 Mei mengumumkan detail infrastruktur dasar AI suara—untuk mendukung layanan AI suara bagi 900 juta pengguna aktif mingguan (Weekly Active Users), tim merancang ulang tumpukan WebRTC, mengubah arsitektur lapisan koneksi media dari pola tradisional “satu port untuk satu session” menjadi relay tipis yang ditulis dengan Go, serta memusatkan seluruh status session WebRTC ke sebuah layanan bernama “transceiver”. Penjelasan ini disampaikan melalui blog resmi OpenAI; arsitektur ini sekaligus mendukung mode suara ChatGPT, Realtime API, dan berbagai proyek penelitian. Ini adalah literatur teknis yang jarang bagi tim mana pun yang mengerjakan rekayasa AI suara—bagian “bagaimana infrastruktur AI suara skala global bisa bertahan”.
Tiga batasan teknis: WebRTC tradisional di skala OpenAI semuanya mentok
Tim engineering OpenAI dalam tulisan itu secara jelas menyoroti tiga batasan yang “saling bentrok” setelah skala dibesarkan:
Metode penghentian media per sesi dengan “satu session satu port” (per-session port termination) tidak cocok untuk infrastruktur OpenAI—karena setiap minggunya ada 900 juta pengguna dan kemungkinan membuka session suara secara bersamaan, desain yang memberi satu port untuk tiap session akan menghabiskan sumber daya jaringan
Sesi ICE (Interactive Connectivity Establishment) dan DTLS (Datagram Transport Layer Security) yang memiliki state, yang perlu pemilik yang stabil—dalam sistem terdistribusi, jika status session dibagi ke beberapa layanan, toleransi kesalahan dan migrasi menjadi sangat rumit
Routing global harus mempertahankan latensi first-hop rendah (first-hop latency)—“rasa alami” pada AI suara ditentukan oleh kelancaran turn-taking (pergantian giliran dalam percakapan), dan jika first-hop melebihi 100ms akan terasa jelas tersendat
Daftar kebutuhan OpenAI juga sama jelasnya: jangkauan global (meliputi 900 juta+ pengguna), pembuatan session yang cepat (pengguna mulai berbicara langsung bisa), serta media round-trip time yang rendah dan stabil (termasuk rendahnya jitter dan hilangnya paket).
Solusi: relay tipis berbasis Go + layanan transceiver terpusat
Arsitektur OpenAI dibagi menjadi dua lapisan:
Lapisan Relay—ditulis dengan Go, sengaja dibuat tetap sederhana. Satu proses Go biasa membaca paket dari socket, memperbarui sedikit status aliran (traffic state), meneruskan paket, dan tidak mengakhiri WebRTC. Inilah kunci agar relay bisa diperluas secara horizontal—tidak perlu mempertahankan status WebRTC lengkap, relay antar-mesin bisa saling dipertukarkan tanpa rasa sakit, dan kegagalan satu titik tidak akan memutus seluruh session.
Lapisan Transceiver—satu-satunya layanan yang memiliki status session WebRTC, mencakup pengecekan koneksi ICE, jabat tangan DTLS, kunci enkripsi SRTP, dan manajemen siklus hidup session. Dengan memusatkan state ke satu layanan, kepemilikan session menjadi mudah ditelusuri, dan layanan backend dapat diperluas seperti layanan biasa tanpa harus bertindak sebagai WebRTC peer.
Keistimewaan desain ini ada pada pemisahan yang ketat antara bagian yang “membutuhkan state” dan bagian yang “tanpa state”. Relay adalah bidang data tanpa state (dapat direplikasi dalam jumlah besar), sedangkan transceiver adalah bidang kontrol berstate (jumlahnya lebih sedikit, namun state lengkap). Pembagian lapisan ini juga memungkinkan OpenAI memperluas secara horizontal sesuai kebutuhan tanpa perlu khawatir ledakan jumlah koneksi WebRTC.
Mengapa memakai Go: logika pemilihan untuk rekayasa AI suara
OpenAI dalam artikel itu secara tegas menyatakan relay ditulis dengan Go, dengan implementasi yang sengaja dibuat sempit. Di balik pilihan ini ada pertimbangan engineering berikut:
Goroutine Go secara native mendukung tugas IO-bound seperti “memproses puluhan ribu koneksi pada satu port”, tanpa perlu event loop yang rumit
Paket net pada pustaka standar bisa langsung membaca paket UDP tanpa harus menautkan ke library fungsi C
Hasil kompilasi berupa satu binary statis; deployment, containerisasi, dan dukungan lintas arsitektur (x86/ARM) jadi mudah
Manajemen memori Go ramah untuk “banyak objek berumur sangat singkat” (setiap paket perlu diparse), dan jeda GC bisa dikendalikan
Hal ini juga menjelaskan mengapa penetrasi Go di lapisan infrastruktur modern (Cloudflare, Tailscale, HashiCorp, dll.) terus meningkat—bukan karena “Go lebih hebat dari bahasa lain”, melainkan “Go paling langsung untuk ditulis dalam skenario infrastruktur yang IO-bound dan perlu diperluas secara horizontal”.
Cermin Cloudflare: medan perang Realtime Voice AI
Cloudflare pada waktu yang sama (awal Mei) juga merilis blog teknis berjudul〈Cloudflare adalah tempat terbaik untuk membangun agen suara real-time〉, lalu memetakan pendekatannya berhadapan dengan OpenAI. Perbedaan jalur keduanya:
OpenAI: membangun sendiri tumpukan WebRTC relay/transceiver, tidak bergantung pada pihak ketiga, dan memasukkan juga lapisan media ke dalam stack teknologinya sendiri
Cloudflare: menjadikan layanan media WebRTC sebagai perpanjangan dari platform Workers miliknya, memberi developer “infrastruktur serba ada” dalam satu paket
Untuk tim aplikasi AI skala menengah-kecil, jalur Cloudflare lebih praktis—tinggal memanggil API tanpa membangun infrastruktur WebRTC sendiri. Untuk tim dengan skala seperti OpenAI, membangun sendiri adalah jalan yang harus dilalui—SLA layanan eksternal, struktur penagihan, serta distribusi geografis tidak mungkin sepenuhnya bisa disesuaikan.
Pengamatan lanjutan: transceiver open-source, skala Realtime API, respons kompetitor
Fokus pengamatan tahap berikutnya:
Apakah OpenAI akan membuka kode transceiver/relay—kompetitor seperti Anthropic, Google, xAI juga membangun tumpukan suara mereka sendiri; jika OpenAI membuka kode, itu berpotensi menjadi standar industri
Penetapan biaya dan skala Realtime API—saat ini terutama mengandalkan subsidi dari langganan ChatGPT; jika pendapatan API tumbuh, apakah ia akan menjadi lini produk yang berdiri sendiri
Pemetaan dari Anthropic dan Google—Claude dan Gemini keduanya sudah mendukung suara, tetapi dibanding OpenAI masih ada kesenjangan dari sisi latensi dan skala; apakah pengungkapan teknis kali ini akan mempercepat langkah engineering mereka
Bagi developer aplikasi AI di Taiwan, AI suara adalah medan perang kunci pada paruh kedua 2026—skenario seperti layanan pelanggan, pendidikan, kendaraan, dan IoT membutuhkan percakapan latensi rendah. Pengungkapan engineering OpenAI kali ini merupakan salah satu referensi terpenting untuk menilai “harus membangun tumpukan suara sendiri atau memakai API pihak ketiga”.
Artikel ini tentang OpenAI yang merombak tumpukan suara WebRTC: 900M pengguna aktif mingguan, relay berbasis Go sebagai inti; pertama kali muncul di 鏈新聞 ABMedia.
