Menyeimbangkan latensi ultra-rendah dan ekonomi cloud di agen suara virtual

Devin Reimer

Selamat datang di Menyeimbangkan Latensi Ultra-Rendah dan Cloud Economics dalam agen suara virtual.

Saya Devin Reimer.

Saya adalah pendiri dan CEO AstroBeam.

Sebelumnya, saya adalah CEO dan salah satu pendiri Owlchemy Labs, yang mungkin paling dikenal karena Job Simulator.

Jadi, di AstroBeam, kami berfokus pada pembuatan AI real-time dalam game.

Secara khusus, kami sangat berfokus pada suara sebagai input.

Sejauh ini, kami telah merilis dua judul, Stellar Cafe, yang tersedia di VR dan PC.

Ini adalah game tempat Anda berbicara dengan robot di kafe stasiun luar angkasa dan membantu memecahkan masalah mereka.

Fitur ini 100% dikontrol dengan suara.

Anda dapat memutar seluruh konten, termasuk menu dan navigasi, hanya dengan suara Anda.

Game kami berikutnya, yang baru saja kami umumkan hari ini, Robo Detective, dibuat untuk Android XR dan khususnya Project Aura XREAL.

Dalam game ini, Anda berperan sebagai detektif yang bekerja sama dengan partner robot untuk membantu mewawancarai robot guna memecahkan kejahatan robot, dan sekali lagi, 100% berbasis suara.

Jadi, agen suara sangat sulit, dan dalam game, sebenarnya lebih sulit lagi.

Alasannya adalah game merupakan hal yang sangat murah, dan agen suara kini menjadi biaya baru yang harus ditambahkan ke pipeline tersebut.

Selain itu, kita tidak bersaing dengan pengisi suara lain, kita bersaing dengan kualitas setiap game yang pernah dibuat, bukan?

Jadi, kita harus memberikan kualitas yang sangat tinggi.

Bukan berarti tidak ada kasus penggunaan agen suara tertentu yang memiliki tantangan unik, atau yang memiliki risiko jauh lebih tinggi, tetapi game jelas sangat menantang secara teknis dalam hal ini.

Namun, karena ini adalah game, ada banyak ruang untuk bereksperimen tentang cara menyelesaikan beberapa masalah sulit ini.

Jadi, saya yakin jika agen suara dapat berfungsi dalam game, agen tersebut dapat berfungsi hampir di mana saja.

Jadi, hal-hal yang saya bicarakan dalam presentasi ini tidak hanya berlaku untuk game, tetapi juga untuk aplikasi voice-first apa pun yang ingin Anda buat.

Jadi, saat Anda memikirkan agen suara, menurut saya ada tiga tantangan utama.

Jadi, kita memiliki latensi, kecerdasan, dan biaya.

Namun, satu hal yang ingin saya perjelas adalah bahwa saat saya berbicara tentang agen suara, saya berbicara tentang agen suara sebagai percakapan, bukan sebagai perintah.

Saya tidak berbicara tentang wrapper mikrofon yang mengirimkan sesuatu ke LLM, lalu menunggu respons.

Maksud saya adalah percakapan dua arah real-time di dunia nyata, dan itulah yang sebenarnya cukup sulit untuk dibuat.

Jadi, mari kita mulai dengan latensi.

Seberapa cepat prosesnya?

Ternyata, kecepatan yang dibutuhkan sangat tinggi, tetapi bergantung pada apa yang Anda baca, kecepatan tersebut mungkin tidak secepat yang Anda kira, atau mungkin jauh lebih cepat daripada yang Anda kira.

Jadi, mari kita bahas beberapa angka yang kami temukan dalam banyak pengujian kami.

Jadi, saat saya berbicara tentang latensi menyeluruh, yang saya maksud adalah waktu dari ucapan terakhir pengguna, suara terakhir yang dibuat pengguna, hingga saat mereka mendengar audio kembali kepada mereka.

Dari pengujian, kami menemukan bahwa 1,5 detik adalah titik saat kami mendapatkan masukan uji coba dari pengguna, mereka mulai tidak menyebutkan kecepatan atau kelambatan atau hal semacam itu.

Tampaknya itulah titik saat orang-orang mulai merasa sangat nyaman menggunakannya.

Jika responsnya jauh lebih lambat dari itu, orang sering kali akan berkomentar, "Ini bagus, tapi", jadi kecepatan tersebut tampaknya merupakan titik optimal.

Kemudian, saat Anda menjadi lebih cepat, kami menemukan bahwa pada sekitar 1,2 detik, beberapa hal yang lebih alami seperti percakapan bolak-balik mulai terjadi.

Jadi, seperti saya mengatakan sesuatu, dalam hal ini robot, akan mengatakan sesuatu dengan sangat cepat dan Anda akan saling berbalas.

Sepertinya ada titik optimal yang terbuka di sana.

Namun, 1,2 detik cukup sulit untuk dilakukan dalam stack.

Lalu, temuan menarik lainnya adalah kami melakukan banyak pengujian, dan akhirnya mendapatkan beberapa skenario untuk mendapatkan waktu kurang dari satu detik.

Jadi, Anda mungkin berpikir, "Oh, itu akan luar biasa!"

Terkadang memang demikian, dan terkadang terasa mengerikan, sangat aneh.

Jadi, Anda mungkin akan mendengar orang-orang berbicara tentang waktu respons 800 milidetik sebagai angka yang tepat, atau 500.

Saya bahkan membaca banyak artikel tentang 300 karena di situlah persepsi manusia benar-benar mendarat.

Kenyataannya, hal ini sangat bergantung pada konteks.

Jadi, misalnya, jika saya menanyakan nama Anda, saya memiliki ekspektasi tentang berapa lama waktu yang Anda perlukan untuk merespons.

Jika saya bertanya kepada Anda apa arti kehidupan, saya mengharapkan waktu penyelesaian yang sangat berbeda.

Saat kami melakukan pengujian dan meminta orang menilai apakah respons ini terasa cepat atau lambat, saat Anda melihat angkanya, ternyata hasilnya sangat bervariasi.

Respons yang membutuhkan waktu lama, menurut orang-orang, terasa cepat dan sebaliknya karena ternyata hal ini sangat bergantung pada konteks.

Selain itu, di mana posisi mereka dalam percakapan.

Umumnya, orang mengharapkan respons pertama lebih cepat daripada respons berikutnya karena ada waktu berpikir.

Namun, terkadang Anda akan mendapatkan percakapan yang sangat singkat, sehingga ekspektasi Anda meningkat.

Jadi, ini bukan ilmu pasti yang memiliki angka sempurna, tetapi kami menemukan bahwa sekitar 1,5, jika Anda berada di posisi itu, Anda sudah cukup baik.

Jadi, setelah Anda mencapai 1,5 detik, sekarang Anda benar-benar mulai peduli dengan konsistensi, bukan?

Karena jika Anda akhirnya mengalami hal ini 90% dari waktu, tetapi 10% dari waktu memerlukan waktu 3 detik, pengalaman Anda akan terasa rusak, bukan buruk, tetapi rusak.

Jadi, pada akhirnya, setelah Anda mendapatkan kecepatan yang cukup, Anda hanya akan peduli dengan konsistensi, yaitu kecepatan yang selalu stabil, bukan hanya sesekali.

Devin Reimer

Jadi, berikut adalah arsitektur pipeline suara standar.

Jadi, kita mengambil Speech-to-Text, mengirimkannya ke LLM, lalu mengirimkan hasil dari LLM kembali ke Text-to-Speech.

Jadi, maksudnya adalah, Speech-to-text, kita mengirim audio ke server, lalu mengonversinya menjadi teks.

Di sisi LLM, kami mengambil teks tersebut, dialog respons tersebut, atau mengonversinya menjadi dialog respons, lalu tindakan apa yang akan dilakukan oleh karakter tersebut.

Kami menggabungkannya dengan erat karena kami menganggap hal itu sangat penting.

Kemudian, di sisi Text-to-Speech, kami mengambil teks tersebut, mengirimkannya ke Text-to-Speech, dan melakukan streaming ke pengguna, yang juga diatur waktunya dengan tindakan yang ingin dilakukan agen.

Salah satu masalahnya adalah menjalankan ini secara berurutan bisa sangat lambat karena Anda harus melalui setiap hal ini.

Jadi, pertanyaan umum yang sering saya dapatkan adalah, jika prosesnya lambat dan Anda harus melakukan tiga langkah, mengapa tidak menggunakan model speech-to-speech saja?

Karena itu akan lebih cepat, bukan?

Dan, ya, biasanya hal itu akan lebih cepat karena Anda menjalankan satu hal.

Namun, ada beberapa konsekuensi besar.

Jadi, meskipun cepat, ada beberapa faktor penentu yang besar bagi kami, dan yang terbesar adalah biaya.

Jadi, umumnya kami menemukan bahwa menjalankan model Speech-to-Speech sekitar 3 hingga 5 kali lebih mahal daripada pendekatan paralel ini.

Jadi, bagi kami, aspek ekonominya tidak berjalan.

Dari segi keamanan, sebenarnya hal ini jauh lebih rumit karena lebih sulit untuk memvalidasi respons yang akan diberikan agen sebelum agen mengatakannya.

Namun, jika Anda memiliki pendekatan pipeline, Anda dapat mengambil respons yang diberikan LLM, lalu memvalidasi dan memeriksa keamanannya saat itu juga sebelum Anda mengirimkannya kepada pengguna.

Untuk gaya suara, Anda hanya dapat menggunakan preset yang ada dalam model Speech-to-Speech tersebut.

Anda tidak bisa berkata, "Oh, tahukah Anda?

Untuk kasus ini, saya sangat ingin menggunakan jenis suara ini."

Anda hanya bisa menggunakan satu akun tersebut.

Dengan pendekatan pipeline, Anda bisa seperti, "Oh, saya akan mengubahnya.

Saya akan memilih model ini karena model ini berfungsi dengan sangat baik untuk kasus penggunaan khusus ini."

Hal yang sama juga berlaku untuk kecerdasan, bukan?

Jika Anda memiliki model Speech-to-Speech yang sangat bagus dan menghasilkan suara yang bagus, tetapi kecerdasannya tidak sesuai dengan keinginan Anda, Anda tidak bisa begitu saja menggantinya, bukan?

Anda seperti terkunci.

Dalam pendekatan pipeline, Anda akan berpikir, "Oh, untuk kasus penggunaan ini, saya ingin menggunakan model tertentu."

Satu hal yang pasti menjadi keunggulan Speech-to-Speech adalah memahami nada bicara pengguna.

Jadi, hal-hal seperti sarkasme dan hal-hal semacam itu.

Saat ini, transkripsi speech-to-text umumnya tidak memiliki banyak informasi tersebut, tetapi saya rasa hal itu akan berubah seiring waktu.

Hal itu jelas merupakan salah satu keunggulan Speech-to-Speech.

Jadi, Speech-to-Speech jelas memiliki keunggulan dalam hal kecepatan, tetapi juga memiliki beberapa tantangan dalam hal konfigurabilitas dan biaya tinggi, terutama bagi kami, yang merupakan faktor penentu.

Jadi, apakah ada cara lain?

Ya.

Yang harus kita lakukan adalah melakukan yang terbaik untuk memparalelkan pipeline.

Jadi, beberapa hal yang kami lakukan adalah menjalankan LLM sebelum speech-to-text memiliki keyakinan penuh.

Tingkat keyakinan yang dimaksud adalah keyakinan pada kata-kata yang dihasilkan dalam transkrip, lalu keyakinan pada akhir giliran.

Jadi, begitu kami merasa ada kemungkinan bahwa ini adalah momen saat pengguna berhenti berbicara dan inilah yang mereka katakan, kami akan melanjutkan.

Jadi, skenario terburuknya adalah kita salah, bukan?

Pengguna terus berbicara.

Namun, bahkan dalam skenario tersebut, yang kami lakukan hanyalah membatalkan LLM, lalu menjalankannya lagi.

Dan karena konteksnya mungkin akan di-cache dan kita belum menghasilkan banyak token, sebenarnya tidak ada biaya besar untuk melakukannya, dan manfaatnya adalah pengguna akhirnya mendengar hal-hal lebih cepat daripada jika Anda menunggu keyakinan penuh.

Kami juga tidak menunggu LLM selesai menghasilkan seluruh responsnya sebelum mulai mengirimkannya ke Text-to-Speech.

Yang kami tunggu adalah semacam bagian pertama yang dapat diucapkan.

Untuk sebagian besar skenario, deskripsi ini berupa kalimat.

Terkadang, konfigurasinya bisa berbeda, tetapi begitu kita memiliki penggalan kalimat pertama, kita akan mengirimkannya ke Text-to-Speech.

Kemudian, jika kita memiliki Text-to-Speech yang bagus yang akan melakukan streaming, segera setelah siap untuk melakukan streaming, maka hal itu dapat disampaikan kepada pengguna.

Kami juga sangat berhati-hati dengan jumlah token yang perlu dibuat.

Jadi, kami tidak menggunakan hal-hal seperti wrapper JSON dan hal-hal semacam itu yang mungkin menambahkan token tambahan.

Kami mencoba mencari tahu struktur yang paling sederhana untuk mendapatkan respons secepat mungkin.

Kami juga menggunakan hal-hal seperti pengisian awal asisten jika kami mengetahui sebelumnya apa yang akan menjadi bagian pertama token dari agen.

Jadi, untuk text-to-speech, hasilnya adalah dua bagian ini, bukan?

Jadi, bagian pertama yang dapat diucapkan akan masuk, lalu kita akan menjalankan semua hal lainnya setelahnya.

Namun, karena pemutaran audio memerlukan waktu lebih lama daripada pembuatan, hampir secara universal, bagian pertama akan selesai diputar kepada pengguna saat bagian kedua selesai.

Jadi, hal itu sebenarnya tidak terlihat oleh pengguna.

Data tersebut akan muncul secepat mungkin.

Jadi, saat Anda mempertimbangkan untuk memilih berbagai layanan, berikut beberapa aturan praktis kami.

Saat memilih jenis audio dan framework agen yang baik, yang Anda perhatikan adalah latensi terendah dalam input dan output.

Jadi, seberapa cepat saya dapat mengirim dan menarik data?

Di sisi speech-to-text, kami mementingkan waktu untuk mencapai keyakinan.

Jadi, ini adalah keyakinan dalam transkrip dan keyakinan dalam akhir giliran.

Keduanya dipasangkan, bukan?

Jika Anda tidak memiliki keyakinan yang cepat pada salah satunya, prosesnya akan berjalan lambat, bukan?

Jadi, kecepatannya hanya secepat yang paling lambat di dalamnya.

Di sisi LLM, kami mementingkan waktu hingga kalimat pertama, yaitu bagian pertama yang dapat diucapkan.

Jadi, ada dua bagian, bukan?

Waktu hingga token pertama yang digabungkan dengan token per detik.

Jadi, jika tiba-tiba Anda menemukan model yang sangat bagus yang memberikan waktu yang sangat baik untuk token pertama, tetapi lambat dalam token per detik, hal itu bisa lebih buruk daripada alternatifnya.

Jadi, cari tahu kombinasi yang tepat untuk itu.

Lalu, di sisi text-to-speech, Anda perlu memperhatikan waktu hingga audio pertama.

Jadi, sangat penting untuk mengukur apa itu, karena terkadang audio dapat kembali dengan keheningan di awal dan pengguna tidak akan mendengarnya.

Jadi, Anda harus mengukur hingga titik saat pengguna mendengar sesuatu.

Lalu, seperti yang saya sebutkan sebelumnya, yang terpenting adalah stabilitas, bukan kecepatan puncak, bukan skenario terbaik.

Berapa latensi yang konsisten dari seluruh stack ini?

Devin Reimer

Jadi, saat ini untuk framework agen audio, kami menggunakan LiveKit.

Untuk speech-to-text, kita menggunakan Deepgram.

Untuk LLM, kami menggunakan Gemma 4 31B, dan kami menghostingnya di LiveKit.

Untuk text-to-speech, kami menggunakan text-to-speech 2 Inworld AI.

Selain itu, kami telah membangun seluruh infrastruktur pengelola agen AI AstroBeam yang tidak hanya menyatukan semua ini, tetapi juga menambahkan semua elemen yang Anda perlukan untuk memiliki agen suara yang sangat baik, terutama yang sangat interaktif seperti milik kami untuk game.

Jadi, satu hal yang belum saya bahas adalah bagaimana dengan model keamanan?

Jadi, secara tradisional, model keamanan adalah bagian dari penerusan LLM, tetapi hal ini menambah latensi dan menambahkan langkah tambahan di dalamnya.

Jadi, bagaimana jika Anda menjalankan model Anda sendiri?

Jadi, inilah tampilan stack kami yang sebenarnya.

Jadi, yang kami lakukan di sini adalah saat kami mendapatkan kembali bagian teks pertama, bagian pertama yang dapat diucapkan yang akan kami kirim ke text-to-speech, pada saat yang sama kami mengirimkannya ke model keamanan kami.

Karena model keamanan lebih kecil dan akan berjalan lebih cepat daripada speech-to-text, model ini hampir selalu dilakukan terlebih dahulu.

Jadi, artinya, menambahkan model keamanan tidak akan menambah latensi ke stack kami, dan bahkan lebih baik lagi, itu adalah bagian yang cukup besar sehingga kami dapat menjalankan model keamanan yang jauh lebih besar daripada yang dipikirkan kebanyakan orang.

Hal ini sangat penting bagi kami, terutama karena kami sedang membangun game.

Ada banyak konteks dunia yang sangat penting.

Jadi, misalnya, Anda sedang membuat game abad pertengahan, dan Anda memiliki NPC dalam game abad pertengahan ini yang berteriak seperti, "Serang!

Penggal kepalanya!", bukan?

Model keamanan tradisional mungkin akan merespons, "Wah, itu tidak baik.

Kamu tidak boleh mengatakan itu."

Namun, dalam konteks game ini, hal itu sangat masuk akal.

Cara yang dapat kami lakukan adalah menggunakan model keamanan yang sedikit lebih kuat dengan lebih banyak konteks tentang apa yang terjadi di dunia agar dapat mewujudkannya.

Anda mungkin melihat di sini bahwa kami benar-benar menjalankan model keamanan dua kali, sehingga kami akhirnya menjalankannya pada potongan pertama, lalu menjalankannya lagi pada keseluruhan teks saat kami memiliki potongan akhir secara keseluruhan.

Sekali lagi, kita harus menjalankannya dua kali, tetapi tidak menambah latensi ke stack.

Jadi, sekarang kita sudah cukup cepat, tetapi sayangnya hal ini tidak akan berarti jika kita tidak cukup cerdas.

Devin Reimer

Jadi, seberapa cerdas model yang diperlukan?

Platform ini harus cukup cerdas bagi pengguna Anda, tetapi yang lebih penting, harus cukup cerdas untuk Anda kembangkan.

Hal ini sering kali tidak terpikirkan oleh orang-orang saat mereka memilih apa yang mereka butuhkan untuk kecerdasan di sini.

Kami telah mengembangkan agen suara selama sekitar tiga tahun, dan misalnya, pada masa-masa awal kami menggunakan beberapa model LLaMA awal, dan meskipun kami dapat membuatnya berfungsi untuk pengguna, sisi pengembangannya sangat mahal karena semuanya sangat rapuh.

Tidak perlu banyak hal bagi model untuk menghasilkan respons yang tidak diinginkan atau hal-hal yang tidak masuk akal, sehingga kami menghabiskan begitu banyak upaya engineering untuk membuatnya berfungsi.

Jadi, itulah yang kami prioritaskan, karena jika kami tidak dapat bergerak cepat dalam membangun hal-hal ini, kami tidak dapat memberikan hal-hal tersebut kepada pengguna.

Jadi, sangat penting untuk memikirkan keduanya.

Jadi, sering kali saat orang berpikir tentang kecerdasan, mereka berpikir tentang LLM, bukan?

Namun, itu hanyalah salah satu bagiannya.

Kita harus memikirkan setiap bagian dalam hal kecerdasan.

Jadi, mari kita bahas kecerdasan speech-to-text.

Jadi, yang penting di sini adalah tingkat kesalahan kata yang rendah.

Selain itu, bukan hanya tingkat errornya yang rendah, tetapi saat error terjadi, kami menghasilkan sesuatu yang sangat mirip dengan yang sebenarnya, karena jika sangat mirip, LLM sering kali dapat, dengan konteks, memahami dengan sangat baik apa itu.

Jika tingkat error Anda rendah, tetapi kesalahan langkahnya sangat tinggi, LLM akan jauh lebih kesulitan dalam mencoba mencari tahu apa maksud sebenarnya.

Hal lain yang perlu dipikirkan adalah platform target Anda.

Jadi, misalnya, jika saya membuat aplikasi untuk XR, dan saya memiliki mikrofon yang sangat dekat dengan mulut pengguna, saya akan memiliki data audio mikrofon yang sangat bagus dan berkualitas tinggi, dan itu mungkin berfungsi dengan sangat baik untuk model tertentu.

Namun, jika tiba-tiba saya membuat aplikasi untuk ponsel yang akan digunakan orang di jalanan yang ramai, hal itu akan memberikan dampak yang sangat berbeda, dan model yang berbeda akan berperilaku berbeda serta dapat memahami apa yang dikatakan dengan cara yang berbeda.

Jadi, Anda harus memikirkannya, pastikan Anda memilih platform yang tepat untuk aplikasi yang Anda buat.

Jadi, mari kita beralih ke sisi text-to-speech dari persamaan kecerdasan.

Terdengar alami, bukan?

Tujuan kami adalah menyampaikan kepada pengguna apa yang dapat dipahami pengguna.

Namun, itu hanya sebagian, bukan?

Ekspresivitas agen tersebut juga sangat, sangat penting karena ada informasi dalam ekspresi, dan juga dalam uji coba, kami menemukan bahwa semakin ekspresif agen kami, semakin cerdas pengguna merasakannya, yang sangat masuk akal.

Lalu, apakah cukup cepat?

Dan saya tahu di bagian sebelumnya, saya membahas latensi, tetapi sebenarnya hal ini juga penting di sini untuk kecerdasan yang dirasakan.

Pengguna menganggap kecepatan respons berkorelasi langsung dengan kecerdasan yang sebenarnya.

Jika saya memiliki respons cepat, respons tersebut mungkin terdengar lebih cerdas.

Jadi, hal-hal ini bisa sangat penting dalam hal bagaimana pengguna memandang pengalaman, dan juga seberapa dalam mereka dapat terlibat dalam pengalaman tersebut.

Jadi, mari kita beralih ke sisi kecerdasan LLM.

Sejauh ini, ini adalah yang paling sulit diseimbangkan karena ada banyak persyaratan yang berbeda di sini, bukan?

Jadi, kami memiliki pemahaman ucapan, konteks, dan grounding.

Dalam game, hal ini sangat sulit, karena Anda harus mendasarkan pada seluruh dunia dan alam semesta, bukan?

Ini bukan kotak teks yang dapat mengarang hal-hal yang terjadi.

Jika agen Anda dalam game mengatakan, "Ada apel di atas meja", dan tidak ada apel di atas meja, hal itu akan merusak pengalaman pengguna.

Kita juga memerlukan hal-hal seperti kepatuhan yang kuat terhadap aturan.

Game sangat berbasis aturan.

Bisakah LLM menangani hal itu?

Dapatkah kita memiliki tingkat halusinasi yang rendah?

Dapatkah kita memiliki karakter yang konsisten saat berinteraksi dengan agen yang sama berulang kali?

Apakah terasa seperti agen yang sama?

Lalu, satu hal yang mungkin membuat Anda bingung, karena ini bukan masalah di awal pengembangan, adalah, apakah model Anda dapat menangani ukuran perintah yang terus bertambah?

Karena seiring Anda terus mengembangkan, Anda pasti akan memasukkan lebih banyak hal ke dalam perintah.

Namun, seiring pengguna terus bermain, histori percakapan dalam perintah tersebut akan bertambah.

Jadi, apakah perintah tersebut akan menangani pertumbuhan itu?

Karena terkadang, untuk model tertentu, seiring bertambahnya perintah, kualitas responsnya menurun, sehingga Anda harus mencari tahu kebutuhan sebenarnya untuk jumlah yang harus dimasukkan ke dalam perintah tersebut setiap saat.

Namun, ini hanyalah sebagian kecilnya saja, dan juga sangat bergantung pada apa yang Anda bangun.

Jadi, Anda harus benar-benar memikirkan apa yang Anda bangun, dan apa yang ingin Anda capai.

Jadi, sekarang kita sudah cukup cepat dan cukup cerdas, tetapi semua ini tidak akan berarti jika biayanya terlalu mahal.

Devin Reimer

Jadi, seberapa murah harganya?

Sayangnya, prosesnya sedikit lebih rumit dari itu.

Jadi, kita harus memikirkan ekonomi aplikasi atau game yang kita buat, bukan?

Jadi, ada beberapa pertanyaan yang perlu Anda ajukan.

Berapa lama pengguna akan berinteraksi dengan agen suara Anda?

Berapa banyak penghasilan yang Anda peroleh per pengguna?

Dan berapa biaya yang diperlukan untuk menjalankan stack suara tersebut per jam?

Kami menyatukannya untuk mencoba mencari tahu, melihat apakah semuanya masuk akal.

Jadi, inilah ekonomi game pertama kami, Stellar Cafe.

Jadi, waktu bermain di Stellar Cafe berkisar antara 1,5 hingga 3,5 jam, jadi mari kita ambil rata-ratanya sekitar 2 jam.

Biaya kami untuk menjalankan agen suara adalah sekitar $1,20 per jam per pengguna, dan pengguna berinteraksi dengannya 100% dari waktu.

Game ini 100% dikontrol dengan suara.

Kami mengenakan biaya tetap sebesar $10 untuk game ini, yang merupakan hal biasa.

Kami tidak menggunakan langganan karena sangat sulit dalam game, dan saya sangat yakin bahwa kami harus membuatnya berfungsi dengan biaya tetap, jika tidak, hal ini tidak akan berhasil dan tidak akan berkembang.

Sebelumnya, kami mengenakan biaya $15, tetapi kami telah berupaya menurunkan biaya server ini, jadi sekarang kami telah menurunkannya menjadi $10.

Dan $1, 20 ini adalah posisi kita saat ini.

Biaya ini tidak berlaku secara universal.

Saya telah melihat hal-hal ini dikenai biaya untuk berbagai hal, dan terkadang jauh lebih mahal.

Jadi, Anda juga harus mencari tahu posisi Anda dalam hal biaya.

Kami bisa saja membuat produk yang lebih murah, tetapi kami berusaha mempertahankan standar kualitas kami setinggi mungkin.

Jadi, jika dihitung, ini berarti pada waktu bermain 2 jam, biaya stack suara kami sekitar $2,40 per pengguna.

Jadi, karena kita mengenakan biaya $10, dan toko mengambil biaya, itu berarti kita menghasilkan sekitar $4,59 per pengguna, bukan?

Jadi, ekonomi dari hal itu berhasil, bukan?

Suara adalah daya tarik kita, itulah yang ingin kita belanjakan, ini berhasil.

Jadi, ini adalah game yang sangat kecil.

Mari kita bahas sesuatu yang sedikit lebih besar.

Jadi, mari kita bahas game hipotetis, game naratif, yang berdurasi antara 5 hingga 9 jam, jadi katakanlah rata-rata 7 jam.

Pada kenyataannya, kebanyakan orang-- banyak orang tidak menyelesaikan game, mereka memainkan sedikit game, dan meninggalkannya, tetapi saya ingin memilih sesuatu yang sedikit lebih tinggi untuk memastikan ekonominya masih berfungsi.

Jadi, kita akan mempertahankan $1,20 per jam, tetapi perubahan yang akan kita lakukan adalah komponen suaranya akan digunakan 60% dari waktu, karena game yang lebih besar akan memiliki lebih banyak mekanisme daripada sekadar suara.

Jadi, game ini akan tetap sangat mengandalkan suara, tetapi akan memiliki fitur lain di dalamnya.

Jadi, jika kita mengenakan biaya $20, dengan mempertimbangkan semua ini lagi, biayanya sekitar-- akan dikenakan biaya sekitar $5 per pengguna, yang berarti pada akhirnya, kita menghasilkan sekitar $9 per pengguna.

Jadi, sekali lagi, dengan ini, ekonomi akan berjalan.

Hal ini tidak berarti bahwa ekonomi akan berfungsi untuk semuanya.

Jadi, misalnya, hal yang tidak boleh dilakukan, jika Anda berpikir, "Oh, saya ingin membuat game gratis, dan mungkin pengguna game ini akan bermain antara 1 jam hingga 100+ jam."

Jadi, mari kita ambil rata-ratanya, yaitu 10 jam.

Game ini 100% berbasis suara, tetapi katakanlah game ini sukses, dan menghasilkan sekitar $3 per pengguna, yang akan sangat bagus sebagai game gratis.

Anda akan kehilangan $10 per pengguna.

Jadi, model ini belum berfungsi di semua hal tersebut, dan Anda harus memikirkan apa yang sedang Anda bangun, dan apakah hal itu masuk akal?

Jangan menunggu sampai akhir untuk mencoba mencari tahu aspek ekonominya.

Devin Reimer

Lalu, pertanyaan berikutnya yang muncul adalah, bagaimana dengan model lokal?

Karena jika Anda memiliki tantangan biaya yang besar ini, bukankah model lokal akan menghilangkannya?

Dan ya, memang demikian.

Namun, ada beberapa konsekuensi yang harus kita pertimbangkan.

Jadi, dari segi biaya, ya, kami akan menghilangkan tagihan server, yang akan menjadi manfaat besar, membuka lebih banyak peluang.

Namun, ada banyak hal yang saat ini dapat diselesaikan oleh cloud, tetapi sulit dilakukan secara lokal.

Misalnya, komputasi.

Sering kali orang berkata, "Lihat, saya menemukan model speech-to-text yang sangat bagus, dan model ini berjalan secara lokal di perangkat ini, bukan?"

Bagus, tetapi yang harus kita pikirkan adalah bahwa model ini tidak menjalankan satu model, melainkan beberapa model, bukan?

Dalam kasus kita, empat, yang berpotensi berjalan secara bersamaan, sehingga tidak cukup jika sesuatu berjalan sekali, melainkan harus berjalan beberapa kali secara bersamaan.

Lalu, jika Anda melakukannya, apakah Anda menyisakan sesuatu untuk menjalankan game atau aplikasi Anda?

Jika Anda memaksimalkan GPU, Anda tidak akan benar-benar merender banyak video game.

Jadi, katakanlah Anda telah mengatasi tantangan tersebut.

Jadi, yang berikutnya adalah kecepatan, bukan?

Sering kali Anda dapat menjalankannya, tetapi akan sangat lambat, dan akan terasa lebih seperti memberikan perintah daripada percakapan real-time yang sebenarnya.

Jadi, secara teori, mendapatkan data secara lokal memang memiliki keuntungan di masa mendatang, karena Anda tidak perlu melakukan perjalanan pulang pergi dari internet.

Saat ini, mendapatkan model yang akan berjalan dengan kecepatan yang tepat untuk membuat fitur ini berfungsi merupakan sebuah tantangan.

Jadi, selanjutnya, katakanlah Anda telah menguasai komputasi dan kecepatan, sekarang kita harus memikirkan kualitas, bukan?

Jadi, umumnya karena Anda menjalankannya di perangkat lokal, Anda menggunakan LLM yang lebih kecil, misalnya, text-to-speech yang lebih primitif, hal ini sebenarnya dapat menimbulkan beberapa tantangan terkait konten yang Anda buat.

Dan seperti yang saya sebutkan sebelumnya, saat Anda memikirkan LLM, pertanyaannya bukan hanya apakah LLM tersebut cukup baik untuk pengguna Anda, tetapi apakah LLM tersebut cukup baik untuk Anda kembangkan?

Jadi, jika model tersebut cukup sulit untuk digunakan dalam membangun sesuatu, hal itu pasti perlu dipertimbangkan.

Jadi, setelah Anda menguasai komputasi, kecepatan, dan kualitas, selanjutnya adalah portabilitas.

Jika Anda menang dan melalui seluruh proses ini, dan Anda berhasil menjalankan hal ini, misalnya, di RTX 5070, itu mungkin satu-satunya tempat yang dapat menjalankannya.

Jadi, jika ada peluang untuk membawanya ke platform baru, Anda mungkin akan kesulitan.

Di sisi cloud, Anda hanya memerlukan internet.

Jadi, hal itu merupakan semacam terobosan besar di sini.

Memungkinkan untuk beralih ke beberapa platform.

Selanjutnya, mari kita bahas pendekatan hybrid.

Jadi, mari kita jalankan beberapa hal di cloud, dan beberapa hal secara lokal.

Sepertinya begitu, apakah itu bisa berhasil?

Kemenangan ini tidak sebesar yang Anda kira.

Jadi, jika Anda akhirnya mendapatkan model yang cukup kecil untuk dijalankan di sebagian besar platform lokal, jika Anda menjalankan model yang sama di cloud, biayanya mungkin sangat murah.

Jadi, umumnya Anda baru akan mendapatkan kemenangan terbesar setelah menyelesaikan seluruh tumpukan.

Lalu, hal berikutnya yang mungkin muncul adalah, bagaimana jika Anda menjalankannya secara lokal jika memungkinkan?

Mereka memiliki hardware yang tepat, dan di cloud jika Anda tidak memilikinya, bukan?

Anda dapat menjalankan hal yang lebih canggih di cloud.

Hal ini memiliki tantangan baru, bukan?

Jika Anda akhirnya menjalankan model yang berbeda, hal ini dapat berdampak cukup besar pada pengembangan.

Dan pada akhirnya, Anda harus menghabiskan banyak waktu untuk mengerjakan spesifikasi minimum.

Dan Anda bisa memiliki model yang berperilaku sangat berbeda.

Jadi, kecuali jika Anda menggunakan model yang sama persis, Anda bisa saja menambah banyak waktu dan biaya pengembangan.

Jadi, penting untuk memikirkan apa yang ingin Anda capai, karena katakanlah Anda berhasil mengetahuinya dan mendapatkan model lokal yang bagus jika diperlukan, dan model cloud jika tidak, model cloud tetap harus menguntungkan secara ekonomi.

Karena jika, tiba-tiba, semua pengguna Anda berada di sisi cloud, Anda akan rugi jika tidak memikirkan hal itu, dari sudut pandang ekonomi.

Jadi, dalam hal model lokal, ini jelas merupakan kemenangan ekonomi yang besar, tetapi masih terlalu dini.

Untuk aplikasi yang sensitif terhadap harga seperti game, saya yakin pada akhirnya aplikasi ini akan menang.

Saat ini, hal tersebut agak rumit di luar kasus penggunaan yang lebih spesifik, terutama hal-hal yang berkaitan dengan perintah.

Jadi, saat ini, kami ingin memberikan pengalaman terbaik.

Itulah sebabnya kami menggunakan cloud.

Namun, ini adalah bidang yang berkembang sangat cepat, dan banyak hal berubah dengan cukup pesat.

Jadi, bagian berikutnya adalah mari kita pikirkan model yang kita gunakan, bukan?

Jadi, pertanyaan berikutnya adalah bobot terbuka versus bobot tertutup.

Apa yang harus kita lakukan di sini?

Kami ingin berfokus pada LLM saat membahas hal ini karena kami mendapati bahwa ini adalah area yang paling terpengaruh oleh pertanyaan tentang open source versus closed source.

Jadi, pasti ada beberapa kelebihan dan kekurangan di sini.

Jadi, terkait model tertutup dan berbobot, model ini umumnya adalah kecerdasan frontier Anda, bukan?

Jadi, jika Anda memerlukan kecerdasan paling tinggi, di sinilah tempatnya.

Sementara itu, di sisi open source, modelnya sering kali tertinggal satu generasi.

Jadi, ini bisa menjadi kompromi yang nyata.

Dari segi kecepatan, saya menyebutkan bahwa saya sangat peduli dengan waktu hingga kalimat pertama.

Yang kami temukan adalah selama masa pakai model tertutup, kecepatannya sering kali menurun.

Ada banyak alasan yang dapat menyebabkan hal ini.

Mungkin lebih banyak orang yang menggunakan model, mungkin hardware telah beralih ke model yang lebih baru.

Namun, ini adalah salah satu hal yang kami perhatikan.

Jadi, Anda harus berhati-hati karena hal ini dapat menyebabkan masalah. Jika Anda mengirimkan sesuatu dan hasilnya bagus, seiring waktu, hal itu bisa menjadi tidak dapat digunakan.

Berikutnya adalah lonjakan.

Anda sangat peduli dengan konsistensi semacam itu, sehingga sering kali, model tertutup dibangun di sekitar pengelompokan dalam tugas asinkron, bukan latensi P99, sedangkan di sisi terbuka, Anda dapat memilih penyedia yang peduli dengan hal yang sangat spesifik yang Anda pedulikan, untuk memberi Anda keyakinan, kecepatan, dan latensi yang pada akhirnya Anda butuhkan.

Berikutnya adalah masa aktif model itu sendiri.

Jadi, model tertutup sering kali dihentikan setelah sekitar satu tahun.

Jadi, jika Anda mengembangkan sesuatu selama setahun, dan Anda memperkirakan sesuatu tersebut akan berada dalam tahap produksi selama 3 tahun, Anda dapat mengalami lebih dari 3 perubahan model.

Dan hanya karena modelnya lebih baik, bukan berarti model tersebut akan berfungsi lebih baik untuk Anda.

Kami telah mengalami banyak perubahan model dalam 3 tahun terakhir, dan sering kali memerlukan waktu berminggu-minggu, terkadang berbulan-bulan untuk melengkapi kembali semuanya, yang, di sisi terbuka, Anda dapat terus menjalankan model tersebut selama seseorang bersedia menghostingnya, atau Anda bersedia menghostingnya sendiri.

Terakhir, biaya.

Seiring waktu, model tertutup ini, saat merilis versi baru, sering kali lebih mahal daripada versi sebelumnya.

Jadi, ini adalah hal lain yang perlu diperhatikan terkait aspek ekonomi, yaitu, sekali lagi, aspek ekonomi Anda mungkin berhasil saat peluncuran, tetapi kemudian tidak berhasil saat Anda akhirnya memigrasikan model.

Di sisi terbuka, Anda memiliki fleksibilitas untuk dapat memindahkannya, dan kemungkinan besar harganya tidak akan meningkat secara drastis karena modelnya sama persis.

Jadi, kami menggunakan Gemma 4 31B dan ini merupakan terobosan besar bagi kami karena, bagi kami, ini adalah kombinasi terbaik antara kecepatan, kecerdasan, dan biaya.

Hal ini juga memungkinkan kami bergerak sangat cepat.

Pengembangannya jauh lebih mudah dibandingkan dengan beberapa hal yang pernah kami gunakan sebelumnya.

Namun, bukan berarti kita hanya menggunakan ini.

Kami menggunakan banyak kombinasi model terbuka dan tertutup yang berbeda.

Jadi, misalnya, hal-hal seperti pembuatan memori, keamanan, dan penyesuaian.

Sangat penting untuk memilih model terbaik untuk kebutuhan spesifik Anda dalam tugas tersebut.

Namun, Gemma 4 31B adalah andalan kami dalam hal agen suara.

Jadi, terkait perbedaan semacam ini di antara keduanya, model terbuka jelas memberi Anda kontrol yang lebih besar dan memungkinkan Anda menyimpan model selama model tersebut dapat dihosting dengan biaya yang lebih dapat diprediksi.

Dan jadwal Anda tidak akan terpengaruh oleh penghentian model.

Devin Reimer

Jadi, sebagai kesimpulan, ini adalah tentang menyeimbangkan ketiga hal ini, bukan?

Latensi Anda, kami mencoba menyeimbangkan aspek streaming, aspek paralel, kecepatan, dan konsistensinya.

Dari segi kecerdasan, model ini cukup cerdas bagi pengguna, dan cukup cerdas untuk digunakan dalam membangun aplikasi.

Terkait biaya, kita perlu mengetahui berapa biaya per pengguna dan berapa banyak yang dapat kita hasilkan per pengguna sehingga kita dapat memastikan aspek ekonominya berjalan.

Jangan membangun terlebih dahulu, lalu memikirkan aspek ekonominya belakangan.

Pikirkan hal itu sejak awal.

Jadi, meskipun masih sangat awal, aspek ekonomi di sini mulai berjalan.

Jadi, model yang lebih murah dan lebih cerdas pasti akan lebih baik.

Namun, saat ini, kita dapat mulai mengatasi tantangan yang sangat sulit yang perlu kita selesaikan untuk membuat agen suara tersedia di mana saja.

Jadi, saya sangat bersemangat untuk menghadirkan kecanggihan agen suara ini kepada semua orang.

Terima kasih.