Extrem niedrige Latenz und Cloud-Wirtschaftlichkeit bei virtuellen Sprach-Agents in Einklang bringen

Devin Reimer

Willkommen bei „Balancing extrem niedrige Latenz und Cloud Economics in virtual voice agents“.

Ich bin Devin Reimer.

Ich bin der Gründer und CEO von AstroBeam.

Zuvor war ich CEO und Mitbegründer von Owlchemy Labs, das wahrscheinlich am besten für Job Simulator bekannt ist.

Bei AstroBeam konzentrieren wir uns also darauf, Echtzeit-KI in Spiele zu integrieren.

Wir konzentrieren uns insbesondere auf die Spracheingabe.

Wir haben bisher zwei Titel veröffentlicht: „Stellar Cafe“ für VR und PC.

In diesem Spiel unterhältst du dich mit Robotern in einem Café auf einer Raumstation und hilfst ihnen, ihre Probleme zu lösen.

Sie wird zu 100 % per Sprache gesteuert.

Du spielst das gesamte Spiel, einschließlich Menüs und Navigation, nur mit deiner Stimme.

Unser nächstes Spiel, das wir heute angekündigt haben, heißt „Robo Detective“ und wurde für Android XR und speziell für Project Aura von XREAL entwickelt.

In diesem Spiel schlüpfen Sie in die Rolle eines Detektivs, der mit einem Roboterpartner zusammenarbeitet, um Roboter zu befragen und Roboterverbrechen aufzuklären. Auch dieses Spiel wird zu 100 % per Sprache gesteuert.

Sprach-Agents sind also wirklich schwierig und in Spielen sogar noch schwieriger.

Der Grund dafür ist, dass Spiele sehr kostengünstig sind und ein Sprach-KI-Agent nun neue Kosten für diese Pipeline verursacht.

Außerdem konkurrieren wir nicht mit anderen Sprachagenten, sondern mit der Qualität aller Spiele, die jemals entwickelt wurden, oder?

Wir müssen also eine sehr hohe Qualität bieten.

Das soll nicht heißen, dass es keine spezifischen Anwendungsfälle für Sprach-Agents gibt, die besondere Herausforderungen mit sich bringen oder bei denen viel mehr auf dem Spiel steht, aber Spiele sind in diesem Bereich definitiv sehr anspruchsvoll.

Da es sich aber um Spiele handelt, gibt es viel Raum für Experimente, um einige dieser schwierigen Probleme zu lösen.

Ich glaube, wenn Sprach-Agents in Spielen funktionieren, können sie fast überall funktionieren.

Die Dinge, über die ich in diesem Vortrag spreche, gelten also nicht nur für Spiele, sondern für jede sprachbasierte Anwendung, die Sie entwickeln möchten.

Bei Sprach-Agents gibt es drei wesentliche Herausforderungen.

Wir haben also Latenz, Intelligenz und Kosten.

Ich möchte jedoch klarstellen, dass ich bei Sprach-Agenten von Sprach-Agenten als Gesprächspartner und nicht als Prompt spreche.

Ich meine damit nicht eine Mikrofon-Wrapper-App, die etwas an ein LLM sendet und dann auf eine Antwort wartet.

Ich meine eine echte Unterhaltung in Echtzeit. Und das ist tatsächlich ziemlich schwierig zu entwickeln.

Beginnen wir mit der Latenz.

Wie schnell muss es gehen?

Es stellt sich heraus, dass sie schnell sein muss, sehr schnell, aber je nachdem, was Sie gelesen haben, ist sie vielleicht nicht so schnell, wie Sie denken, oder sie ist viel schneller, als Sie denken.

Sehen wir uns also einige Zahlen an, die wir bei unseren Tests ermittelt haben.

Wenn ich von End-to-End-Latenz spreche, meine ich die Zeit von der letzten Nutzeräußerung, also dem letzten Ton, den der Nutzer von sich gegeben hat, bis zu dem Zeitpunkt, an dem er die Audioantwort hört.

Bei unseren Tests haben wir festgestellt, dass Nutzer bei einer Dauer von etwa 1,5 Sekunden in ihrem Feedback zu Spieltests nicht mehr die Geschwindigkeit oder Langsamkeit oder Ähnliches erwähnen.

Das scheint der Punkt zu sein, an dem sich die Leute wirklich wohl damit fühlen.

Wenn wir viel langsamer werden, sagen die Leute oft: „Das ist toll, aber…“ Das scheint also ein guter Mittelweg zu sein.

Wenn die Antwortzeit dann noch kürzer wird, so bei etwa 1,2 Sekunden, wird die Unterhaltung noch natürlicher und es entsteht ein echter Dialog.

Ich sage also etwas, in diesem Fall sagt der Roboter etwas sehr schnell und wir wechseln uns ab.

Es scheint, als ob es da einen Sweetspot gibt, der freigeschaltet wird.

Allerdings sind 1, 2 Sekunden in einem Stack ziemlich schwer zu erreichen.

Ein weiteres interessantes Ergebnis ist, dass wir viele Tests durchgeführt haben und in einigen Szenarien eine Latenz von unter einer Sekunde erreichen konnten.

Und Sie denken vielleicht: „Oh, das wird toll!“

Manchmal war es das auch, aber manchmal fühlte es sich schrecklich an, sehr unheimlich.

Es kann also sein, dass Sie von Leuten hören, dass 800 Millisekunden die richtige Antwortzeit sind, oder 500.

Ich habe sogar einige Artikel über 300 dpi gelesen, weil das die Grenze der menschlichen Wahrnehmung ist.

Tatsächlich ist das sehr kontextabhängig.

Wenn ich Sie zum Beispiel nach Ihrem Namen frage, habe ich eine Erwartung, wie lange es dauern wird, bis Sie antworten.

Wenn ich Sie nach dem Sinn des Lebens frage, erwarte ich eine ganz andere Antwortzeit.

Als wir Tests durchgeführt und die Nutzer gebeten haben, zu bewerten, ob sich diese Antwort schnell oder langsam angefühlt hat, waren die Ergebnisse sehr unterschiedlich.

Antworten, die lange dauerten, wurden als schnell bezeichnet und umgekehrt, weil es sich als sehr kontextabhängig herausstellte.

und wo sie sich in der Unterhaltung befanden.

In der Regel erwarten Nutzer, dass die allererste Antwort schneller ist als nachfolgende Antworten, da die KI Zeit zum Nachdenken benötigt.

Manchmal gibt es aber auch sehr kurze Hin- und Her-Nachrichten, sodass die Erwartungen steigen.

Es ist also keine exakte Wissenschaft, bei der es eine perfekte Zahl gibt, aber wir haben festgestellt, dass 1, 5 ein ziemlich guter Wert ist.

Wenn Sie also diese 1, 5 Sekunden erreicht haben, sollten Sie sich um die Konsistenz kümmern, oder?

Wenn das in 90 % der Fälle passiert, aber in 10 % der Fälle 3 Sekunden dauert, fühlt sich die Nutzung nicht nur schlecht, sondern fehlerhaft an.

Wenn Sie schnell genug sind, geht es nur noch um Konsistenz, also immer schnell, nicht nur meistens.

Devin Reimer

Hier sehen Sie eine Standardarchitektur für eine Sprachpipeline.

Wir nehmen also die Sprache-zu-Text-Ausgabe, senden sie an ein LLM und senden dann das Ergebnis des LLM zurück an Text-to-Speech.

Bei Speech-to-Text werden Audiodaten an den Server gesendet und dann in Text umgewandelt.

Auf der LLM-Seite wird dieser Text, dieser Antwortdialog, in einen Antwortdialog umgewandelt und dann werden die Aktionen festgelegt, die von diesem Charakter ausgeführt werden.

Wir koppeln diese eng, weil wir das für sehr wichtig halten.

Und auf der Text-to-Speech-Seite nehmen wir diesen Text, senden ihn an unseren Text-to-Speech-Dienst und streamen ihn an den Nutzer, ebenfalls zeitlich abgestimmt auf die Aktionen, die der Agent ausführen möchte.

Ein Problem dabei ist, dass die sequenzielle Ausführung ziemlich langsam sein kann, weil Sie jeden dieser Schritte einzeln durchgehen müssen.

Eine häufige Frage, die mir gestellt wird, ist: „Wenn das so langsam ist und drei Schritte erfordert, warum verwenden wir dann nicht einfach ein Speech-to-Speech-Modell?“

Das wäre doch schneller, oder?

Und ja, meistens wäre das schneller, weil Sie nur eine Sache ausführen.

Allerdings gibt es auch einige große Nachteile.

Es ist zwar schnell, aber es gibt einige große Nachteile für uns, vor allem die Kosten.

Im Allgemeinen ist die Ausführung eines Speech-to-Speech-Modells etwa drei- bis fünfmal so teuer wie dieser parallelisierte Ansatz.

Für uns ist das wirtschaftlich einfach nicht machbar.

In Bezug auf die Sicherheit ist es tatsächlich etwas schwieriger, da es schwieriger ist, die Antwort des KI-Agenten zu validieren, bevor er sie gesagt hat.

Wenn Sie jedoch einen Pipeline-Ansatz verwenden, können Sie die Antwort des LLM direkt validieren und auf Sicherheit prüfen, bevor Sie sie an einen Nutzer senden.

Beim Sprachstil sind Sie an die Voreinstellungen des Speech-to-Speech-Modells gebunden.

Du kannst nicht sagen: „Weißt du was?

Für diesen Fall möchte ich wirklich diese Art von Stimme verwenden.“

Sie sind also an diese bestimmte Version gebunden.

Beim Pipeline-Ansatz können Sie sagen: „Oh, ich werde das ändern.

Ich wähle dieses Modell, weil es für diesen speziellen Anwendungsfall sehr gut geeignet ist.“

Und das Gleiche gilt für Intelligenz, oder?

Wenn Sie ein wirklich gutes Speech-to-Speech-Modell haben, das eine gute Stimme erzeugt, aber die Intelligenz nicht ganz Ihren Vorstellungen entspricht, können Sie das nicht einfach austauschen, oder?

Sie sind also gewissermaßen an das System gebunden.

Beim Pipeline-Ansatz sagen Sie: „Für diesen Anwendungsfall möchte ich ein bestimmtes Modell verwenden.“

Ein Bereich, in dem Speech-to-Speech definitiv punktet, ist das Verständnis des Tons des Nutzers.

Zum Beispiel Sarkasmus und Ähnliches.

Derzeit enthalten Sprache-zu-Text-Transkriptionen im Allgemeinen nicht viele dieser Informationen, aber ich denke, das wird sich im Laufe der Zeit ändern.

Das ist definitiv ein Pluspunkt für Speech-to-Speech.

Speech-to-Speech hat also definitiv einen Vorteil, was die Geschwindigkeit angeht, aber es gibt auch einige Herausforderungen, was die Konfigurierbarkeit angeht, und die hohen Kosten waren für uns einfach ein Ausschlusskriterium.

Gibt es also eine andere Möglichkeit?

Ja.

Wir sollten unser Bestes tun, um die Pipeline zu parallelisieren.

Wir führen das LLM also aus, bevor die Sprache-zu-Text-Funktion die Eingabe vollständig verarbeitet hat.

Mit Konfidenz meine ich die Konfidenz in die Wörter, die im Transkript generiert werden, und die Konfidenz des Endes des Redebeitrags.

Sobald wir also glauben, dass der Nutzer aufgehört hat zu sprechen, und wir wissen, was er gesagt hat, machen wir weiter.

Das Worst-Case-Szenario ist, dass wir falsch liegen, oder?

Der Nutzer spricht weiter.

Aber selbst in diesem Szenario brechen wir das LLM nur ab und führen es dann noch einmal aus.

Und da der Kontext wahrscheinlich im Cache gespeichert wird und wir nicht so viele Tokens generiert haben, ist das nicht mit hohen Kosten verbunden. Der Vorteil ist, dass der Nutzer die Antwort schneller hört, als wenn Sie auf die vollständige Konfidenz warten würden.

Wir warten auch nicht, bis das LLM die gesamte Antwort generiert hat, bevor wir sie an Text-to-Speech senden.

Wir warten auf den ersten sprechbaren Teil.

In den meisten Fällen ist es ein Satz.

Manchmal sind es auch andere Konfigurationen, aber sobald wir den ersten Satzteil haben, senden wir ihn an Text-to-Speech.

Und wenn wir dann ein gutes Text-to-Speech-Modell haben, das streamen kann, sobald es bereit ist, kann das an den Nutzer gesendet werden.

Wir achten auch sehr genau auf die Anzahl der Tokens, die generiert werden müssen.

Wir verwenden also keine JSON-Wrapper und ähnliche Dinge, die zusätzliche Tokens hinzufügen könnten.

Wir versuchen, die einfachste Struktur zu finden, um die schnellste Antwort zu erhalten.

Wir verwenden auch Funktionen wie die Vorabausfüllung durch den Assistenten, wenn wir im Voraus wissen, wie der erste Token-Block des Agents aussehen wird.

Für die Text-zu-Sprache-Funktion waren es diese beiden Blöcke, richtig?

Der erste sprechbare Block wird also geladen und dann wird alles andere ausgeführt.

Da die Wiedergabe von Audioinhalten jedoch länger dauert als die Generierung, ist der erste Block fast immer fertig abgespielt, wenn der zweite Block fertig ist.

Das ist für den Nutzer also unsichtbar.

Es kommt so schnell wie möglich.

Wenn Sie also verschiedene Dienste auswählen, sollten Sie die folgenden Faustregeln beachten.

Bei der Auswahl eines guten Audio- und Agenten-Frameworks ist die geringste Latenz beim Ein- und Ausgang entscheidend.

Wie schnell kann ich also Daten hoch- und herunterladen?

Bei der Sprache-zu-Text-Funktion ist die Zeit bis zur Konfidenz wichtig.

Das ist die Konfidenz in das Transkript und die Konfidenz in das Ende des Turns.

Die gehören zusammen, oder?

Wenn Sie nicht schnell Vertrauen in eine Lösung haben, wird es einfach so langsam sein, oder?

Die Geschwindigkeit wird also durch die langsamste Komponente bestimmt.

Auf der LLM-Seite ist die Zeit bis zum ersten Satz, also dem ersten sprechbaren Block, wichtig.

Das sind also zwei Teile, richtig?

Das ist die Zeit bis zum ersten Token kombiniert mit den Tokens pro Sekunde.

Wenn Sie also plötzlich ein wirklich gutes Modell finden, das eine sehr gute Zeit bis zum ersten Token bietet, aber langsam bei den Tokens pro Sekunde ist, könnte das schlechter sein als die Alternative.

Finde also heraus, welche Kombination dafür am besten geeignet ist.

Und bei der Text-zu-Sprache-Funktion ist die Zeit bis zur ersten Audioausgabe wichtig.

Deshalb ist es sehr wichtig, die Latenz zu messen, da Audio manchmal mit einer führenden Stille zurückgegeben wird, die der Nutzer nicht hört.

Sie müssen also tatsächlich bis zu dem Punkt messen, an dem der Nutzer etwas hört.

Und wie bereits erwähnt, ist Ihnen vor allem die Stabilität wichtig, nicht die Höchstgeschwindigkeit oder das Best-Case-Szenario.

Wie hoch ist die konsistente Latenz dieses gesamten Stacks?

Devin Reimer

Derzeit verwenden wir für unsere Audio-Agenten-Frameworks LiveKit.

Für Sprache-zu-Text verwenden wir Deepgram.

Als LLM verwenden wir Gemma 4 31B, das auf LiveKit gehostet wird.

Für die Sprachausgabe verwenden wir Inworld AI Text-to-Speech 2.

Darüber hinaus haben wir unser gesamtes AstroBeam-KI-Agenten-Framework entwickelt, das nicht nur alles miteinander verbindet, sondern auch alle Komponenten hinzufügt, die für einen wirklich guten Sprach-Agenten erforderlich sind, insbesondere einen, der wie unser Agent für Spiele hochgradig interaktiv ist.

Ein Thema, das ich noch nicht angesprochen habe, sind Sicherheitsmodelle.

Sicherheitsmodelle sind also traditionell Teil des LLM-Durchlaufs, was jedoch die Latenz erhöht und einen zusätzlichen Schritt erfordert.

Was wäre, wenn Sie stattdessen Ihre eigene Instanz ausführen?

So sieht unser Stack also tatsächlich aus.

Wenn wir den ersten Textblock zurückerhalten, der an die Text-zu-Sprache-Funktion gesendet werden soll, senden wir ihn gleichzeitig an unser Sicherheitsmodell.

Und da das Sicherheitsmodell kleiner ist und schneller ausgeführt wird als die Sprache-zu-Text-Seite, wird es fast immer im Voraus ausgeführt.

Das bedeutet, dass das Hinzufügen eines Sicherheitsmodells keine Latenz in unseren Stack bringt. Und noch besser: Das ist ein so großer Teil, dass wir ein viel größeres Sicherheitsmodell ausführen können, als die meisten Leute überhaupt in Betracht ziehen.

Das ist für uns besonders wichtig, weil wir Spiele entwickeln.

Es gibt so viel Kontext in dieser Welt, der superwichtig ist.

Angenommen, Sie entwickeln ein mittelalterliches Spiel und haben einen NPC, der „Angriff!“ ruft.

Kopf ab!“, oder?

Ein herkömmliches Sicherheitsmodell würde vielleicht sagen: „Das ist nicht cool.

Das solltest du nicht sagen.“

Im Kontext dieses Spiels ergibt das aber durchaus Sinn.

Dazu verwenden wir ein robusteres Sicherheitsmodell mit viel mehr Kontext zu dem, was in der Welt passiert.

Sie werden vielleicht bemerken, dass wir das Sicherheitsmodell zweimal ausführen: einmal für den ersten Block und dann noch einmal für das gesamte Ergebnis, wenn wir den letzten Block haben.

Auch hier müssen wir es zweimal ausführen, aber es wird keine Latenz zum Stack hinzugefügt.

Wir sind jetzt also schnell genug, aber das nützt uns nichts, wenn wir nicht schlau genug sind.

Devin Reimer

Wie intelligent muss es also sein?

Sie muss intelligent genug für Ihre Nutzer sein, aber fast noch wichtiger ist, dass sie intelligent genug für Sie ist, um damit zu entwickeln.

Das ist oft etwas, worüber die Leute nicht nachdenken, wenn sie auswählen, was sie hier für die Intelligenz brauchen.

Wir arbeiten jetzt seit etwa drei Jahren an Sprach-Agents. Am Anfang haben wir zum Beispiel einige frühe LLaMA-Modelle verwendet. Wir konnten sie zwar für Nutzer zum Laufen bringen, aber die Entwicklung war sehr teuer, weil alles sehr instabil war.

Es war nicht schwer, die Modelle dazu zu bringen, unerwünschte Antworten oder Dinge zu generieren, die einfach keinen Sinn ergaben. Wir haben also viel Entwicklungsarbeit investiert, um das zu verhindern.

Das hat für uns Priorität, denn wenn wir diese Dinge nicht schnell entwickeln können, können wir sie auch nicht für die Nutzer bereitstellen.

Es ist also sehr wichtig, über beides nachzudenken.

Wenn Menschen an Intelligenz denken, denken sie oft an das LLM, oder?

Aber das ist nur ein Teil davon.

Wir müssen jeden Aspekt berücksichtigen, wenn es um Intelligenz geht.

Sprechen wir also über die Speech-to-Text-Intelligenz.

Hier ist also eine niedrige Wortfehlerrate wichtig.

Und es ist nicht nur so, dass die Fehlerrate niedrig ist, sondern auch, dass wir, wenn es passiert, etwas generieren, das dem tatsächlichen Ding sehr nahe kommt. Denn wenn es wirklich nahe ist, kann das LLM oft mit Kontext sehr gut verstehen, was es ist.

Wenn die Fehlerrate niedrig ist, aber die Anzahl der Fehltritte sehr hoch, wird es dem LLM viel schwerer fallen, die tatsächliche Absicht zu erkennen.

Außerdem sollten Sie sich Gedanken über die Zielplattform machen.

Wenn ich beispielsweise für XR entwickle und Mikrofone habe, die sich sehr nah am Mund des Nutzers befinden, erhalte ich sehr gute, hochwertige Audiodaten, die für bestimmte Modelle sehr gut funktionieren könnten.

Wenn ich aber plötzlich eine App für ein Smartphone entwickle, das auf einer belebten Straße verwendet wird, hat das ganz andere Auswirkungen. Verschiedene Modelle verhalten sich unterschiedlich und können auf verschiedene Weise intelligent auf das Gesagte reagieren.

Sie müssen also darüber nachdenken und sicherstellen, dass Sie die richtige Plattform auswählen, für die Sie entwickeln.

Kommen wir nun zur Text-zu-Sprache-Funktion.

Klingt es natürlich?

Unser Ziel ist es, dem Nutzer zu vermitteln, was er verstehen kann.

Aber das ist nur ein Teil davon, oder?

Die Ausdrucksfähigkeit des Agenten ist ebenfalls sehr wichtig, da sie Informationen vermittelt. In unseren Tests haben wir festgestellt, dass Nutzer die Agenten umso intelligenter fanden, je ausdrucksstärker sie waren. Das ergibt Sinn.

Und ist es schnell genug?

Im vorherigen Abschnitt habe ich über Latenz gesprochen, aber sie ist auch hier für die wahrgenommene Intelligenz wichtig.

Nutzer nehmen die Geschwindigkeit der Antwort direkt im Zusammenhang mit der tatsächlichen Intelligenz wahr.

Wenn ich schnell antworte, klingt das wahrscheinlich intelligenter.

Diese Dinge können also wirklich wichtig sein, wenn es darum geht, wie der Nutzer die Erfahrung wahrnimmt und wie sehr er in die Erfahrung eintauchen kann.

Kommen wir nun zur LLM-Seite der Intelligenz.

Das ist bei Weitem am schwierigsten, weil es so viele verschiedene Anforderungen gibt.

Wir haben also Sprachverständnis, Kontext und Fundierung.

In Spielen ist das besonders schwierig, weil man eine ganze Welt und ein ganzes Universum erschaffen muss, oder?

Es ist kein Textfeld, in dem es sich Dinge ausdenken kann, die passieren.

Wenn Ihr Agent in einem Spiel sagt: „Auf dem Tisch liegt ein Apfel“, und auf dem Tisch liegt kein Apfel, wird das die Nutzererfahrung beeinträchtigen.

Wir brauchen auch Dinge wie eine strikte Einhaltung von Regeln.

Spiele sind sehr regelbasiert.

Kann das LLM damit umgehen?

Können wir eine niedrige Halluzinationsrate erreichen?

Können wir konsistente Charaktere haben, wenn wir immer wieder mit demselben Agenten interagieren?

Haben Sie das Gefühl, dass es sich um denselben Agenten handelt?

Und dann ein Problem, das Sie vielleicht überrascht, weil es zu Beginn der Entwicklung kein Problem ist: Kann Ihr Modell mit der wachsenden Prompt-Größe umgehen?

Denn im Laufe der Entwicklung werden Sie unweigerlich mehr Inhalte in den Prompt einfügen.

Wenn die Nutzer dann weiterspielen, wird der Chatverlauf im Prompt immer länger.

Kann der Prompt mit diesem Wachstum umgehen?

Denn bei bestimmten Modellen kann es vorkommen, dass die Qualität der Antwort mit zunehmender Länge des Prompts abnimmt. Sie müssen also herausfinden, was Sie tatsächlich benötigen und wie viel Informationen jedes Mal in den Prompt einfließen müssen.

Aber das ist nur die Spitze des Eisbergs und hängt auch davon ab, was Sie entwickeln.

Sie müssen sich also genau überlegen, was Sie entwickeln und was Sie erreichen möchten.

Wir sind also schnell und intelligent genug, aber das alles nützt nichts, wenn es zu teuer ist.

Devin Reimer

Wie günstig muss es also sein?

Leider ist es etwas komplizierter.

Wir müssen also über die Wirtschaftlichkeit der App oder des Spiels nachdenken, das wir entwickeln, oder?

Hier sind einige Fragen, die Sie sich stellen sollten.

Wie lange werden Nutzer mit Ihren Sprach-Agents interagieren?

Wie viel verdienen Sie pro Nutzer?

Und wie viel kostet der Betrieb dieses Voice-Stacks pro Stunde?

Wir setzen sie zusammen, um herauszufinden, ob sie Sinn ergeben.

Hier ist die Wirtschaft unseres ersten Spiels, Stellar Cafe.

Die Spielzeit in Stellar Cafe liegt also zwischen 1,5 und 3,5 Stunden. Nehmen wir also einen Durchschnitt von etwa 2 Stunden an.

Die Kosten für den Betrieb von Sprach-Agents belaufen sich auf etwa 1,20 $ pro Stunde und Nutzer, und die Nutzer interagieren die ganze Zeit damit.

Es ist ein Spiel, das zu 100 % sprachgesteuert ist.

Wir verlangen eine Pauschalgebühr von 10 $ für das Spiel, was traditionell ist.

Wir bieten keine Abos an, weil das bei Spielen sehr schwierig ist. Ich bin der festen Überzeugung, dass wir es zu einem Pauschalpreis anbieten müssen, sonst funktioniert es einfach nicht und lässt sich nicht skalieren.

Früher haben wir 15 $ berechnet, aber wir haben daran gearbeitet, die Serverkosten zu senken, sodass wir jetzt nur noch 10 $ berechnen.

Und diese 1, 20 $ sind der aktuelle Stand.

Das ist kein universeller Preis.

Ich habe diese Dinge schon zu sehr unterschiedlichen Preisen gesehen, manchmal auch viel teurer.

Sie müssen also auch herausfinden, wo Sie sich auf der Kostenseite befinden.

Wir könnten die Preise senken, aber wir versuchen, unsere Qualitätsstandards so hoch wie möglich zu halten.

Wenn wir das alles durchrechnen, bedeutet das, dass bei einer Spielzeit von 2 Stunden unser Voice Stack etwa 2, 40 $ pro Nutzer kostet.

Da wir 10 $ verlangen und der Store eine Gebühr erhebt, verdienen wir etwa 4,59 $ pro Nutzer, richtig?

Und so funktioniert die Wirtschaft, oder?

Die Stimme ist unser Aufhänger, dafür wollen wir Geld ausgeben, das funktioniert.

Das ist also ein sehr kleines Spiel.

Lassen Sie uns über etwas Größeres sprechen.

Nehmen wir ein hypothetisches Spiel, ein narratives Spiel, das zwischen 5 und 9 Stunden dauert, also im Durchschnitt 7 Stunden.

In Wirklichkeit spielen die meisten Leute Spiele nicht zu Ende. Sie spielen ein bisschen und hören dann auf. Ich möchte aber einen etwas höheren Wert wählen, damit die Wirtschaftlichkeit noch gegeben ist.

Wir behalten also die 1, 20 $ pro Stunde bei, aber wir ändern die Nutzung der Sprachkomponente auf 60 % der Zeit, da ein größeres Spiel viel mehr Mechaniken als nur Sprache hat.

Es wird also weiterhin ein sehr sprachgesteuertes Spiel sein, aber es wird auch andere Funktionen haben.

Wenn wir also 20 $ verlangen, kostet uns das etwa 5 $ pro Nutzer, was bedeutet, dass wir am Ende des Tages etwa 9 $ pro Nutzer verdienen.

Auch hier funktioniert die Wirtschaftlichkeit.

Das bedeutet nicht, dass die Wirtschaftlichkeit für alles gegeben ist.

Ein Beispiel für etwas, das Sie nicht tun sollten: „Ich möchte ein Free-to-Play-Spiel entwickeln, das Nutzer wahrscheinlich zwischen 1 Stunde und über 100 Stunden spielen werden.“

Nehmen wir also einen Durchschnitt von 10 Stunden an.

Es ist zu 100 % sprachgesteuert. Nehmen wir an, wir haben einen Hit und das Spiel generiert etwa 3 $ pro Nutzer. Das wäre für ein Free-to-Play-Spiel ziemlich gut.

Sie würden 10 $ pro Nutzer verlieren.

Es funktioniert also noch nicht für alle diese Dinge. Sie müssen sich überlegen, was Sie gerade entwickeln und ob es Sinn ergibt.

Warten Sie nicht bis zum Ende, um die Wirtschaftlichkeit zu ermitteln.

Devin Reimer

Die nächste Frage, die sich stellt, ist: Was ist mit lokalen Modellen?

Wenn die Kosten ein so großes Problem sind, würden lokale Modelle dieses Problem dann nicht beseitigen?

Und ja, das wäre es.

Aber es gibt einige Kompromisse, die wir berücksichtigen müssen.

Kostenseitig würden wir die Serverrechnung eliminieren, was ein großer Vorteil wäre und viele neue Möglichkeiten eröffnen würde.

Aber es gibt viele Dinge, die die Cloud derzeit lösen kann, mit denen lokale Systeme Probleme haben.

Beispiel: Compute.

Oft sagen die Leute: „Schau mal, ich habe dieses wirklich gute Speech-to-Text-Modell gefunden, und es läuft lokal auf diesem Gerät, oder?“

Das ist gut, aber wir müssen bedenken, dass nicht nur ein Modell ausgeführt wird, sondern mehrere, oder?

In unserem Fall sind es vier, möglicherweise gleichzeitig. Es reicht also nicht, dass etwas einmal ausgeführt wird, sondern es muss mehrmals gleichzeitig ausgeführt werden.

Und wenn Sie das geschafft haben, bleibt dann noch etwas übrig, damit Ihr Spiel oder Ihre Anwendung ausgeführt werden kann?

Wenn die GPU ausgelastet ist, können Sie nicht wirklich ein Videospiel rendern.

Nehmen wir an, Sie haben diese Herausforderungen gemeistert.

Der nächste Punkt ist die Geschwindigkeit.

Oft kann man sie zwar zum Laufen bringen, aber sie sind dann sehr langsam und es fühlt sich eher wie Prompting als wie eine echte Echtzeit-Unterhaltung an.

Theoretisch hat es also einen Vorteil, wenn die Daten lokal gespeichert werden, da sie nicht aus dem Internet abgerufen werden müssen.

Es ist derzeit eine Herausforderung, Modelle zu finden, die mit der richtigen Geschwindigkeit laufen, damit das funktioniert.

Angenommen, Sie haben die Rechenleistung und die Geschwindigkeit im Griff. Jetzt müssen wir uns Gedanken über die Qualität machen, oder?

Da Sie die Anwendung auf einem lokalen Gerät ausführen, verwenden Sie in der Regel ein kleineres LLM, z. B. eine einfachere Text-zu-Sprache-Funktion. Das kann bei der Erstellung von Inhalten zu Herausforderungen führen.

Wie bereits erwähnt, sollten Sie sich bei der Auswahl eines LLM nicht nur fragen, ob es gut genug für Ihre Nutzer ist, sondern auch, ob es gut genug für Ihre Entwicklung ist.

Wenn es also sehr schwierig ist, mit diesem Modell etwas zu entwickeln, sollten Sie sich das auf jeden Fall überlegen.

Angenommen, Sie haben die Rechenleistung, die Geschwindigkeit und die Qualität im Griff. Als Nächstes kommt die Portabilität.

Wenn Sie gewinnen und den gesamten Prozess durchlaufen und das Ding auf einer RTX 5070 zum Laufen bringen, ist das möglicherweise der einzige Ort, an dem es ausgeführt werden kann.

Wenn sich also die Gelegenheit ergibt, das Spiel auf eine neue Plattform zu bringen, stecken Sie möglicherweise fest.

Für die Cloud-Seite benötigen Sie lediglich eine Internetverbindung.

Das ist also ein großer Vorteil.

Ermöglicht das Streamen auf mehreren Plattformen.

Als Nächstes sprechen wir über einen hybriden Ansatz.

Wir führen also einige Dinge in der Cloud und andere lokal aus.

Könnte das funktionieren?

Nun, das ist kein so großer Gewinn, wie Sie vielleicht denken.

Wenn Sie also ein Modell erhalten, das klein genug ist, um auf den meisten lokalen Plattformen ausgeführt zu werden, und Sie dieses Modell in der Cloud ausführen, kostet es Sie wahrscheinlich nur ein paar Cent.

Und so ist es im Allgemeinen so, dass Sie erst dann die größten Erfolge erzielen, wenn Sie den gesamten Stack gelöst haben.

Als Nächstes wird oft gefragt, ob man die Modelle nicht auch lokal ausführen kann, wenn das möglich ist.

Sie haben die richtige Hardware und in der Cloud, wenn Sie sie nicht haben, richtig?

Sie könnten etwas Leistungsstärkeres in der Cloud ausführen.

Das bringt neue Herausforderungen mit sich, oder?

Wenn Sie am Ende ein anderes Modell ausführen, kann sich das erheblich auf die Entwicklung auswirken.

Und am Ende müssen Sie trotzdem viel Zeit in die Mindestspezifikationen investieren.

Und Sie könnten Modelle haben, die sich ganz unterschiedlich verhalten.

Wenn Sie also nicht genau dieselben Modelle verwenden, kann das zu einem erheblichen Entwicklungsaufwand und hohen Kosten führen.

Es ist also wichtig, sich zu überlegen, was man erreichen möchte. Denn selbst wenn man das herausgefunden hat und eine gute lokale Lösung hat, wenn es nötig ist, und eine Cloud-Lösung, wenn nicht, muss die Wirtschaftlichkeit für das Cloud-Modell immer noch stimmen.

Denn wenn plötzlich alle Ihre Nutzer in der Cloud sind, werden Sie verlieren, wenn Sie das nicht aus wirtschaftlicher Sicht bedacht haben.

Lokale Modelle sind also definitiv ein großer wirtschaftlicher Gewinn, aber wir stehen noch am Anfang.

Bei preissensitiven Anwendungen wie Spielen wird es sich meiner Meinung nach wahrscheinlich durchsetzen.

Heute ist das außerhalb von spezifischeren Anwendungsfällen, insbesondere bei befehlsbasierten Dingen, etwas schwierig.

Wir möchten also heute die bestmögliche Erfahrung bieten.

Deshalb verwenden wir die Cloud.

Aber das ist ein sehr schnelllebiger Bereich und die Dinge ändern sich rasant.

Als Nächstes sollten wir uns Gedanken über die Modelle machen, die wir verwenden.

Die nächste Frage ist: Open Weights oder Closed Weights?

Was sollten wir hier tun?

Ich möchte mich hier auf LLMs konzentrieren, da wir festgestellt haben, dass dieser Bereich am stärksten von der Frage „Open Source oder proprietär?“ betroffen ist.

Es gibt also definitiv Vor- und Nachteile.

Bei geschlossenen Modellen mit Gewichtungen handelt es sich im Allgemeinen um Frontier-Intelligence, richtig?

Wenn Sie also die meisten Informationen benötigen, ist dies oft die richtige Wahl.

Auf der offenen Seite hinken sie dagegen oft eine Generation hinterher.

Das kann also ein echter Kompromiss sein.

In Bezug auf die Geschwindigkeit habe ich erwähnt, dass mir die Zeit bis zum ersten Satz sehr wichtig ist.

Wir haben festgestellt, dass die Geschwindigkeit von geschlossenen Modellen im Laufe ihrer Lebensdauer oft abnimmt.

Dafür kann es viele Gründe geben.

Vielleicht verwenden mehr Personen das Modell oder die Hardware wurde auf ein neueres Modell umgestellt.

Aber es ist uns aufgefallen.

Sie müssen also vorsichtig sein, denn es kann ein Problem verursachen, wenn Sie etwas versenden, das großartig ist, aber im Laufe der Zeit unbrauchbar wird.

Als Nächstes kommen Spitzen.

Diese Art von Konsistenz ist Ihnen sehr wichtig. Daher sind die geschlossenen Modelle oft auf die Batchverarbeitung in asynchronen Aufgaben ausgelegt, nicht auf P99-Latenzen. Auf der offenen Seite können Sie einen Anbieter auswählen, der sich um genau das kümmert, was Ihnen wichtig ist, um Ihnen die Zuverlässigkeit, Geschwindigkeit und Latenz zu bieten, die Sie letztendlich benötigen.

Als Nächstes folgt die Lebensdauer des Modells selbst.

Geschlossene Modelle werden oft nach etwa einem Jahr eingestellt.

Wenn Sie also ein Jahr lang etwas entwickeln und erwarten, dass es drei Jahre lang in der Produktion ist, könnten Sie mehr als drei Modelländerungen durchlaufen.

Und nur weil ein Modell besser ist, bedeutet das nicht, dass es für Sie besser funktioniert.

In den letzten drei Jahren haben wir viele Modelländerungen vorgenommen. Oft dauert es Wochen, manchmal Monate, bis alles umgestellt ist. Bei offenen Modellen können Sie das Modell so lange weiter ausführen, wie jemand bereit ist, es zu hosten, oder Sie es selbst hosten möchten.

Der letzte Punkt sind die Kosten.

Oft sind diese geschlossenen Modelle im Laufe der Zeit, wenn neue Versionen veröffentlicht werden, teurer als die vorherigen.

Auch das ist ein wichtiger Aspekt, den Sie im Auge behalten sollten: Ihre Wirtschaftlichkeit kann beim Start gut sein, aber dann nicht mehr, wenn Sie Modelle migrieren.

Auf der offenen Seite haben Sie die Flexibilität, es zu verschieben, und die Wahrscheinlichkeit, dass es sich drastisch erhöht, ist gering, da es sich um genau dasselbe Modell handelt.

Wir verwenden Gemma 4 31B. Das war ein großer Durchbruch für uns, weil es die beste Kombination aus Geschwindigkeit, Intelligenz und Kosten ist.

Außerdem konnten wir sehr schnell vorankommen.

Die Entwicklung ist damit viel einfacher als mit einigen anderen Tools, die wir zuvor verwendet haben.

Das bedeutet nicht, dass wir nur diese verwenden.

Wir verwenden viele Kombinationen aus verschiedenen offenen und geschlossenen Modellen.

Dazu gehören beispielsweise die Erstellung von Informationen, die sich Gemini merken soll, sowie Sicherheits- und Anpassungsfunktionen.

Es ist einfach wichtig, das beste Modell für Ihre speziellen Anforderungen bei dieser Aufgabe auszuwählen.

Gemma 4 31B ist unser Arbeitstier, wenn es um Sprach-Agenten geht.

Bei diesen Unterschieden zwischen den beiden bieten offene Modelle definitiv mehr Kontrolle und ermöglichen es Ihnen, Modelle so lange zu behalten, wie sie zu vorhersehbaren Kosten gehostet werden können.

Und Ihr Zeitplan wird nicht durch die Einstellung eines Modells beeinträchtigt.

Devin Reimer

Zusammenfassend geht es also darum, diese drei Dinge in Einklang zu bringen, richtig?

Bei der Latenz versuchen wir, den Streaming-Aspekt, den parallelen Aspekt, die Geschwindigkeit und die Konsistenz in Einklang zu bringen.

In Sachen Intelligenz ist es smart genug für die Nutzer und smart genug, um damit zu entwickeln.

In Bezug auf die Kosten müssen wir wissen, wie viel es pro Nutzer kosten wird und wie viel wir pro Nutzer verdienen können, damit wir sicherstellen können, dass die Wirtschaftlichkeit stimmt.

Entwickeln Sie nicht erst ein Produkt und machen Sie sich dann Gedanken über die Wirtschaftlichkeit.

Denken Sie von Anfang an darüber nach.

Es ist also noch sehr früh, aber die wirtschaftlichen Aspekte funktionieren bereits.

Günstigere Modelle sind definitiv besser, intelligentere Modelle sind definitiv besser.

Aber schon heute können wir an den wirklich schwierigen Herausforderungen arbeiten, die wir bewältigen müssen, damit Sprach-Agenten überall eingesetzt werden können.

Ich freue mich sehr, diese leistungsstarken Sprach-Agents für alle verfügbar zu machen.

Vielen Dank.