Cara membangun agen suara sendiri dengan latensi di bawah 500 ms

 (ntik.me)
12 poin oleh GN⁺ 2026-03-03 | 1 komentar | Bagikan ke WhatsApp
  • Studi kasus pengembangan agen suara buatan sendiri dengan latensi sistem AI berbasis suara ditekan ke kisaran 400 ms
  • STT, LLM, dan TTS dihubungkan dalam pipeline real-time untuk mencapai kecepatan respons 2x lebih cepat dibanding platform komersial yang ada (seperti Vapi)
  • Deepgram Flux digunakan untuk menangani deteksi ujaran dan pergantian giliran, sementara model Groq llama-3.3-70b dipakai untuk memangkas waktu pembuatan token pertama secara signifikan
  • Penempatan geografis dan optimasi jaringan menurunkan latensi hingga kurang dari setengah saat dideploy di wilayah EU
  • Inti agen suara adalah orkestrasi real-time dan desain pipeline, dan membangunnya sendiri membantu mengidentifikasi bottleneck performa dengan jelas

Latar belakang membangun agen suara

  • Berdasarkan pengalaman mengembangkan prototipe agen suara untuk perusahaan besar produk konsumen, penulis mencoba membangun sendiri untuk menangani kompleksitas platform komersial secara langsung
  • Platform seperti ElevenLabs dan Vapi memang praktis, tetapi sulit memahami cara kerja internalnya dan tidak memungkinkan kontrol latensi yang detail
  • Tujuannya adalah mewujudkan performa setara Vapi secara mandiri, dan itu berhasil dilakukan hanya dalam satu hari dengan sekitar 100 dolar kredit API

Kompleksitas agen suara

  • Tidak seperti chatbot berbasis teks, suara membutuhkan manajemen pergantian giliran secara real-time (turn-taking)
  • Saat pengguna mulai berbicara, sistem harus segera menghentikan ucapannya sendiri, dan ketika pengguna berhenti, sistem harus cepat mulai merespons
  • Deteksi suara sederhana (VAD) saja sulit menentukan akhir ujaran secara akurat, sehingga bisa muncul latensi, ujaran yang saling tumpang tindih, dan jeda hening yang tidak perlu

Implementasi pertama: pengujian berbasis VAD

  • Menggunakan server FastAPI dan Twilio WebSocket untuk menerima stream audio μ-law
  • Silero VAD dipakai untuk menentukan ada tidaknya suara, lalu file WAV yang sudah direkam sebelumnya diputar saat ujaran berakhir
  • Meski sederhana, tahap ini menunjukkan responsivitas instan dan alur percakapan yang natural
  • Dari sini diperoleh tolok ukur untuk mengukur batas bawah latensi

Implementasi kedua: Deepgram Flux dan pipeline real-time

  • Deepgram Flux diadopsi untuk menggabungkan transkripsi streaming dan deteksi giliran
  • Saat Flux mendeteksi akhir ujaran, proses berikut dijalankan
    • Hasil transkripsi dan riwayat percakapan dikirim ke LLM
    • Begitu token pertama dihasilkan, hasilnya langsung di-stream ke TTS (WebSocket)
    • Audio yang dihasilkan dikirim secara real-time ke Twilio
  • Koneksi TTS dipertahankan tetap hangat (warm pool) untuk menghemat sekitar 300 ms latensi
  • Saat pengguna mulai berbicara, LLM, TTS, dan transmisi audio langsung dibatalkan agar interupsi terasa natural

Pengukuran latensi dan deployment regional

  • Saat dijalankan secara lokal dari Turki, latensi rata-rata mencapai 1,6~1,7 detik
  • Setelah dideploy ke region EU di Railway dan Twilio, Deepgram, serta ElevenLabs diselaraskan ke region EU
    • Rata-rata turun menjadi 690 ms (total 790 ms), sekitar 50 ms lebih cepat dibanding Vapi
  • Penurunan latensi ini sangat meningkatkan respons percakapan, termasuk penanganan interupsi saat berbicara

Pemilihan model dan peningkatan performa

  • Awalnya menggunakan gpt-4o-mini, lalu diganti ke Groq llama-3.3-70b
  • Hasil pengujian menunjukkan waktu pembuatan token pertama (TTFT) model Groq hingga 3x lebih cepat dibanding OpenAI
  • Berhasil mencapai latensi end-to-end rata-rata di bawah 400 ms, dengan audio pertama tiba dalam 500 ms
  • Pada level ini, agen terasa bereaksi lebih cepat daripada manusia

Pelajaran teknis utama

  • Optimasi latensi bergantung pada pengelolaan seluruh jalur dari akhir ujaran hingga keluaran suara pertama
  • Karena TTFT menyumbang lebih dari setengah total latensi, pemilihan model berlatensi rendah sangat penting
  • STT→LLM→TTS tidak boleh diproses secara berurutan, tetapi harus dijadikan pipeline streaming
  • Semua komponen harus langsung dibatalkan saat terjadi interupsi ujaran agar percakapan tetap natural
  • Kedekatan geografis antar-layanan berdampak sangat besar terhadap latensi

Perbandingan dengan platform komersial

  • Vapi dan ElevenLabs tetap berguna bagi sebagian besar tim karena menyediakan API, stabilitas, observabilitas, dan fitur tambahan lainnya
  • Namun, membangun sendiri memungkinkan kita memahami bottleneck nyata dan arti parameter secara langsung, serta
    mewujudkan orkestrasi kustom sesuai kebutuhan spesifik
  • Pada akhirnya, sistem suara adalah masalah orkestrasi, dan jika strukturnya dipahami dengan jelas, ini adalah tantangan engineering yang bisa diselesaikan

Kode sumber

Bacaan terkait

1 komentar

 
GN⁺ 2026-03-03
Komentar Hacker News

  • Tulisan ini benar-benar menarik. Dulu tim Amazon Alexa meneliti masalah ini dan bahkan punya paten terkait
    Dalam percakapan, rata-rata jeda antarmanusia adalah 0ms, artinya orang berikutnya mulai bicara bahkan sebelum lawan bicaranya selesai. Ini karena otak memprediksi ucapan lawan bicara sambil menyiapkan jawaban secara bersamaan
    Sebaliknya, orang justru mengharapkan adanya jeda dari asisten suara. Alasannya ada dua — persepsi bahwa komputer perlu ‘berpikir’, dan latensi panggilan ponsel
    Hampir tidak ada respons Alexa yang di bawah 500ms. Dulu 300ms keheningan hanya dianggap sebagai ‘akhir giliran’, tetapi inti sebenarnya adalah semantic end-of-turn
    Sekarang sumber daya komputasi sudah cukup, jadi saya penasaran seberapa jauh bagian ini berkembang. Pemrosesan berdasarkan kedekatan geografis (edge computing) adalah titik balik besar

    • Latensi panggilan ponsel sangat membuat stres terutama bagi orang yang lebih tua. Di era telepon kabel hampir tidak ada jeda, jadi mereka merasa tidak nyaman tanpa benar-benar tahu alasannya
    • Saya tidak setuju dengan poin nomor 2. Latency pada asisten suara masih terlalu lambat. Kita jadi menunggu sambil bertanya, “ini tadi benar-benar jalan atau tidak?” Saya tidak berpikir latensi ponsel ikut membentuk ekspektasi untuk perangkat lain
    • Menganggap 300ms keheningan sebagai akhir giliran sangat tidak nyaman. Jadi saya sengaja harus menambahkan filler seperti “emm...”, dan akhirnya malah berhenti memakai voice chat
    • Terima kasih sudah membagikan pembahasan yang menarik. Tapi saya penasaran kenapa Amazon/Google/Apple berhenti berinovasi pada asisten suara dalam beberapa tahun terakhir. Dengan basis pengguna yang sudah ada, mereka sebenarnya bisa mendefinisikan ulang pasar
    • Sepertinya yang dimaksud adalah arsitektur di mana LLM melanjutkan ucapan pengguna secara prediktif. Jika saat ucapan benar-benar selesai hasilnya cocok dengan prediksi, sistem bisa langsung merespons tanpa jeda. Sepertinya juga mungkin melakukan prediksi beberapa kandidat thread secara bersamaan lalu memangkasnya

  • Menurut saya, suara pada akhirnya adalah masalah turn-taking. Ada perbaikan mudah yang belum banyak disentuh — yaitu filler dan pengaturan tempo
    Saat LLM mendeteksi jeda singkat, ia bisa memasukkan filler yang sesuai konteks seperti “emm” atau “ya, benar” sementara respons sebenarnya sedang dihasilkan. Ini membuat percakapan terasa jauh lebih alami

    • Sangat setuju. Model low-latency kecil bisa lebih dulu membuat respons pendek, lalu hasil TTS-nya di-cache sehingga latensi bisa ditekan sangat rendah. Kalimat seperti “sebentar ya, saya sedang berpikir” bisa direspons dalam hitungan milidetik
    • Tapi ini mungkin bukan ‘perbaikan mudah’. Membuat sistem yang terasa manusiawi itu sulit, dan hanya mengubah struktur kalimat justru bisa terdengar makin mekanis. Saya pernah mencoba sendiri dan gagal
    • Terkait ini, blog LiveKit “Prompting Voice Agents to Sound More Realistic” menarik untuk dibaca
    • Jika sistem bisa memprediksi respons sebelum pengguna selesai bicara, hasilnya akan jauh lebih alami
    • Saat akhir giliran terdeteksi keliru, mungkin juga bisa menyambung secara alami dengan filler tingkat fonem. Sebaliknya, jika terdeteksi terlalu terlambat, suku kata pertama bisa ditentukan lebih dulu dan dimasukkan ke prompt agar jawaban dimulai dari sana

  • Tulisan yang luar biasa. OpenAI Responses client baru-baru ini memakai websocket sehingga latensinya turun.
    Cara lain adalah menjalankan LLM yang sangat kecil secara lokal. Saya membuat pipeline sepenuhnya lokal lewat proyek ova, dan meski tanpa streaming tetap mendapatkan round-trip time di bawah 1 detik

    • Proyek yang keren, jadi saya simpan di bookmark. Nanti saya ingin berbagi pengalaman dan berdiskusi

  • Struktur pipeline streaming dan analisis latensi per tahap di tulisan ini sangat berguna. Saya terkesan karena mereka benar-benar mengimplementasikan loop turn-taking sendiri
    Namun, perbandingan “2x lebih cepat daripada Vapi” agak kurang tepat. Vapi menangani jauh lebih banyak hal seperti tool calling, webhook, multi-tenant routing
    Nilai utama tulisan ini sebenarnya ada pada ‘wawasan dari loop orkestrasi buatan sendiri’. Kalau dirangkum sebagai “hal-hal yang dipelajari saat membangunnya sendiri”, itu akan sempurna

  • Saya juga sedang membangun agen suara produksi dengan kombinasi Twilio + Deepgram + ElevenLabs + LLM API
    Kuncinya bukan akurasi STT, melainkan UX turn-taking. Saat kami beralih dari ambang keheningan tetap ke semantic end-of-turn, perbedaannya langsung sangat terasa
    Latensi antarwilayah juga penting. Saat terhubung dari India ke server AS, edge hop Twilio saja menambah 150~250ms. Kami memperbaikinya dengan routing per wilayah
    Menangani barge-in juga rumit. Bukan cuma menghentikan LLM dan TTS, tetapi juga membatalkan workflow otomatis yang sudah telanjur berjalan. Dulu pernah ada bug di mana saat pengguna menyela ketika konfirmasi reservasi, reservasinya benar-benar tetap selesai diproses

  • Soniox Real-time (mendukung 60 bahasa) menangani endpoint detection di level model. Ini jauh lebih akurat daripada VAD
    Bisa lihat dokumentasi teknis, benchmark dari Daily, dan halaman demo
    Saya dulu bekerja di Soniox. Itu adalah layanan pertama yang mengimplementasikan endpoint detection real-time

    • Kalau lihat artikel aslinya, mereka menggunakan Deepgram Flux. Ini juga mendukung endpointing dan merupakan lapisan abstraksi yang lebih tinggi daripada VAD
    • Saya sedang memakai Soniox sekarang, jadi penasaran bagaimana rasanya bekerja di sana. Saya juga ingin tahu rahasia mereka bisa memberi performa SoTA dengan harga yang murah dibanding pesaing

  • Secara pribadi saya melihat arsitektur STT → LLM → TTS punya keterbatasan. Masa depan ada pada model suara end-to-end
    Dua tahun lalu saya membuat demo Chirpy, tetapi untuk mencapai kualitas yang benar-benar layak pakai ternyata butuh pelatihan khusus. Untuk side project, itu di luar jangkauan

    • Dari sudut pandang itu, riset PersonaPlex dari NVIDIA mungkin menarik: https://research.nvidia.com/labs/adlr/personaplex/
    • Saya hanya berkutat dengan agen suara selama beberapa tahun terakhir. Model cascading tidak akan hilang dalam waktu dekat.
      Pelanggan enterprise menekankan auditability dan reliability. Di industri teregulasi seperti kesehatan dan keuangan, output STT dan LLM harus bisa diverifikasi secara terpisah
      Sebaliknya, model suara end-to-end lebih cocok untuk penggunaan yang bersifat naratif seperti wawancara atau survei. Pelanggan nyata lebih menginginkan kematangan engineering daripada model terbaru
    • Pada dasarnya, kemampuan memprediksi kapan giliran saya dimulai harus tertanam di dalam model. Mode full-duplex Moshi menunjukkan arah itu dengan baik: https://arxiv.org/abs/2410.00037
    • Kelebihan arsitektur cascading adalah setiap tahap bisa diganti dengan model baru. Karena laju perkembangan STT, TTS, dan LLM berbeda-beda, fleksibilitasnya tinggi
    • Tokenizer suara terbaru kini mencapai sekitar 12Hz per detik. Ini memakai token jauh lebih banyak dibanding LLM biasa

  • Pendekatan kali ini mengingatkan saya pada perkembangan awal netcode di game engine. Latensi bukan masalah model, melainkan masalah orkestrasi
    Makalah VR John Carmack tahun 2013 juga menyampaikan argumen yang sama — kita harus melacak seluruh pipeline untuk menemukan bottleneck pada level milidetik
    Latency Mitigation Strategies layak dibaca. Contoh membuka pool websocket TTS lebih awal untuk menghemat 300ms adalah ilustrasi yang sempurna

  • Saya ingin memperkenalkan aplikasi pengenalan suara open source Handy. Aplikasi ini bekerja sepenuhnya secara offline dan bisa diperluas
    Saya memakainya setiap hari bersama Claude, dan hasilnya jauh lebih baik daripada diktasi bawaan macOS

  • Tulisan yang bagus, tetapi menjelaskan percakapan hanya lewat turn-taking itu terlalu menyederhanakan
    Percakapan nyata juga mencakup ucapan yang saling tumpang tindih, sinyal konfirmasi, phatic messages untuk menjaga keterlibatan mendengar, bahkan perilaku kooperatif seperti menyelesaikan ucapan lawan bicara
    Unsur-unsur ini tidak mudah direpresentasikan dengan model turn-taking sederhana, dan model harus mampu menghasilkan sekaligus memahaminya