Hızlı yanıt veren sesli iletişim yapay zekâ sistemini altı ayda nasıl geliştirdik?

Sesli yapay zekâ için ne zaman konuşacağını bilmek, göründüğünden daha zordur. İnsanlar saniyenin çok küçük bir bölümünde sözü zahmetsizce birbirine devreder ancak önceki sesli yapay zekâ sistemleri bu ritme ayak uyduramıyordu. Sıra tabanlı mimarileri, sıra algılayıcı denen küçük modellere dayanıyordu. Bu modellerin işi zordu: Çok erken tahmin ederlerse kullanıcının sözü kesiliyor, çok geç kalırlarsa yanıt ağır hissettiriyordu. Çok daha büyük olan LLM ancak algılayıcı kararını verdikten sonra çalışmaya başlayabiliyordu.

Üçüncü nesil sesli iletişim sistemimiz GPT‑Live⁠, sıra algılayıcıyı ses yolundan kaldırıyor. Sesli iletişim modeli tam çift yönlüdür; yani aynı anda hem dinleyip hem konuşabilir. Bu, ayrı bir algılayıcı ihtiyacını ortadan kaldırarak sohbeti daha anlık ve doğal hissettirir. Daha derin akıl yürütme veya araç kullanımı gerektiğinde GPT‑Live, sohbetin akışını kesmeden GPT‑5.5 gibi en üst seviye modellerimize de danışabilir. Bu yetenekler bir araya gelerek GPT‑Live'a sohbet akıcılığı ile zekânın daha önce görülmemiş bir bileşimini kazandırıyor.

Bu deneyimi geniş ölçekte sunmak, düşük gecikme için optimize edilmiş yeni bir sistem mimarisi gerektirdi. Tipik istek-yanıt çıkarımından farklı olarak sistemimiz, gelen sesi ses modeline ve çıkan konuşmayı kullanıcıya aktarırken aktarımları ayrı bir eşzamansız yolda işler. Son altı ayda konuşmanın uçtan uca akıcı kalması için model çıkarımını, bağlam yönetimini ve medya aktarımını yeniden düzenledik.

Mimari ayrıca temel ses yolu ile uygulama mantığı arasında net bir sınır oluşturuyor. Böylece yanıt hızını etkilemeden uygulama davranışını özelleştirmek kolaylaşıyor. Bu temel, ChatGPT masaüstü uygulamasında bilgisayarınızı kontrol etme ve ajanlarınızı koordine etme gibi yeni kullanıma sunulan özellikler dâhil, ChatGPT Sesli İletişim'deki giderek genişleyen yetenekleri destekliyor.

Bu yazıda önceki sıra tabanlı sistemlerin ihtiyaçlarımızı neden karşılayamadığını ve yeni sistemi her katmanda hızlı yanıt verecek şekilde nasıl tasarladığımızı açıklayacağız. GPT‑Live'ı gerçekten canlı hissettirmek için birlikte çalışan durum bilgili çıkarımı, dinamik bağlam yönetimini, eşzamansız aktarımı ve protokol düzeyindeki optimizasyonu ele alacağız.

Önceki ses mimarileri, metin LLM'lerinin sıra tabanlı yapısını devralmıştı ancak her sıra metin yerine ayrı bir ses öbeğiyle temsil ediliyordu. Basamaklı sistemlerde konuşmayı metne dönüştürme, LLM ve metni konuşmaya dönüştürme işlemleri sırayla çalışıyordu. Bu sıralama gecikmeyi artırıyor; tonlama ve konuşma hızı gibi ipuçlarını göz ardı ediyordu.

Sesli sohbet modelleri, sesi doğrudan işleyerek bu yaklaşımı geliştirdi. Modelin konuşmayı doğrudan anlayıp üretecek şekilde eğitilmesi, döküm sırasında kaybolan ayrıntıları korumasını ve daha hızlı yanıt vermesini sağladı. Ancak sistem çıkarımın ne zaman başlayacağına karar vermek için hâlâ sıra algılayıcıya dayanıyordu. Model etkileşimin daha büyük bölümünü üstlense de etkileşim sıra tabanlı kalıyordu.

GPT‑Live, sohbetin kontrolünü sesli iletişim modeline verir: Ses modele girip çıkarken daha derin akıl yürütme ve araç kullanımı eşzamansız gerçekleşir. Sistemin temel görevi kesintisiz bir medya döngüsünü sürdürmektir. En üst seviye modelleri çağırmak ve sohbeti kalıcı hâle getirmek gibi diğer işler canlı yolun dışında gerçekleşir.

Bu medya döngüsünü kesintisiz sürdürmek her zaman kolay değildir. Aktarım, işleme veya çıkarımdaki her gecikme, duyulabilir bir duraklamaya ya da bozulmaya dönüşebilir. Önceki sıra tabanlı sistem, bir ses öbeğinin varış zamanındaki bir miktar değişimi tolere edebiliyordu. Ancak canlı bir medya sisteminin her ses karesini zamanında iletmesi gerekir.

ChatGPT Sesli İletişim ve Realtime API üzerine önceki çalışmalarımız bize önemli bir temel sağladı. Ses ve videoyu daha düşük, daha öngörülebilir gecikmeyle doğrudan sistemlerimize ve sistemlerimizden dışarı aktarmak için sesli iletişim altyapımızı baştan kurmuştuk⁠. GPT‑Live bu tasarımı daha da ileri taşıdı ve sürekli sohbet için geliştirilen yeni, durum bilgili bir çıkarım sistemi üzerinden medyayı modele kadar aktardı.

Ancak akış tabanlı çıkarım, çözümün yalnızca bir parçasıydı. Üretim ortamında iyi çalışması için istemciden çıkarım katmanına güvenilir ses iletimini sağlamamız ve durum bilgisinin getirdiği zorlukları çözmemiz de gerekiyordu.

İlk kararlarımızdan biri, medya akışını uygulama ve iş mantığından özellikle ayırmaktı. Ses, istemci ile sesli iletişim modeli arasında özel bir hızlı yol üzerinden taşınır. Aktarım, araç kullanımı ve diğer uygulama işleri eşzamansız bir RPC sınırının gerisinde gerçekleşir. Yavaş bir araç çağrısı veya arka uç hizmeti kendi sonucunu geciktirebilir ancak medya akışını durduramaz.

Bu ayrım, sisteme özelleştirme için de net bir sınır sağlar. Uygulamalar; ses akışını sürdürmekten sorumlu medya ön ucunu etkilemeden araçlarını, politikalarını ve arka uç davranışlarını değiştirebilir. Canlı yol küçük ve öngörülebilir kalır; yalnızca gerçek zamanlı yapılması gereken işlere odaklanır.

Medya ön ucunu ve çıkarım mantığını Go ile yazarak önceki Python asyncio uygulamasının yerini aldık. Bu, kare iletiminin akıcılığını önemli ölçüde artırdı; yeni sistemin p95 değeri önceki sistemin p50 değerine ulaştı.

Aktarımın temelini WebRTC sağlar. Düşük gecikmeli medya için tasarlanan WebRTC; paket kaybı, saat sapması ve istemci bağlantısındaki değişiklikler sırasında çalışmayı sürdürebilir. Paketler geç ulaşırsa WebRTC boşlukları önlemek için sesi belli belirsiz uzatabilir, ardından gerçek zamanı yakalamak için oynatmayı kısa süreliğine hızlandırabilir.

Sistem genelinde arabelleğe alma ve engellemeyi en aza indirerek insanların sohbetten beklediği bir saniyenin altındaki yanıt hızını sağlayabiliyoruz.

Durum bilgili çıkarımın kendine özgü operasyonel ödünleşimleri vardır. Bir sesli iletişim oturumu uzun süre etkin kalabilir ancak bağlamı sürekli büyür; model örnekleri de talebe göre devreye girip çıkar.

Bu sorunları gidermek için model örnekleri arasında kesintisiz bir devir mekanizması geliştirdik. Geçiş gerektiğinde mevcut örneğin yanında yedek bir model örneğini hazırlayabiliyor, güncel oturum bağlamını önceden yükleyebiliyor, çıkarımı ikisinde paralel çalıştırabiliyor ve yeni örnek tamamen hazır olduğunda ona geçebiliyoruz.

Aynı temel mekanizma dinamik bağlam yoğunlaştırmayı da destekler. Sohbet ilerledikçe biriken bağlam sonunda modelin bağlam sınırını aşabilir. Bağlam yoğunlaştırma, bağlamı sınıra sığacak kadar küçültebilir ancak bu işlem zaman alır. Ayrıca geçmiş bağlamı değiştirdiği için modelin daha önce işlenen token'lara ait dikkat anahtarlarını ve değerlerini saklayan anahtar-değer (KV) önbelleğini de geçersiz kılar. Bu durumu yeniden oluşturmak yeni bir ön yükleme gerektirir ve ek gecikmeye yol açar.

Bunun yerine bağlam yoğunlaştırmayı yönetilen başka bir geçiş olarak ele alıyoruz. İlk model örneği sohbeti sürdürürken sistem bağlamı yoğunlaştırır ve yeni bağlamla yedek bir model örneği hazırlar. Bu örnek hazır olduğunda medyada kesinti olmadan ona geçebiliriz. Böylece sistem, gerektiğinde bağlamı yoğunlaştırarak uzun süren görüşmeleri destekleyebilir.

Ağır işlemler canlı yolun dışında kalır; böylece devir sırasında bile sohbetin ritmi hiç bozulmaz.

GPT‑Live'ın mevcut en üst seviye modelleri çağırabilmesi ona büyük güç kazandırıyor ve “konuşmayı” daha derin “düşünmeden” etkin biçimde ayırıyor. Ancak bu iki modelli mimariyi tek bir sistem gibi hissettirmek, birbiriyle bağlantılı iki mühendislik sorununun çözülmesini gerektirdi.

İlk olarak sonuçların devam eden konuşmada işe yarayacak kadar hızlı dönmesi gerekiyordu. Bu nedenle yönlendirme ve prompt işlemeden çıkarım ve araç çağrılarına kadar tüm aktarım yolundaki gecikmeyi en aza indirmeliydik. Aynı zamanda ürünün diğer bölümlerindeki sistemler hâlâ ayrı mesajlara ihtiyaç duyuyordu; dolayısıyla devam eden sohbeti onların anlayabileceği bir biçimde temsil etmeliydik.

Bir aktarım başlatıldığında, en üst seviye modelin sohbet için yararlı bir çıktı üretmesine kadar geçen süreyi optimize ederiz. En üst seviye model akıl yürütürken veya araçları kullanırken ses modeli konuşmayı kısa süreliğine sürdürebilir ancak sınırsız ölçüde yavaş bir yanıtı gizleyemez. Bu nedenle yönlendirme, prompt işleme, çıkarım ve araç çağrılarından oluşan tüm aktarım döngüsünü yanıt süresi bütçesinin bir parçası olarak ele aldık.

İlk optimizasyon, aktarım talep edilmeden önce en üst seviye modeli ve ihtiyaç duyacağı araçları hazırlamaktır. Bir sesli oturum başladığında uygulama sunucusu, en üst seviye model için bir çıkarım oturumu oluşturup ilk sohbet bağlamını önceden yükler; böylece ilk aktarılan istekten önce prompt tamamen işlenmiş olur.

Ardından bu çıkarım oturumunu sesli sohbet boyunca hazır tutar ve birbirini izleyen istekler için kararlı oturum yakınlığı kullanırız. Prompt önbelleğe almayla birlikte bu teknikler gecikmeyi azaltırken çalışan arızalarının kolayca giderilebilmesini sağlar.

Akıl yürütme çabası, çıktı sınırları, araç şemaları ve model-araç gidiş gelişleri de sohbetin yararlı bir sonuç alma süresini etkiler. Daha hızlı yanıtlar için bu ayarları düzenledik. Aktarım yolunda gereken işi en aza indirerek sesli iletişim modelinin en üst seviye modellerimizden gelen sonuçları hızla kullanmasını sağladık.

Sesli iletişim modeli kesintisiz konuşma akışlarıyla çalışsa da ChatGPT'nin sohbet arayüzü ile analiz ve güvenlik altyapımızın bazı bölümleri dâhil çevresindeki birçok sistem hâlâ kullanıcı ve asistan sıralarıyla çalışır. Bu nedenle uygulama sunucusu, örtüşen ve zaman zaman belirsizleşen sohbeti ayrı mesajlara ayırır.

Ses geldikçe sunucu, kimin konuştuğunu belirlemek ve bir mesaj kuyruğu oluşturmak için kısmi dökümleri ve zamanlama sinyallerini kullanır. En yeni mesaj geçici kalır; daha fazla konuşma geldikçe metni, zamanlaması ve konuşmacı ataması değişebilir. Bir konuşmacı, atamanın güvenilir olmasına yetecek kadar uzun süre sözünü sürdürdüğünde sunucu ilgili mesajı kesinleştirir.

Konuşmacıların üst üste konuşması bu süreci karmaşıklaştırır. Kullanıcı konuşurken asistanın verdiği kısa bir onayın (ör. “mm hmm” veya “okay”) mutlaka ayrı bir mesaja dönüşmesi gerekmez. Ancak asistanın anlamlı bir araya girişi çoğu zaman ayrı bir mesaj olmalıdır. Benzer şekilde, kullanıcı araya girse bile görüntülenen asistan yanıtlarının tutarlılığına öncelik veririz.

Her bölümleme politikası, güncellik ile kesinlik arasında bir ödünleşim yapar. Çok erken kesinleştirmek parçalı bir geçmişe ve kararsız sıralamaya yol açar; çok beklemekse dökümleri ve bunlara bağlı özellikleri geciktirir. Bu nedenle sistem sohbetin birbiriyle bağlantılı iki görünümünü tutar: mevcut durumun tahmine dayalı görünümü ve söylenenlerin kesin kaydı. Uygulama arayüzündeki sohbet görünümü güncellemeleri işleyebildiğinden tahmine dayalı görünümü kullanır. Ancak analiz işlem hattına kayıt için kesinleşmiş bir döküm gerekir.

Böylece canlı sesli iletişim yoluna sıra düzeni dayatmadan ChatGPT'nin geri kalanına konuşmanın kararlı bir görünümü sunulur.

Yanıt hızı, kullanıcı düğmeye tıkladığı anda başlar. GPT‑Live'da sohbet başlamadan önce sistemin medya yolunu kurması ve sesi model üzerinden işlemeye başlaması gerekir. Bu nedenle başlatma dizisinin her parçası kritik yol üzerinde yer alır.

Yukarıda belirtildiği gibi WebRTC, gerçek zamanlı iletişim için güçlü bir temel sağlar ancak standart bir WebRTC oturumu başlatmak şaşırtıcı sayıda protokol el sıkışması ve ağ gidiş gelişi gerektirir. WebRTC, QUIC gibi sonraki protokolleri şekillendiren gidiş gelişleri en aza indirme yaklaşımından önce geliştirilmiştir. Bu nedenle temelindeki protokoller birlikte kullanıldıklarında bazen aynı işi tekrarlar. Örneğin tam WebRTC yığını bağlamında gerekli olmasa bile her protokol kendi hizmet engelleme saldırısı önleme mekanizmasını içeriyordu.

Yığını analiz ederek medya ve veri başlangıcını altı ağ gidiş gelişinden yalnızca bire indiren WebRTC Kısaltılmış Gidiş Geliş Protokolü'nü (WARP⁠(yeni bir pencerede açılır)) geliştirdik. WARP bunu geriye dönük uyumlu bir dizi protokol iyileştirmesiyle gerçekleştirir: DTLS el sıkışmasını ICE üzerinden taşımak (SPED⁠(yeni bir pencerede açılır)), daha hızlı DTLS 1.3⁠(yeni bir pencerede açılır) el sıkışmasını kullanmak, SCTP el sıkışmasını önceden uzlaştırmak (SNAP⁠(yeni bir pencerede açılır)) ve DCEP⁠(yeni bir pencerede açılır) kullanmak yerine veri kanallarını önceden uzlaştırmak.

Daha geniş ekosistemin bu çalışmadan yararlanabilmesi için WebRTC topluluğundaki iş ortaklarımızla birlikte WARP'ı açık spesifikasyonlar bütünü olarak tasarladık. Önerileri IETF'nin TSVWG çalışma grubu aracılığıyla ilerletiyoruz. WARP desteği libwebrtc ve Pion'a şimdiden eklendi; diğer WebRTC uygulamalarında da çalışmalar sürüyor.

Medya el sıkışmasını optimize ettikten sonra kalan bir gecikme öne çıktı: WebRTC bağlanmadan önce SDP parametrelerini paylaşmak için kullanılan sinyalleşme alışverişi. Bu alışverişi kritik yoldan çıkarmak için Instant Connect adını verdiğimiz sistemi geliştirdik. Sunucu kapasitesi ayırmadan ve mevcut WebRTC uygulamalarını değiştirmeden bu parametreleri önceden uzlaştırır.

Instant Connect, standart sinyalleşme akışıyla birlikte çalışır. Önceden uzlaştırılan parametreler geçerliyse sunucu, ilk medya paketi ulaştığında oturumu oluşturabilir. Parametreler eski veya geçersizse sinyalleşme akışı zaten devam ettiğinden istemci ek gecikme olmadan standart yönteme dönebilir.

Instant Connect ile WARP birlikte, kullanıcı niyetinden canlı medya akışına kadar geçen süreyi büyük ölçüde azaltır. SDP alışverişi kritik yolun dışında kaldığından ve WARP aktarım el sıkışmasını kısalttığından istemci artık tek bir UDP paketiyle oturum başlatabilir. Sunucu hemen yanıt verebilir ve sistemin geri kalanının kullanıcının asıl önemsediği işi yapmaya, yani dinleyip yanıt vermeye başlamasını sağlar.

Bir sistem kâğıt üzerinde hızlı görünüp gerçek sesli iletişim trafiği altında yine de tıkanabilir. GPT‑Live'ın kullanıcılarla konuşmasına izin vermeden önce, üretimdeki ChatGPT Sesli İletişim oturumlarının küçük ve kademeli olarak artan bir bölümünü hem mevcut gelişmiş sesli iletişim modu deneyimine hem de yeni sistemimize yönlendiren sessiz bir test gerçekleştirdik. Gelişmiş sesli iletişim modu kullanıcılara her zamanki gibi hizmet vermeyi sürdürürken gölge yol, çıkarımı salt okunur modda çalıştırdı. Böylece kullanıcıların duyduklarını değiştirmeden sistemi gerçek istemcilere, ağlara, oturum sürelerine ve coğrafi dağılıma maruz bıraktık.

İlk derslerden biri, kapasitenin yalnızca GPU işlem kapasitesine indirgenemeyeceğiydi. Sesli iletişim oturumları açık kalıp sürekli kare gönderdiğinden CPU tarafındaki akış işleyicilerinin, kuyrukların ve ağ yollarının da çıkarımla birlikte ölçeklenmesi gerekir. Gerçek yük altında, destekleyici bileşenlerden biri yük testi tahminlerimizden daha erken doygunluğa ulaştı; bunun sonucunda çıkarım istekleri birikti ve gecikmeler katlandı. Kapasiteyle ilgili sorumuzu “Bir GPU kaç isteği işleyebilir?” yerine “Sistem, her kareyi zamanında işlerken aynı anda kaç oturumu sürdürebilir?” olarak değiştirdik.

Test ayrıca coğrafyayı birincil öncelik hâline getirdi. Bir oturumu uzaktaki kapasiteye yönlendirmek, başlatma ve akış sırasında çeşitli noktalarda gecikmeye yol açabilir. Model dağıtımlarını bölgesel kapasite ve trafik yönlendirme yapılandırmasıyla birlikte doğrulamaya, ardından gecikmeyi kaynak coğrafyaya göre ayrıştırmaya başladık. Çıkarımı kullanıcılara yaklaştırmak işe yaradı ancak daha genel bir dersi de pekiştirdi: Uçtan uca yanıt hızı yalnızca model sunucusuna değil, yol üzerindeki her hizmete bağlıdır.

Diğer arızalar yalnızca gerçekçi oturum yaşam döngülerinde ortaya çıktı. Uzun süren oturumlar bellek ve kalıcılık üzerindeki baskıyı açığa çıkardı. Yeniden bağlantılar, bağlam yoğunlaştırma ve durum geri yükleme süreçlerini sınadı. Olağan istemci bağlantı kesintileri, kapatma el sıkışmasındaki yarış durumlarını ortaya çıkardı. Zamana, biriken duruma ve hizmet sınırlarını aşan davranışlara bağlı oldukları için bu sorunlar kısa yük testlerinde nadiren görülüyordu.

Son olarak üretim testleri, gözlemlenebilirliği ve dağıtım kontrollerini geliştirmemizi zorunlu kıldı. Farklı gecikme kaynaklarını birbirine karıştıran metrikler, toplu değerleri tekil sağlıksız motorları gizleyen panolar ve test edilen sistemlerle dağıtılan sistemler arasında yapılandırma sapmaları bulduk. Bunun üzerine daha ayrıntılı telemetri, çalıştığı bilinen yapılandırmalara göre doğrulama, aşamalı trafik artışı ve tekil yolları hızla yalıtma veya devre dışı bırakma olanağı ekledik. Sessiz test, yalnızca sistemin ne kadar trafik kabul edebileceğini değil, arızaları ne kadar hızlı tespit edip sınırlayabileceğimizi ve bunlardan ne kadar çabuk kurtulabileceğimizi de ölçen erken bir lansman provasına dönüştü.

GPT‑Live'ı ChatGPT ölçeğine taşımak için tek bir temel ilke etrafında kurulmuş yepyeni bir sistem gerekiyordu: Sesli iletişim kesintisiz akmalı. Akış tabanlı çıkarım, tam çift yönlü modeli kesintisiz sesli iletişimle besler. Özel bir medya yolu, karelerin güvenilir biçimde iletilmesini sağlar. Eşzamansız aktarım, daha derin düşünmenin paralel yürütülmesini sağlar. Optimize edilmiş aktarım, kullanıcıya kadar tüm deneyimin hızlı yanıt vermesini sağlar.

GPT‑Live'ın temelindeki mimari, gerçek zamanlı etkileşim için şimdiden daha geniş bir platforma dönüşüyor. ChatGPT Sesli İletişim'in sohbetten otonom koordinasyona doğru genişlemesini destekliyor ve yakında sunulacak GPT‑Live API'sinin temelini oluşturacak. Zamanla sesli iletişim deneyimlerinin, sesli sohbeti canlı hissettiren anındalıktan ödün vermeden daha fazla cihaza, uygulamaya ve modaliteye yayılmasını sağlayacak.

Siz de bu tür mühendislik sorunlarını çözmek istiyorsanız bize katılın⁠.