OpenAI, düşük gecikmeli sesli yapay zekayı büyük ölçekte nasıl sunuyor?

Sesli yapay zeka ancak konuşma, konuşma hızıyla aktığında doğal hissettirir. Ağ araya girdiğinde insanlar bunu hemen garip duraksamalar, kesilen sözler ya da gecikmeli araya girme olarak fark eder. Bu, ChatGPT Sesli Sohbet için, Realtime API ile ürün geliştiren geliştiriciler için, etkileşimli iş akışlarında çalışan otonom ajanlar için ve kullanıcı hâlâ konuşurken sesi işlemesi gereken modeller için önemlidir.

OpenAI ölçeğinde bu, üç somut gereksinime karşılık gelir:

• Haftalık 900 milyondan fazla aktif kullanıcı için küresel erişim
• Bir oturum başlar başlamaz kullanıcının konuşmaya başlayabilmesi için hızlı bağlantı kurulumu
• Konuşma akışının hızlı ve doğal hissedilmesi için düşük ve istikrarlı medya gidiş-dönüş süresi ile düşük jitter ve paket kaybı

OpenAI’da gerçek zamanlı yapay zeka etkileşimlerinden sorumlu ekip, ölçekte çakışmaya başlayan üç kısıtı ele almak için kısa süre önce WebRTC yığınımızı yeniden tasarladı: oturum başına tek portlu medya sonlandırma OpenAI altyapısına iyi uymuyor, durum bilgili ICE (Interactive Connectivity Establishment) ve DTLS (Datagram Transport Layer Security) oturumlarının kararlı sahipliğe ihtiyacı var ve küresel yönlendirmenin ilk sıçrama gecikmesini düşük tutması gerekiyor. Bu yazıda, paketlerin OpenAI altyapısı içinde nasıl yönlendirildiğini değiştirirken istemciler için standart WebRTC davranışını korumak amacıyla kurduğumuz bölünmüş relay artı alıcı-verici mimarisini anlatıyoruz.

WebRTC, tarayıcılar, mobil uygulamalar ve sunucular arasında düşük gecikmeli ses, video ve veri göndermeye yönelik açık bir standarttır. Genellikle eşler arası aramayla ilişkilendirilir, ancak istemciden sunucuya gerçek zamanlı sistemler için de pratik bir temeldir çünkü etkileşimli medyanın zor kısımlarını standartlaştırır: bağlantı kurulumu ve NAT (Network Address Translation) geçişi için ICE, şifreli taşıma için DTLS ve SRTP (Secure Real-time Transport Protocol), sesi sıkıştırıp çözmek için codec pazarlığı, kalite kontrolü için RTCP (Real-time Transport Control Protocol) ve yankı engelleme ile jitter tamponlama gibi istemci tarafı özellikler.

Bu standardizasyon yapay zekâ ürünleri için önemlidir. WebRTC olmasaydı, her istemci NAT’ler üzerinden bağlantı kurma, medyayı şifreleme, codec’leri (iletim ve açma için seçilen kodlayıcı-kod çözücüleri) pazarlık etme ve değişen ağ koşullarına uyum sağlama konusunda farklı bir çözüme ihtiyaç duyardı. WebRTC ile, tarayıcılar ve mobil platformlarda hâlihazırda uygulanmış bir protokol yığını üzerine inşa edebiliyor, kendi çalışmamızı gerçek zamanlı medyayı modellere bağlayan altyapıya odaklayabiliyoruz.

Ayrıca olgun açık kaynak uygulamaları ve tarayıcılar, mobil uygulamalar ve sunucuların birlikte çalışabilirliğini koruyan standart çalışmalarını da içeren WebRTC ekosisteminin kendisinden yararlanıyoruz. Justin Uberti’nin (WebRTC’nin özgün mimarlarından biri) ve Sean DuBois'nın (Pion'ın yaratıcısı ve bakımını yapan kişi) temel çalışmaları, bizimki gibi ekiplerin düşük seviyeli taşıma, şifreleme ve tıkanıklık kontrolü davranışlarını yeniden icat etmek yerine sahada kendini kanıtlamış medya altyapısı üzerine inşa etmesini mümkün kıldı. Justin ve Sean'in artık burada OpenAI'da çalışma arkadaşlarımız olması ve WebRTC ile gerçek zamanlı yapay zekayı birbirine daha da yaklaştırma şeklimize rehberlik etmesi bizim için büyük şans.

Yapay zeka için en önemli özellik, sesin kesintisiz bir akış olarak ulaşmasıdır. Konuşan bir ajan, tam yüklemeyi beklemek yerine kullanıcı hâlâ konuşurken yazıya dökme, akıl yürütme, araç çağırma veya konuşma üretmeye başlayabilir. İşte bu, konuşma gibi hissettiren bir sistemle bas-konuş gibi hissettiren bir sistem arasındaki farktır.

WebRTC’yi seçtikten sonra sıradaki soru, onu nerede sonlandıracağımızdı (yani WebRTC bağlantısını nerede kabul edip sahipleneceğimiz—örneğin edge’de) ve bu oturumları çıkarım arka ucuna nasıl bağlayacağımızdı. Sonlandırma önemlidir çünkü gerçek zamanlı oturum durumunu, medya taşımayı, yönlendirmeyi, gecikmeyi ve hata yalıtımını nasıl ele alacağımızı belirler.

Bir SFU ya da selective forwarding unit, her katılımcıdan bir WebRTC akışı alan ve akışları seçerek diğerlerine ileten bir medya sunucusudur. Bu modelde SFU, her katılımcı için ayrı bir WebRTC bağlantısını sonlandırır ve yapay zeka oturuma başka bir katılımcı olarak katılır. Bu, grup aramaları, sınıflar veya ortak çalışma toplantıları gibi doğası gereği çok katılımcılı ürünler için iyi bir seçenek olabilir. Ses codec’lerini, RTCP mesajlarını, veri kanallarını, kaydı ve akış başına politikayı tek yerde tutar.¹

İstemciden yapay zekaya ürünlerde bile SFU çoğu zaman varsayılan başlangıç noktasıdır; çünkü ekiplerin sinyalleme, medya yönlendirme, kayıt, gözlemlenebilirlik ve insan devri ya da daha fazla katılımcı ekleme gibi gelecekteki genişletmeler için kendini kanıtlamış tek bir sistemi yeniden kullanmasına imkan tanır.

Bizim iş yükümüz farklı. Oturumların çoğu bire bir (bir kullanıcının bir modelle ya da bir uygulamanın bir gerçek zamanlı ajanla konuştuğu durumlar) ve her turda gecikmeye duyarlı. Trafiğin bu biçimi için alıcı-verici modelini seçtik: bir WebRTC edge hizmeti istemci bağlantısını sonlandırıyor ve ardından medyayı ve olayları model çıkarımı, yazıya dökme, konuşma üretimi, araç kullanımı ve orkestrasyon için daha basit iç protokollere dönüştürüyor.

Bu tasarımda alıcı-verici; ICE bağlantı kontrolleri, DTLS el sıkışması, SRTP şifreleme anahtarları ve oturum yaşam döngüsü dâhil olmak üzere WebRTC oturum durumunun sahibi olan tek hizmettir. Buradaki “sonlandırma”, alıcı-vericinin bu el sıkışmalarını tamamlayan ve medyayı şifreleyen ya da şifresini çözen uç nokta olması anlamına gelir. Bu durumu tek yerde tutmak, oturum sahipliğini anlamayı kolaylaştırdı ve arka uç hizmetlerinin kendilerinin WebRTC eşi gibi davranması yerine normal hizmetler gibi ölçeklenmesini sağladı.

Alıcı-verici modelini seçtikten sonra ilk uygulamamız, hem sinyallemeyi hem de medya sonlandırmayı yöneten, Pion üzerine kurulmuş tek bir Go hizmetiydi. Bu hizmet ChatGPT Sesli Sohbet’e, Realtime API’nin WebRTC uç noktasına ve bir dizi araştırma projesine güç veriyor.

Operasyonel olarak alıcı-verici hizmeti iki iş yapar:

• Sinyalleme: SDP pazarlığı, codec seçimi, ICE kimlik bilgileri ve oturum kurulumu
• Medya: aşağı akış WebRTC bağlantılarını sonlandırma ve çıkarım ile orkestrasyon için arka uç hizmetlerine yukarı akış bağlantılarını sürdürme

Hizmetin altyapımızın geri kalanı gibi çalışmasını istiyorduk: iş yüklerinin ölçeklenip küçülebildiği ve talep değiştikçe makineler arasında taşınabildiği Kubernetes üzerinde. Ancak geleneksel oturum başına tek portlu WebRTC modeli bu ortama pek uymuyor, çünkü pod’lar eklendikçe, kaldırıldıkça veya yeniden planlandıkça açığa çıkarılması, güvenliğinin sağlanması ve korunması zor olan geniş herkese açık UDP port aralıklarına dayanıyor.²

İlk sorun, oturum başına tek port modelinin kendisiydi. Yüksek eşzamanlılıkta bu, çok büyük UDP port aralıklarını açığa çıkarmak ve yönetmek anlamına geliyor.

• Bulut yük dengeleyicileri ve Kubernetes servisleri, servis başına on binlerce herkese açık UDP portu etrafında tasarlanmamıştır. Eklenen her aralık, yük dengeleyici yapılandırması, sağlık kontrolü, güvenlik duvarı politikası ve sürüm geçiş güvenliğinde operasyonel karmaşıklık yaratır.³
• Büyük UDP port aralıklarının güvenliğini sağlamak zordur; çünkü dışarıdan erişilebilen yüzey alanını genişletir ve ağ politikasının denetlenmesini zorlaştırır.
• Otomatik ölçeklendirme için de kötü bir uyum gösterirler. Kubernetes’te pod’lar sürekli eklenir, kaldırılır ve yeniden planlanır. Her pod’un büyük ve kararlı bir port aralığını ayırmasını ve ilan etmesini istemek bu esnekliği kırılgan hale getirir.⁴

Bu nedenle birçok WebRTC sistemi, bu portun arkasında uygulama düzeyinde çoklama çözümüyle sunucu başına tek UDP portuna yönelir.⁵

Sunucu başına tek port tasarımları port sayısı sorununu çözer, ancak ikinci bir sorun yaratır: filodaki her oturumun sahipliğini korumak.

ICE ve DTLS durum bilgili protokollerdir. Bir oturumu oluşturan sürecin, bağlantı kontrollerini doğrulayabilmesi, DTLS el sıkışmasını tamamlayabilmesi, SRTP’nin şifresini çözebilmesi ve ICE yeniden başlatmaları gibi daha sonraki oturum değişikliklerini işleyebilmesi için o oturumun paketlerini almaya devam etmesi gerekir. Aynı oturuma ait paketler farklı bir sürece düşerse kurulum başarısız olabilir veya medya bozulabilir.

Bu da bize net bir hedef verdi: herkese açık internete küçük ve sabit bir UDP yüzeyi sunarken, her paketi karşılık gelen WebRTC oturumunun sahibi olan alıcı-vericiye yönlendirmek.

Oraya ulaşmak için çeşitli yolları değerlendirdik; bunlara, edge relay’in istemci tahsislerini sonlandırıp trafiği onların adına ilettiği TURN (Traversal Using Relays around NAT) de dahildi.²

Üretime aldığımız mimari, paket yönlendirmeyi protokol sonlandırmadan ayırıyor. Sinyalleme, oturum kurulumu için hâlâ alıcı-vericiye ulaşıyor, medya ise önce relay üzerinden giriyor. Relay, herkese açık ayak izi küçük olan hafif bir UDP iletim katmanı; alıcı-verici ise onun arkasındaki durum bilgili WebRTC uç noktasıdır.

Relay medyanın şifresini çözmez, ICE durum makinelerini çalıştırmaz veya codec pazarlığına katılmaz. Bir hedef seçmek için yeterli paket meta verisini okur, sonra paketi oturumun sahibi olan alıcı-vericiye iletir. Alıcı-verici yine normal bir WebRTC akışı görür ve tüm protokol durumunun sahibi olmaya devam eder. İstemci açısından bakıldığında WebRTC oturumu hakkında hiçbir şey değişmez.

Bu kurulumda ilk paket yönlendirmesi kilit adımdır. Bir relay, bir istemciden gelen ilk paketi, paket yolunun üzerinde henüz bir oturum yokken ve harici bir sorgu hizmetinde duraklamadan önce yönlendirebilmelidir.

Her WebRTC oturumu zaten protokole özgü bir yönlendirme kancası taşır: ICE username fragment ya da ufrag; bu, oturum kurulumu sırasında değiş tokuş edilen ve STUN bağlantı kontrollerinde tekrar edilen kısa bir tanımlayıcıdır. Sunucu tarafı ufrag’ı, relay’in hedef kümeyi ve sahip alıcı-vericiyi çıkarabilmesi için tam gerektiği kadar yönlendirme meta verisi içerecek şekilde üretiyoruz.

Sinyalleme sırasında alıcı-verici oturum durumunu ayırır ve SDP yanıtında paylaşılan bir relay VIP’i ile UDP portu döndürür. VIP, relay filosunun önündeki sanal IP adresidir; portla birlikte istemciye, arkasında çok sayıda relay örneği bulunsa bile `203.0.113.10:3478` gibi tek ve kararlı bir hedef verir. İstemcinin medya yolundaki ilk paketi genellikle STUN (Session Traversal Utilities for NAT) binding isteğidir; ICE bunu paketlerin ilan edilen adrese ulaşabildiğini doğrulamak için kullanır.

Relay, ilk STUN paketinin yalnızca gerektiği kadarını ayrıştırarak sunucu ufrag’ını okur, yönlendirme ipucunu çözer ve paketi sahip alıcı-vericiye iletir. Her alıcı-verici paylaşılan bir UDP soketini dinler; yani oturum başına bir soket değil, iç IP:port’a bağlanmış tek bir işletim sistemi uç noktası. Relay, istemcinin kaynak IP:port’undan bu alıcı-verici hedefine bir oturum oluşturduktan sonra, sonraki DTLS, RTP ve RTCP paketleri ufrag yeniden çözülmeden bu oturum içinde akar.

Relay’in oturumu bilerek en yalın hâlde tutulur; paket iletimini bilgilendiren yalnızca bellek içi bir oturum, ayrıca izleme için gerekli sayaçlar ve oturumun sona ermesi ile temizliği için zamanlayıcılar bulunur. Bu tasarım tercihi paket yönlendirmeyi doğrudan paket yolu üzerinde tutar. Bir relay yeniden başlarsa ve oturumu kaybederse sonraki STUN paketi oturumu ufrag yönlendirme ipucundan yeniden oluşturur. Bunu daha da güvenilir kılmak için, rota kurulduğunda <istemci IP + Port, alıcı-verici IP + Port> eşlemesini tutan bir Redis önbelleği kullanılır; böylece eşleme sonraki STUN paketi gelmeden çok daha önce kurtarılabilir.

Herkese açık UDP yüzeyini az sayıda kararlı adres ve porta indirdikten sonra aynı relay desenini küresel olarak dağıtabildik. Global Relay, coğrafi olarak dağıtılmış relay giriş noktalarından oluşan ve hepsinde aynı paket iletim davranışının uygulandığı filomuzdur.

Geniş coğrafi giriş, istemciden OpenAI'a ilk sıçramayı kısaltır; çünkü paket, önce uzak bir bölgeye kamu internetini aşmak yerine hem coğrafi olarak hem de ağ topolojisi bakımından kullanıcıya yakın bir relay’den ağımıza girebilir. Pratikte bu, trafik omurgamıza ulaşmadan önce daha düşük gecikme, daha az jitter ve önlenebilir daha az kayıp patlaması anlamına gelir.⁶

İlk HTTP veya WebSocket isteğinin yakındaki bir alıcı-verici kümesine ulaşması için sinyallemede Cloudflare coğrafi ve yakınlık yönlendirmesini kullanıyoruz. İstek bağlamı, oturumun konumunu ve istemciye hangi Global Relay giriş noktasının bildirileceğini belirler. SDP yanıtı Global Relay adresini sağlarken, ufrag Global Relay’in medyayı belirlenen kümeye ve relay’in de hedef alıcı-vericiye yönlendirmesi için yeterli bilgiyi içerir.

Coğrafi yönlendirmeli sinyalleme ile Global Relay birlikte, hem kurulumu hem de medyayı yakındaki bir giriş yoluna yerleştirirken oturumu tek bir alıcı-vericiye sabitler. Bu, sinyalleme ve ilk ICE bağlantı kontrolü için gidiş-dönüş süresini azaltır; dolayısıyla kullanıcının konuşma başlamadan önce beklediği süreyi doğrudan kısaltır.

Relay hizmetini Go ile yazdık ve uygulamayı bilerek dar kapsamlı tuttuk. Linux’ta çekirdeğin ağ yığını, makinenin ağ arabiriminden UDP paketlerini alır ve bunları, bir süreç IP:Port’a bağlandıktan sonra okuyabildiği işletim sistemi uç noktası olan bir sokete teslim eder. Relay kullanıcı alanında çalışır; dolayısıyla normal bir Go süreci bu soketten paket başlıklarını okur, az miktarda akış durumunu günceller ve WebRTC’yi sonlandırmadan paketleri iletir. Kullanıcı alanındaki bir sürecin daha yüksek paket hızları için ağ kuyruklarını doğrudan yoklamasına izin verecek ama operasyonel karmaşıklık da ekleyecek olan herhangi bir kernel-bypass çatısına ihtiyaç duymadık.

Temel tasarım tercihleri:

• Protokol sonlandırma yok: Relay yalnızca STUN başlıklarını/ufrag’ı ayrıştırır; sonraki DTLS, RTP ve RTCP için önbelleğe alınmış durumu kullanır ve paketleri opak tutar.
• Geçici durum: Akış durumu ve gözlemlenebilirlik için istemci adresinden alıcı-verici hedefine giden küçük, kısa zaman aşımına sahip, bellek içi bir eşleme tutar.
• Yatay ölçeklenebilirlik: Birden çok relay örneği bir yük dengeleyicinin arkasında paralel çalışır. Durum, katı WebRTC durumu değildir; bu yüzden yeniden başlatmalar en aza inen trafik düşüşlerine ve hızlı akış toparlanmasına yol açar.

Verimlilik önlemleri:

• SO_REUSEPORT, aynı makinedeki birden fazla relay çalışanının aynı UDP portuna bağlanmasına izin veren bir Linux soket seçeneğidir. Ardından çekirdek gelen paketleri bu çalışanlar arasında dağıtır; bu da tek bir okuma döngüsü darboğazını önler.
• runtime.LockOSThread, UDP okuyan her goroutine’i belirli bir işletim sistemi iş parçacığına sabitler. SO_REUSEPORT ile birleştiğinde bu, aynı akıştan gelen paketlerin (kaynak ve hedef IP:Port ile protokol) aynı CPU çekirdeğinde kalmasına eğilim gösterir; böylece önbellek yerelliği iyileşir ve bağlam değiştirme azalır.
• Önceden ayrılmış arabellekler ve en aza indirilmiş kopyalama, Go'da çöp toplamayı önlemek için ayrıştırma ve tahsis yükünü düşük tutar.

Bu uygulama, küresel gerçek zamanlı medya trafiğimizi nispeten küçük bir relay ayak iziyle taşıdı; bu yüzden kernel bypass yoluna girmek yerine daha basit tasarımı koruduk.

Bu mimari, binlerce UDP portu açığa çıkarmadan Kubernetes üzerinde WebRTC medyası çalıştırmamızı sağlıyor. Bu önemli; çünkü daha küçük ve sabit bir UDP yüzeyinin güvenliğini sağlamak ve yük dengelemek daha kolay, ayrıca altyapının geniş herkese açık port aralıkları ayırmadan ölçeklenmesini mümkün kılıyor. Kubernetes’ten daha iyi altyapı desteği ve daha küçük yüzey alanı sayesinde daha yüksek güvenlik sunan bu tasarım, istemciler için standart WebRTC davranışını da koruyor ve SFU’suz bir tasarımın iş yükümüz için doğru varsayılan olduğunu doğruluyor. Oturumlarımızın çoğu noktadan noktaya, gecikmeye duyarlı ve çıkarım hizmetlerinin WebRTC eşi gibi davranmasına gerek olmadığında ölçeklemesi daha kolay.

Daha geniş ders şu: karmaşıklık eklemek için en iyi yer, her arka uç hizmeti ya da özel istemci davranışı değil, ince bir yönlendirme katmanıdır. Yönlendirme meta verisini protokole özgü bir alana kodlamak bize deterministik ilk paket yönlendirmesi, küçük bir herkese açık UDP ayak izi ve giriş noktalarını dünyanın dört bir yanındaki kullanıcılara yakın yerleştirmek için yeterli esneklik verdi.

Bazı tercihler özellikle önemliydi:

• Edge’de protokol anlambilimini koruyun. İstemciler hâlâ standart WebRTC konuşuyor; bu da tarayıcı ve mobil birlikte çalışabilirliğini koruyor.
• Zor oturum durumlarını tek yerde tutun. Alıcı-verici; ICE, DTLS, SRTP ve oturum yaşam döngüsünün sahibidir; relay yalnızca paketleri iletir.
• Kurulumda halihazırda mevcut olan bilgilere göre yönlendirme yapın. ICE ufrag, etkin yol sorgu bağımlılığı eklemeden bize bir ilk paket yönlendirme kancası verdi.
• Kernel bypass’a yönelmeden önce yaygın durumu optimize edin. SO_REUSEPORT, iş parçacığı sabitleme ve düşük tahsisli ayrıştırmanın dikkatli kullanıldığı dar kapsamlı bir Go uygulaması iş yükümüz için yeterliydi.

Gerçek zamanlı sesli yapay zeka ancak altyapı gecikmeyi görünmez hissettirdiğinde çalışır. Bizim için bu, istemcilerin WebRTC’nin kendisinden beklediğini değiştirmeden WebRTC dağıtımımızın şeklini değiştirmek anlamına geliyordu.