How we built a realtime system for responsive voice AI in six months
İnsanlar konuşurken sırayı saniyenin küçük bir kesrinde devralır. Eski sesli asistanlar bunu yakalayamıyordu çünkü mimarileri sıra tabanlıydı (turn-based): önce küçük bir turn detector modeli "kullanıcı sustu mu?" diye karar veriyor, ancak ondan sonra büyük dil modeli çalışmaya başlıyordu. Erken karar verirse kullanıcının sözünü kesiyor, geç verirse sistem ağır hissettiriyordu.
GPT-Live bu dedektörü ses yolundan tamamen çıkarmış. Model full-duplex çalışıyor: aynı anda hem dinliyor hem konuşuyor. Yani "sıra kimde?" kararı ayrı bir bileşenin tahmini olmaktan çıkıp modelin kendi işinin parçası oluyor.
İşin mühendislik açısından asıl öğretici kısmı şu mimari karar: ses akışı ile uygulama mantığı iki ayrı yola ayrılmış. Ses, istemci ile model arasında kesintisiz bir fast pathda (fast path) akıyor; araç çağırma, daha derin reasoning için GPT-5.5'e failover gibi işler ise asenkron bir yan yolda yürüyor. Böylece pahalı bir işlem sesin akışını durdurmuyor.
Bu ayrım olmadan sistem çalışmıyor, çünkü sürekli akışta tolerans yok: eski sıra tabanlı sistemde bir ses parçasının 50 ms geç gelmesi fark edilmezken, kesintisiz akışta aynı gecikme kulakta duyulabilir bir boşluk ya da cızırtı hâline geliyor.
Öne çıkanlar
- Turn detector'ı kaldırıp modeli full-duplex yapmak, "tahmin et" problemini tamamen ortadan kaldırıyor — çözülmesi zor bir problemi çözmek yerine yok etmek.
- Medya yolu ile kontrol yolu ayrıldı: ses kesintisiz akarken tool use ve model failover asenkron bir kanalda yürüyor.
- Stateful inference — model isteğe değil, oturuma bağlı. Bu, istekleri herhangi bir sunucuya dağıtmayı imkânsız kılıyor; yönlendirme oturum-farkında olmalı.
- Sürekli akışta hata bütçesi çok daha dar: taşıma, işleme ve inference’taki her gecikme doğrudan duyulabilir bir kusura dönüşüyor.
- Protokol seviyesine kadar inilmiş — ses taşıma katmanı da öngörülebilir gecikme için yeniden yazılmış.
Neden önemli?
"Fast path / yavaş yol ayrımı" bu yazının asıl dersi ve sesli AI'a özgü değil. Aynı desen ödeme sistemlerinde (yetkilendirme senkron, reconciliation asenkron), mesajlaşma uygulamalarında (mesaj iletimi senkron, bildirim ve arşivleme asenkron) ve arama sistemlerinde de aynı. Bir sistemi hızlandırmanın en güçlü yolu genellikle kodu optimize etmek değil, kritik yoldan iş çıkarmaktır.
Pratikte
Bir konuşma pratiği ya da sesli asistan özelliği tam olarak bu problemin küçük ölçekli hâli: kullanıcı konuşurken kaydı işleme, değerlendirme ve puanlama işlerinin hepsini cevap yolunda yaparsan uygulama ağır hisseder. Spring Boot tarafında kritik yolu ‘sesi al, akışı sürdür’ ile sınırlayıp değerlendirme, kayıt ve istatistik güncellemeyi bir kuyruğa (Redis Streams ya da basit bir async queue) atmak bu yazının doğrudan uygulaması olur. Bir de ‘stateful inference’ uyarısını not al: oturuma bağlı bir servisin önüne rastgele load balancer koyarsan oturumlar kopar; sticky routing gerekir.
Sözlük
- full-duplex
- Bir kanalın aynı anda hem veri alıp hem gönderebilmesi. Telsiz (sırayla) değil, telefon (aynı anda) gibi.
- turn detection
- Konuşmada karşı tarafın sözünü bitirip bitirmediğini tahmin eden bileşen.
- stateful inference
- Modelin her isteği sıfırdan işlemeyip oturum boyunca biriken durumu koruması; ölçeklemeyi zorlaştırır çünkü istek belirli bir sunucuya bağlanır.
- fast path
- Sistemde gecikmeye en duyarlı akış; buraya ek iş koymamak için özel olarak korunur.
GEM Training: How Meta Doubled the Efficiency of Its LLM-Scale Ads Foundation Model
GEM, Instagram ve Facebook'un reklam önerilerini besleyen foundation model. Meta bunu binlerce GPU üzerinde eğitiyor ve 12 ayda toplam hesap gücünü 4 katına çıkarırken verimliliği (MFU — GPU'nun teorik kapasitesinin ne kadarının gerçekten kullanıldığı) %20-25'e, yani iki katına çıkarmış.
Yazının en çarpıcı iddiası şu: LLM'ler için optimize edilmiş altyapı öneri modellerine doğrudan aktarılamıyor. Sebebi veri: kullanıcı geçmişi kişiden kişiye çok değişken uzunlukta (jagged input), ve hepsini en uzun olana göre doldurmak hesabın %50'sine kadarını çöpe atıyor. Meta bu yüzden kendi çekirdek kütüphanesini yazmış (Jagged Flash Attention gibi) ve MXFP8 gibi çok düşük hassasiyetli sayı formatlarına inmiş.
Öne çıkanlar
- Ölçeklemek ≠ GPU eklemek: uçtan uca süre
max(hesap süresi, iletişim süresi) ile belirleniyor, iletişim baskınsa yeni GPU'lar boş bekliyor. - Reklam tahmini (CTR/CVR) sayısal olarak hassas; düşük hassasiyete naif geçiş model kalitesini bozuyor.
- Çözüm tek bir yerde değil: çekirdekler, sayı hassasiyeti, paralellik ve ağ topolojisi birlikte tasarlanmış.
Pratikte
Bu yazıyı GPU sayısı için değil, kaynak israfını ölçme alışkanlığı için oku. ‘Padding yüzünden hesabın yüzde 50’si boşa gidiyor’ tespiti, değişken uzunluklu zaman serisi batch’lerinde birebir geçerli. PyTorch’ta değişken uzunluklu diziler için pack_padded_sequence ya da nested tensor kullanmak aynı israfı önler. Genel ders: bir işi hızlandırmadan önce kaç biriminin gerçekten işe yaradığını ölç.
Sözlük · 2 terim
- MFU (Model FLOPs Utilization)
- GPU'nun teorik işlem kapasitesinin yüzde kaçının gerçekten faydalı hesaba gittiği. %20 bile büyük ölçekte iyi sayılır.
- jagged / ragged input
- Batch içindeki örneklerin farklı uzunlukta olması; sabit uzunluğa doldurulunca (padding) hesap israf edilir.
Cloudflare Workers and Containers now support inbound TCP connections and gRPC
Workers 2017'den beri HTTP dünyasında yaşıyordu. Şimdi connect(socket) adında yeni bir handler ile gelen ham TCP bağlantısını doğrudan alabiliyor. Bu soket bir Worker'dan diğerine, oradan bir Durable Object'e ve nihayetinde bir container içindeki sunucuya geçirilebiliyor.
Pratik sonucu: HTTP'ye sığmayan protokoller — gRPC'nin çift yönlü akışı, veritabanı protokolleri, özel binary protokoller — artık edge üzerinde çalışabiliyor. Yazıda Worker → Durable Object → Container zincirinin her adımı kısa kod örnekleriyle gösteriliyor.
Öne çıkanlar
connect(socket) handler'ı soketi bir nesne gibi devredilebilir kılıyor; yönlendirme kararını kod veriyor.- Worker'lar gRPC-web yazıp otomatik gRPC'ye çevrilebiliyor; tam çift yönlü akış için container gerekiyor.
- Şu an özel beta — üretim için değil, mimari fikir için okunmalı.
Pratikte
gRPC backend mülakatlarında ‘REST mi gRPC mi?’ sorusuyla sık çıkıyor. Buradan alacağın net cevap şu: gRPC HTTP/2 ve TCP üstünde çalışır, asıl kazancı bidirectional streaming ve sıkı sözleşmedir (protobuf), ve tam da bu yüzden yalnızca HTTP destekleyen platformlarda çalıştırmak zordur. Mesajlaşma gibi gerçek zamanlı bir üründe WebSocket yerine gRPC streaming’i neden seçip seçmeyeceğini bu yazıdan sonra anlatabilirsin.
Sözlük · 2 terim
- gRPC
- HTTP/2 üstünde çalışan, şema tabanlı (protobuf) ve akış destekli bir servisler-arası iletişim protokolü.
- Durable Object
- Cloudflare'ın tekil, durum tutan hesaplama birimi; aynı anahtar hep aynı örneğe yönlenir.
Workers RPC now works across Python and JavaScript
Normalde iki farklı dilde yazılmış servisi konuşturmak için protobuf gibi dilden bağımsız bir serileştirme formatı seçersin, şema yazarsın, kod üretirsin. Cloudflare bu adımı tamamen atlıyor: TypeScript'te tanımlı bir metodu Python'dan doğrudan çağırabiliyorsun, şema yok, bağımlılık yok.
Yazının öğretici kısmı bunun nasıl mümkün olduğu. İki dilin tip sistemi farklı düşünüyor: JavaScript karmaşık parametreyi tek bir nesne olarak geçer, Python ise adlandırılmış argüman (keyword argument) kullanır. Köprü, Pyodide'nin FFI katmanı üzerinden bu farkı otomatik çeviriyor — JS Date nesnesi Python datetime'a dönüşüyor, fonksiyonlar iki yönde geçirilebiliyor, istisnalar çağrı noktasında fırlatılıyor.
Öne çıkanlar
- Şema yazmadan çapraz dil RPC — protobuf'un getirdiği bakım yükü ortadan kalkıyor.
- Çoğu durumda ağ üzerinden geçmiyor: çağrılan Worker aynı thread'de çalıştığı için maliyet neredeyse sıfır.
- Tip köprüleme kolay değil; asıl iş iki dilin çağrı geleneklerini eşlemekte.
Pratikte
Sen zaten iki dilli çalışıyorsun: Java/Spring Boot backend + Python/LLM pipeline. Bugün bunları muhtemelen REST veya kuyrukla konuşturuyorsun. Bu yazı sana "aradaki sınırın maliyeti nedir?" sorusunu sordurmalı — serileştirme, şema bakımı, tip uyuşmazlığı. Kendi projende de aynı soruyu sor: Python tarafındaki kategorizasyon pipeline'ı ile Java servisi arasındaki sözleşmeyi kim koruyor, şema değişince ne kırılıyor?
Sözlük · 2 terim
- RPC (Remote Procedure Call)
- Başka bir süreçteki/makinedeki fonksiyonu yerel fonksiyon gibi çağırma yöntemi.
- FFI (Foreign Function Interface)
- Bir dilin başka bir dilde yazılmış kodu çağırabilmesini sağlayan köprü katmanı.
Unify public and private data with Data Commons on Spanner Graph
Data Commons, BM'den Dünya Bankası'na 100+ kaynaktan gelen 400 milyar veri noktasını birleştiren açık bir knowledge graph. İlk kurulduğunda graph veritabanı teknolojisi olgun olmadığı için Bigtable üzerinde önceden hesaplanmış cache katmanıyla çalışıyordu.
Şimdi Spanner Graph'a taşınmışlar ve kazanç listesi klasik bir "cache borcu" hikâyesi: önceden hesaplanan indeksler her güncellemede pahalı bir yeniden inşa gerektiriyordu; artık tek bir veri kümesini artımlı olarak güncelleyebiliyorlar. Ayrıca kıta → ülke → il → ilçe gibi çok adımlı gezinmeler sorgu anında yapılabiliyor — bu da GraphRAG akışlarının önünü açıyor.
Öne çıkanlar
- Önceden hesaplanmış cache hızlıdır ama güncellemeyi pahalılaştırır; bu takas her sistemde karşına çıkar.
- Çok adımlı ilişki sorgularını uygulama katmanında değil veritabanında yapmak kod karmaşıklığını ciddi düşürüyor.
- GraphRAG: modele düz metin parçaları yerine grafik üzerinde gezinerek toplanmış bağlam vermek.
Pratikte
AI destekli doküman arama mimarisiyle doğrudan ilgili. Klasik RAG belgeleri parçalara bölüp embedding benzerliğiyle getirir ama ‘bu sözleşme hangi firmaya bağlı, o firmanın hangi belgeleri var?’ gibi ilişkisel sorularda benzerlik yetmez. Bu yazı ilişkinin kendisini modellemenin alternatifini gösteriyor. PostgreSQL kullanıyorsan Spanner’a geçmen gerekmez: recursive CTE ile aynı çok adımlı gezinmeyi yapabilirsin; önemli olan deseni tanımak.
Sözlük · 3 terim
- knowledge graph
- Varlıkları node, aralarındaki ilişkileri kenar olarak tutan veri modeli.
- GraphRAG
- RAG'de bağlamı düz benzerlik yerine grafik üzerinde ilişkileri izleyerek toplama yöntemi.
- incremental update
- Tüm veriyi yeniden işlemek yerine yalnızca değişen kısmı güncelleme.