L'IA pour la maison connectée : Llama 8B en local, vrais pièges et comment se passer du cloud

L'IA locale pour la maison connectée cesse d'être une expérience et devient une solution exploitable, à condition de bien assembler la pile et de savoir à l'avance où se cachent les écueils.

Les discussions sur l'IA domotique finissent généralement dans l'impasse de la même façon : on énumère une dizaine d'outils qui « savent tout faire », puis on découvre qu'ils ne se parlent pas. La vraie difficulté n'est pas de trouver un composant, mais de faire fonctionner l'ensemble comme un tout. C'est le sujet de la première partie d'une analyse détaillée sur Habr : non pas une liste, mais l'architecture des interactions.

Au centre, Llama 8B joue le rôle de modèle de langage local : il traite les commandes, analyse les données des capteurs et pilote la logique d'automatisation sans la moindre requête vers le cloud. Un détail essentiel : tout le traitement s'effectue sur du matériel domestique, ce qui règle deux questions à la fois, la confidentialité et le fonctionnement sans internet.

La question clé est la performance. Sur un matériel domestique moyen sans accélération GPU, Llama 8B impose une latence notable à chaque requête. Avec une quantification en 4 bits et un réglage correct du contexte, elle retombe à un niveau acceptable pour un assistant vocal. En revanche, pour des réactions instantanées à des événements comme un mouvement, de la fumée ou l'ouverture d'une porte, il faut une logique supplémentaire, sans couche LLM dans le chemin critique.

Le problème de Llama 8B est précis : le modèle est assez compact pour un déploiement domestique, mais sa capacité ne suffit pas toujours pour des chaînes de raisonnement complexes, surtout quand il doit garder en même temps le contexte de plusieurs appareils. La solution est architecturale : le LLM interprète l'intention de l'utilisateur et génère des règles d'automatisation, tandis qu'un moteur déterministe (Home Assistant ou équivalent) les exécute. Le modèle reste en dehors de la boucle temps réel.

La pile d'outils examinée par l'auteur : Ollama comme serveur local pour exécuter le modèle, Home Assistant comme plateforme domotique et un pont d'API sur mesure pour transmettre le contexte de l'un à l'autre. S'y ajoutent Whisper pour la reconnaissance vocale locale et un TTS pour le retour vocal. L'ensemble fonctionne hors ligne.

L'article traite à part la façon de contourner les limites de Llama 8B sans passer à des modèles plus gros ni à des API cloud. Les principales techniques : quantification agressive, découpage des tâches en sous-tâches avec des prompts distincts, mise en cache des requêtes fréquentes au niveau de l'application. Résultat : un comportement proche de celui de modèles plus grands, tout en gardant un déploiement entièrement local.

Les pièges se répartissent en trois catégories. Gestion de la mémoire : charger plusieurs modèles simultanément sur une machine à RAM limitée provoque du swapping et des délais inacceptables ; il faut un chargement différé selon le scénario. Format des prompts : Llama 8B est sensible à la structure de la requête, donc le modèle de prompt qui fonctionne doit être figé dans la configuration plutôt que réinventé à chaque mise à jour. Gestion des versions : une nouvelle version du modèle peut modifier un comportement qui semblait stable, et sans benchmarks locaux sur ses propres scénarios, mettre à jour est risqué.

Principale conclusion de cette première partie : l'IA locale pour la maison connectée a atteint la maturité technique, mais exige de la discipline architecturale. Faire passer un LLM par toute la chaîne d'exécution est une erreur classique. Le bon schéma : le modèle comme interprète des intentions en entrée, l'automatisation déterministe comme mécanisme d'exécution. La latence reste alors acceptable, et le système ne plante pas quand le modèle est surchargé.