Balancing ultra-low latency and cloud economics in virtual voice agents

Devin Reimer

Witamy w module „Balancing Ultra-Low Latency and Cloud Economics in virtual voice agents”.

Nazywam się Devin Reimer.

Jestem założycielem i prezesem AstroBeam.

Wcześniej byłem dyrektorem generalnym i współzałożycielem Owlchemy Labs, firmy znanej głównie z gry Job Simulator.

Dlatego w AstroBeam skupiamy się na tworzeniu AI działającej w czasie rzeczywistym w grach.

Skupiamy się na głosie jako metodzie wprowadzania danych.

Do tej pory wydaliśmy 2 tytuły: Stellar Cafe, który jest dostępny na VR i PC,

To gra, w której rozmawiasz z robotami w kawiarni na stacji kosmicznej i pomagasz im rozwiązywać problemy.

Jest w 100% sterowany głosem.

Możesz odtworzyć całą treść, w tym menu i nawigację, za pomocą głosu.

Nasza kolejna gra, którą właśnie ogłosiliśmy, Robo Detective, została stworzona na Androida XR, a konkretnie na Project Aura firmy XREAL.

W tej grze wcielasz się w detektywa, który współpracuje z robotem, aby przesłuchiwać inne roboty i rozwiązywać robotyczne przestępstwa. Gra jest w 100% sterowana głosem.

Agenty głosowe są bardzo trudne do stworzenia, a w grach jest to jeszcze trudniejsze.

Gry są bardzo tanie, a agent głosowy to nowy koszt, który trzeba doliczyć do procesu.

Poza tym nie konkurujemy z innymi agentami głosowymi, ale z jakością wszystkich gier, które kiedykolwiek powstały, prawda?

Dlatego musimy zapewnić bardzo wysoką jakość.

Nie oznacza to, że nie ma konkretnych przypadków użycia agentów głosowych, które wiążą się z unikalnymi wyzwaniami lub w których stawka jest znacznie wyższa, ale gry są zdecydowanie bardzo wymagające pod względem technicznym w tym obszarze.

Jednak ponieważ są to gry, dają duże możliwości eksperymentowania z rozwiązaniami tych trudnych problemów.

Dlatego uważam, że jeśli agenty głosowe mogą działać w grach, mogą działać niemal wszędzie.

Dlatego to, o czym mówię, dotyczy nie tylko gier, ale każdej aplikacji głosowej, którą chcesz stworzyć.

Jeśli chodzi o agentów głosowych, myślę, że istnieją 3 główne wyzwania.

Mamy więc opóźnienie, inteligencję i koszt.

Chcę jednak wyjaśnić, że gdy mówię o agentach głosowych, mam na myśli agentów głosowych jako rozmowę, a nie jako prompt.

Nie mówię o mikrofonie, który wysyła coś do LLM, a potem czeka na odpowiedź.

Mam na myśli rozmowę w czasie rzeczywistym, która przypomina prawdziwą rozmowę z człowiekiem. To właśnie jest najtrudniejsze do stworzenia.

Zacznijmy od opóźnienia.

Jak szybko musi to nastąpić?

Okazuje się, że musi być szybka, bardzo szybka, ale w zależności od tego, co czytasz, może nie być tak szybka, jak myślisz, lub może być znacznie szybsza, niż myślisz.

Omówmy więc kilka liczb, które odkryliśmy podczas wielu testów.

Gdy mówię o opóźnieniu od początku do końca, mam na myśli czas od ostatniej wypowiedzi użytkownika, czyli ostatniego dźwięku, który wydał, do momentu, gdy usłyszy on odpowiedź.

Podczas testów odkryliśmy, że 1,5 sekundy to czas, w którym użytkownicy przestają wspominać o szybkości lub powolności działania.

To wydaje się być moment, w którym ludzie zaczynają czuć się naprawdę komfortowo.

Gdy tylko czas oczekiwania jest dłuższy, ludzie często mówią: „To świetne, ale…”. Wygląda więc na to, że to jest optymalny czas.

Gdy czas odpowiedzi skróci się do około 1, 2 sekundy, rozmowa zaczyna przypominać naturalną wymianę zdań.

Na przykład ja coś mówię, a w tym przypadku robot szybko odpowiada i tak na zmianę.

Wygląda na to, że udało się znaleźć idealne rozwiązanie.

Jednak 1, 2 sekundy to dość trudny do osiągnięcia wynik w przypadku stosu.

Innym ciekawym odkryciem było to, że po przeprowadzeniu wielu testów udało nam się uzyskać w niektórych scenariuszach czas poniżej sekundy.

Możesz pomyśleć: „O, to będzie niesamowite!”.

Czasami tak było, a czasami było to okropne, bardzo dziwne.

Możesz więc usłyszeć, że odpowiedni czas odpowiedzi to 800 milisekund lub 500 milisekund.

Przeczytałem nawet kilka artykułów o 300, bo to jest właśnie granica ludzkiej percepcji.

W rzeczywistości jest to bardzo zależne od kontekstu.

Jeśli na przykład zapytam Cię, jak się nazywasz, mam pewne oczekiwania co do tego, jak szybko odpowiesz.

Jeśli zapytam, jaki jest sens życia, będę oczekiwać odpowiedzi w zupełnie innym czasie.

Gdy przeprowadziliśmy testy i poprosiliśmy użytkowników o ocenę, czy odpowiedź była szybka czy wolna, wyniki były bardzo zróżnicowane.

Odpowiedzi, które zajęły dużo czasu, były określane jako szybkie i na odwrót, ponieważ okazało się, że zależy to od kontekstu.

oraz na jakim etapie rozmowy się znajdowali.

Zwykle użytkownicy oczekują, że pierwsza odpowiedź będzie szybsza niż kolejne, ponieważ wymaga ona czasu na przemyślenie.

Ale czasami zdarza się, że wymiana zdań jest bardzo krótka, więc oczekiwania rosną.

Nie jest to więc idealna nauka, w której istnieje idealna liczba, ale odkryliśmy, że jeśli jesteś w tym miejscu, to jest to całkiem niezły wynik.

Gdy osiągniesz ten poziom 1, 5 sekundy, zaczynasz dbać o spójność, prawda?

Jeśli bowiem w 90% przypadków wszystko działa, ale w 10% zajmuje to 3 sekundy, użytkownik nie będzie uważał, że usługa działa źle, ale że jest uszkodzona.

Gdy osiągniesz już wystarczającą szybkość, zaczynasz dbać o spójność, czyli o to, aby szybkość była stała, a nie tylko chwilowa.

Devin Reimer

Oto standardowa architektura potoku głosowego.

Przekazujemy więc dane z zamiany mowy na tekst do LLM, a następnie wynik z LLM z powrotem do zamiany tekstu na mowę.

Mam na myśli to, że w przypadku zamiany mowy na tekst wysyłamy dźwięk na serwer, a następnie konwertujemy go na tekst.

Po stronie LLM bierzemy ten tekst, ten dialog odpowiedzi, lub przekształcamy go w dialog odpowiedzi, a następnie określamy, jakie działania podejmie ta postać.

Ściśle łączymy te elementy, ponieważ uważamy, że jest to bardzo ważne.

Następnie po stronie zamiany tekstu na mowę bierzemy ten tekst, wysyłamy go do zamiany tekstu na mowę i przesyłamy strumieniowo do użytkownika, również w czasie zgodnym z działaniami, które agent chce wykonać.

Jednym z problemów jest to, że sekwencyjne uruchamianie może być dość powolne, ponieważ trzeba przejść przez każdy z tych elementów.

Często słyszę pytanie: skoro to jest powolne i wymaga 3 kroków, dlaczego nie użyć modelu mowa-mowa?

Bo tak byłoby szybciej, prawda?

And, yeah, like, most of the time that would be faster because you're running one thing.

Wiąże się to jednak z pewnymi kompromisami.

Chociaż jest szybki, ma kilka poważnych wad, z których największą jest koszt.

Ogólnie rzecz biorąc, uruchomienie modelu mowa-mowa jest około 3–5 razy droższe niż w przypadku podejścia równoległego.

Dlatego dla nas to się po prostu nie opłaca.

Jeśli chodzi o bezpieczeństwo, jest to nieco bardziej skomplikowane, ponieważ trudniej jest zweryfikować odpowiedź agenta, zanim ją wypowie.

Jeśli jednak masz podejście potokowe, możesz sprawdzić odpowiedź LLM i przeprowadzić kontrolę bezpieczeństwa, zanim jeszcze zbliżysz się do wysłania informacji do użytkownika.

Jeśli chodzi o stylizację głosu, musisz korzystać z ustawień wstępnych w modelu zamiany mowy na mowę.

Nie możesz powiedzieć: „Wiesz co?

W tym przypadku naprawdę chcę użyć tego typu głosu”.

Nie możesz go zmienić.

W podejściu potokowym możesz powiedzieć: „O, zmienię to.

Wybiorę ten model, ponieważ świetnie sprawdza się w tym konkretnym przypadku użycia”.

To samo dotyczy inteligencji, prawda?

Jeśli masz naprawdę dobry model mowy na mowę, który generuje dobry głos, ale inteligencja nie jest taka, jakiej oczekujesz, nie możesz go po prostu zmienić, prawda?

Nie masz wyboru.

W podejściu potokowym mówisz: „W tym przypadku chcę użyć konkretnego modelu”.

Jednym z obszarów, w których tryb mowy zdecydowanie wygrywa, jest rozumienie tonu użytkownika.

Na przykład sarkazm.

Obecnie transkrypcje mowy na tekst zwykle nie zawierają wielu takich informacji, ale myślę, że z czasem to się zmieni.

To zdecydowanie jedna z zalet funkcji mowy na mowę.

Speech-to-Speech ma więc zdecydowanie przewagę, jeśli chodzi o szybkość, ale wiąże się z pewnymi wyzwaniami w zakresie konfigurowalności, a wysoki koszt był dla nas po prostu nie do zaakceptowania.

Czy jest więc inny sposób?

Tak.

Powinniśmy zrobić wszystko, co w naszej mocy, aby zrównoleglić potok.

Dlatego niektóre z naszych działań polegają na uruchamianiu LLM, zanim system zamiany mowy na tekst uzyska pełną pewność.

Mam na myśli pewność co do słów generowanych w transkrypcji, a następnie pewność co do końca tury.

Gdy tylko uznamy, że użytkownik przestał mówić i powiedział to, co powiedział, przechodzimy do działania.

Najgorszy scenariusz jest taki, że się mylimy.

Użytkownik kontynuuje wypowiedź.

Ale nawet w takim przypadku wystarczy anulować LLM i uruchomić go ponownie.

Kontekst będzie prawdopodobnie przechowywany w pamięci podręcznej, a my nie wygenerowaliśmy zbyt wielu tokenów, więc nie wiąże się to z dużymi kosztami. Korzyścią jest to, że użytkownik usłyszy odpowiedź szybciej, niż gdybyśmy czekali na pełną pewność.

Nie czekamy też, aż LLM wygeneruje całą odpowiedź, zanim zaczniemy wysyłać ją do usługi zamiany tekstu na mowę.

Czekamy na pierwszy fragment, który można odczytać na głos.

W większości przypadków jest to zdanie.

Czasami mogą to być inne konfiguracje, ale gdy tylko otrzymamy pierwszy fragment zdania, wysyłamy go do usługi zamiany tekstu na mowę.

Jeśli mamy dobrą funkcję zamiany tekstu na mowę, która będzie przesyłać strumieniowo, gdy tylko będzie gotowa, użytkownik będzie mógł z niej korzystać.

Zwracamy też szczególną uwagę na liczbę tokenów, które muszą zostać wygenerowane.

Nie używamy więc takich elementów jak kontenery JSON, które mogą dodawać kolejne tokeny.

Staramy się znaleźć najbardziej uproszczoną strukturę, która pozwoli uzyskać jak najszybszą odpowiedź.

Używamy też takich funkcji jak wstępne wypełnianie asystenta, jeśli wiemy, jaki będzie pierwszy fragment tokenów od agenta.

W przypadku zamiany tekstu na mowę były to te 2 fragmenty.

Najpierw pojawia się pierwszy fragment do odczytania, a potem cała reszta.

Ponieważ jednak odtwarzanie dźwięku trwa dłużej niż jego generowanie, pierwszy fragment zostanie odtworzony użytkownikowi, zanim drugi fragment będzie gotowy.

Jest to więc niewidoczne dla użytkownika.

Pojawia się tam tak szybko, jak to możliwe.

Jeśli zastanawiasz się nad wyborem różnych usług, oto kilka naszych wskazówek.

Jeśli chodzi o wybór dobrego rodzaju dźwięku i platformy agenta, najważniejsze jest jak najniższe opóźnienie wejściowe i wyjściowe.

Jak szybko mogę wysyłać i pobierać dane?

Jeśli chodzi o zamianę mowy na tekst, zależy nam na czasie do uzyskania pewności.

So this is confidence in transcript and confidence in end of turn.

Te urządzenia są sparowane, prawda?

Jeśli nie masz pewności, czy dany model jest szybki, będzie on działał powoli, prawda?

Dlatego szybkość działania zależy od najwolniejszego elementu.

Jeśli chodzi o LLM, interesuje nas czas do pierwszego zdania, czyli pierwszego fragmentu, który można wypowiedzieć.

Są 2 aspekty tej kwestii.

Jest to czas do pierwszego tokena połączony z tokenami na sekundę.

Jeśli więc nagle znajdziesz naprawdę dobry model, który zapewnia bardzo dobry czas do pierwszego tokena, ale jest powolny pod względem liczby tokenów na sekundę, może to być gorsze rozwiązanie niż alternatywa.

Zastanów się, jaka kombinacja będzie najlepsza.

Jeśli chodzi o zamianę tekstu na mowę, ważny jest czas do pierwszego dźwięku.

Dlatego bardzo ważne jest, aby zmierzyć, co to jest, ponieważ czasami dźwięk może powrócić z ciszą na początku, której użytkownik nie usłyszy.

Musisz więc mierzyć czas do momentu, gdy użytkownik usłyszy dźwięk.

Jak już wspominałem, najważniejsza jest stabilność, a nie maksymalna prędkość czy najlepszy możliwy scenariusz.

Jakie są stałe opóźnienia całego stosu?

Devin Reimer

Obecnie w przypadku naszych platform agentów audio używamy LiveKit.

Do zamiany mowy na tekst używamy Deepgram.

W przypadku LLM używamy modelu Gemma 4 31B, który hostujemy na LiveKit.

Jeśli chodzi o zamianę tekstu na mowę, używamy technologii Inworld AI Text-to-Speech 2.

Oprócz tego stworzyliśmy całą uprząż agenta AI AstroBeam, która nie tylko łączy to wszystko, ale też dodaje wszystkie elementy potrzebne do stworzenia naprawdę dobrego agenta głosowego, zwłaszcza takiego, który jest wysoce interaktywny, jak nasz w grach.

Nie wspomniałem jeszcze o modelach bezpieczeństwa.

Tradycyjnie modele bezpieczeństwa są częścią LLM, ale to zwiększa czas oczekiwania i dodaje kolejny krok.

A gdyby tak uruchomić własny?

Tak naprawdę nasz stos wygląda bardziej tak.

Dlatego gdy otrzymujemy pierwszy fragment tekstu, który ma zostać odczytany, wysyłamy go do zamiany tekstu na mowę i jednocześnie do naszego modelu bezpieczeństwa.

Ponieważ model bezpieczeństwa jest mniejszy i będzie działać szybciej niż zamiana mowy na tekst, prawie zawsze jest on uruchamiany wcześniej.

Oznacza to, że dodanie modelu bezpieczeństwa nie powoduje żadnych opóźnień w naszym stosie, a co więcej, jest to na tyle duży fragment, że możemy uruchomić znacznie większy model bezpieczeństwa, niż większość osób w ogóle bierze pod uwagę.

To dla nas bardzo ważne, zwłaszcza że tworzymy gry.

W tym świecie jest wiele bardzo ważnych kontekstów.

Załóżmy na przykład, że tworzysz grę osadzoną w średniowieczu, w której postać niezależna krzyczy: „Do ataku!

Ściąć im głowy!”, prawda?

Tradycyjny model bezpieczeństwa może wyglądać tak: „O, to nie jest fajne.

Nie powinnaś tak mówić”.

Ale w kontekście tej gry ma to sens.

Możemy to zrobić, używając bardziej niezawodnego modelu bezpieczeństwa z dużo większą ilością kontekstu dotyczącego tego, co dzieje się na świecie.

Możesz zauważyć, że model bezpieczeństwa jest uruchamiany dwukrotnie – najpierw na pierwszym fragmencie, a potem na całości, gdy mamy już ostatni fragment.

Musimy uruchomić go dwukrotnie, ale nie powoduje to opóźnień w stosie.

Teraz jesteśmy wystarczająco szybcy, ale to nie ma znaczenia, jeśli nie jesteśmy wystarczająco mądrzy.

Devin Reimer

Jak inteligentny musi być?

Musi być wystarczająco inteligentna dla użytkowników, ale co ważniejsze, musi być wystarczająco inteligentna, aby można było ją rozwijać.

Często ludzie nie myślą o tym, gdy wybierają to, czego potrzebują do analizy zagrożeń.

Pracujemy nad agentami głosowymi od około 3 lat. Na początku używaliśmy niektórych wczesnych modeli LLaMA. Chociaż udało nam się sprawić, że działały dla użytkowników, proces ich tworzenia był bardzo kosztowny, ponieważ wszystko było bardzo niestabilne.

Modele mogły łatwo generować niepożądane odpowiedzi lub rzeczy, które po prostu nie miały sensu, dlatego poświęciliśmy wiele wysiłku, aby to działało.

To dla nas priorytet, ponieważ jeśli nie będziemy działać szybko, nie będziemy mogli udostępniać użytkownikom nowych funkcji.

Dlatego warto wziąć pod uwagę oba te aspekty.

Często, gdy ludzie myślą o inteligencji, myślą o LLM, prawda?

Ale to tylko część problemu.

Jeśli chodzi o inteligencję, musimy wziąć pod uwagę każdy element.

Porozmawiajmy o funkcjach zamiany mowy na tekst.

W tym przypadku zależy nam na niskim współczynniku błędów słów.

Dodatkowo nie tylko odsetek błędów jest niski, ale gdy już się pojawiają, generujemy coś, co jest bardzo zbliżone do rzeczywistego wyniku. Jeśli jest on bardzo zbliżony, LLM może często, dzięki kontekstowi, bardzo dobrze zrozumieć, o co chodzi.

Jeśli odsetek błędów jest niski, ale liczba błędnych kroków jest bardzo wysoka, LLM będzie miał znacznie większe trudności z ustaleniem rzeczywistej intencji.

Inną kwestią, którą warto rozważyć, jest platforma docelowa.

Jeśli na przykład tworzę aplikację XR i mam mikrofony, które są bardzo blisko ust użytkownika, będę mieć bardzo dobre, wysokiej jakości dane audio z mikrofonu, co może bardzo dobrze działać w przypadku niektórych modeli.

Jeśli jednak nagle tworzę aplikację na telefon komórkowy, z której ludzie będą korzystać na ruchliwej ulicy, ma to zupełnie inny wpływ, a różne modele będą zachowywać się inaczej i będą mogły w różny sposób inteligentnie interpretować to, co jest mówione.

Musisz więc o tym pamiętać i wybrać odpowiednią platformę, na którą tworzysz aplikację.

Przejdźmy teraz do zamiany tekstu na mowę.

Brzmi naturalnie, prawda?

Naszym celem jest przekazanie użytkownikowi informacji, które będzie w stanie zrozumieć.

Ale to tylko część, prawda?

Ekspresyjność agenta jest również bardzo ważna, ponieważ zawiera informacje. Podczas testów odkryliśmy, że im bardziej ekspresyjni są nasi agenci, tym bardziej inteligentni wydają się użytkownikom, co ma sens.

Czy jest wystarczająco szybki?

W poprzedniej sekcji mówiłem o opóźnieniu, ale ma ono znaczenie również w przypadku postrzeganej inteligencji.

Użytkownicy postrzegają szybkość odpowiedzi jako bezpośrednio powiązaną z tym, jak jest ona inteligentna.

Jeśli mam szybką odpowiedź, prawdopodobnie brzmi ona bardziej inteligentnie.

Te elementy mogą mieć duże znaczenie dla tego, jak użytkownik postrzega dany materiał i jak bardzo się w niego angażuje.

Przejdźmy teraz do LLM.

To zdecydowanie najtrudniejsza kwestia, ponieważ jest tu tak wiele różnych wymagań.

Mamy więc rozumienie mowy, kontekst i uzasadnienie.

W grach jest to bardzo trudne, ponieważ trzeba stworzyć cały świat i uniwersum, prawda?

To nie jest pole tekstowe, w którym może zmyślać różne rzeczy.

Jeśli agent w grze powie: „Na stole jest jabłko”, a na stole nie ma jabłka, zakłóci to wrażenia użytkownika.

Potrzebujemy też takich rzeczy jak ścisłe przestrzeganie zasad.

Gry są bardzo oparte na regułach.

Czy LLM sobie z tym poradzi?

Czy możemy mieć niski wskaźnik halucynacji?

Czy możemy mieć spójne postacie, gdy wielokrotnie wchodzimy w interakcję z tym samym agentem?

Czy masz wrażenie, że rozmawiasz z tym samym agentem?

Kolejny problem, który może Cię zaskoczyć, ponieważ nie pojawia się na początku prac, to pytanie, czy Twój model poradzi sobie z rosnącym rozmiarem prompta.

W miarę rozwoju aplikacji będziesz dodawać do promptu coraz więcej informacji.

W miarę jak użytkownicy będą kontynuować grę, w prompcie będzie pojawiać się coraz więcej historii czatu.

Czy ten prompt poradzi sobie z tym wzrostem?

Czasami w przypadku niektórych modeli wraz ze wzrostem długości prompta spada jakość odpowiedzi, więc musisz określić, jakie są Twoje rzeczywiste potrzeby dotyczące ilości informacji, które muszą być zawarte w prompcie za każdym razem.

To jednak tylko wierzchołek góry lodowej, a wszystko zależy od tego, co budujesz.

Musisz więc dokładnie przemyśleć, co tworzysz i co chcesz osiągnąć.

Mamy już wystarczająco szybkie i inteligentne rozwiązanie, ale to wszystko nie ma znaczenia, jeśli jest zbyt kosztowne.

Devin Reimer

Jak tanie musi być to rozwiązanie?

Niestety jest to nieco bardziej skomplikowane.

Musimy więc pomyśleć o ekonomii tworzonej aplikacji lub gry.

Oto kilka pytań, które musisz zadać.

Jak długo użytkownik będzie wchodzić w interakcję z agentami głosowymi?

Ile zarabiasz na użytkowniku?

A ile kosztuje godzina działania tego stosu głosowego?

Łączymy je, aby spróbować to rozgryźć i sprawdzić, czy to ma sens.

Oto ekonomia naszej pierwszej gry, Stellar Cafe.

Czas gry w Stellar Cafe wynosi od 1,5 do 3,5 godziny, więc przyjmijmy średnią wartość około 2 godzin.

Koszt działania agentów głosowych wynosi około 1,20 USD za godzinę na użytkownika, a użytkownicy wchodzą z nimi w interakcję przez cały czas.

Gra jest w 100% sterowana głosem.

Pobieramy stałą opłatę w wysokości 10 USD za grę, co jest tradycyjnym rozwiązaniem.

Nie oferujemy subskrypcji, ponieważ są one bardzo trudne w grach. Jestem przekonany, że musimy zapewnić działanie gry przy stałych kosztach, bo inaczej to nie zadziała i nie będzie się skalować.

Wcześniej pobieraliśmy opłatę w wysokości 15 USD, ale pracowaliśmy nad obniżeniem kosztów serwerów, więc teraz udało nam się ją obniżyć do 10 USD.

A ta kwota 1, 20 USD to nasza obecna sytuacja.

Nie jest to uniwersalna cena.

Widziałem(-am) te rzeczy w bardzo różnych cenach, czasem znacznie wyższych.

Musisz więc też dowiedzieć się, jak wygląda sytuacja po stronie kosztów.

Moglibyśmy obniżyć cenę, ale staramy się utrzymać jak najwyższą jakość.

Podsumowując, oznacza to, że przy 2 godzinach odtwarzania koszt naszego stosu głosowego wynosi około 2, 40 USD na użytkownika.

Pobieramy 10 USD, a sklep pobiera opłatę, co oznacza, że zarabiamy około 4,59 USD na użytkowniku, prawda?

W ten sposób to się opłaca, prawda?

Głos to nasza przynęta, na którą chcemy wydawać pieniądze. To działa.

To naprawdę niewielka gra.

Porozmawiajmy o czymś większym.

Porozmawiajmy o hipotetycznej grze fabularnej, która trwa od 5 do 9 godzin, czyli średnio 7 godzin.

W rzeczywistości większość osób nie kończy gier – grają przez chwilę, a potem je porzucają. Chcę jednak wybrać nieco wyższą wartość, aby mieć pewność, że ekonomia nadal działa.

Zostaniemy więc przy 1,20 USD za godzinę, ale wprowadzimy zmianę polegającą na tym, że komponent głosowy będzie używany przez 60% czasu, ponieważ większa gra będzie miała o wiele więcej mechanik niż tylko głos.

Gra nadal będzie w dużym stopniu oparta na głosie, ale będzie miała też inne funkcje.

Jeśli więc pobieramy 20 USD, to po odliczeniu wszystkich kosztów, które wynoszą około 5 USD na użytkownika, zarabiamy około 9 USD na użytkownika.

Dzięki temu ekonomia działa.

Nie oznacza to jednak, że ekonomia będzie działać we wszystkich przypadkach.

Na przykład nie należy robić czegoś takiego: „Chcę stworzyć grę bezpłatną, w którą użytkownicy będą grać od 1 godziny do ponad 100 godzin”.

Załóżmy, że średnio jest to 10 godzin.

Jest w 100% sterowana głosem, ale załóżmy, że mamy hit i gra generuje około 3 USD na użytkownika, co byłoby całkiem niezłym wynikiem jak na grę bezpłatną.

Stracisz 10 USD na użytkownika.

Nie działa jeszcze we wszystkich tych obszarach, więc musisz zastanowić się, co obecnie tworzysz i czy ma to sens.

Nie czekaj do końca, aby spróbować zrozumieć kwestie finansowe.

Devin Reimer

Następne pytanie, które się pojawia, brzmi: „A co z modelami lokalnymi?”.

Jeśli bowiem koszty są tak dużym wyzwaniem, czy modele lokalne nie rozwiązałyby tego problemu?

Tak, to prawda.

Musimy jednak wziąć pod uwagę pewne kompromisy.

Jeśli chodzi o koszty, wyeliminowalibyśmy rachunki za serwer, co byłoby ogromną korzyścią i otworzyłoby przed nami wiele nowych możliwości.

Ale jest wiele rzeczy, które obecnie można rozwiązać w chmurze, a które są trudne do zrealizowania lokalnie.

Na przykład compute.

Często ludzie mówią: „Spójrz, znalazłem ten naprawdę dobry model zamiany mowy na tekst, który działa lokalnie na tym urządzeniu, prawda?”.

Świetnie, ale musimy pamiętać, że nie chodzi o uruchamianie jednego modelu, ale wielu modeli, prawda?

W naszym przypadku są to 4 osoby, potencjalnie jednocześnie, więc nie wystarczy, że coś uruchomi się raz, musi uruchomić się kilka razy jednocześnie.

A jeśli to zrobisz, czy pozostanie coś, co pozwoli na uruchomienie gry lub aplikacji?

Jeśli wykorzystasz całą moc GPU, nie uda Ci się wyrenderować zbyt wiele z gry wideo.

Załóżmy, że udało Ci się pokonać te wyzwania.

Następna jest prędkość, prawda?

Często można je uruchomić, ale będą działać bardzo wolno i będzie to przypominać raczej podpowiadanie niż prawdziwą rozmowę w czasie rzeczywistym.

Teoretycznie więc lokalne pobieranie ma przyszłość, ponieważ nie trzeba wykonywać tej operacji w obie strony przez internet.

Obecnie wyzwaniem jest uzyskanie modeli, które będą działać z odpowiednią szybkością, aby to było możliwe.

Załóżmy, że udało się rozwiązać problemy z mocą obliczeniową i szybkością. Teraz musimy pomyśleć o jakości.

Zazwyczaj, ponieważ uruchamiasz go na urządzeniu lokalnym, używasz mniejszego modelu LLM, np. bardziej prymitywnej zamiany tekstu na mowę. Może to stanowić pewne wyzwanie, jeśli chodzi o tworzone treści.

Jak już wspomnieliśmy, gdy myślisz o modelu LLM, nie chodzi tylko o to, czy jest on wystarczająco dobry dla użytkowników, ale też o to, czy jest wystarczająco dobry do tworzenia aplikacji.

Jeśli więc stworzenie czegoś na podstawie tego modelu jest trudne, warto się nad tym zastanowić.

Załóżmy, że udało się rozwiązać problemy z mocą obliczeniową, szybkością i jakością. Kolejnym wyzwaniem jest przenośność.

Jeśli wygrasz i przejdziesz przez cały ten proces, a potem uruchomisz ten model na przykład na RTX 5070, może to być jedyne miejsce, w którym będzie on działać.

Jeśli więc pojawi się możliwość przeniesienia gry na nową platformę, możesz mieć problem.

Jeśli chodzi o chmurę, potrzebujesz tylko internetu.

To bardzo ważna zmiana.

Umożliwia prowadzenie transmisji na wielu platformach.

Porozmawiajmy teraz o podejściu hybrydowym.

Uruchommy więc niektóre elementy w chmurze, a inne lokalnie.

Może być, czy to zadziała?

To nie jest aż tak duży sukces, jak Ci się wydaje.

Jeśli więc masz model, który jest wystarczająco mały, aby działać na większości platform lokalnych, uruchomienie go w chmurze będzie kosztować grosze.

Dlatego największe korzyści można zwykle osiągnąć dopiero po rozwiązaniu problemów na wszystkich poziomach.

Następnie pojawia się pytanie, czy można uruchomić model lokalnie, jeśli jest to możliwe.

Mają odpowiedni sprzęt, a jeśli Ty go nie masz, możesz skorzystać z chmury, prawda?

Można uruchomić coś bardziej zaawansowanego w chmurze.

To wiąże się z nowymi wyzwaniami, prawda?

Jeśli ostatecznie użyjesz innego modelu, może to mieć duży wpływ na proces programowania.

I tak musisz poświęcić dużo czasu na pracę nad minimalną specyfikacją.

Możesz mieć modele, które zachowują się zupełnie inaczej.

Jeśli więc nie używasz dokładnie tych samych modeli, możesz znacznie wydłużyć czas i zwiększyć koszty programowania.

Warto więc zastanowić się, co chcesz osiągnąć, bo powiedzmy, że udało Ci się to rozgryźć i masz dobry model lokalny, jeśli jest potrzebny, lub model w chmurze, jeśli nie jest, ale model w chmurze nadal musi być opłacalny.

Jeśli nagle wszyscy użytkownicy przejdą do chmury, a Ty nie weźmiesz tego pod uwagę, stracisz na tym finansowo.

Jeśli chodzi o modele lokalne, to zdecydowanie duży sukces ekonomiczny, ale to dopiero początek.

W przypadku aplikacji, w których cena ma duże znaczenie, takich jak gry, moim zdaniem ostatecznie wygra.

Obecnie jest to dość trudne, z wyjątkiem bardziej konkretnych przypadków użycia, zwłaszcza tych związanych z poleceniami.

Dlatego już teraz chcemy zapewnić jak najlepsze wrażenia.

Dlatego korzystamy z chmury.

Jednak ta branża rozwija się bardzo szybko i sytuacja dynamicznie się zmienia.

W kolejnej części zastanówmy się nad modelami, których używamy.

Kolejne pytanie dotyczy otwartych i zamkniętych wag.

Co powinniśmy tu zrobić?

Chcę skupić się na dużych modelach językowych, ponieważ odkryliśmy, że jest to obszar, na który najbardziej wpływa kwestia otwartego lub zamkniętego charakteru.

Są więc pewne zalety i wady.

Jeśli chodzi o zamknięte modele wag, są to zazwyczaj modele o najwyższym poziomie inteligencji, prawda?

Jeśli więc potrzebujesz najbardziej zaawansowanych funkcji, często musisz skorzystać z tej opcji.

Z kolei w przypadku otwartego ekosystemu często są o generację do tyłu.

Może to być więc prawdziwy kompromis.

Jeśli chodzi o szybkość, wspomniałem, że bardzo zależy mi na czasie do pierwszego zdania.

Odkryliśmy, że w przypadku modeli zamkniętych szybkość często spada w miarę upływu czasu.

Może to wynikać z różnych powodów.

Być może więcej osób korzysta z modelu, a być może sprzęt został zmieniony na nowszy model.

Ale to jedna z rzeczy, które zauważyliśmy.

Dlatego trzeba uważać, bo może to spowodować problem, gdy wyślesz coś, co jest świetne, ale z czasem może stać się bezużyteczne.

Kolejny element to skoki.

Bardzo zależy Ci na takiej spójności, dlatego często modele zamknięte są budowane wokół przetwarzania wsadowego w zadaniach asynchronicznych, a nie opóźnień P99. W przypadku modeli otwartych możesz wybrać dostawcę, który dba o tę konkretną rzecz, na której Ci zależy, aby zapewnić Ci pewność, szybkość i opóźnienie, których potrzebujesz.

Kolejny czynnik to okres istnienia samego modelu.

W przypadku modeli zamkniętych często wycofuje się je po około roku.

Oznacza to, że jeśli przez rok będziesz rozwijać coś, co ma być w produkcji przez 3 lata, możesz przejść przez ponad 3 zmiany modelu.

To, że model jest lepszy, nie oznacza, że będzie lepiej działał w Twoim przypadku.

W ciągu ostatnich 3 lat wprowadziliśmy wiele zmian w modelach. Często wymagało to tygodni, a czasem miesięcy pracy nad przebudową wszystkiego. W przypadku otwartego modelu można go używać tak długo, jak długo ktoś chce go hostować lub jak długo sami chcemy go hostować.

Ostatnia kwestia to koszt.

Często z czasem te zamknięte modele, gdy wydawane są ich nowe wersje, są droższe od poprzednich.

Dlatego trzeba uważać na kwestie finansowe. Może się okazać, że model finansowy, który sprawdzał się na początku, przestanie działać po zmianie modelu biznesowego.

Po stronie otwartej masz możliwość przenoszenia go, a prawdopodobieństwo, że cena drastycznie wzrośnie, jest niewielkie, ponieważ jest to dokładnie ten sam model.

Używamy modelu Gemma 4 31B, który był dla nas przełomem, ponieważ stanowi najlepsze połączenie szybkości, inteligencji i kosztów.

Pozwoliło nam to również na bardzo szybkie działanie.

Praca z nim jest o wiele łatwiejsza niż z niektórymi narzędziami, których używaliśmy wcześniej.

Nie oznacza to, że używamy tylko tego.

Używamy wielu kombinacji różnych modeli otwartych i zamkniętych.

Na przykład generowanie wspomnień, bezpieczeństwo i personalizacja.

Ważne jest, aby wybrać najlepszy model do konkretnych potrzeb w danym zadaniu.

Jednak Gemma 4 31B to nasz główny model, jeśli chodzi o agentów głosowych.

Jeśli chodzi o tego rodzaju różnice między tymi dwoma rodzajami modeli, modele otwarte zdecydowanie dają większą kontrolę i pozwalają zachować modele tak długo, jak długo można je hostować przy bardziej przewidywalnych kosztach.

Nie musisz się też martwić, że wycofanie modelu wpłynie na Twój harmonogram.

Devin Reimer

Podsumowując, chodzi o zachowanie równowagi między tymi 3 elementami, prawda?

Jeśli chodzi o czas oczekiwania, staramy się zachować równowagę między aspektem strumieniowania, aspektem równoległym, szybkością i spójnością.

Jeśli chodzi o inteligencję, jest wystarczająco inteligentny dla użytkowników i do tworzenia rozwiązań.

Jeśli chodzi o koszty, musimy wiedzieć, ile będzie kosztować każdy użytkownik i ile możemy na nim zarobić, aby upewnić się, że to się opłaca.

Nie twórz najpierw gry, a potem nie zastanawiaj się nad jej aspektami finansowymi.

Pomyśl o tym od samego początku.

To dopiero początek, ale już widać, że ten model biznesowy działa.

Dlatego tańsze modele będą zdecydowanie lepsze, a bardziej inteligentne modele będą zdecydowanie lepsze.

Ale już dziś możemy zacząć pracować nad naprawdę trudnymi wyzwaniami, które musimy rozwiązać, aby agenci głosowi stali się powszechni.

Dlatego bardzo się cieszę, że możemy udostępnić wszystkim możliwości agentów głosowych.

Dziękujemy.