AWS, sesli yapay zekâ ajanları için Kokoro TTS'i SageMaker AI üzerinde sundu

Amazon Web Services (AWS), sesli yapay zekâ ajanlarının yanıtlarını beklerken oluşan gecikmeyi azaltmak için Kokoro-82M metinden sese modelini Amazon SageMaker AI üzerinde akışlı biçimde çalıştıran bir çözümü duyurdu. Şirketin Machine Learning Blog'unda yayımlanan yazıya göre yöntem, ajanın yanıtının tamamını beklemek yerine her cümleyi üretildiği anda sentezlemeye gönderiyor.

AWS'nin aktardığı örneğe göre tek cümlelik bir yanıt yaklaşık 600 milisaniyede üretilebiliyor, ancak çok paragraflı bir yanıtın tamamı 5 saniyeyi bulabiliyor. Mevcut entegrasyonlar sentezi bu sürenin sonunda başlattığı için kullanıcı bu arada sessizlikle karşılaşıyor. Akışlı yaklaşımda ses, ilk cümle hazır olduğunda çalmaya başlayabiliyor.

Kokoro TTS neden tek GPU'ya sığıyor?

Kokoro-82M, adından da anlaşılacağı gibi 82 milyon parametreli küçük bir model. AWS'ye göre bu boyut, modelin tek bir orta seviye GPU örneğinde ekonomik biçimde çalışmasına imkân veriyor. Şirket, gerçek trafik altında hem gecikmenin hem de çıkarım maliyetinin bu sayede düşük kaldığını belirtiyor.

Model, SageMaker AI gerçek zamanlı uç noktasında ml.g5.xlarge GPU örneği üzerinde özel bir konteynerde çalışıyor. Konteyner iki yol sunuyor: tek bir girdi için yanıt akıtan POST /invocations ve çift yönlü olarak birçok mesaj boyunca açık kalan WS /invocations-bidirectional-stream.

Çift yönlü akışta hangi hatalar öne çıkıyor?

AWS'nin yazısı, kurulum sırasında karşılaşılan iki soruna dikkat çekiyor. İlki, SageMaker AI'ın istemci mesajının her parçasını ikili WebSocket çerçevesi olarak iletmesi. Yaygın kullanılan receive_text() çağrısı bu durumda KeyError veriyor ve hata, genel bir istisna yakalayıcı tarafından istemciye 'text' biçiminde bir hata çerçevesi olarak dönüyor. Uç nokta ise bağlantıları kabul ettiği ve her mesaja yanıt verdiği için InService durumunu koruyor; bu da sorunun teşhisini zorlaştırıyor.

İkinci sorun, konteynerin bir mesajın sesini gönderdikten sonra oturumu kapatma eğilimi. AWS'ye göre doğru davranış, aynı açık oturumda bir sonraki mesajı beklemek ve bağlantıyı yalnızca istemci açık bir kapatma mesajı gönderdiğinde sonlandırmak. Aksi halde her cümle için yeni bağlantı kurulması gerekiyor ve gecikme kazancının büyük kısmı kayboluyor.

Ses tarayıcıya nasıl taşınıyor?

Yazı, metni modele akıtmanın sorunun yalnızca yarısını çözdüğünü belirtiyor. Diğer yarısı, üretilen sesi tarayıcıya ulaştırmak. Çoğu ajan ve sohbet arayüzü metni zaten Server-Sent Events (SSE) ile aktarıyor; ancak SSE tek yönlü ve metin tabanlı bir protokol, ham ikili veriyi taşımak için tasarlanmamış. AWS, bu nedenle sesin base64 ile kodlanıp bir JSON olayına sarılması yaklaşımının maliyetini 24 ses klibi üzerinde ölçtüğünü ve Amazon Transcribe ile kodlamalar arasında kalite farkı olmadığını doğruladığını aktarıyor.

Ölçüme göre base64, her yükü beklenen oran olan yaklaşık yüzde 33 şişiriyor. Daha az görünür maliyet ise çerçeve hizalaması: SSE olayları boş satırla ayrılırken, içindeki ses MP3 karelerine bölünüyor ve iki şema her zaman örtüşmüyor. AWS'nin paylaştığı bir örnekte dört mantıksal MP3 karesi altı teslimat parçası halinde geldi ve ikisi karenin ortasında kesildi.

Şirketin bugün modelle konuşan tarafta kullandığı alternatif yöntem ise base64 ve SSE çerçevelemesini tamamen atlıyor. Ham ikili ses ve JSON kontrol çerçeveleri, artımlı metni taşıyan aynı çift yönlü oturum üzerinden gönderiliyor ve tek bir kuralla ayırt ediliyor: JSON nesnesi olarak çözülemeyen parça ses sayılıyor. Ham PCM sesin 0x7b baytıyla, yani JSON nesnesini açan { karakteriyle başlayabildiği durum da bu kural sayesinde yanlış sınıflandırılmıyor; çünkü kural ilk bayta değil, parçanın tamamının geçerli JSON olarak çözülmesine bakıyor.

Neden önemli?

Sesli ajanlarda gecikme, kullanıcının soruyla yanıt arasındaki sessizlikte ilgisini kaybetmesine yol açan temel sorunlardan biri. AWS'nin önerdiği mimari, modelin küçük tutulmasıyla maliyeti, cümle bazlı akışla da algılanan bekleme süresini düşürmeyi hedefliyor. Yazıda ayrıca, mevcut SSE hattı olan ekipler için base64 kodlu sesin pratik bir seçenek olduğu, ses yolunu sıfırdan kuranlar ya da gecikmeyi önceleyenler için birleşik ikili ve JSON yaklaşımının iki maliyetten de kaçındığı belirtiliyor.

Kaynak metin, örnek konteynerin bilinen bir güvenlik bildirimi bulunan eski bir PyTorch sürümüne sabitlendiğini ve üretim dışı kullanımdan önce bu sürümün gözden geçirilip yükseltilmesi gerektiğini de not ediyor. Modelin Türkiye'deki kullanıcılara yönelik erişim koşulları ya da Türkçe desteğine ilişkin bir bilgi ise paylaşılmadı.