Yandex : Alice traite les commandes domotiques directement sur le haut-parleur — en moyenne 6x plus rapide que le cloud

• Станция Миди и голосовое управление Zigbee-устройствами без интернета. История разработки — Habr (блог Яндекса), 2023-11
• Итоги Яндекса за 2025: 5,3 млн активных устройств YaOS/YaOS X, 2,9 млрд запросов к Алисе — Habr, 2025
• Яндекс.Станция — линейка устройств, включая Станцию Мини 3 Про с локальной обработкой команд — TAdviser, n/a
• Яндекс Станция Миди — официальная страница продукта (Zigbee-хаб, локальные команды) — Яндекс, n/a

Contexte

Alice est l'assistant vocal de Yandex résidant dans des haut-parleurs intelligents et des téléviseurs sur les plates-formes YaOS et YaOS X. L'échelle de l'écosystème à la fin de 2025 : 5.3 millions d'appareils actifs, 2.9 milliards de demandes traitées au cours de l'année, et 14 nouveaux gadgets intelligents dans la gamme (données Yandex publiées sur Habr). C'est l'un des plus grands écosystèmes vocaux en dehors du monde anglophone.

En novembre 2023, Yandex a lancé Station Midi — le premier haut-parleur dans lequel Alice a appris à comprendre et exécuter les commandes domotiques localement, directement sur l'appareil, sans aller-retour au cloud. Midi agit également comme hub Zigbee lui-même : les capteurs, ampoules et prises se connectent directement au haut-parleur, en contournant les services cloud.

Ce qui rend le cas remarquable du point de vue technique : Yandex est une rare compagnie qui a détaillé publiquement son architecture sur l'appareil — l'équipe l'a décrite dans un article technique sur Habr en novembre 2023, avec des tailles de modèles concrètes, des empreintes mémoire et l'historique des optimisations. À titre de comparaison : Amazon et Google ont également déplacé le traitement des commandes vocales sur les appareils, mais n'ont jamais fourni une documentation technique publique aussi détaillée de leurs solutions.

Cette transparence rend le cas vérifiable et instructif : vous pouvez retracer comment une pile de reconnaissance vocale et de compréhension côté serveur occupant des dizaines de gigaoctets est comprimée dans un haut-parleur avec un gigaoctet de RAM.

Problème

L'architecture classique d'un assistant vocal achemine chaque commande via le cloud : l'enregistrement vocal est envoyé à un serveur, y est reconnu et interprété, et la réponse revient à l'appareil. Pour une maison intelligente, cela signifie deux problèmes. Premièrement, la latence entre dire 'éteindre la lumière' et la lumière qui s'éteint réellement : même avec une bonne connexion Internet, la commande fait un aller-retour réseau complet, bien que le haut-parleur et l'ampoule soient dans la même pièce. Deuxièmement, une maison intelligente complètement non fonctionnelle lors de pannes Internet : un interrupteur qui ne fonctionne plus avec le Wi-Fi mine la confiance dans l'idée même d'une maison intelligente.

Déplacer le traitement sur l'appareil a buté contre une arithmétique des ressources difficile. La pile serveur d'Alice a été conçue pour un centre de données : le service NLU cloud 'Begemot' seul nécessite au moins 30 gigaoctets de RAM et environ 30 gigaoctets de disque. Un haut-parleur intelligent typique (Station Mini) dispose de 256 mégaoctets de RAM et 256 mégaoctets de mémoire flash — un écart de plus de cent fois. La reconnaissance vocale sur l'appareil doit également fonctionner en mode streaming — en commençant à analyser la phrase avant que la personne la termine, sinon il n'y a pas de gain de vitesse.

Ainsi, la tâche n'a pas été présentée comme 'mettre un modèle sur un haut-parleur' mais comme un programme d'ingénierie complet : reconstruire trois sous-systèmes — reconnaissance vocale (ASR), compréhension du langage (NLU) et le backend domotique — en versions qui tiennent dans des mégaoctets à un ou deux chiffres, sans perte de qualité sur la classe cible de commandes.

Solution

La fondation a été posée au moment de la conception du matériel. Station Midi est construite sur un SoC Amlogic A113X2 avec un processeur neural intégré (NPU), 1 gigaoctet de RAM et 8 gigaoctets de mémoire flash — par rapport à 256 mégaoctets de chacun dans la Mini. Le NPU et la marge de manœuvre mémoire étaient un pari délibéré sur les modèles locaux, fait avant que ces modèles ne soient prêts.

La reconnaissance vocale (ASR) a été construite sur un codeur transformer avec un passage de CTC à RNN-T — une architecture permettant la reconnaissance en streaming et en temps réel : le haut-parleur analyse la phrase au fur et à mesure qu'elle est prononcée. Le modèle, d'environ 10 millions de paramètres, a été entraîné sur le même ensemble de données que le reconnaisseur cloud, avec des exemples de commandes domotiques ajoutés. À titre de comparaison : les modèles ASR cloud sont des ordres de grandeur plus grands.

La compréhension du langage a été résolue en adaptant le service 'Begemot' côté serveur — ainsi 'Begemotik' est née. D'un service nécessitant au moins 30 gigaoctets de RAM, tout ce qui était inutile pour le domaine domotique a été supprimé : les composants ML lourds, la reconnaissance géographique et de date. Le résultat — 90 mégaoctets de RAM et 73 mégaoctets de mémoire flash : deux à trois ordres de grandeur de compression tout en préservant la qualité sur les commandes cibles.

Le troisième composant est le backend domotique local en Go : la logique d'exécution des commandes qui consommait 500+ mégaoctets dans le cloud a été comprimée à ~200 mégaoctets de RAM et 90 mégaoctets de mémoire flash — en partie en supprimant la synthèse vocale et en conservant le stockage local de la configuration domotique avec la synchronisation.

Le lien de connexion est le hub Zigbee intégré : les appareils domotiques se connectent directement au haut-parleur, de sorte que tout le chemin 'voix → reconnaissance → interprétation → commande de l'appareil' reste à l'intérieur de l'appartement. Internet n'est pas du tout nécessaire pour ces scénarios. L'architecture est cependant hybride : tout ce qui dépasse les commandes domotiques de routine — musique, recherche, conversation avec Alice — va toujours au cloud, où les modèles de taille réelle s'exécutent.

Notamment, l'équipe a publié non seulement le résultat mais aussi l'historique du développement avec les échecs et les bifurcations intermédiaires (par exemple, pourquoi CTC a été abandonnée en faveur de RNN-T) — un rare niveau de transparence technique pour un produit grand public.

Résultat

Selon l'équipe Yandex, le traitement local des commandes domotiques est en moyenne 6x plus rapide que le chemin cloud — le gain provient de l'élimination de l'aller-retour réseau plus le traitement en streaming sur l'appareil ; la compagnie n'a pas publié de millisecondes exactes, et la vitesse de reconnaissance varie en fonction de la complexité de la phrase. Les lumières et autres appareils Zigbee continuent à fonctionner quand Internet s'arrête — la résilience hors ligne n'est pas devenue un effet secondaire mais le deuxième résultat phare du projet.

L'approche s'est implantée dans toute la gamme : les appareils plus récents, y compris Station Mini 3 Pro, ont également obtenu le traitement des commandes vocales locales (TAdviser) — Midi n'était pas une expérience mais un rodage de l'architecture pour toute la plateforme. L'écosystème a continué à croître entre-temps : 5.3 millions d'appareils YaOS/YaOS X actifs et 2.9 milliards de demandes Alice en 2025.

L'échelle de compression que l'équipe a documentée en chiffres est révélatrice en elle-même : NLU — de au moins 30 gigaoctets de RAM jusqu'à 90 mégaoctets ; le backend domotique — de 500+ à ~200 mégaoctets ; ASR — jusqu'à un modèle à ~10 millions de paramètres, des ordres de grandeur plus petit que les homologues cloud. Ces chiffres sont un rare point de référence public pour quiconque évalue la faisabilité de l'IA sur l'appareil sur du matériel bon marché.

À notre avis, la principale leçon transférable du cas est la décomposition correcte de l'hybride : Yandex n'a pas essayé de traîner 'toute Alice' sur le haut-parleur ; il a isolé le domaine étroit où la localité apporte le plus de valeur (commandes domotiques de routine — haute fréquence, courtes, avec un vocabulaire limité) et a laissé tout le reste au cloud. Ce cadrage — 'local pour ce qui est fréquent et simple ; cloud pour ce qui est rare et complexe' — s'applique bien au-delà de la maison intelligente : des menus vocaux bancaires aux assistants automobiles.

La deuxième observation : l'IA sur l'appareil commence par le matériel. Le NPU dans le SoC et le gigaoctet de mémoire ont été conçus dans Midi dès le départ — sur une puce faible, cette architecture ne se serait pas produite. Les équipes planifiant des modèles locaux dans les appareils devraient budgéter la marge de manœuvre de calcul une génération avant que les modèles ne soient prêts — sinon, au moment où le logiciel arrive à maturité, le matériel dans les appareils déjà vendus ne pourra pas faire face.

Leçons

1. La latence est une métrique de produit domotique : les utilisateurs ressentent le gain 'en moyenne 6x' à chaque coup d'interrupteur.
2. L'IA sur l'appareil est avant tout une discipline de compression : un ASR à ~10M paramètres et une NLU comprimée de 30 GB à 90 MB suffisent pour les commandes de routine — aucun modèle géant requis.
3. Comprimez en coupant le domaine, pas seulement par quantification : 'Begemotik' est devenue des centaines de fois plus petite que 'Begemot' parce que tout ce dont la maison intelligente n'a pas besoin a été supprimé (géographie, dates, composants ML lourds).
4. Décomposez l'hybride par fréquence et complexité : local pour les commandes simples fréquentes, cloud pour les requêtes complexes rares ; n'essayez pas de traîner l'assistant entier sur l'appareil.
5. La résilience hors ligne est une valeur en soi : une maison intelligente qui meurt avec le Wi-Fi mine la confiance dans toute la catégorie.
6. Le matériel spécialisé (un NPU dans le SoC, marge de manœuvre mémoire) doit être planifié au moment de la conception de l'appareil — une génération avant que les modèles ne soient prêts ; vous ne pouvez pas adapter les modèles sur l'appareil sur une puce faible.
7. Un article technique public (Habr) avec des tailles de modèles concrètes et un historique des échecs est une pratique rare et correcte : cela rend les résultats revendiqués vérifiables.

Questions fréquentes