L’article XDA de la semaine dernière s’est terminé là où se terminent tous les fils de discussions sur les home-labs : un seul des sept LLM locaux a fait ses preuves en tant que cerveau d’une maison intelligente quand l’automatisation devenait intéressante. Les autres hallucinent lors des appels de fonction, ratent l’intention « éteindre la lumière du porche », ou fonctionnent tellement chaud que les ventilateurs du NAS tournent pendant des heures. Un modèle local sur un NAS est une réponse légitime au contrôle vocal, mais le choix du runtime compte plus que le choix du modèle.
Nous avons testé 7 applications de bureau qui s’exécutent sur un NAS domestique ou un mini PC sur le même réseau LAN, exposent un endpoint compatible OpenAI et s’intègrent proprement au pipeline vocal basé sur LLM de Home Assistant. Tout ce qui suit fonctionne hors ligne une fois les poids téléchargés, et tout a une image Docker documentée.
À quoi faire attention
- API compatible OpenAI. Home Assistant’s Assist l’attend, et tous les autres outils ci-dessous se connectent de la même manière.
- Prise en charge des appels de fonction. Un modèle qui ne peut pas émettre un appel de fonction structuré ne peut pas allumer une lumière.
- Support des modèles GGUF ou GPTQ. Si le NAS n’a pas de GPU, un Q4 GGUF sur CPU est le point de départ honnête.
- Une consommation mémoire sensée. Un modèle 7B Q4 devrait rester sous 6 GB de RAM au repos.
- Démarrage à chaud. Charger à froid un modèle 7B à chaque commande vocale est un délai de cinq secondes que vous remarquerez.
- Un gestionnaire de processus stable. Le NAS redémarre hebdomadairement pour les mises à jour ; le modèle devrait redémarrer automatiquement.
Comparaison rapide
| App | Meilleur pour | Plateformes | Plan gratuit | Fonctionnalité en avant |
|---|---|---|---|---|
| Ollama | Le runner par défaut que visent la plupart des guides Home Assistant | Linux, macOS, Windows | Oui (open source) | Catalogue de modèles et un endpoint stable compatible OpenAI |
| LocalAI | Remplacement tout en un pour les API OpenAI, incluant l’audio | Linux, macOS, Windows (Docker) | Oui (open source) | Gère le chat, les embeddings, TTS et STT depuis un seul conteneur |
| LM Studio | GUI sur l’hôte NAS et serveur pour le LAN | Windows, macOS, Linux | Oui | Découverte de modèles et basculement serveur en un clic |
| Open WebUI | Frontend de chat web qui communique aussi avec Home Assistant | Linux, macOS, Windows (Docker) | Oui (open source) | Chat multi-utilisateurs avec Ollama, LocalAI ou n’importe quel backend compatible OpenAI |
| Home Assistant | Le consommateur de l’endpoint | Windows, macOS, Linux (HAOS, Docker) | Oui | Intégration native d’Assist LLM avec routage des appels de fonction |
| vLLM | Meilleur débit sur un NAS avec GPU | Linux (Docker) | Oui (open source) | Traitement par lot continu et attention paginée pour une utilisation multi-utilisateurs |
| llama.cpp | Le runner bare-metal C++ derrière la plupart de ce qui précède | Linux, macOS, Windows | Oui (open source) | Exécute GGUF sur CPU sur presque n’importe quel matériel |
Les 7 meilleures apps pour un LLM domotique local sur NAS
1. Ollama — le meilleur runner par défaut que visent la plupart des guides
Ollama enveloppe llama.cpp avec une CLI propre, une bibliothèque de modèles et un serveur HTTP compatible OpenAI que l’intégration Assist LLM de Home Assistant reconnaît directement. Installez sur le NAS, lancez ollama pull qwen2.5:7b-instruct et pointez Home Assistant sur http://<nas-ip>:11434. Le gestionnaire de service le maintient en vie à travers les redémarrages.
Où ça échoue : La concurrence multi-utilisateurs est à une voie ; les requêtes parallèles s’empilent plutôt que de se regrouper. Le support Windows est arrivé récemment et est en retard sur Linux en stabilité.
Tarification :
- Gratuit : open source sous MIT
- Payant : rien pour l’auto-hébergement
Plateformes : Linux, macOS, Windows (natif et Docker)
Télécharger : ollama.com
Conclusion : Choisissez Ollama en premier, et ne partez que quand une limitation spécifique vous pousse.
2. LocalAI — meilleur si vous voulez chat, parole et embeddings dans un conteneur
LocalAI est le remplacement qui couvre toute la surface OpenAI : complétions de chat, embeddings, TTS, STT et génération d’images, tout en local. Le protocole Wyoming de Home Assistant peut pointer vers l’endpoint Whisper de LocalAI pour STT et Piper pour TTS, ce qui signifie que toute la boucle vocale vit sur le NAS.
Où ça échoue : Le fichier de config est dense et nécessite une première lecture. Les chemins d’accélération GPU (CUDA, ROCm, Vulkan) sont spécifiques à la compilation et choisir la mauvaise image donne un fallback CPU silencieux.
Tarification :
- Gratuit : open source sous MIT
- Payant : rien
Plateformes : Linux, macOS, Windows (Docker)
Télécharger : localai.io
Conclusion : Choisissez LocalAI si l’objectif est une pile vocale autonome avec STT, TTS et chat sous un même toit.
3. LM Studio — meilleur quand une interface plus conviviale compte
LM Studio a commencé comme une application de chat de bureau et a grandi en mode serveur headless. Sur un NAS avec un écran ou une session KVM distante, le sélecteur de modèles et le sélecteur de quantification sont plus tolérants qu’une CLI brute. Le serveur intégré expose l’endpoint compatible OpenAI que Home Assistant attend.
Où ça échoue : L’application principale est fermée, ce qui est un refus catégorique pour certains setups de home-lab. Le mode headless est disponible mais reste un citoyen de seconde classe.
Tarification :
- Gratuit : application complète
- Payant : rien
Plateformes : Windows, macOS, Linux
Télécharger : lmstudio.ai
Conclusion : Choisissez LM Studio si vous voulez une interface pour essayer des modèles avant d’en verrouiller un pour le rôle de maison intelligente.
4. Open WebUI — meilleur frontend de chat qui garde les humains dans la boucle
Open WebUI est le frontend basé sur navigateur style ChatGPT qui s’exécute contre Ollama, LocalAI ou n’importe quel endpoint compatible OpenAI. Sur un NAS, il double comme surface de test : lancez un prompt contre le même modèle que le pipeline Assist utilise, ajustez le prompt système, puis mettez à jour Home Assistant. Le support multi-utilisateurs avec rôles garde la famille hors de la console d’administrateur.
Où ça échoue : C’est une interface de chat, pas une partie du chemin d’automatisation lui-même. La configuration nécessite un volume persistant et un proxy inverse pour l’accès LAN ou Tailscale.
Tarification :
- Gratuit : open source sous MIT
- Payant : rien
Plateformes : Linux, macOS, Windows (Docker)
Télécharger : openwebui.com
Conclusion : Choisissez Open WebUI comme le chat orienté utilisateur au-dessus de n’importe quel runtime sur lequel vous vous installez.
5. Home Assistant — meilleur consommateur de l’endpoint
Home Assistant’s intégration Assist LLM est ce qui transforme « allume la lumière de la cuisine » en appel de fonction. Pointez sur Ollama, LocalAI, LM Studio ou n’importe quel endpoint compatible OpenAI, cochez « expose to Assist » sur les entités que vous voulez que le modèle contrôle, et la voix s’exécute entièrement sur le LAN. Le template de prompt est éditable, c’est ainsi que vous empêchez le modèle de halluciner les pièces.
Où ça échoue : La qualité des appels de fonction dépend du modèle, et Home Assistant ne vous dira pas quand le modèle retourne un ID d’entité plausible mais incorrect. Le débogage vit dans le panneau de débogage d’Assist et prend du temps à maîtriser.
Tarification :
- Gratuit : open source
- Payant : Cloud Nabu Casa optionnel, non requis pour la voix locale
Plateformes : Windows, macOS, Linux (HAOS, Docker, VM)
Télécharger : home-assistant.io
Conclusion : Choisissez Home Assistant parce que le LLM n’est intéressant que si quelque chose agit sur sa sortie, et c’est précisément ce rôle.
6. vLLM — meilleur si le NAS a un vrai GPU
vLLM est le runtime axé sur le débit. Le traitement par lot continu, l’attention paginée et une file d’attente multi-requêtes appropriée transforment une petite carte NVIDIA en endpoint à l’échelle familiale qui peut servir des requêtes vocales, un onglet Open WebUI et un plugin Obsidian simultanément sans que l’un bloque l’autre.
Où ça échoue : GPU uniquement, donc un NAS sans GPU est exclu. La compatibilité des modèles est plus étroite qu’Ollama et ajouter une nouvelle architecture est une étape de compilation.
Tarification :
- Gratuit : open source sous Apache 2.0
- Payant : rien
Plateformes : Linux (Docker)
Télécharger : github.com/vllm-project/vllm
Conclusion : Choisissez vLLM si le NAS a une carte NVIDIA supportée et plusieurs membres de la famille vont solliciter le modèle simultanément.
7. llama.cpp — meilleur runner bare-metal pour matériel limité
llama.cpp est le projet C++ qui alimente la plupart des runtimes ci-dessus. L’exécuter directement, avec le serveur HTTP intégré, est le moyen le plus économe de compresser un modèle 7B sur un Synology ou une vieille boîte ARM. Le support de Metal sur Apple Silicon et CUDA sur NVIDIA permet à un seul binaire de couvrir la plupart des configurations domestiques.
Où ça échoue : Pas de gestion des modèles, pas de mises à jour automatiques, pas de scripts de service prêts à l’emploi. C’est un ensemble d’outils, pas un produit.
Tarification :
- Gratuit : open source sous MIT
- Payant : rien
Plateformes : Linux, macOS, Windows (source, binaire ou Docker)
Télécharger : github.com/ggerganov/llama.cpp
Conclusion : Choisissez llama.cpp si le NAS est petit, le système d’exploitation est inhabituel et vous voulez l’abstraction minimale sur le fichier de modèle.
Comment choisir
Si vous partez de zéro, installez Ollama sur le NAS et pointez Home Assistant dessus.
Si la pile vocale a besoin de STT et TTS sur la même machine, remplacez Ollama par LocalAI et tirez les images Whisper et Piper.
Si vous voulez une interface pour comparer les modèles avant de vous engager, installez LM Studio et utilisez son mode serveur.
Si la famille veut discuter avec le même modèle qui exécute l’automatisation, ajoutez Open WebUI par-dessus.
Si le NAS a un GPU NVIDIA et plus d’un utilisateur lourd, basculez vers vLLM pour la concurrence.
Si le matériel est inhabituellement petit et chaque mégaoctet compte, lancez llama.cpp directement.
FAQ
Puis-je vraiment exécuter un modèle utile sur un NAS ?
Oui. Un modèle 7B Q4 dans llama.cpp sur un CPU à huit cœurs moderne génère à une vitesse lisible pour les réponses de courtes commandes vocales. Si le NAS a 16 GB de RAM et un cache NVMe, le modèle se charge en quelques secondes après un démarrage à chaud. Pour les longs chats ou le raisonnement, ajoutez un GPU.
Quel modèle gère le mieux les appels de fonction Home Assistant ?
Qwen 2.5 Instruct, Llama 3.1 8B Instruct et Hermes-3-Llama sont les options locales fiables à la taille 7B-8B. En dessous de 7B, le formatage des appels de fonction commence à se briser. Testez avec le panneau de débogage d’Assist sur une poignée de commandes réalistes avant de vous engager.
Le modèle voit-il tout l’état de ma maison ?
Seulement les entités que vous exposez explicitement à Assist. Le basculement d’exposition est par entité, donc une lumière au bureau ne doit pas fuir dans le contexte du modèle. Gardez l’ensemble exposé petit ; le prompt est moins cher et le modèle fait moins d’erreurs.
Que se passe-t-il quand Internet est coupé ?
Rien ne change. STT, LLM et TTS s’exécutent tous sur le NAS, donc la commande vocale continue de fonctionner. Le seul chemin qui a besoin de WAN est l’accès à distance, et le Cloud Nabu Casa ou un VPN auto-hébergé fixes tous les deux séparément.
