Pourquoi un assistant vocal domestique semble-t-il lent, même lorsque le LLM répond rapidement ?

Un assistant vocal domestique peut sembler lent parce que la capture de la parole, la détection de fin d’énoncé, les outils, la synthèse et la lecture entourent le LLM de délais successifs.

Un modèle local peut produire son premier token en 120 ms, alors que l’enceinte de la cuisine répond deux secondes après la fin de la commande. L’utilisateur perçoit l’ensemble de l’échange, et non un seul benchmark. La détection du silence avant l’envoi du prompt et la mise en mémoire tampon audio après la réponse peuvent chacune peser davantage que la rapidité d’inférence du modèle de langage.

Le LLM ne gère qu’un seul segment de l’échange vocal

Un échange parlé passe par la mise en mémoire tampon du microphone, la détection d’activité vocale, la détection de fin d’énoncé, la reconnaissance automatique de la parole, la préparation du prompt, la génération du modèle, l’exécution des outils, la synthèse vocale et la sortie audio. La plupart des étapes attendent la précédente. Un faible délai avant le premier token prouve donc seulement que l’étape linguistique est rapide une fois le texte reçu.

Une analyse de la latence d’une pile vocale décompose le parcours en plusieurs étapes de latence, montrant pourquoi l’optimisation d’un seul composant ne garantit pas une conversation rapide. Les surcoûts successifs s’accumulent, même lorsque chaque étape semble modeste prise isolément.

La détection de fin d’énoncé constitue souvent le coût caché en amont. L’assistant doit déterminer si une pause signifie que la personne a fini de parler ou qu’elle réfléchit. Un délai d’attente prudent évite les interruptions, mais ajoute du silence avant la finalisation de la reconnaissance vocale. Le système semble donc hésitant, même si le LLM démarre immédiatement après.

La diffusion en continu améliore la rapidité perçue sans supprimer tout le travail

Les transcriptions partielles peuvent lancer la préparation du prompt, et les tokens diffusés en continu peuvent alimenter la synthèse vocale avant la fin de la réponse. Ces chevauchements raccourcissent le chemin critique. Toutefois, la taille des segments, les contrôles de sécurité, la confirmation des outils et la quantité de texte stable requise avant la synthèse déterminent toujours le moment où la sortie audible commence.

Les recherches sur les agents vocaux à faible latence combinent la reconnaissance vocale en continu, des modèles de langage quantifiés et la synthèse en temps réel, car la réactivité de bout en bout dépend de la coordination des trois plutôt que de la seule vitesse du modèle.

Le premier son compte également davantage que la durée audio finale. Un système qui commence une réponse naturelle à 500 ms peut sembler plus rapide qu’un autre qui termine silencieusement toute la réponse en 900 ms. La diffusion en continu modifie le moment du retour utilisateur, mais elle ne fait pas disparaître un appel d’outil lent.

Quand l’explication par le pipeline cesse de s’appliquer

Le délai du pipeline n’explique pas tout lorsque l’assistant attend volontairement une confirmation, limite le débit des commandes ou applique une pause conversationnelle. Les variations du réseau, le mode d’économie d’énergie de l’enceinte, la reconnexion Bluetooth et le délai de sortie de veille du périphérique audio peuvent se produire en dehors de la pile d’IA. Une trace rapide sur le serveur peut tout de même aboutir à une enceinte lente dans la pièce.

Les recommandations sur la latence conversationnelle soulignent que les utilisateurs s’attendent à des intervalles courts entre les tours, faisant du moment où la réponse est perçue une propriété du produit plutôt qu’une statistique d’un modèle unique. Le délai perçu peut augmenter même lorsque le temps total de calcul reste inchangé si le retour utilisateur est différé.

Ce mécanisme ne s’applique pas lorsque les horodatages du serveur montrent que la lecture audio commence rapidement, mais que les utilisateurs signalent malgré tout un délai. La distance acoustique, la synchronisation du périphérique ou le retour de l’interface peuvent alors être en cause. Il n’explique pas non plus une première commande lente suivie de commandes rapides, ce qui suggère davantage un démarrage à froid ou des transitions d’état d’alimentation.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Mesurez l’ensemble de l’échange vocal, pas seulement le LLM

Enregistrez un horodatage monotone au début de la capture par le microphone, à la détection de la fin d’énoncé, à la transcription finale, à l’envoi du prompt, au premier token du LLM, à la fin de l’exécution de l’outil, au premier segment de synthèse vocale, à la mise en file de lecture et à la sortie audible. Exécutez vingt commandes courtes ainsi que cinq commandes utilisant des outils, après des démarrages à froid et à chaud.

Comparez ces traces aux démarrages à froid de l’IA locale, car le chargement du modèle peut fausser le premier tour, tandis que la détection de fin d’énoncé domine les suivants. Conservez les temps bruts plutôt qu’une seule valeur combinée de « temps de réponse ».

Optimisez l’intervalle répétable le plus long, et non le modèle le plus visible. Si la détection de fin d’énoncé domine, ajustez la détection des tours de parole ; si les outils dominent, préchargez uniquement les données sûres ; si le premier son suit tardivement la synthèse vocale, examinez la mise en mémoire tampon et la sortie de veille de l’enceinte. Gardez les délais de confirmation explicites, car la sécurité volontaire n’est pas un échec de performance.