500 ms altı gecikmeli bir sesli ajanı nasıl kendim kurdum

 (ntik.me)
12 puan yazan GN⁺ 2026-03-03 | 1 yorum | WhatsApp'ta paylaş
  • Gecikmeyi 400 ms seviyesine indiren, kendi inşa edilmiş bir ses tabanlı yapay zeka sistemi geliştirme örneği tanıtılıyor
  • STT, LLM ve TTS gerçek zamanlı bir pipeline içinde bağlanarak mevcut ticari platformlara (Vapi vb.) kıyasla 2 kat daha hızlı yanıt elde edildi
  • Deepgram Flux ile konuşma algılama ve geçiş yönetildi, Groq'un llama-3.3-70b modeli kullanılarak ilk token üretim süresi büyük ölçüde kısaltıldı
  • Coğrafi yerleşim ve ağ optimizasyonu sayesinde AB bölgesine dağıtımda gecikme yarıdan fazla azaltıldı
  • Sesli ajanların özü gerçek zamanlı orkestrasyon ve pipeline tasarımıdır; bunu doğrudan uygulamak performans darboğazlarını net biçimde görmeyi sağlar

Sesli ajanı kurma arka planı

  • Tüketim ürünleri alanındaki büyük bir şirket için sesli ajan prototipi geliştirme deneyimine dayanarak, ticari platformların karmaşıklığını doğrudan ele almak için kendi çözümünü kurma denemesi yapıldı
  • ElevenLabs ve Vapi gibi platformlar kullanışlı olsa da iç işleyişlerini anlamak zor ve gecikme üzerinde ayrıntılı kontrol mümkün değil
  • Hedef, Vapi seviyesinde performansı doğrudan yeniden üretmekti; bu da bir gün ve yaklaşık 100 dolarlık API kredisiyle gerçekleştirildi

Sesli ajanların karmaşıklığı

  • Metin tabanlı chatbot'lardan farklı olarak seste gerçek zamanlı sıra yönetimi (turn-taking) gerekir
  • Kullanıcı konuşmaya başladığı anda sistemin kendi konuşmasını hemen kesmesi, kullanıcı durunca da hızla yanıt vermeye başlaması gerekir
  • Yalnızca basit ses algılama (VAD), konuşmanın bittiği anı doğru belirlemekte yetersiz kalır ve gecikme, çakışan konuşmalar ve gereksiz sessizlikler ortaya çıkar

İlk uygulama: VAD tabanlı test

  • FastAPI sunucusu ve Twilio WebSocket kullanılarak μ-law ses akışı alındı
  • Silero VAD ile ses varlığı tespit edildi ve konuşma bitince önceden kaydedilmiş bir WAV dosyası çalındı
  • Basit olmasına rağmen anlık tepki verebilme ve doğal konuşma akışı doğrulandı
  • Bu aşamada gecikmenin alt sınırını ölçmek için bir referans elde edildi

İkinci uygulama: Deepgram Flux ve gerçek zamanlı pipeline

  • Deepgram Flux eklenerek streaming transkripsiyon ile sıra algılama birleştirildi
  • Flux konuşmanın bittiğini algıladığında süreç şu sırayla ilerledi
    • Transkripsiyon sonucu ve konuşma geçmişi LLM'e iletildi
    • İlk token üretilir üretilmez TTS (WebSocket) tarafına streaming başlatıldı
    • Üretilen ses Twilio'ya gerçek zamanlı olarak gönderildi
  • TTS bağlantısı önceden sıcak tutuldu (warm pool) ve böylece yaklaşık 300 ms gecikme tasarrufu sağlandı
  • Kullanıcı konuşmaya başladığında LLM, TTS ve ses aktarımı hemen iptal edilerek doğal kesme davranışı uygulandı

Gecikme ölçümü ve bölgesel dağıtım

  • Türkiye'de yerel çalıştırmada ortalama 1.6~1.7 saniye gecikme oluştu
  • Railway EU bölgesine dağıtım yapılıp Twilio, Deepgram ve ElevenLabs de AB bölgelerine hizalanınca
    • Ortalama 690 ms'ye (toplam 790 ms) düştü; bu da Vapi'den yaklaşık 50 ms daha hızlıydı
  • Gecikmenin düşmesiyle konuşma tepkiselliği belirgin biçimde arttı, konuşma kesme işlemi de daha akıcı hale geldi

Model seçimi ve performans artışı

  • Başlangıçta gpt-4o-mini kullanıldı, ardından Groq llama-3.3-70b ile değiştirildi
  • Testlerde Groq modelinin ilk token üretim süresinin (TTFT) OpenAI'ye kıyasla 3 kata kadar daha hızlı olduğu görüldü
  • Ortalama uçtan uca 400 ms altı gecikme elde edildi, ilk ses 500 ms içinde ulaştı
  • Bu seviyede ajanın insandan daha hızlı tepki verdiği hissediliyor

Başlıca teknik dersler

  • Gecikme optimizasyonunda kilit nokta, konuşmanın bitişinden ilk ses çıkışına kadar tüm yolu yönetmektir
  • TTFT toplam gecikmenin yarısından fazlasını oluşturduğundan, düşük gecikmeli model seçimi önemlidir
  • STT→LLM→TTS sıralı işlem yerine streaming pipeline kurulmalıdır
  • Konuşma yarıda kesildiğinde tüm bileşenler hemen iptal edilmelidir ki doğal diyalog korunabilsin
  • Servisler arasındaki coğrafi yakınlık gecikme üzerinde belirleyici etkiye sahiptir

Ticari platformlarla karşılaştırma

  • Vapi ve ElevenLabs, API, kararlılık, gözlemlenebilirlik gibi ek özellikler sunduğu için çoğu ekip için hâlâ faydalıdır
  • Ancak doğrudan kurulum sayesinde gerçek darboğazlar ve parametrelerin anlamı anlaşılabilir ve
    belirli ihtiyaçlara göre özelleştirilmiş orkestrasyon mümkün olur
  • Ses sistemleri sonuçta bir orkestrasyon problemidir; yapı net görüldüğünde çözülebilir bir mühendislik görevi haline gelir

Kaynak kodu

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-03
Hacker News yorumları

  • Bu yazı gerçekten çok ilginç. Eskiden Amazon Alexa ekibinde bu sorun araştırılmıştı ve bununla ilgili patentler de var.
    İnsanlar arasındaki ortalama konuşma gecikmesi 0ms; yani karşı taraf sözünü bitirmeden diğer kişi konuşmaya başlıyor. Bunun nedeni beynin karşı tarafın sözünü öngörmesi ve aynı anda yanıt hazırlaması.
    Buna karşılık insanlar sesli asistanlarda gecikme bekliyor. Bunun iki nedeni var — bilgisayarın ‘düşünmesi’ gerektiği algısı ve cep telefonu görüşmelerindeki gecikme.
    Alexa yanıtlarının neredeyse hiçbiri 500ms altında değil. Eskiden sadece 300ms sessizlik ‘tur sonu’ kabul ediliyordu ama asıl mesele semantic end-of-turn.
    Artık hesaplama kaynakları yeterli olduğuna göre bu alanın ne kadar ilerlediğini merak ediyorum. Coğrafi olarak yakın işleme (edge computing) büyük bir dönüm noktasıydı.

    • Cep telefonu görüşmelerindeki gecikme özellikle ileri yaştaki insanlar için stresli oluyor. Sabit hat döneminde neredeyse hiç gecikme yoktu; bu yüzden neden rahatsız olduklarını tam anlayamasalar da bunaltıcı buluyorlar.
      1. maddeye katılmıyorum. Sesli asistanların gecikmesi (latency) hâlâ fazla yavaş. “Çalıştı mı?” diye bekliyorsunuz. Cep telefonundaki gecikmenin başka cihazlar için de beklenti yarattığını sanmıyorum.
    • 300ms sessizliği tur sonu saymak çok rahatsız ediciydi. Bu yüzden bilerek “ııı…” gibi doldurma sözcükleri (filler) eklemek zorunda kalıyordum ve sonunda sesli sohbetten vazgeçtim.
    • İlginç içerik için teşekkürler. Ama Amazon/Google/Apple son yıllarda sesli asistan inovasyonunu neden durdurdu, merak ediyorum. Mevcut kullanıcı tabanlarıyla bile pazarı yeniden tanımlayabilirlerdi.
    • Sanırım burada kastedilen, LLM’in kullanıcının sözünü öngörülü şekilde devraldığı bir yapı. Kullanıcının sözü gerçekten bittiğinde tahminle örtüşürse gecikme olmadan anında yanıt verilebilir. Birden fazla aday iş parçacığını aynı anda öngörüp budama yapmak da mümkün görünüyor.

  • Bence ses işi sonuçta bir turn-taking problemi. Kimsenin el atmadığı kolay bir iyileştirme var — doldurma sözcükleri ve tempo ayarı.
    LLM kısa bir sessizlik algıladığında, asıl yanıt üretilirken “ıı”, “evet” gibi bağlama uygun doldurma ifadeleri ekleyebilir. Böylece konuşma çok daha doğal olur.

    • Kesinlikle katılıyorum. Küçük bir düşük gecikmeli model önce kısa bir yanıt üretip TTS sonucunu önbelleğe alırsa gecikme aşırı derecede azaltılabilir. “Bir saniye, düşünüyorum” gibi cümleler milisaniyeler içinde dönebilir.
    • Ama bu belki de ‘kolay bir iyileştirme’ değildir. Robotik bir sistemi insansı hale getirmek zor; sadece cümle yapısını değiştirmek bazen onu daha da mekanik hissettirebiliyor. Bizzat denedim ama başarısız oldum.
    • Bununla ilgili olarak LiveKit’in “Prompting Voice Agents to Sound More Realistic” blogu ilginç.
    • Sistem kullanıcı konuşmasını bitirmeden yanıtı öngörebilirse çok daha doğal olur.
    • Tur sonu yanlış algılandığında bunu fonem düzeyinde filler ile doğal biçimde devam ettirmek de mümkün olabilir. Tersine, çok geç algılandıysa ilk heceyi önceden belirleyip yanıtın onunla başlamasını prompt’a koymak da düşünülebilir.

  • Harika bir yazı. OpenAI Responses client yakın zamanda WebSocket ekledi ve gecikme azaldı.
    Bir başka yöntem de son derece küçük bir LLM’i yerelde doğrudan çalıştırmak. Ben ova projesi ile tamamen yerel bir pipeline kurdum ve streaming olmadan bile 1 saniyenin altında gidiş-dönüş süresi elde ettim.

    • Güzel bir proje, favorilere ekledim. Daha sonra deneyimleri paylaşarak sohbet etmek isterim.

  • Yazıdaki streaming pipeline yapısı ve adım adım gecikme analizi çok faydalıydı. Turn-taking döngüsünü doğrudan uygulamış olması etkileyiciydi.
    Ancak “Vapi’den 2 kat daha hızlı” karşılaştırması biraz yanıltıcı. Vapi tool calling, webhook, multi-tenant routing gibi çok daha fazla iş yapıyor.
    Bu yazının asıl değeri, ‘elle kurulmuş orkestrasyon döngüsünden çıkan içgörüler’de. Sadece “kendim yaparken öğrendiklerim” diye çerçevelense kusursuz olurdu.

  • Ben de Twilio + Deepgram + ElevenLabs + LLM API kombinasyonuyla ticari bir sesli ajan kuruyorum.
    Kilit nokta STT doğruluğu değil, turn-taking UX oldu. Sabit sessizlik eşiği yerine semantic end-of-turn kullanınca hissedilen deneyim tamamen değişti.
    Bölgeler arası gecikme de önemli. Hindistan’dan ABD sunucularına bağlanırken yalnızca Twilio edge hop bile 150~250ms ekliyordu. Bunu bölgesel routing ile iyileştirdik.
    Barge-in (araya girme) yönetimi de karmaşık. Sadece LLM ve TTS’yi durdurmak yetmiyor, daha önce tetiklenmiş otomasyon iş akışlarını da geri almak gerekiyor. Eskiden rezervasyon onayı sırasında araya girilirse rezervasyonun gerçekten tamamlandığı bir bug vardı.

  • Soniox Real-time (60 dili destekliyor), endpoint detection işini model seviyesinde yapıyor. VAD’den çok daha doğru.
    Teknik dokümanlar, Daily benchmark’ı, demo sayfası incelenebilir.
    Eskiden Soniox’ta çalışıyordum. Gerçek zamanlı endpoint detection’ı ilk uygulayan hizmet buydu.

    • Asıl yazıda Deepgram Flux kullanıldığı yazıyor. Bu da endpointing destekliyor ve VAD’den daha üst bir soyutlama katmanı.
    • Şu anda Soniox kullanıyorum; içeride çalışmak nasıldı merak ediyorum. Rakiplere kıyasla daha düşük fiyatla SoTA performansı sunmalarının sırrını bilmek isterim.

  • Kişisel olarak STT → LLM → TTS yapısının sınırlı olduğunu düşünüyorum. Gelecek uçtan uca ses modellerinde.
    2 yıl önce Chirpy demosunu yapmıştım ama gerçekten kullanılabilir bir seviyeye gelmesi için özel eğitim gerekiyordu. Bir yan proje için bunun altından kalkmak mümkün değildi.

    • Bu açıdan bakarsanız NVIDIA’nın PersonaPlex araştırması ilginizi çekebilir: https://research.nvidia.com/labs/adlr/personaplex/
    • Ben son birkaç yıldır yalnızca sesli ajanlarla uğraşıyorum. Cascading model bir süre daha ortadan kalkmayacak.
      Kurumsal müşteriler denetlenebilirlik (auditability) ve güvenilirliğe önem veriyor. Sağlık ve finans gibi regüle sektörlerde STT ile LLM çıktılarının ayrı ayrı doğrulanması gerekiyor.
      Buna karşılık uçtan uca ses modelleri, röportaj veya anket gibi daha anlatısal kullanım alanlarına uygun. Gerçek müşteriler, en yeni modelden çok mühendislik olgunluğu istiyor.
    • Temelde modelin içinde “sıranın bana ne zaman geldiğini tahmin etme yeteneği” yerleşik olmalı. Moshi’nin full-duplex modu bu yönü iyi gösteriyor: https://arxiv.org/abs/2410.00037
    • Cascading yapının avantajı, her aşamada yeni modeli değiştirebilmeniz. STT, TTS ve LLM’in gelişim hızları farklı olduğu için esnekliği yüksek.
    • Modern ses tokenizer’ları saniyede yaklaşık 12Hz düzeyine ulaştı. Bu da sıradan LLM’lerden çok daha fazla token kullanıldığı anlamına geliyor.

  • Bu yaklaşım bana oyun motoru ağ kodunun ilk gelişim dönemini hatırlattı. Gecikme bir model sorunu değil, orkestrasyon sorunu.
    Carmack’ın 2013 VR makalesi de aynı şeyi savunuyordu — milisaniye seviyesindeki darboğazları bulmak için tüm pipeline’ı izlemek gerekir.
    Latency Mitigation Strategies bakmaya değer. TTS WebSocket havuzunu önceden açarak 300ms kazanılması buna mükemmel bir örnek.

  • Açık kaynak ses tanıma uygulaması Handy’yi tanıtmak isterim. Tamamen çevrimdışı çalışıyor ve genişletilebilir.
    Ben bunu her gün Claude ile birlikte kullanıyorum; macOS’in varsayılan diktesinden çok daha iyi çalışıyor.

  • Güzel bir yazı, ama turn-taking ile konuşmayı tamamen açıklamak fazla indirgemeci.
    Gerçek konuşmada üst üste binen konuşmalar, onay sinyalleri, iletişimi sürdürmeye yarayan ifadeler (phatic messages) ve hatta karşı tarafın sözünü tamamlayan işbirlikçi davranışlar da var.
    Bu unsurlar basit bir turn-taking modeliyle iyi ifade edilemez; modelin bunları hem üretip hem de anlayabilmesi gerekir.