Sanal sesli temsilcilerde ultra düşük gecikme ile bulut ekonomisini dengeleme

Devin Reimer

Sanal ses aracılarında ultra düşük gecikme ve bulut ekonomisini dengeleme konulu kursa hoş geldiniz.

Ben Devin Reimer.

AstroBeam'in kurucusu ve CEO'suyum.

Daha önce, muhtemelen en çok Job Simulator ile tanınan Owlchemy Labs'in CEO'su ve kurucu ortağıydım.

AstroBeam'de oyunlarda gerçek zamanlı yapay zeka oluşturmaya odaklanıyoruz.

Özellikle ses girişine odaklanıyoruz.

Şimdiye kadar iki oyun yayınladık. Bunlardan biri VR ve PC'de oynanabilen Stellar Cafe.

Uzay istasyonundaki bir kafede robotlarla konuşup sorunlarını çözmelerine yardımcı olduğunuz bir oyun.

Tamamen sesle kontrol edilir.

Menüler ve gezinme dahil olmak üzere oyunun tamamını yalnızca sesinizle oynarsınız.

Bugün duyurduğumuz yeni oyunumuz Robo Detective, Android XR ve özellikle XREAL'in Project Aura'sı için tasarlandı.

Bu oyunda, robot suçlarını çözmek için robotlarla görüşme yapmanıza yardımcı olan bir robot partnerle çalışan bir dedektifi canlandırıyorsunuz. Bu oyun da tamamen sesle oynanıyor.

Sesli temsilcilerle çalışmak gerçekten zor. Oyunlarda ise daha da zor.

Bunun nedeni, oyunların çok düşük maliyetli olması ve sesli asistanın bu sürece yeni bir maliyet eklemesidir.

Ayrıca diğer sesli asistanlarla değil, şimdiye kadar yapılmış tüm oyunların kalitesiyle rekabet ediyoruz, değil mi?

Bu nedenle, çok yüksek kalitede içerikler sunmamız gerekiyor.

Bu, benzersiz zorlukların olduğu veya risklerin çok daha yüksek olduğu belirli sesli temsilci kullanım alanlarının olmadığı anlamına gelmez ancak oyunlar bu alanda teknik açıdan kesinlikle çok zorlayıcıdır.

Ancak bunlar oyun olduğu için bu zor sorunlardan bazılarını çözme konusunda deneme yapmaya çok fazla alan kalıyor.

Bu nedenle, sesli temsilciler oyunlarda çalışabiliyorsa neredeyse her yerde çalışabileceklerine inanıyorum.

Bu konuşmada bahsettiğim şeyler yalnızca oyunlar için değil, geliştirmek istediğiniz tüm ses öncelikli uygulamalar için geçerli.

Sesli temsilcilerle ilgili üç temel zorluk olduğunu düşünüyorum.

Gecikme, zeka ve maliyet.

Ancak sesli temsilcilerden bahsederken istem olarak değil, sohbet olarak sesli temsilcilerden bahsettiğimi belirtmek isterim.

Bir LLM'ye bir şey gönderip yanıt bekleyen bir mikrofon sarmalayıcıdan bahsetmiyorum.

Gerçek dünyada, gerçek zamanlı bir karşılıklı konuşmadan bahsediyorum. Bunu oluşturmak aslında oldukça zor.

Gecikmeyle başlayalım.

Ne kadar hızlı olması gerekiyor?

Hızlı, çok hızlı olması gerektiği ortaya çıktı ancak okuduklarınıza bağlı olarak düşündüğünüz kadar hızlı olmayabilir veya düşündüğünüzden çok daha hızlı olabilir.

Şimdi, testlerimizin çoğunda keşfettiğimiz bazı sayılardan bahsedelim.

Uçtan uca gecikme süresi, kullanıcının son konuşmasından (kullanıcının çıkardığı son sesten) sesin kullanıcıya geri döndüğü ana kadar geçen süredir.

Testlerimizde, kullanıcıların oyun testi geri bildirimlerinde hız veya yavaşlık gibi konulardan bahsetmeyi bıraktığı noktanın yaklaşık 1,5 saniye olduğunu fark ettik.

İnsanlar bu noktadan sonra kendilerini gerçekten rahat hissetmeye başlıyor.

Bundan daha yavaş olduğumuzda insanlar genellikle "Bu harika ama..." diyerek bunu dile getiriyor. Bu nedenle, bu süre ideal bir nokta gibi görünüyor.

Daha da hızlandığınızda, yaklaşık 1,2 saniyede, daha doğal bir karşılıklı konuşma gerçekleşmeye başladığını fark ettik.

Yani ben bir şey söylüyorum, bu durumda robot çok hızlı bir şekilde bir şey söylüyor ve siz de bir nevi karşılıklı konuşuyorsunuz.

Bu konuda bir denge yakalanmış gibi görünüyor.

Bununla birlikte, 1,2 saniye bir yığın içinde gerçekten yapılması oldukça zordur.

Bir diğer ilginç bulgu da, çok sayıda test yaptık ve bazı senaryolarda bir saniyenin altında sonuçlar elde ettik.

"Harika olacak!" diye düşünebilirsiniz.

Bazen öyleydi, bazen de korkunç, çok tuhaf hissettiriyordu.

Bu nedenle, insanların 800 milisaniyelik yanıt süresinin doğru sayı olduğunu veya 500 olduğunu söylediğini duyabilirsiniz.

Hatta 300 ile ilgili bir sürü makale okudum çünkü insan algısı gerçekten bu noktada devreye giriyor.

Aslında bu tamamen bağlama bağlıdır.

Örneğin, size adınızı sorduğumda yanıt vermenizin ne kadar süreceğiyle ilgili bir beklentim olur.

Hayatın anlamını sorarsam çok farklı bir yanıt süresi beklerim.

Testler yapıp kullanıcılardan bu yanıtın hızlı mı yoksa yavaş mı olduğunu değerlendirmelerini istediğimizde, sayılara baktığınızda aslında her yerdeydi.

Uzun süren yanıtların hızlı olduğu, hızlı yanıtların ise yavaş olduğu söylendi. Çünkü bu durumun tamamen bağlama bağlı olduğu ortaya çıktı.

Ayrıca, görüşmenin neresinde kaldıklarını da görebilirler.

Genellikle kullanıcılar, düşünme süresi olduğu için ilk yanıtın sonraki yanıtlardan daha hızlı olmasını bekler.

Ancak bazen çok kısa bir süre içinde yanıt alırsınız ve beklentiniz artar.

Yani bu, mükemmel bir sayının olduğu mükemmel bir bilim değil, ancak yaklaşık 1, 5 olduğunu keşfettik, bu noktadaysanız oldukça iyi bir noktadasınız demektir.

1,5 saniyeye ulaştığınızda tutarlılığa önem vermeye başlarsınız.

Çünkü bu durum %90 oranında gerçekleşirse ancak %10 oranında 3 saniye sürerse deneyiminiz kötü değil, bozuk hissettirir.

Yeterince hızlı hale geldiğinizde tutarlılığa önem vermeye başlarsınız. Yani çoğu zaman değil, her zaman hızlı olmaya çalışırsınız.

Devin Reimer

Standart bir ses ardışık düzeni mimarisi bu şekildedir.

Yani, Speech-to-Text'i alıp LLM'ye gönderiyoruz ve ardından LLM'den gelen sonucu Text-to-Speech'e geri gönderiyoruz.

Yani, sesle yazma özelliğinde sesi sunucuya gönderip metne dönüştürüyoruz.

LLM tarafında bu metni, yani yanıt diyaloğunu alıyoruz veya yanıt diyaloğuna dönüştürüyoruz. Ardından bu karakterin hangi eylemleri gerçekleştireceğini belirliyoruz.

Bunları sıkı bir şekilde birbirine bağlıyoruz çünkü bunun çok önemli olduğunu düşünüyoruz.

Metin Okuma tarafında ise bu metni alıp Metin Okuma'ya gönderiyoruz ve kullanıcıya aktarıyoruz. Bu işlem, temsilcinin gerçekleştirmek istediği işlemlerle de zamanlanıyor.

Bu yaklaşımın sorunlarından biri, her bir adımı tek tek uygulamanız gerektiği için sıralı çalıştırmanın oldukça yavaş olabilmesidir.

Bu nedenle, sıkça karşılaştığım bir soru var: "Bu süreç yavaşsa ve üç adım gerektiriyorsa neden doğrudan bir konuşmadan konuşmaya modeli kullanmıyoruz?"

Çünkü bu daha hızlı olur, değil mi?

Çoğu zaman tek bir şey çalıştırdığınız için bu daha hızlı olur.

Ancak bu durumun bazı önemli dezavantajları vardır.

Hızlı olmasına rağmen bizim için önemli dezavantajları var. Bunların en büyüğü de maliyet.

Dolayısıyla, konuşmadan konuşmaya modelini çalıştırmanın bu paralel yaklaşıma göre genellikle yaklaşık 3 ila 5 kat daha pahalı olduğunu gördük.

Bu nedenle, ekonomik açıdan bizim için uygun değil.

Güvenlik açısından bakıldığında, temsilcinin vereceği yanıtı söylemeden önce doğrulamak daha zor olduğu için bu durum aslında biraz daha karmaşıktır.

Ancak bu arada, ardışık düzen yaklaşımınız varsa LLM'nin verdiği yanıtı alıp kullanıcıya göndermeye yaklaşmadan önce doğrulayabilir ve güvenlik kontrolü yapabilirsiniz.

Ses stilinde, Konuşmadan Konuşmaya modelindeki hazır ayarlarla sınırlısınız.

"Biliyor musun?

Bu durumda bu tür bir ses kullanmak istiyorum."

Bu durumda, o seçeneğe bağlı kalırsınız.

Ardışık düzende ise "Değişiklik yapacağım.

Bu kullanım alanı için çok iyi çalıştığından bu modeli seçeceğim."

Aynı şey zeka için de geçerli, değil mi?

İyi ses üreten çok iyi bir konuşmadan konuşmaya modeliniz varsa ancak zeka tam olarak istediğiniz gibi değilse bunu değiştiremezsiniz, değil mi?

Bir nevi kilitlenmiş oluyorsunuz.

Ardışık düzene dayalı yaklaşımda ise "Bu kullanım alanı için belirli bir modeli kullanmak istiyorum." diyebilirsiniz.

Konuşmadan Konuşmaya özelliğinin kesinlikle daha iyi olduğu bir alan, kullanıcının ses tonunu anlamaktır.

Örneğin, alaycı ifadeler gibi şeyler.

Şu anda konuşmayı metne dönüştürme transkriptlerinde genellikle bu bilgilerin çoğu yer almıyor ancak bunun zamanla değişeceğini düşünüyorum.

Bu, Speech-to-Speech'in kesinlikle avantajlı olduğu bir nokta.

Dolayısıyla, Speech-to-Speech'in hız açısından kesinlikle bir avantajı var ancak yapılandırılabilirlik açısından bazı zorlukları var ve yüksek maliyet, özellikle bizim için, anlaşmayı bozan bir unsur oldu.

Peki, başka bir yol var mı?

Evet.

Bu durumda, ardışık düzeni paralel hâle getirmek için elimizden geleni yapmalıyız.

Bu nedenle, yaptığımız şeylerden biri, konuşmayı metne dönüştürme işlemi tam olarak güvenilir olmadan önce LLM'yi çalıştırmaktır.

Güven derken, transkriptte oluşturulan kelimelere olan güveni ve ardından sıra sonuna olan güveni kastediyorum.

Bu nedenle, kullanıcının konuşmayı bıraktığı anın bu olduğunu ve söylediği şeyin bu olduğunu düşündüğümüz anda harekete geçiyoruz.

Bu durumda en kötü senaryo, yanılıyor olmamızdır, değil mi?

Kullanıcı konuşmaya devam eder.

Ancak bu senaryoda bile tek yaptığımız LLM'yi iptal edip tekrar çalıştırmak.

Bağlam muhtemelen önbelleğe alınacağı ve çok fazla jeton üretmediğimiz için bu işlemin maliyeti yüksek olmaz. Ayrıca, kullanıcı tam güveni beklemenize kıyasla yanıtları daha hızlı duyar.

Ayrıca, LLM'nin yanıtının tamamını oluşturmasını beklemeden yanıtı Text-to-Speech'e göndermeye başlarız.

Beklediğimiz şey, ilk konuşulabilir parçadır.

Çoğu senaryoda bu bir cümledir.

Bazen başka yapılandırmalar da olabilir ancak ilk cümle parçasını alır almaz metin okuma özelliğimize göndeririz.

Ardından, akış yapacak iyi bir Metin Okuma modelimiz varsa akışa hazır olduğu anda kullanıcıya sunulabilir.

Oluşturulması gereken jeton sayısına da çok dikkat ediyoruz.

Bu nedenle, ek jetonlar ekleyebilecek JSON sarmalayıcıları gibi şeyler kullanmıyoruz.

Mümkün olan en hızlı yanıtı almak için en basit yapının ne olduğunu bulmaya çalışırız.

Ayrıca, temsilciden gelecek ilk jeton grubunun ne olacağını önceden biliyorsak asistan ön doldurma gibi özellikleri de kullanırız.

Metin okuma için bu iki parçayı kullandık, değil mi?

Böylece ilk seslendirilebilir parça gelir ve ardından diğer her şeyi çalıştırırız.

Ancak ses çıkışını dinlemek, oluşturmaktan daha uzun sürdüğü için neredeyse her zaman ikinci parça tamamlandığında ilk parçanın kullanıcıya çalınması tamamlanmış olur.

Bu nedenle kullanıcı tarafından görülmez.

Mümkün olan en hızlı şekilde gelir.

Farklı hizmetler seçmeyi düşünürken göz önünde bulundurmanız gereken bazı genel kurallarımız şunlardır:

İyi bir ses ve temsilci çerçevesi seçerken dikkat etmeniz gereken en önemli nokta, giriş ve çıkışta en düşük gecikme süresidir.

Peki, ne kadar hızlı veri gönderip alabilirim?

Konuşmayı metne dönüştürme tarafında ise güvene ulaşma süresine önem veriyoruz.

Yani bu, transkriptteki güven ve sıra sonundaki güvendir.

Bunlar birbiriyle eşleşiyor, değil mi?

Birine hızlı bir şekilde güvenmezseniz süreç de o kadar yavaş ilerler, değil mi?

Bu nedenle, yalnızca en yavaş olan kadar hızlıdır.

LLM tarafında ise ilk cümleye, yani ilk konuşulabilir parçaya kadar geçen süreye önem veriyoruz.

Bu iki bölümden oluşuyor, değil mi?

İlk jetona kadar geçen süre ile saniye başına jeton sayısının birleşimidir.

Dolayısıyla, ilk jeton süresi çok iyi olan ancak saniye başına jeton hızı düşük olan bir model bulursanız bu model, alternatifinden daha kötü olabilir.

Bu nedenle, bunun için doğru kombinasyonun ne olduğunu bulun.

Metin okuma tarafında ise ilk sese kadar geçen süre önemlidir.

Bu nedenle, bunun ne olduğunu ölçmek çok önemlidir. Çünkü bazen ses, başta sessizlik olacak şekilde geri gelebilir ve kullanıcı bunu duyamaz.

Bu nedenle, kullanıcının sesleri duyduğu noktaya kadar ölçüm yapmanız gerekir.

Daha önce de belirttiğim gibi, her şeyden önce en yüksek hızlara veya en iyi senaryoya değil, kararlılığa önem verirsiniz.

Bu yığının tamamının tutarlı gecikme süresi nedir?

Devin Reimer

Şu anda sesli temsilci çerçevelerimiz için LiveKit'i kullanıyoruz.

Sesle yazma için Deepgram'ı kullanıyoruz.

LLM'ler için Gemma 4 31B'yi kullanıyoruz ve LiveKit'te barındırıyoruz.

Metin okuma tarafında ise Inworld AI metin okuma 2'yi kullanıyoruz.

Ayrıca tüm bunları bir araya getiren ve özellikle oyunlar için bizimki gibi son derece etkileşimli, gerçekten iyi bir sesli yapay zeka ajanı için ihtiyacınız olan tüm parçaları ekleyen AstroBeam yapay zeka ajan düzeneğimizi geliştirdik.

Güvenlik modellerinden bahsetmedim.

Geleneksel olarak güvenlik modelleri LLM geçişinin bir parçasıdır ancak bu durum gecikmeye neden olur ve ek bir adım gerektirir.

Peki, bunun yerine kendi sunucunuzu çalıştırırsanız ne olur?

Yani yığınımız aslında daha çok bu şekilde görünüyor.

Burada yaptığımız şey, ilk metin parçasını aldığımızda, metin okuma modeline göndereceğimiz ilk seslendirilebilir parçayı aynı anda güvenlik modelimize de göndermek.

Güvenlik modeli daha küçük olduğundan ve konuşmayı metne dönüştürme işleminden daha hızlı çalışacağından, neredeyse her zaman önceden yapılır.

Bu da güvenlik modeli eklemenin yığınımıza sıfır gecikme eklediği anlamına geliyor. Hatta bu, çoğu kişinin çalıştırmayı düşündüğünden çok daha büyük bir güvenlik modelini çalıştırabileceğimiz kadar büyük bir parça.

Bu bizim için çok önemli, özellikle de oyun geliştirdiğimiz için.

Bu dünyada çok önemli olan pek çok bağlam var.

Örneğin, orta çağ temalı bir oyun geliştiriyorsunuz ve bu oyunda "Saldırın!" diye bağıran bir NPC var.

"Kellesini uçurun!" değil mi?

Geleneksel bir güvenlik modeli, "Bu hiç hoş değil.

Bunu söylememeniz gerekir."

Ancak bu oyunun bağlamında bu son derece mantıklı.

Bunu yapabilmek için dünyada olup bitenleri daha iyi anlayabilen, daha güçlü bir güvenlik modeli kullanıyoruz.

Burada güvenlik modelini iki kez çalıştırdığımızı fark edebilirsiniz. Önce ilk parçada çalıştırıyoruz, ardından son parçayı da aldığımızda hepsini bir arada çalıştırıyoruz.

Yine iki kez çalıştırmamız gerekiyor ancak bu işlem yığına gecikme eklemiyor.

Artık yeterince hızlıyız ancak yeterince akıllı değilsek bunun bir önemi yok.

Devin Reimer

Peki, ne kadar akıllı olması gerekiyor?

Kullanıcılarınız için yeterince akıllı olması gerekir ancak daha da önemlisi, sizin geliştirme yapabileceğiniz kadar akıllı olması gerekir.

Bu, insanların zeka için neye ihtiyaç duyduklarını seçerken genellikle düşünmedikleri bir şeydir.

Yaklaşık üç yıldır sesli temsilciler üzerinde çalışıyoruz. Örneğin, ilk zamanlarda bazı erken LLaMA modellerini kullanıyorduk ve bunları kullanıcılar için çalışır hale getirebilsek de her şey çok kırılgan olduğu için geliştirme tarafı çok pahalıydı.

Modellerin istenmeyen yanıtlar veya anlamsız şeyler üretmesi çok kolaydı. Bu nedenle, bunu düzeltmek için çok fazla mühendislik çabası harcadık.

Bu nedenle, bu konuya öncelik veriyoruz. Bu özellikleri geliştirirken hızlı hareket edemezsek kullanıcıların hizmetine sunamayız.

Bu nedenle, her ikisini de düşünmek çok önemlidir.

İnsanlar zeka dendiğinde genellikle LLM'leri düşünüyor, değil mi?

Ancak bu, işin yalnızca bir kısmı.

Zeka söz konusu olduğunda her parçayı düşünmemiz gerekir.

Şimdi de konuşmayı metne dönüştürme zekasından bahsedelim.

Burada bizim için önemli olan, kelime hata oranının düşük olmasıdır.

Ayrıca, hata oranı düşük olmakla kalmıyor, hata olduğunda da gerçek şeye çok yakın bir şey üretiyoruz. Çünkü gerçekten yakınsa LLM, bağlamla birlikte ne olduğunu anlama konusunda genellikle çok iyi bir iş çıkarabiliyor.

Hata oranınız düşük ancak yanlış adımlar çok yüksekse LLM, asıl amacın ne olduğunu anlamaya çalışırken çok daha fazla zorlanır.

Dikkate almanız gereken bir diğer konu da hedef platformunuzun ne olduğudur.

Örneğin, XR için geliştirme yapıyorsam ve kullanıcının ağzına çok yakın mikrofonlarım varsa gerçekten iyi, yüksek kaliteli mikrofon ses verileri elde ederim ve bu, belirli modeller için çok iyi çalışabilir.

Ancak aniden, insanların kalabalık bir sokakta kullanacağı bir cep telefonu uygulaması geliştiriyorsam bu durumun çok farklı bir etkisi olur. Farklı modeller farklı şekilde davranır ve söylenenleri farklı şekillerde akıllıca yorumlayabilir.

Bu nedenle, bunu göz önünde bulundurmanız ve geliştirdiğiniz platform için doğru seçimi yaptığınızdan emin olmanız gerekir.

Şimdi de zeka denkleminin metin okuma tarafına geçelim.

Doğal bir konuşma gibi geliyor, değil mi?

Hedefimiz, kullanıcıya ne olduğunu anlatmak. Kullanıcı bunu anlayabiliyor mu?

Ancak bu, işin yalnızca bir kısmı, değil mi?

Temsilcinin kendini ifade edebilmesi de çok önemli. Çünkü kendini ifade etme biçimi de bilgi içerir. Ayrıca oyun testlerimizde, temsilcilerimiz kendilerini ne kadar iyi ifade edebilirse kullanıcıların onları o kadar akıllı bulduğunu keşfettik. Bu da son derece mantıklı.

Ardından, yeterince hızlı mı?

Önceki bölümde gecikmeden bahsetmiştim ancak gecikme, algılanan zeka açısından da önemlidir.

Kullanıcılar, yanıt hızının zeka ile doğrudan ilişkili olduğunu düşünür.

Hızlı bir yanıtım varsa muhtemelen daha akıllıca bir yanıt olur.

Bu nedenle, kullanıcının deneyimi nasıl algıladığı ve deneyime ne kadar dahil olabileceği konusunda bu unsurlar gerçekten önemli olabilir.

Şimdi de zekanın LLM tarafına geçelim.

Dengelemesi en zor olanı bu çünkü çok fazla farklı gereksinim var, değil mi?

Yani konuşmayı anlama, bağlam ve temellendirme gibi özelliklerimiz var.

Oyunlarda bunu yapmak çok zor çünkü koca bir dünyayı ve evreni temel almanız gerekiyor, değil mi?

Bu, olan bitenleri uydurabileceği bir metin kutusu değildir.

Oyun içindeki temsilciniz "Masada bir elma var" derse ve masada elma yoksa bu durum kullanıcının deneyimini bozar.

Ayrıca kurallara sıkı sıkıya uyma gibi özelliklere de ihtiyacımız var.

Oyunlar kurallara dayalıdır.

LLM bunu yapabilir mi?

Halüsinasyon oranını düşürebilir miyiz?

Aynı temsilciyle tekrar tekrar etkileşim kurduğunuzda tutarlı karakterler elde edebilir miyiz?

Aynı temsilciyle mi konuşuyormuş gibi hissettiriyor?

Geliştirme sürecinin başında sorun olmasa da sonradan sizi zorlayabilecek bir diğer konu da modelinizin büyüyen istem boyutunu kaldırıp kaldıramayacağıdır.

Çünkü geliştirmeye devam ettikçe isteme daha fazla şey ekleyeceksiniz.

Ancak kullanıcılar oynamaya devam ettikçe bu istemde daha fazla sohbet geçmişi de olacak.

Bu istem, artan talebi karşılayabilecek mi?

Çünkü bazen belirli modellerde isteminiz büyüdükçe yanıtın kalitesi düşer. Bu nedenle, her seferinde bu isteme girilmesi gereken miktar için gerçek ihtiyaçlarınızın ne olduğunu bulmanız gerekir.

Ancak bu sadece buzdağının görünen kısmı ve aslında ne geliştirdiğinize bağlı.

Bu nedenle, ne geliştirdiğiniz ve neyi başarmaya çalıştığınız konusunda çok dikkatli düşünmeniz gerekir.

Artık yeterince hızlı ve akıllıyız. Ancak çok pahalıysa bunların hiçbirinin önemi yok.

Devin Reimer

Peki ne kadar ucuz olması gerekiyor?

Maalesef durum bundan biraz daha karmaşık.

Bu nedenle, geliştirdiğimiz uygulama veya oyunun ekonomisini düşünmemiz gerekir.

Bu nedenle, sormanız gereken birkaç soru var.

Kullanıcı, sesli temsilcilerinizle ne kadar süre etkileşimde bulunacak?

Kullanıcı başına ne kadar kazanıyorsunuz?

Bu ses yığınının saatlik çalışma maliyeti ne kadar?

Bunları bir araya getirip anlamlı olup olmadıklarını anlamaya çalışırız.

İlk oyunumuz Stellar Cafe'nin ekonomisi şöyle.

Stellar Cafe'de oyun süresi 1,5 ile 3,5 saat arasında değişiyor. Ortalama 2 saat diyelim.

Sesli temsilcileri çalıştırmanın maliyeti kullanıcı başına saatte yaklaşık 1, 20 ABD doları.Kullanıcılar bu temsilcilerle her zaman etkileşim kuruyor.

Tamamen sesle oynanan bir oyundur.

Oyun için 10 ABD doları tutarında sabit bir ücret alıyoruz. Bu, geleneksel bir yöntem.

Oyunlarda çok zor olduğu için abonelik sunmuyoruz. Sabit bir maliyetle çalışması gerektiğine inanıyorum. Aksi takdirde bu işe yaramaz ve ölçeklenemez.

Daha önce 15 ABD doları ücret alıyorduk ancak bu sunucu maliyetlerini düşürmek için çalışıyoruz. Bu nedenle, şu anda 10 ABD dolarına indirdik.

Bu 1,20 ABD doları, şu anki durumumuz.

Bu, her yerde geçerli olan bir maliyet değildir.

Bu tür şeylerin çok farklı fiyatlara satıldığını ve bazen çok daha pahalı olduğunu gördüm.

Bu nedenle, maliyet açısından nerede olduğunuzu da belirlemeniz gerekir.

Daha ucuz bir model de üretebilirdik ancak kalite çıtamızı mümkün olduğunca yüksek tutmaya çalışıyoruz.

Tüm bunları hesapladığımızda, 2 saatlik oyun süresi için ses yığınımızın kullanıcı başına maliyeti yaklaşık 2,40 ABD doları oluyor.

10 ABD doları ücret aldığımız ve mağaza da ücret aldığı için kullanıcı başına yaklaşık 4,59 ABD doları kazanıyoruz, değil mi?

Bu nedenle, bunun ekonomisi işe yarıyor, değil mi?

Ses, bizim kancamız. Para harcamak istediğimiz şey bu. Bu işe yarıyor.

Bu çok küçük bir oyun.

Şimdi biraz daha büyük bir şeyden bahsedelim.

Şimdi, 5 ila 9 saat, ortalama 7 saat süren varsayımsal bir hikaye oyunundan bahsedelim.

Aslında çoğu kişi oyunları bitirmez. Biraz oynayıp bırakırlar. Ancak ekonominin işlediğinden emin olmak için biraz daha yüksek bir oran seçmek istiyorum.

Bu nedenle, saatte 1, 20 ABD doları olan bu tutarı koruyacağız ancak yapacağımız değişiklik, ses bileşeninin %60 oranında kullanılacak olmasıdır.Çünkü daha büyük bir oyunda sesten çok daha fazla mekanik olacaktır.

Yani, sesle oynanan bir oyun olmaya devam edecek ancak içinde başka özellikler de olacak.

Yani 20 dolar ücret alırsak, tüm bunları tekrar hesapladığımızda, kullanıcı başına yaklaşık 5 dolar maliyetimiz olur. Bu da günün sonunda kullanıcı başına yaklaşık 9 dolar kazandığımız anlamına gelir.

Yani bu sayede ekonomik açıdan da kârlı bir iş ortaya çıkıyor.

Bu, ekonomik açıdan her şeyin işe yarayacağı anlamına gelmez.

Örneğin, "Ücretsiz oynanabilen bir oyun geliştirmek istiyorum ve kullanıcılar bu oyunu muhtemelen 1 saat ile 100 saatten fazla oynayacak." gibi bir yaklaşım doğru olmaz.

Ortalama 10 saat diyelim.

%100 sesle kontrol ediliyor. Diyelim ki oyunumuz çok başarılı oldu ve kullanıcı başına yaklaşık 3 ABD doları kazandırıyor. Ücretsiz oynanabilen bir oyun için bu oldukça iyi bir rakam.

Kullanıcı başına 10 ABD doları kaybedersiniz.

Yani henüz tüm bu konularda çalışmıyor ve şu anda ne oluşturduğunuzu ve bunun mantıklı olup olmadığını düşünmeniz gerekiyor.

Ekonomik durumu anlamak için son ana kadar beklemeyin.

Devin Reimer

Ardından, "Peki ya yerel modeller?" sorusu sorulur.

Çünkü maliyetle ilgili bu büyük zorlukla karşılaşıyorsanız yerel modeller bunu ortadan kaldırmaz mı?

Evet, bu mümkün.

Ancak burada düşünmemiz gereken bazı ödünler var.

Maliyet açısından bakarsak sunucu faturasını ortadan kaldırmış oluruz. Bu da büyük bir avantaj sağlar ve daha fazla fırsat sunar.

Ancak şu anda bulutun çözebileceği, yerel olarak zorlanılan pek çok şey var.

Örneğin, işlem.

İnsanlar genellikle "Bakın, çok iyi bir konuşma metni modeli buldum ve bu cihazda yerel olarak çalışıyor, değil mi?" diyor.

Harika, ancak tek bir model değil, birden fazla model çalıştırdığını düşünmemiz gerekiyor, değil mi?

Bizim durumumuzda, potansiyel olarak aynı anda dört tane var. Bu nedenle, bir şeyin bir kez çalışması yeterli değil, aynı anda birden çok kez çalışması gerekiyor.

Bunu yaptıktan sonra oyununuzun veya uygulamanızın çalışması için yapmanız gereken başka bir şey kaldı mı?

GPU'yu maksimum kapasitede kullanıyorsanız video oyununu pek fazla oluşturamazsınız.

Bu zorlukların üstesinden geldiğinizi varsayalım.

Sırada hız var, değil mi?

Genellikle çalıştırabilirsiniz ancak çok yavaş olurlar ve gerçek zamanlı bir sohbetten ziyade istem girmeye benzerler.

Teorik olarak, yerel olarak almak gelecekte bir kazanç sağlar çünkü internetten gidiş dönüş yapmanız gerekmez.

Şu anda bu işi yapacak doğru hızda çalışacak modelleri bulmak zor.

Diyelim ki işlem gücü ve hız sorunlarını çözdünüz. Şimdi de kaliteyi düşünmeniz gerekir, değil mi?

Genellikle yerel bir cihazda çalıştırdığınız için daha küçük bir LLM (ör. daha ilkel bir metin okuma modeli) kullanırsınız. Bu durum, oluşturduğunuz içerik açısından bazı zorluklara neden olabilir.

Daha önce de belirttiğim gibi, LLM'yi değerlendirirken yalnızca kullanıcılarınız için yeterince iyi olup olmadığını değil, sizin geliştirme yapmanız için yeterince iyi olup olmadığını da düşünmelisiniz.

Bu nedenle, bu modelle bir şey oluşturmak oldukça zorlaşırsa bu kesinlikle üzerinde düşünülmesi gereken bir konudur.

Hesaplama, hız ve kalite konularında başarılı olduğunuzu varsayalım. Sırada taşınabilirlik var.

Kazandıysanız ve tüm bu süreçten geçtiyseniz ve bu şeyi, diyelim ki bir RTX 5070'te çalıştırdıysanız, çalışabileceği tek yer burası olabilir.

Bu nedenle, yeni bir platforma geçme fırsatı doğduğunda zorluk yaşayabilirsiniz.

Bulut tarafında ise tek ihtiyacınız olan internettir.

Bu, çok önemli bir gelişme.

Birden fazla platformda yayın yapmanıza olanak tanır.

Şimdi de karma yaklaşımdan bahsedelim.

Bu nedenle, bazı işlemleri bulutta, bazılarını ise yerel olarak çalıştıralım.

Biraz. Bu işe yarar mı?

Aslında bu, düşündüğünüz kadar büyük bir kazanç değil.

Çoğu yerel platformda çalıştırılabilecek kadar küçük bir model elde ederseniz bu modeli bulutta çalıştırmanın maliyeti muhtemelen çok düşük olacaktır.

Bu nedenle, genellikle tüm yığını çözene kadar en büyük kazançlarınızı elde edemezsiniz.

Sonra, akla gelen bir diğer soru da şu: Mümkünse bunu yerel olarak çalıştırmak nasıl olur?

Sizde yoksa bulutta doğru donanım vardır, değil mi?

Bulutta daha güçlü bir şey çalıştırabilirsiniz.

Bu da yeni zorluklar getiriyor, değil mi?

Farklı bir model kullanırsanız bu durum geliştirme sürecini önemli ölçüde etkileyebilir.

Zaten minimum spesifikasyon üzerinde çalışmak için çok zaman harcamanız gerekir.

Farklı davranışlar sergileyen modelleriniz olabilir.

Dolayısıyla, tamamen aynı modelleri kullanmıyorsanız geliştirme süresini ve maliyetini artırabilirsiniz.

Bu nedenle, neyi başarmaya çalıştığınızı düşünmek önemlidir. Çünkü diyelim ki bunu çözdünüz ve iyi bir yerel model elde ettiniz. Gerekirse yerel, gerekmezse bulut modelini kullanırsınız. Ancak bulut modelinin ekonomik açıdan uygun olması gerekir.

Çünkü birdenbire tüm kullanıcılarınız bulut tarafına geçerse ve siz bunu düşünmediyseniz ekonomik açıdan kaybedersiniz.

Yerel modeller, ekonomik açıdan kesinlikle büyük bir kazanç sağlıyor ancak henüz yolun başındayız.

Oyunlar gibi fiyata duyarlı uygulamalar için bu yöntemin eninde sonunda kazanacağına inanıyorum.

Şu anda, komut tabanlı işlemler gibi daha spesifik kullanım alanları dışında bu biraz zor.

Bu nedenle, bugün mümkün olan en iyi deneyimi sunmak istiyoruz.

Bu nedenle bulutu kullanıyoruz.

Ancak bu çok hızlı gelişen bir alan ve her şey çok hızlı değişiyor.

Bir sonraki aşamada, kullandığımız modelleri düşünelim.

Sıradaki soru, açık ağırlıklar ile kapalı ağırlıklar arasındaki farkla ilgili.

Burada ne yapmalıyız?

Bu konuyu ele alırken LLM'lere odaklanmak istiyorum çünkü açık ve kapalı kaynak sorusundan en çok etkilenen alanın bu olduğunu gördük.

Yani bu yöntemin kesinlikle bazı avantajları ve dezavantajları var.

Kapalı, ağırlık modelleri söz konusu olduğunda bunlar genellikle öncü zekanızdır, değil mi?

Bu nedenle, en fazla istihbarata ihtiyacınız varsa genellikle buraya gitmeniz gerekir.

Açık kaynak tarafında ise genellikle bir nesil gerideler.

Bu nedenle, bu gerçek bir ödün verme olabilir.

Hız konusunda, ilk cümleye kadar geçen süreye çok önem verdiğimden bahsetmiştim.

Kapalı modellerin kullanım ömrü boyunca hızın genellikle düştüğünü fark ettik.

Bunun birçok nedeni olabilir.

Belki modeli daha fazla kişi kullanıyordur, belki de donanım daha yeni bir modele geçmiştir.

Ancak bu, fark ettiğimiz bir şey.

Bu nedenle dikkatli olmanız gerekir. Çünkü gönderdiğiniz harika bir ürün zamanla kullanılamaz hale gelebilir.

Sırada ani artışlar var.

Bu tür bir tutarlılığa çok önem veriyorsunuz. Bu nedenle, kapalı modeller genellikle P99 gecikmeleri yerine eşzamansız görevlerde toplu işleme etrafında oluşturulur. Açık tarafta ise önem verdiğiniz belirli bir konuya önem veren bir sağlayıcı seçerek ihtiyacınız olan güveni, hızı ve gecikmeyi elde edebilirsiniz.

Bir sonraki ise modelin kullanım ömrüdür.

Kapalı modeller genellikle yaklaşık bir yıl sonra kullanımdan kaldırılır.

Bu durum, bir yıl boyunca geliştirdiğiniz ve 3 yıl boyunca üretimde kalmasını beklediğiniz bir ürün için 3'ten fazla model değişikliği yapabileceğiniz anlamına gelir.

Bir modelin daha iyi olması, sizin için daha iyi çalışacağı anlamına gelmez.

Son 3 yılda birçok model değişikliği yaptık. Bunlar genellikle haftalar, bazen de aylarca süren çalışmalar gerektiriyor. Açık tarafta ise birileri barındırmak istediği sürece veya siz kendiniz barındırmak istediğiniz sürece o modeli çalıştırmaya devam edebilirsiniz.

Son olarak maliyetten bahsedelim.

Zaman içinde bu kapalı modellerin yeni sürümleri yayınlandıkça genellikle önceki sürümlerden daha pahalı olur.

Ekonomi konusunda dikkatli olunması gereken bir diğer nokta da, ekonominizin lansman sırasında işe yarayıp modelleri taşıdığınızda işe yaramayabileceğidir.

Açık tarafta, modeli hareket ettirme esnekliğine sahipsiniz ve aynı model olduğu için maliyetin önemli ölçüde artması pek olası değildir.

Gemma 4 31B'yi kullanıyoruz. Bu model bizim için hız, zeka ve maliyet açısından en iyi kombinasyonu sunduğu için büyük bir avantaj sağladı.

Ayrıca çok hızlı hareket etmemizi sağladı.

Daha önce kullandığımız bazı araçlara kıyasla geliştirme yapmak çok daha kolay.

Bu, yalnızca bu yöntemi kullandığımız anlamına gelmez.

Farklı açık ve kapalı modellerin birçok kombinasyonunu kullanıyoruz.

Örneğin, bellek üretimi, güvenlik ve özelleştirme gibi konuları ele alacağız.

Bu görevde, özel ihtiyaçlarınız için en iyi modeli seçmek çok önemlidir.

Ancak sesli asistanlar söz konusu olduğunda Gemma 4 31B en çok tercih edilen modelimizdir.

İkisi arasındaki bu tür farklar söz konusu olduğunda, açık modeller kesinlikle size daha fazla kontrol sağlar ve modelleri daha öngörülebilir bir maliyetle barındırılabildikleri sürece saklamanıza olanak tanır.

Ayrıca, bir modelin kullanımdan kaldırılması programınızı etkilemez.

Devin Reimer

Özetlemek gerekirse bu üç unsur arasında denge kurmak gerekiyor, değil mi?

Gecikme süreniz, akış yönünü, paralel yönü, hızı ve bunun tutarlılığını dengelemeye çalışıyoruz.

Zeka açısından, kullanıcılar için yeterince akıllı ve geliştirme yapmaya uygun.

Maliyet konusunda, kullanıcı başına ne kadar maliyet olacağını ve kullanıcı başına ne kadar kazanabileceğimizi bilmemiz gerekiyor. Böylece ekonomik açıdan işe yarayacağından emin olabiliriz.

Önce ürünü oluşturup sonra ekonomik yönünü düşünmeyin.

Bunu en başından itibaren düşünün.

Henüz çok erken olsa da buradaki ekonomi işlemeye başladı.

Bu nedenle, daha ucuz modeller kesinlikle daha iyi olacak, daha akıllı modeller kesinlikle daha iyi olacak.

Ancak şu anda, bugün, sesli temsilcileri her yerde kullanılabilir hale getirmek için üzerinde çalışmamız gereken gerçekten zorlu sorunlar üzerinde çalışmaya başlayabiliriz.

Bu nedenle, sesli temsilcilerin gücünü herkesle buluşturmaktan büyük heyecan duyuyorum.

Teşekkür ederiz.