Ollama, LM Studio, llama.cpp ou vLLM pour Home Assistant

Quel LLM local pour Home Assistant choisir en 2026 ? Ollama, LM Studio, llama.cpp et vLLM savent faire tourner des modèles sur votre matériel, mais ils ne répondent pas aux mêmes besoins. La différence se joue dans la mise en service, la consommation de RAM, l’API disponible et la capacité du modèle à appeler des outils pour agir sur les appareils.

Voici un guide orienté pratique : architecture réseau, installation Docker, commandes Linux, appels API, connexion à Assist, exemple YAML et méthode de mesure des performances. Les configurations sont des exemples à adapter à votre réseau et à tester avant de piloter de vrais équipements.

1. Comprendre l’architecture : Home Assistant ne fait pas tourner le modèle à lui seul

Dans le montage recommandé, Home Assistant conserve les entités, les permissions et les automatisations. Un autre équipement (mini-PC, serveur Linux, PC Windows ou Mac) héberge le LLM. Les deux communiquent en HTTP sur le réseau local. L’agent conversationnel n’est pas la même chose que la reconnaissance vocale : pour une installation entièrement hors cloud, la transcription (STT) et la synthèse vocale (TTS) doivent elles aussi être locales.

Téléphone / satellite vocal
           |
       Home Assistant Assist
       |               |
  STT / TTS local   Agent Ollama (conversation + tools)
                           |
                  HTTP sur réseau local
                           |
                 Mini-PC :11434 (modèle)
                           |
                 Retour vers Assist API
                           |
               Entités autorisées uniquement

Une requête du type « Quelle est la température du salon ? » peut être satisfaite à partir des entités exposées. « Allume la lampe du bureau » nécessite en plus un modèle capable d’appeler des outils (tool calling) et l’activation explicite du contrôle dans l’intégration Ollama. Le LLM ne doit pas remplacer vos automatismes déterministes.

Documentation : intégration officielle Ollama et pipeline vocal entièrement local.

2. Quel matériel pour démarrer ?

Ce sont des repères de dimensionnement, pas des performances mesurées. Un modèle quantifié en 4 bits utilise beaucoup moins de mémoire que son équivalent en précision supérieure, mais il faut aussi compter la fenêtre de contexte, le cache KV, les services système et les éventuelles requêtes parallèles. Un modèle 8B ne signifie pas « 8 Go de RAM ». Commencez petit, mesurez, puis augmentez.

Pour un premier essai, Qwen3 est une famille intéressante à comparer car elle propose des variantes multilingues et compatibles avec les appels d’outils. Dans les exemples ci-dessous, nous utilisons qwen3:4b-instruct. La qualité du pilotage domotique reste à vérifier sur votre installation : le support annoncé des tools ne garantit pas des commandes fiables.

3. Installer Ollama avec Docker Compose : tutoriel complet

Prérequis : un PC ou mini-PC disposant de Docker et du module Compose, avec une adresse LAN réservée dans la box (ici 192.168.1.50, à remplacer). Pour commencer, n’ouvrez aucun port vers Internet.

Étape A — Créer le fichier compose.yaml

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      # Remplacer 192.168.1.50 par l'IP LAN réelle du serveur.
      # Pour un test sur la même machine uniquement : 127.0.0.1:11434:11434
      - "192.168.1.50:11434:11434"
    volumes:
      - ollama_data:/root/.ollama

volumes:
  ollama_data:

Le volume ollama_data conserve les modèles après un redémarrage. Le port publié sur une IP LAN n’est pas une authentification : limitez l’accès au port 11434 avec le pare-feu du serveur et n’autorisez que l’hôte Home Assistant. Ne configurez aucune redirection NAT. Avec Home Assistant et Ollama sur le même PC, préférez une écoute sur 127.0.0.1 lorsque les conditions réseau le permettent.

Étape B — Démarrer le serveur et télécharger un modèle

docker compose up -d
docker exec ollama ollama pull qwen3:4b-instruct

# Modèles téléchargés
docker exec ollama ollama list

# Santé de l'API depuis une machine autorisée
curl http://192.168.1.50:11434/api/tags

Une réponse JSON avec un tableau models confirme que l’API répond. Si la connexion échoue, contrôlez docker compose ps, docker compose logs --tail=80 ollama, l’adresse IP et le pare-feu. Le téléchargement du modèle exige une connexion Internet initiale ; l’inférence locale n’en a pas besoin.

Étape C — Envoyer une vraie requête à l’API

curl -s http://192.168.1.50:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:4b-instruct",
    "messages": [
      {"role": "system", "content": "Réponds en français, clairement."},
      {"role": "user", "content": "Explique la différence entre Zigbee et Thread en 3 phrases."}
    ],
    "stream": false,
    "options": {"num_ctx": 8192},
    "keep_alive": "5m"
  }'

Dans le JSON retourné, message.content contient la réponse, total_duration la durée globale et eval_count/eval_duration permettent d’estimer le débit de génération. Ce test valide le serveur d’inférence, pas encore les autorisations de Home Assistant. Pour le modèle et l’API : installation Docker et référence /api/chat.

Alternative : Ollama installé directement sous Linux

Si vous utilisez le service systemd plutôt que Docker, la documentation Ollama recommande de modifier les variables d’environnement du service. Exemple pour rendre le serveur joignable sur le LAN (à sécuriser par pare-feu) :

# sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_NO_CLOUD=1"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama pull qwen3:4b-instruct
ollama ps

OLLAMA_NO_CLOUD=1 désactive les fonctions cloud d’Ollama pour une installation qui doit rester locale. OLLAMA_HOST=0.0.0.0:11434 écoute sur toutes les interfaces : il faut donc restreindre l’accès réseau. Voir les variables officielles Ollama.

4. Brancher Ollama à Home Assistant et tester Assist

1. Dans Home Assistant, ouvrez Paramètres → Appareils et services → Ajouter une intégration, puis recherchez Ollama.
2. Renseignez l’URL du serveur : http://192.168.1.50:11434 (pas localhost si Home Assistant tourne sur une autre machine).
3. Sélectionnez qwen3:4b-instruct. Le téléchargement peut aussi être proposé par l’intégration.
4. Commencez avec l’option Contrôler Home Assistant désactivée. Vérifiez d’abord les réponses textuelles.
5. Dans Paramètres → Assistants vocaux, associez l’agent de conversation Ollama à votre assistant ou à votre pipeline.
6. Pour tester le pilotage, activez ensuite le contrôle, puis utilisez l’onglet Exposer pour ne rendre accessibles que quelques entités non sensibles, par exemple light.bureau et sensor.temperature_salon.

Home Assistant conseille de rester sous 25 entités exposées lors des essais avec un LLM local. Seuls les modèles qui gèrent les outils peuvent demander une action. Un assistant qui sait discuter n’est pas nécessairement un agent capable de contrôler une lampe. Documentation : exposer les entités à Assist.

Exemple YAML : interroger l’agent depuis un script Home Assistant

Dans un nouveau script Home Assistant, passez en édition YAML et adaptez cet exemple. Il utilise l’agent de conversation par défaut : sélectionnez donc Ollama comme agent par défaut dans le pipeline voulu avant l’essai, ou ajoutez agent_id avec l’identifiant réel de votre agent.

alias: "Test LLM local - état des lampes"
sequence:
  - action: conversation.process
    data:
      text: "Est-ce que la lampe du bureau est allumée ?"
    response_variable: resultat_ia
  - action: persistent_notification.create
    data:
      title: "Réponse de l'agent local"
      message: "{{ resultat_ia.response.speech.plain.speech }}"
mode: single

Ce script crée une notification à partir de la réponse d’Assist. Si le capteur ou la lampe n’est pas exposé, le modèle ne doit pas pouvoir en consulter l’état. Le schéma de conversation.process et le nom réel de vos entités sont à vérifier sur votre instance.

Exemple concret : créer une action déterministe « mode soirée »

Pour réduire les erreurs, il vaut souvent mieux exposer un script Home Assistant bien décrit que laisser un LLM improviser plusieurs appels. Exemple de script à créer dans Home Assistant :

alias: "Mode soirée salon"
description: "Active un éclairage doux dans le salon à 25 %."
sequence:
  - action: light.turn_on
    target:
      entity_id: light.salon
    data:
      brightness_pct: 25
mode: single

Remplacez light.salon par l’entité réelle. Activez ensuite l’exposition du script à Assist dans ses paramètres. Un agent LLM compatible pourra voir ce script comme un outil, à condition que le contrôle soit autorisé par l’intégration. La description est importante : elle aide le modèle à choisir le bon outil. Ne créez pas de scripts de déverrouillage, d’alarme ou d’ouverture de portail accessibles de cette manière. Consultez le guide officiel des scripts exposés aux LLM.

5. LM Studio : lancer une API locale en quelques secondes

LM Studio est particulièrement pratique pour comparer plusieurs modèles à la souris. Téléchargez un modèle depuis son interface, chargez-le, puis ouvrez l’onglet Developer et activez le serveur. La commande équivalente sur une installation avec l’outil lms est :

lms server start --port 1234
curl http://127.0.0.1:1234/v1/models

Copiez l’identifiant renvoyé dans /v1/models (il dépend du modèle réellement chargé), puis testez un appel :

curl http://127.0.0.1:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "IDENTIFIANT_RETOURNE_PAR_V1_MODELS",
    "messages": [
      {"role": "user", "content": "Rédige une commande vocale Home Assistant sans ambiguïté."}
    ]
  }'

LM Studio sait proposer des points d’accès compatibles avec l’API OpenAI et des appels d’outils pour les modèles compatibles, mais cela ne crée pas automatiquement une intégration officielle équivalente à Ollama dans Assist. Pour le piloter depuis Home Assistant, il faut un client ou une passerelle compatible, avec son propre travail de configuration et de sécurité. Ne confondez pas « API compatible » et « prise en charge native ». Guides : serveur local LM Studio et endpoints compatibles OpenAI.

6. llama.cpp : gérer soi-même le GGUF et le serveur

llama.cpp convient à ceux qui veulent choisir précisément un fichier quantifié au format .gguf, le nombre de couches déportées au GPU ou la taille du contexte. Après compilation ou installation d’une version contenant llama-server, et après avoir obtenu légalement un modèle GGUF compatible :

# CPU (adapter le chemin au fichier GGUF téléchargé)
./build/bin/llama-server \
  -m /models/mon-modele.gguf \
  --host 127.0.0.1 --port 8080 \
  -c 8192 --jinja

# Vérification du serveur
curl http://127.0.0.1:8080/v1/models

Sur une machine dotée d’un GPU compatible avec votre compilation, -ngl 99 peut demander le déport d’un grand nombre de couches vers le GPU. Ce n’est pas une garantie que le modèle tienne entièrement en VRAM : contrôlez les logs au démarrage. Si Home Assistant tourne ailleurs, il faudra une exposition réseau maîtrisée et un connecteur adapté ; l’intégration Ollama officielle ne se branche pas simplement sur toutes les API compatibles OpenAI. Documentation : README de llama-server et appels de fonctions.

7. vLLM : à réserver au serveur GPU multi-clients

Avec vLLM, l’objectif est de servir efficacement un modèle à plusieurs clients via HTTP plutôt que d’obtenir la configuration la plus simple pour un seul foyer. Exemple indicatif sur une machine Linux déjà préparée pour vLLM et disposant d’un accélérateur adapté :

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --host 127.0.0.1 --port 8000 \
  --api-key "CLE_DE_TEST_A_REMPLACER"

curl http://127.0.0.1:8000/v1/models \
  -H "Authorization: Bearer CLE_DE_TEST_A_REMPLACER"

Le téléchargement du modèle, les dépendances GPU et la mémoire disponible restent des prérequis. Attention : la documentation vLLM avertit qu’une clé --api-key ne protège pas nécessairement tous les endpoints. N’exposez pas directement ce service sur Internet. Pour Home Assistant, il faut toujours un agent ou connecteur qui transforme correctement les requêtes et les appels d’outils. Voir documentation officielle du serveur vLLM.

8. Comparatif orienté Home Assistant

9. Mesurer le temps de réponse plutôt que se fier aux fiches techniques

Le débit en tokens/seconde ne dit pas tout : pour une maison connectée, la latence perçue, la fiabilité des actions et les erreurs de choix d’entité comptent davantage. Ce petit script Python (bibliothèque standard seulement) mesure le temps réel, la durée de chargement et le débit de génération rapportés par l’API Ollama :

import json
import time
from urllib.request import Request, urlopen

url = "http://127.0.0.1:11434/api/chat"
payload = {
    "model": "qwen3:4b-instruct",
    "messages": [{"role": "user", "content": "Décris en une phrase le rôle d'Assist."}],
    "stream": False,
}

req = Request(url, data=json.dumps(payload).encode(),
              headers={"Content-Type": "application/json"})
debut = time.perf_counter()
with urlopen(req, timeout=180) as response:
    data = json.load(response)
temps = time.perf_counter() - debut

tokens = data.get("eval_count", 0)
duree = data.get("eval_duration", 0) / 1e9
chargement = data.get("load_duration", 0) / 1e9
print(f"Temps total observé : {temps:.2f} s")
print(f"Chargement du modèle : {chargement:.2f} s")
print(f"Débit génération : {tokens / duree:.1f} tok/s" if duree else "Débit indisponible")

Sur une installation réelle, répétez chaque question plusieurs fois et mesurez aussi les erreurs : « allume la lampe du bureau », « donne la température du salon », « éteins uniquement l’entrée ». Comparez à matériel, modèle, quantification et contexte identiques. Pensez à mesurer le premier appel (chargement à froid) puis les suivants (modèle déjà en RAM). ollama ps aide à savoir si le modèle est en CPU ou GPU.

10. Dépannage et sécurité : les erreurs les plus courantes

• « Connection refused » : vérifier l’IP, le port 11434, les règles du pare-feu et le fait que localhost désigne la machine depuis laquelle le client appelle. Docker, Home Assistant OS et un PC distant n’ont pas le même localhost.
• Modèle introuvable : comparer exactement le nom choisi à la sortie de ollama list ou /api/tags.
• Le LLM parle mais n’allume rien : vérifier « Contrôler Home Assistant », la prise en charge des tools et l’exposition explicite de l’entité.
• Réponse lente : inspecter ollama ps, réduire le modèle ou la fenêtre de contexte, puis mesurer à nouveau. Plus d’entités signifie aussi plus de contexte à traiter.
• Action sur le mauvais appareil : renommer les entités et leurs alias, associer les équipements à la bonne pièce et utiliser des scripts spécialisés plutôt qu’une instruction vague.
• Sécurité : ne jamais publier une API locale par redirection de port ; réserver les accès LAN, filtrer au pare-feu et exclure alarmes, serrures et portails. Un simple prompt ne constitue pas une barrière de sécurité.

Verdict : avec quoi commencer en pratique ?

Pour un projet de domotique DIY, installez Ollama sur un mini-PC distinct, branchez-le à l’intégration officielle Home Assistant et testez d’abord cinq à dix entités non sensibles. LM Studio sert à sélectionner un modèle avant déploiement. llama.cpp donne davantage de contrôle sur le matériel et les fichiers GGUF. vLLM se justifie lorsque le même serveur doit traiter un flux de requêtes plus conséquent.

Le point important n’est pas uniquement de faire répondre un LLM en français : c’est de prouver qu’il vise la bonne entité, qu’il n’agit pas hors périmètre et qu’une panne de l’IA ne perturbe pas vos automatismes.

À lire aussi sur Domo-Attitude

• Home Assistant : applications ou intégrations, que choisir ? — comprendre où s’insère un agent conversationnel.
• Clavier Zigbee frient et Home Assistant — exemple d’intégration d’un matériel réel dans la domotique.
• Home Assistant Cloud devient Link — distinguer les services distants d’une installation réellement locale.

FAQ

Est-ce possible sans Internet ?

Oui, après installation et téléchargement des modèles, à condition de garder en local le LLM, la transcription vocale, la synthèse vocale et les équipements concernés. Vérifiez les options cloud éventuelles de chaque logiciel.

Est-ce qu’Ollama remplace Whisper et Piper ?

Non. Ollama gère la conversation par modèle de langage ; Whisper et Piper remplissent des rôles différents dans la chaîne voix → texte → réponse → voix.

Un modèle « tools » est-il fiable pour une alarme ?

Non, pas comme unique mécanisme de décision. Même si un modèle sait appeler une fonction, il peut mal interpréter une consigne. Les équipements de sécurité doivent rester soumis à des contrôles déterministes.