Équilibrer la latence ultra-faible et les avantages économiques du cloud dans les agents vocaux virtuels

Devin Reimer

Bienvenue dans le cours "Équilibrer la latence ultra-faible et l'économie du cloud dans les agents vocaux virtuels".

Je m'appelle Devin Reimer.

Je suis le fondateur et PDG d'AstroBeam.

Auparavant, j'étais PDG et cofondateur d'Owlchemy Labs, un studio surtout connu pour Job Simulator.

Chez AstroBeam, nous nous concentrons sur l'intégration de l'IA en temps réel dans les jeux.

Plus précisément, nous nous concentrons sur la voix comme entrée.

Nous avons sorti deux titres jusqu'à présent : Stellar Cafe, qui est disponible sur RV et PC,

C'est un jeu dans lequel vous parlez à des robots dans le café d'une station spatiale et les aidez à résoudre leurs problèmes.

Il est 100 % contrôlé par la voix.

Vous jouez à l'intégralité du jeu, y compris les menus et la navigation, uniquement avec votre voix.

Notre prochain jeu, que nous venons d'annoncer aujourd'hui, Robo Detective, est conçu pour Android XR et plus particulièrement pour le Project Aura de XREAL.

Dans ce jeu, vous incarnez un détective qui travaille avec un partenaire robot pour interroger des robots et résoudre des crimes robotiques. Là encore, le jeu est entièrement contrôlé par la voix.

Les agents vocaux sont donc très difficiles à créer, et encore plus dans les jeux.

En effet, les jeux sont très peu coûteux, et un agent vocal représente un nouveau coût à ajouter à ce pipeline.

De plus, nous ne sommes pas en concurrence avec d'autres agents vocaux, mais avec la qualité de tous les jeux jamais créés, n'est-ce pas ?

Nous devons donc proposer un produit de très haute qualité.

Cela ne veut pas dire qu'il n'existe pas de cas d'utilisation d'agents vocaux spécifiques qui présentent des défis uniques ou des enjeux beaucoup plus importants, mais les jeux sont sans aucun doute très complexes sur le plan technique dans ce domaine.

Mais comme il s'agit de jeux, cela laisse aussi beaucoup de place à l'expérimentation pour résoudre certains de ces problèmes complexes.

Je pense donc que si les agents vocaux peuvent fonctionner dans les jeux, ils peuvent fonctionner presque n'importe où.

Ainsi, les applications… les choses dont je parle dans cette présentation ne s'appliquent pas seulement aux jeux, mais à toutes les applications vocales que vous souhaitez créer.

Quand on pense aux agents vocaux, on pense à trois défis principaux.

Nous avons donc la latence, l'intelligence et le coût.

Je tiens toutefois à préciser que lorsque je parle d'agents vocaux, je parle d'agents vocaux en tant que conversation, et non en tant que prompt.

Je ne parle pas d'un wrapper de micro qui envoie quelque chose à un LLM, puis attend une réponse.

Je parle d'un échange en temps réel, comme dans le monde réel, et c'est en fait ce qui devient assez difficile à créer.

Commençons par la latence.

À quelle vitesse doit-il être ?

Il s'avère qu'il doit être rapide, très rapide, mais selon ce que vous avez lu, il n'est peut-être pas aussi rapide que vous le pensez, ou il est peut-être beaucoup plus rapide que vous ne le pensez.

Parlons maintenant de quelques chiffres que nous avons découverts lors de nos nombreux tests.

Quand je parle de latence de bout en bout, je parle du temps qui s'écoule entre le dernier énoncé de l'utilisateur, le dernier son qu'il a émis, et le moment où il entend la réponse audio.

Lors de nos tests, nous avons constaté que lorsque nous obtenons des commentaires de la part des utilisateurs, ils ne mentionnent plus la vitesse ou la lenteur à partir de 1,5 seconde.

C'est à ce moment-là que les gens commencent à se sentir vraiment à l'aise.

Dès que nous sommes beaucoup plus lents que cela, les gens nous disent souvent : "C'est génial, mais…". Cela semble donc être un bon compromis.

Ensuite, lorsque vous devenez encore plus rapide, nous avons découvert qu'à environ 1,2 seconde, des échanges plus naturels commencent à se produire.

Par exemple, je dis quelque chose, et dans ce cas, le robot répond très rapidement, et vous échangez ainsi de suite.

Il semble y avoir un juste milieu qui est débloqué.

Cela dit, 1,2 seconde est un délai assez difficile à atteindre dans une pile.

Autre découverte intéressante : nous avons effectué de nombreux tests et avons fini par obtenir des scénarios de moins d'une seconde.

Vous vous dites peut-être : "Oh, ça va être génial !"

Et parfois, c'était le cas, et parfois, c'était terrible, très étrange.

Vous entendrez peut-être des gens dire qu'un temps de réponse de 800 millisecondes est le bon chiffre, ou de 500.

J'ai même lu plusieurs articles sur 300, car c'est là que se situe la perception humaine.

En réalité, cela dépend énormément du contexte.

Par exemple, si je vous demande votre nom, je m'attends à ce que vous me répondiez dans un certain délai.

Si je vous demande quel est le sens de la vie, je m'attends à un délai d'exécution très différent.

Lorsque nous avons effectué des tests et demandé aux utilisateurs d'évaluer si cette réponse leur semblait rapide ou lente, les chiffres étaient très variables.

Les réponses qui prenaient beaucoup de temps étaient considérées comme rapides, et inversement, car cela dépendait fortement du contexte.

et où ils en étaient dans la conversation.

En général, les utilisateurs s'attendent à ce que la toute première réponse soit plus rapide que les suivantes, car il y a un temps de réflexion.

Mais parfois, vous finissez par avoir des échanges très courts, ce qui augmente vos attentes.

Il ne s'agit pas d'une science exacte avec un nombre parfait, mais nous avons découvert qu'un ratio d'environ 1,5 est un bon objectif.

Une fois que vous avez atteint ce seuil de 1,5 seconde, vous devez vraiment vous soucier de la cohérence.

En effet, si cela se produit 90 % du temps, mais que 10 % du temps, cela prend trois secondes, l'expérience semblera défectueuse, pas mauvaise, mais défectueuse.

Une fois que vous avez atteint une vitesse suffisante, vous ne vous souciez plus que de la cohérence, c'est-à-dire d'être rapide tout le temps, et pas seulement la plupart du temps.

Devin Reimer

Voici l'architecture d'un pipeline vocal standard.

Nous prenons donc notre Speech-to-Text, nous l'envoyons à un LLM, puis nous renvoyons le résultat du LLM à Text-to-Speech.

En d'autres termes, avec Speech-to-Text, nous envoyons du contenu audio au serveur, qui le convertit ensuite en texte.

Du côté du LLM, nous prenons ce texte, ce dialogue de réponse, ou nous le convertissons en dialogue de réponse, puis nous déterminons les actions que ce personnage va effectuer.

Nous les couplons étroitement, car nous pensons que c'est très important.

Ensuite, côté Text-to-Speech, nous prenons ce texte, nous l'envoyons à notre service Text-to-Speech et nous le diffusons à l'utilisateur, également en fonction des actions que l'agent souhaite effectuer.

L'un des problèmes de cette approche est que l'exécution séquentielle peut être assez lente, car vous devez passer par chacune de ces étapes.

On me demande souvent : "Si c'est lent et qu'il faut suivre trois étapes, pourquoi ne pas utiliser un modèle de reconnaissance vocale directe ?"

Parce que ce serait plus rapide, non ?

Et oui, la plupart du temps, ce serait plus rapide, car vous n'exécutez qu'une seule chose.

Mais cela s'accompagne de compromis importants.

Bien qu'il soit rapide, il présente des inconvénients majeurs pour nous, le plus important étant le coût.

En général, nous avons constaté qu'un modèle Speech-to-Speech est environ trois à cinq fois plus coûteux à exécuter que cette approche parallélisée.

Pour nous, l'aspect économique n'est tout simplement pas viable.

En ce qui concerne la sécurité, c'est un peu plus délicat, car il est plus difficile de valider la réponse de l'agent avant qu'il ne l'ait formulée.

Mais en attendant, si vous avez une approche par pipeline, vous pouvez prendre la réponse du LLM, la valider et vérifier sa sécurité avant même d'être sur le point de l'envoyer à un utilisateur.

Pour le style de voix, vous êtes limité aux préréglages du modèle Speech-to-Speech.

Vous ne pouvez pas vous dire : "Oh, vous savez quoi ?

Pour ce cas, je veux vraiment utiliser ce type de voix."

Vous êtes en quelque sorte coincé avec celui-ci.

Dans l'approche par pipeline, vous pouvez vous dire : "Oh, je vais changer de méthode.

Je vais choisir ce modèle, car il fonctionne très bien pour ce cas d'utilisation particulier."

Il en va de même pour l'intelligence, n'est-ce pas ?

Si vous disposez d'un très bon modèle de reconnaissance vocale qui produit une voix de qualité, mais que l'intelligence n'est pas tout à fait celle que vous souhaitez, vous ne pouvez pas simplement la remplacer, n'est-ce pas ?

Vous êtes en quelque sorte bloqué.

Dans l'approche par pipeline, vous vous dites : "Pour ce cas d'utilisation, je veux utiliser un modèle particulier."

Un domaine dans lequel la reconnaissance vocale l'emporte sans conteste est la compréhension du ton de l'utilisateur.

par exemple, le sarcasme.

Pour l'instant, les transcriptions de la reconnaissance vocale ne contiennent généralement pas beaucoup de ces informations, mais je pense que cela va changer au fil du temps.

C'est un point positif pour Speech-to-Speech.

La reconnaissance vocale présente donc un avantage certain en termes de rapidité, mais elle pose des problèmes de configurabilité, et son coût élevé, en particulier pour nous, était tout simplement rédhibitoire.

Existe-t-il une autre solution ?

Oui.

Nous devrions plutôt faire de notre mieux pour paralléliser le pipeline.

Nous exécutons donc le LLM avant que la reconnaissance vocale ne soit totalement fiable.

Par "confiance", j'entends la confiance dans les mots générés dans la transcription, puis la confiance dans la fin du tour de parole.

Dès que nous pensons que l'utilisateur a fini de parler et que nous avons compris ce qu'il a dit, nous anticipons.

Dans le pire des cas, nous nous trompons, n'est-ce pas ?

L'utilisateur continue de parler.

Mais même dans ce cas, nous nous contentons d'annuler le LLM, puis de l'exécuter à nouveau.

Comme le contexte sera probablement mis en cache et que nous n'avons pas généré beaucoup de jetons, cela ne coûte pas très cher. De plus, l'utilisateur entend les choses plus rapidement que si vous attendiez d'avoir une confiance totale.

De plus, nous n'attendons pas que le LLM ait fini de générer l'intégralité de sa réponse avant de commencer à l'envoyer à Text-to-Speech.

Nous attendons en quelque sorte le premier segment prononçable.

Dans la plupart des cas, il s'agit d'une phrase.

Il peut parfois s'agir d'autres configurations, mais dès que nous avons ce premier segment de phrase, nous l'envoyons à notre service Text-to-Speech.

Ensuite, si nous disposons d'un bon système de synthèse vocale qui diffuse le contenu dès qu'il est prêt, l'utilisateur peut en profiter.

Nous sommes également très attentifs au nombre de jetons à générer.

Nous n'utilisons donc pas d'éléments tels que des wrappers JSON, qui pourraient ajouter des jetons supplémentaires.

Nous essayons de trouver la structure la plus simple pour obtenir la réponse la plus rapide possible.

Nous utilisons également des fonctionnalités telles que le préremplissage de l'assistant si nous savons à l'avance quel sera le premier bloc de jetons de l'agent.

Pour la synthèse vocale, il s'agit de ces deux blocs.

Le premier segment prononçable est donc traité, puis tout le reste est exécuté.

Toutefois, comme l'écoute de la lecture audio prend plus de temps que la génération, la lecture du premier fragment sera presque toujours terminée avant que le deuxième fragment ne soit prêt.

Cette opération est donc invisible pour l'utilisateur.

Il arrive aussi vite que possible.

Voici quelques règles de base à suivre lorsque vous envisagez de choisir différents services.

Pour choisir un bon framework audio et d'agent, vous devez privilégier la latence la plus faible possible en entrée et en sortie.

À quelle vitesse puis-je envoyer et récupérer des données ?

En ce qui concerne la reconnaissance vocale, nous nous intéressons au temps nécessaire pour atteindre un niveau de confiance suffisant.

Il s'agit donc de la confiance dans la transcription et de la confiance dans la fin du tour de parole.

Ils sont associés, n'est-ce pas ?

Si vous n'avez pas rapidement confiance en l'un d'eux, le processus sera tout aussi lent, n'est-ce pas ?

La vitesse est donc limitée par le composant le plus lent.

Du côté du LLM, nous nous intéressons au délai avant la première phrase, c'est-à-dire au premier segment prononçable.

Il y a donc deux aspects.

Il s'agit du délai d'émission du premier jeton combiné au nombre de jetons par seconde.

Si vous trouvez soudainement un très bon modèle qui offre un excellent délai d'émission du premier jeton, mais qui est lent en termes de jetons par seconde, cela pourrait être pire que l'alternative.

Déterminez donc la bonne combinaison pour cela.

En ce qui concerne la synthèse vocale, vous devez vous intéresser au délai avant le premier audio.

Il est donc très important de mesurer cette latence, car l'audio peut parfois revenir avec un silence initial que l'utilisateur n'entendra pas.

Vous devez donc mesurer jusqu'au moment où l'utilisateur entend quelque chose.

Et comme je l'ai déjà mentionné, vous vous souciez avant tout de la stabilité, et non des vitesses de pointe ou du meilleur scénario possible.

Quelle est la latence constante de l'ensemble de cette pile ?

Devin Reimer

Actuellement, nous utilisons LiveKit pour nos frameworks d'agents audio.

Pour la reconnaissance vocale, nous utilisons Deepgram.

Pour les LLM, nous utilisons Gemma 4 31B, que nous hébergeons sur LiveKit.

Pour la synthèse vocale, nous utilisons Inworld AI text-to-speech 2.

En plus de cela, nous avons conçu l'ensemble de notre harnais d'agent IA AstroBeam, qui non seulement relie tous ces éléments, mais ajoute également tous les éléments nécessaires pour disposer d'un agent vocal de qualité, en particulier un agent hautement interactif comme le nôtre pour les jeux.

Je n'ai pas encore parlé des modèles de sécurité.

Traditionnellement, les modèles de sécurité font partie de la passe du LLM, mais cela ajoute de la latence et une étape supplémentaire.

Et si vous exécutiez plutôt votre propre serveur ?

Voici à quoi ressemble notre pile.

Lorsque nous recevons le premier bloc de texte, c'est-à-dire le premier bloc prononçable que nous allons envoyer à la synthèse vocale, nous l'envoyons en même temps à notre modèle de sécurité.

Comme le modèle de sécurité est plus petit et s'exécute plus rapidement que la reconnaissance vocale, il est presque toujours exécuté en amont.

Cela signifie que l'ajout d'un modèle de sécurité n'ajoute aucune latence à notre pile. Mieux encore, cela nous permet d'exécuter un modèle de sécurité beaucoup plus volumineux que ce que la plupart des gens envisagent.

C'est très important pour nous, en particulier parce que nous créons des jeux.

Le contexte de ce monde est très important.

Par exemple, imaginons que vous développez un jeu médiéval et que vous avez un PNJ qui crie "À l'attaque !"

Qu'on leur coupe la tête !", n'est-ce pas ?

Un modèle de sécurité traditionnel pourrait dire : "Ouh là, ce n'est pas cool.

Tu ne devrais pas dire ça."

Mais dans le contexte de ce jeu, cela prend tout son sens.

Pour ce faire, nous utilisons un modèle de sécurité un peu plus robuste, avec beaucoup plus de contexte sur ce qui se passe dans le monde.

Vous remarquerez peut-être que nous exécutons le modèle de sécurité deux fois : une fois sur le premier fragment, puis une seconde fois sur l'ensemble du texte lorsque nous avons le fragment final.

Là encore, nous devons l'exécuter deux fois, mais cela n'ajoute aucune latence à la pile.

Nous sommes désormais assez rapides, mais cela ne suffit pas si nous ne sommes pas assez intelligents.

Devin Reimer

Mais à quel point doit-elle être intelligente ?

Il doit être suffisamment intelligent pour vos utilisateurs, mais aussi et surtout pour vous permettre de développer des applications.

C'est souvent un aspect auquel les gens ne pensent pas lorsqu'ils choisissent ce dont ils ont besoin pour le renseignement.

Nous travaillons sur les agents vocaux depuis environ trois ans. Au début, nous utilisions des modèles LLaMA précoces. Même si nous parvenions à les faire fonctionner à peu près pour les utilisateurs, le développement était très coûteux, car tout était très fragile.

Il ne fallait pas grand-chose pour que les modèles génèrent des réponses indésirables ou des choses qui n'avaient tout simplement aucun sens. Nous avons donc consacré beaucoup d'efforts d'ingénierie pour que cela fonctionne.

C'est donc une priorité pour nous, car si nous ne pouvons pas créer ces éléments rapidement, nous ne pouvons pas les proposer aux utilisateurs.

Il est donc très important de réfléchir à ces deux aspects.

Souvent, quand on pense à l'intelligence, on pense au LLM, n'est-ce pas ?

Mais ce n'est qu'une partie de l'histoire.

Nous devons penser à chaque élément lorsqu'il s'agit d'intelligence.

Parlons maintenant de l'intelligence de la reconnaissance vocale.

Ce qui nous intéresse ici, c'est d'obtenir un faible taux d'erreur de mots.

De plus, non seulement le taux d'erreur est faible, mais lorsqu'une erreur se produit, nous générons quelque chose de très proche de la réalité. En effet, si c'est très proche, le LLM peut souvent, grâce au contexte, très bien comprendre de quoi il s'agit.

Si votre taux d'erreur est faible, mais que les erreurs sont très importantes, le LLM aura beaucoup plus de mal à déterminer l'intention réelle.

Vous devez également réfléchir à votre plate-forme cible.

Par exemple, si je développe pour la XR et que j'ai des micros très proches de la bouche de l'utilisateur, je vais obtenir des données audio de très bonne qualité, ce qui peut très bien fonctionner pour certains modèles.

Mais si, tout à coup, je crée une application pour un téléphone mobile que les gens vont utiliser dans une rue animée, l'impact est très différent. Les modèles se comporteront différemment et pourront interpréter intelligemment ce qui est dit de différentes manières.

Vous devez donc en tenir compte et vous assurer de choisir la bonne plate-forme pour laquelle vous développez.

Passons maintenant à la synthèse vocale, l'autre composante de l'équation de l'intelligence.

Est-ce que ça semble naturel ?

Notre objectif est de communiquer à l'utilisateur ce qu'il est capable de comprendre.

Mais ce n'est qu'une partie de l'histoire, n'est-ce pas ?

L'expressivité de cet agent est également très importante, car elle permet de transmettre des informations. De plus, lors de nos tests, nous avons découvert que plus nos agents sont expressifs, plus les utilisateurs les trouvent intelligents, ce qui est tout à fait logique.

Et est-il assez rapide ?

Dans la section précédente, j'ai parlé de la latence, mais elle est également importante ici pour l'intelligence perçue.

Les utilisateurs perçoivent la vitesse de réponse comme étant directement corrélée à l'intelligence réelle.

Si je réponds rapidement, j'ai l'air plus intelligent.

Ces éléments peuvent donc vraiment avoir une incidence sur la façon dont l'utilisateur perçoit l'expérience et sur son degré d'immersion.

Passons maintenant à l'aspect LLM de l'intelligence.

C'est de loin le plus difficile à équilibrer, car il y a tellement d'exigences différentes, n'est-ce pas ?

Nous avons donc la compréhension de la parole, le contexte et l'ancrage.

Dans les jeux, c'est très difficile, car il faut s'appuyer sur tout un monde et un univers, n'est-ce pas ?

Il ne s'agit pas d'une zone de texte dans laquelle il peut inventer des choses qui se produisent.

Si votre agent dans un jeu dit "Il y a une pomme sur la table" et qu'il n'y en a pas, l'expérience de l'utilisateur sera gâchée.

Nous avons également besoin d'un respect strict des règles.

Les jeux sont très basés sur des règles.

Le LLM peut-il gérer cela ?

Peut-on avoir un faible taux d'hallucination ?

Pouvons-nous avoir des personnages cohérents lorsque vous interagissez avec le même agent encore et encore ?

Avez-vous l'impression de parler au même agent ?

Enfin, un problème qui pourrait vous surprendre, car il ne se pose pas au début du développement, est de savoir si votre modèle peut gérer l'augmentation de la taille des requêtes.

En effet, à mesure que vous développez votre application, vous allez inévitablement ajouter des éléments au prompt.

Mais à mesure que les utilisateurs continuent de jouer, l'historique des discussions s'allonge dans ce prompt.

Cette requête pourra-t-elle gérer cette croissance ?

En effet, pour certains modèles, plus le prompt est long, plus la qualité de la réponse diminue. Vous devez donc déterminer vos besoins réels en termes de quantité d'informations à inclure dans le prompt à chaque fois.

Mais ce n'est que la partie visible de l'iceberg, et cela dépend aussi beaucoup de ce que vous créez.

Vous devez donc réfléchir très attentivement à ce que vous créez et à ce que vous essayez d'accomplir.

Nous sommes désormais assez rapides et intelligents, mais cela ne sert à rien si les coûts sont trop élevés.

Devin Reimer

Alors, à quel point doit-il être bon marché ?

Malheureusement, ce n'est pas aussi simple.

Nous devons donc réfléchir à l'économie de l'application ou du jeu que nous créons, n'est-ce pas ?

Voici quelques questions à vous poser.

Combien de temps l'utilisateur interagira-t-il avec vos agents vocaux ?

Combien gagnez-vous par utilisateur ?

Et combien coûte l'exécution de cette pile vocale par heure ?

Nous les rassemblons pour essayer de comprendre, pour voir si les choses ont du sens.

Voici donc l'économie de notre premier jeu, Stellar Cafe.

La durée de jeu dans Stellar Cafe est donc comprise entre 1 h 30 et 3 h 30. Nous allons donc l'estimer à environ 2 heures.

Le coût d'exécution de nos agents vocaux est d'environ 1,20 $ par heure et par utilisateur, et les utilisateurs interagissent avec eux 100 % du temps.

Il s'agit d'un jeu 100 % vocal.

Nous facturons un montant fixe de 10 $ pour le jeu, ce qui est classique.

Nous ne proposons pas d'abonnements, car ils sont très difficiles à gérer dans les jeux. Je suis convaincu que nous devons faire en sorte que cela fonctionne à un coût fixe, sinon cela ne fonctionnera pas et ne sera pas évolutif.

Auparavant, nous facturions 15 $, mais nous avons travaillé à réduire ces coûts de serveur, et nous les avons ramenés à 10 $.

Et ce 1,20 $, c'est là où nous en sommes.

Il ne s'agit pas d'un coût universel.

J'ai vu des prix très variés pour ce genre de choses, et parfois bien plus élevés.

Vous devez donc également déterminer où vous vous situez en termes de coûts.

Nous pourrions proposer un prix inférieur, mais nous essayons de maintenir un niveau de qualité aussi élevé que possible.

En faisant le calcul, cela signifie que pour deux heures de jeu, notre pile vocale coûte environ 2, 40 $ par utilisateur.

Comme nous facturons 10 $ et que le magasin prélève des frais, nous gagnons environ 4,59 $ par utilisateur, n'est-ce pas ?

Et donc, l'économie de ce système fonctionne, n'est-ce pas ?

La voix est notre accroche, c'est ce sur quoi nous voulons dépenser de l'argent, ça fonctionne.

C'est donc un jeu très petit.

Parlons de quelque chose d'un peu plus grand.

Prenons l'exemple d'un jeu narratif hypothétique qui dure entre 5 et 9 heures, soit 7 heures en moyenne.

En réalité, la plupart des gens (beaucoup de gens) ne finissent pas les jeux. Ils y jouent un peu, puis les abandonnent. Je veux donc choisir un chiffre un peu plus élevé pour m'assurer que l'économie fonctionne toujours.

Nous allons donc conserver ce coût de 1,20 $ par heure, mais nous allons modifier la part de la voix, qui sera utilisée 60 % du temps, car un jeu plus important aura beaucoup plus de mécanismes que la voix seule.

Il s'agira donc toujours d'un jeu très axé sur la voix, mais il comportera d'autres types de fonctionnalités.

Donc, si nous facturons 20 $, en reprenant tout cela, cela nous coûte environ 5 $ par utilisateur, ce qui signifie qu'au final, nous gagnons environ 9 $ par utilisateur.

Donc, encore une fois, avec cela, l'économie fonctionne.

Cela ne signifie pas que l'économie va fonctionner pour tout.

Par exemple, si vous vous dites : "Je veux créer un jeu sans frais, et les utilisateurs y joueront probablement entre 1 heure et plus de 100 heures", ce n'est pas la bonne approche.

Disons donc 10 heures en moyenne.

Il est 100 % contrôlé par la voix. Imaginons que nous ayons un succès entre les mains et que le jeu génère environ 3 $ par utilisateur, ce qui serait plutôt bien pour un jeu sans frais.

Vous perdriez 10 $ par utilisateur.

Il ne fonctionne donc pas encore pour toutes ces choses, et vous devez réfléchir à ce que vous êtes en train de créer et vous demander si cela est pertinent.

N'attendez pas la fin pour essayer de comprendre les aspects économiques.

Devin Reimer

La question suivante est : qu'en est-il des modèles locaux ?

En effet, si vous êtes confronté à ce problème de coût, les modèles locaux ne l'élimineraient-ils pas ?

Et oui, ce serait le cas.

Mais il y a des compromis à prendre en compte.

Donc, du côté des coûts, oui, nous éliminerions la facture du serveur, ce qui serait un énorme avantage et ouvrirait beaucoup plus d'opportunités.

Mais il y a beaucoup de choses que le cloud peut résoudre dès maintenant et qui posent problème en local.

Par exemple, le calcul.

On me dit souvent : "Regarde, j'ai trouvé ce modèle de reconnaissance vocale, et il s'exécute localement sur cet appareil, n'est-ce pas ?"

C'est bien, mais il faut garder à l'esprit qu'il n'exécute pas un seul modèle, mais plusieurs.

Dans notre cas, quatre, potentiellement en même temps. Il ne suffit donc pas qu'un élément s'exécute une fois, il doit s'exécuter plusieurs fois en même temps.

Et si vous y parvenez, avez-vous laissé de la place pour que votre jeu ou votre application puisse s'exécuter ?

Si vous avez atteint la limite du GPU, vous ne pourrez pas vraiment afficher un jeu vidéo.

Imaginons que vous ayez relevé ces défis.

La prochaine étape est la vitesse, n'est-ce pas ?

Vous pouvez souvent les faire fonctionner, mais ils seront très lents et vous aurez l'impression de saisir des prompts plutôt que d'avoir une véritable conversation en temps réel.

En théorie, l'exécution locale présente un avantage à l'avenir, car vous n'avez pas besoin d'effectuer cet aller-retour depuis Internet.

Pour l'instant, il est difficile d'obtenir des modèles qui s'exécutent à la bonne vitesse pour que cela fonctionne.

Imaginons que vous ayez résolu les problèmes de calcul et de vitesse. Vous devez maintenant vous pencher sur la qualité, n'est-ce pas ?

En général, comme vous l'exécutez sur un appareil local, vous utilisez un LLM plus petit, par exemple un modèle de synthèse vocale plus primitif. Cela peut poser des problèmes pour le contenu que vous créez.

Comme je l'ai déjà mentionné, lorsque vous réfléchissez au LLM, vous devez vous demander s'il est adapté à vos utilisateurs, mais aussi s'il est adapté à vos besoins de développement.

Si ce modèle devient difficile à utiliser pour créer quelque chose, il faut absolument y réfléchir.

Imaginons que vous ayez maîtrisé le calcul, la vitesse et la qualité. L'étape suivante est la portabilité.

Si vous avez gagné et que vous avez suivi tout ce processus, et que vous avez réussi à faire fonctionner ce modèle sur une RTX 5070, par exemple, il se peut que ce soit le seul endroit où il puisse fonctionner.

Ainsi, si l'occasion se présente de le porter sur une nouvelle plate-forme, vous risquez de vous retrouver bloqué.

Côté cloud, vous n'avez besoin que d'Internet.

C'est donc une avancée majeure.

Permet de diffuser sur plusieurs plates-formes.

Parlons maintenant de l'approche hybride.

Nous allons donc exécuter certains éléments dans le cloud et d'autres localement.

En quelque sorte, est-ce que ça pourrait fonctionner ?

Eh bien, ce n'est pas une victoire aussi importante que vous le pensez.

Ainsi, si vous obtenez un modèle suffisamment petit pour s'exécuter sur la plupart des plates-formes locales, l'exécuter dans le cloud ne vous coûtera probablement que quelques centimes.

En général, ce n'est que lorsque vous avez résolu l'ensemble de la pile que vous obtenez les meilleurs résultats.

Ensuite, la question suivante est : que se passe-t-il si vous l'exécutez localement, si c'est possible ?

Ils ont le bon matériel, et dans le cloud si vous ne l'avez pas, n'est-ce pas ?

Vous pourriez exécuter un modèle plus puissant dans le cloud.

Cela pose de nouveaux défis, n'est-ce pas ?

Si vous finissez par exécuter un modèle différent, cela peut avoir un impact considérable sur le développement.

Et vous finissez par devoir passer beaucoup de temps à travailler sur les spécifications minimales.

et vous pourriez avoir des modèles qui se comportent de manière très différente.

Donc, à moins d'utiliser exactement les mêmes modèles, vous risquez d'augmenter considérablement le temps et les coûts de développement.

Il est donc important de réfléchir à ce que vous essayez d'accomplir. En effet, même si vous avez trouvé une bonne solution locale pour les cas où c'est nécessaire, et une solution cloud pour les autres, le modèle cloud doit rester rentable.

En effet, si tous vos utilisateurs se retrouvent soudainement sur le cloud, vous risquez de perdre de l'argent si vous n'avez pas anticipé cette situation d'un point de vue économique.

En ce qui concerne les modèles locaux, il s'agit d'une grande victoire économique, mais il est encore tôt.

Pour les applications sensibles au prix, comme les jeux, je pense qu'il finira par s'imposer.

Aujourd'hui, c'est un peu compliqué en dehors de cas d'utilisation plus spécifiques, en particulier pour les éléments basés sur des commandes.

Aujourd'hui, nous voulons offrir la meilleure expérience possible.

C'est pourquoi nous utilisons le cloud.

Mais ce domaine évolue très rapidement, et les choses changent vite.

Penchons-nous à présent sur les modèles que nous utilisons.

La question suivante est de savoir s'il faut utiliser des pondérations ouvertes ou fermées.

Que devrions-nous faire ici ?

Je souhaite me concentrer sur les LLM, car nous avons constaté que c'est le domaine le plus touché par la question de l'ouverture ou de la fermeture.

Il y a donc des avantages et des inconvénients.

En ce qui concerne les modèles fermés à pondération, il s'agit généralement de l'intelligence de pointe, n'est-ce pas ?

Si vous avez besoin d'un maximum d'intelligence, c'est souvent vers ce type de modèle que vous devez vous tourner.

En revanche, sur le côté ouvert, ils sont souvent en retard d'une génération.

Il s'agit donc d'un véritable compromis.

En ce qui concerne la vitesse, j'ai mentionné que le délai avant la première phrase était très important.

Nous avons découvert que la vitesse des modèles fermés diminue souvent au fil du temps.

Il peut y avoir de nombreuses raisons à cela.

Peut-être que plus de personnes utilisent le modèle, ou que le matériel a été remplacé par un modèle plus récent.

Mais c'est une chose que nous avons remarquée.

Vous devez donc faire attention, car si vous livrez un produit de qualité, il peut devenir inutilisable au fil du temps.

Passons aux pics.

Vous accordez beaucoup d'importance à ce type de cohérence. Souvent, les modèles fermés sont conçus autour du traitement par lot dans des tâches asynchrones, et non des latences P99. En revanche, du côté des modèles ouverts, vous pouvez choisir un fournisseur qui se soucie de ce point très spécifique qui vous intéresse, afin de vous offrir la confiance, la vitesse et la latence dont vous avez besoin.

Le suivant est la durée de vie du modèle lui-même.

Les modèles fermés sont souvent abandonnés au bout d'un an environ.

Cela signifie que si vous développez un modèle pendant un an et que vous prévoyez de l'utiliser en production pendant trois ans, vous pourriez avoir à le modifier plus de trois fois.

Et ce n'est pas parce qu'un modèle est meilleur qu'il fonctionnera mieux pour vous.

Nous avons apporté de nombreuses modifications à nos modèles au cours des trois dernières années. Il faut souvent des semaines, voire des mois, pour tout réorganiser. Avec les modèles ouverts, vous pouvez continuer à exécuter un modèle tant que quelqu'un est prêt à l'héberger, ou que vous êtes prêt à l'héberger vous-même.

Enfin, le coût.

Souvent, au fil du temps, ces modèles fermés, à mesure qu'ils publient de nouvelles versions, sont plus coûteux que les précédents.

C'est un autre point à prendre en compte concernant l'aspect économique : encore une fois, votre modèle économique peut fonctionner au lancement, puis ne plus fonctionner lorsque vous migrez des modèles.

Du côté de l'open source, vous pouvez le déplacer, et il est peu probable que le coût augmente considérablement, car il s'agit exactement du même modèle.

Nous utilisons donc Gemma 4 31B, qui a été une véritable révélation pour nous, car il s'agit de la meilleure combinaison de vitesse, d'intelligence et de coût.

Cela nous a également permis d'avancer très rapidement.

Il est plus facile de développer avec cette solution qu'avec d'autres que nous avons utilisées par le passé.

Cela ne signifie pas que nous n'utilisons que cela.

Nous utilisons de nombreuses combinaisons de différents modèles ouverts et fermés.

Par exemple, la génération de mémoire, la sécurité et la personnalisation.

Il est simplement très important de choisir le modèle le plus adapté à vos besoins spécifiques pour cette tâche.

Mais Gemma 4 31B est notre modèle de prédilection pour les agents vocaux.

En ce qui concerne ce type de différences entre les deux, les modèles ouverts vous offrent sans aucun doute un meilleur contrôle et vous permettent de conserver les modèles tant qu'ils peuvent être hébergés à un coût plus prévisible.

De plus, l'abandon d'un modèle n'aura pas d'impact sur votre calendrier.

Devin Reimer

Pour résumer, il s'agit de trouver un équilibre entre ces trois éléments, n'est-ce pas ?

Pour la latence, nous essayons de trouver un équilibre entre l'aspect streaming, l'aspect parallèle, la vitesse et la cohérence.

En termes d'intelligence, il est suffisamment intelligent pour les utilisateurs et pour créer des applications.

Pour ce qui est du coût, nous devons savoir combien cela va coûter par utilisateur et combien nous pouvons gagner par utilisateur, afin de nous assurer que le modèle économique est viable.

Ne créez pas d'abord votre application pour ensuite réfléchir à son modèle économique.

Pensez-y dès le début.

Il est encore très tôt, mais le modèle économique commence à fonctionner.

Donc, des modèles moins chers et plus intelligents seront sans aucun doute plus performants.

Mais dès aujourd'hui, nous pouvons commencer à nous attaquer aux défis vraiment difficiles que nous devons relever pour que les agents vocaux soient présents partout.

Je suis donc ravi de mettre la puissance des agents vocaux à la disposition de tous.

Merci.