3 Ağustos 2026, Pazartesi 5 yazı OpenAI Research, Meta Engineering, Cloudflare Blog, Google Cloud Blog
Editörden

Bugünün ortak teması gecikme (latency) ve sınır çizmek: OpenAI ses sisteminde medya yolunu iş mantığından ayırıyor, Cloudflare Worker'lara ham TCP sokedi veriyor, Meta öneri modelini LLM ölçeğinde eğitirken hesap ile iletişimi birbirinden ayırmaya çalışıyor. Üçü de aynı dersi veriyor: hızlı sistemler, yavaş işi kritik yolun dışına atarak hızlanır.

Günün Kapağı
OpenAI Research 3 Ağustos 202612 dk okuma orta

Sesli AI'da altı ayda gerçek zamanlı mimari: sıra beklemeyi bırakmak

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 hızlı yolda (fast path) akıyor; araç çağırma, daha derin akıl yürütme için GPT-5.5'e devretme 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 devretme 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 çıkarımdaki 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?

"Hızlı yol / yavaş yol ayrımı" bu yazının asıl dersi ve sesli AI'a özgü değil. Aynı desen ödeme sistemlerinde (yetkilendirme senkron, mutabakat 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.

Sende karşılığı

KlioAI'daki konuşma pratiği ö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 yanıt 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 veya 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 yük dengeleyici koyarsan oturumlar kopar — sticky routing gerekir.

Sözlük

full-duplex çift yönlü eşzamanlı
Bir kanalın aynı anda hem veri alıp hem gönderebilmesi. Telsiz (sırayla) değil, telefon (aynı anda) gibi.
turn detection sıra tespiti
Konuşmada karşı tarafın sözünü bitirip bitirmediğini tahmin eden bileşen.
stateful inference durum tutan çıkarım
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 hızlı yol
Sistemde gecikmeye en duyarlı akış; buraya ek iş koymamak için özel olarak korunur.
Orijinali oku

Kısa Kısa

Meta Engineering 3 Ağustos 202622 dk okuma ileri

Meta reklam modelini LLM ölçeğinde eğitirken verimliliği ikiye katladı

GEM Training: How Meta Doubled the Efficiency of Its LLM-Scale Ads Foundation Model

GEM, Instagram ve Facebook'un reklam önerilerini besleyen temel 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ş.

  • Ö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ış.

Sende karşılığı

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 %50'si boşa gidiyor" tespiti, senin Tradebot projendeki 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

MFU (Model FLOPs Utilization) model işlem verimliliği
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 düzensiz uzunluklu girdi
Batch içindeki örneklerin farklı uzunlukta olması; sabit uzunluğa doldurulunca (padding) hesap israf edilir.
Orijinali oku
Cloudflare Blog 3 Ağustos 20267 dk okuma orta

Cloudflare Workers artık ham TCP bağlantısı ve gRPC kabul ediyor

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.

  • 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ı.

Sende karşılığı

gRPC senin CV'nde yok ama backend mülakatlarında "REST mi gRPC mi?" sorusu sık çıkıyor. Buradan alacağın net cevap şu: gRPC HTTP/2 ve TCP üstünde çalışır, asıl kazancı çift yönlü akış (bidirectional streaming) ve sıkı sözleşmedir — ve tam da bu yüzden HTTP-only platformlarda çalıştırmak zordur. Mobit'teki mesajlaşma uygulaması 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

gRPC gRPC uzak yordam çağrısı
HTTP/2 üstünde çalışan, şema tabanlı (protobuf) ve akış destekli bir servisler-arası iletişim protokolü.
Durable Object kalıcı nesne
Cloudflare'ın tekil, durum tutan hesaplama birimi; aynı anahtar hep aynı örneğe yönlenir.
Orijinali oku
Cloudflare Blog 3 Ağustos 20267 dk okuma orta

Python ve JavaScript arasında şemasız RPC: tip sistemlerini köprülemek

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.

  • Ş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.

Sende karşılığı

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

RPC (Remote Procedure Call) uzak yordam çağrısı
Başka bir süreçteki/makinedeki fonksiyonu yerel fonksiyon gibi çağırma yöntemi.
FFI (Foreign Function Interface) yabancı fonksiyon arayüzü
Bir dilin başka bir dilde yazılmış kodu çağırabilmesini sağlayan köprü katmanı.
Orijinali oku
Google Cloud Blog 3 Ağustos 20265 dk okuma orta

Önbellek katmanından graph veritabanına: Data Commons'ın mimari göçü

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 bilgi grafiği. İlk kurulduğunda graph veritabanı teknolojisi olgun olmadığı için Bigtable üzerinde önceden hesaplanmış önbellek katmanıyla çalışıyordu.

Şimdi Spanner Graph'a taşınmışlar ve kazanç listesi klasik bir "önbellek 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.

  • Önceden hesaplanmış önbellek 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.

Sende karşılığı

Mobit'teki AI destekli doküman arama mimarisi ile doğrudan ilgili. Klasik RAG belgeleri parçalara bölüp embedding benzerliğiyle getirir; ama "bu ihale hangi firmaya bağlı, o firmanın hangi belgeleri var?" gibi ilişkisel sorularda benzerlik yetmez. Bu yazı sana ilişkinin kendisini modellemenin alternatifini gösteriyor. PostgreSQL kullandığın için Spanner'a geçmene gerek yok — recursive CTE ile aynı çok adımlı gezinmeyi yapabilirsin; önemli olan deseni tanımak.

Sözlük

knowledge graph bilgi grafiği
Varlıkları düğüm, aralarındaki ilişkileri kenar olarak tutan veri modeli.
GraphRAG grafik tabanlı bağlam getirme
RAG'de bağlamı düz benzerlik yerine grafik üzerinde ilişkileri izleyerek toplama yöntemi.
incremental update artımlı güncelleme
Tüm veriyi yeniden işlemek yerine yalnızca değişen kısmı güncelleme.
Orijinali oku