Prérequis
- Hermes Agent installé (voir le guide macOS)
- 8 Go+ de RAM (16 Go+ recommandés pour les modèles plus grands)
- Environ 5 à 10 Go d'espace disque libre par modèle
- Mac à processeur Apple Silicon (M1/M2/M3/M4) ou processeur x86 moderne avec prise en charge AVX2
- Un GPU dédié est facultatif mais utile — la mémoire unifiée d'Apple Silicon fonctionne bien
- Environ 30 à 60 minutes pour la configuration initiale et le téléchargement du modèle
Étape 1 : Installer llama.cpp
llama.cpp est le moteur qui exécute efficacement les modèles au format GGUF sur du matériel grand public. Installez-le via Homebrew (macOS) ou compilez à partir des sources :
# macOS — méthode la plus simple brew install llama.cpp # Vérifier l'installation llama-cli --version
Si vous préférez compiler à partir des sources (pour les fonctionnalités les plus récentes ou pour Linux) :
git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp make -j4 # Facultatif : activer l'accélération GPU Metal sur macOS GGML_METAL=1 make -j4
L'accélération Metal (Apple Silicon) améliore considérablement la vitesse d'inférence. Si vous êtes sur Mac, utilisez la compilation Metal.
Étape 2 : Télécharger un modèle GGUF
GGUF est le format de modèle utilisé par llama.cpp. Le meilleur endroit pour trouver des modèles GGUF est HuggingFace. Voici nos recommandations pour différents niveaux de matériel :
| Modèle | Taille | RAM nécessaire | Idéal pour |
|---|---|---|---|
| Llama 3.2 3B | ~2 Go (quantification Q4_K_M) | 4 à 6 Go | Tâches légères, machines à faibles ressources |
| Mistral 7B | ~4 Go (quantification Q4_K_M) | 8 Go | Bon modèle polyvalent, raisonnement solide pour sa taille |
| Llama 3.1 8B | ~5 Go (quantification Q4_K_M) | 8 à 12 Go | Usage général, bonne capacité à suivre les instructions |
| Qwen 2.5 14B | ~9 Go (quantification Q4_K_M) | 16 Go | Raisonnement de meilleure qualité, génération de code |
Téléchargez avec huggingface-cli (installez avec pip install huggingface_hub) ou téléchargez directement depuis le site HuggingFace. Stockez les modèles dans un répertoire dédié :
# Créer un répertoire pour les modèles mkdir -p ~/.hermes/models # Exemple : télécharger Mistral 7B (TheBloke maintient des quantifications GGUF de haute qualité) huggingface-cli download TheBloke/Mistral-7B-Instruct-v0.2-GGUF \ mistral-7b-instruct-v0.2.Q4_K_M.gguf \ --local-dir ~/.hermes/models # Ou pour Llama 3.1 8B huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF \ Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \ --local-dir ~/.hermes/models
Étape 3 : Configurer Hermes pour utiliser le point de terminaison local
Hermes Agent se connecte à llama.cpp via un serveur HTTP local. D'abord, démarrez le serveur llama.cpp avec votre modèle :
# Démarrer le serveur d'inférence local llama-server \ --model ~/.hermes/models/mistral-7b-instruct-v0.2.Q4_K_M.gguf \ --host 127.0.0.1 \ --port 8080 \ --ctx-size 8192 \ --n-gpu-layers 99
L'option --n-gpu-layers 99 délègue autant de couches que possible au GPU (Metal sur Apple Silicon). Ajustez ce nombre selon votre matériel — essayez 99 d'abord et réduisez-le si vous manquez de mémoire.
Ensuite, configurez Hermes pour utiliser le point de terminaison local. Exécutez l'assistant de configuration et choisissez « local » lorsque demandé :
hermes setup
Ou modifiez ~/.hermes/config.yaml directement :
provider: local model: mistral-7b endpoint: http://127.0.0.1:8080/v1
Aucune clé API n'est nécessaire pour les modèles locaux — le point de terminaison est sur votre machine.
Étape 4 : Tester les performances et ajuster
Démarrez une session Hermes interactive pour tester votre modèle local :
hermes > Quel modèle es-tu et où t'exécutes-tu?
La première réponse peut être lente pendant que le modèle se réchauffe. Les réponses suivantes devraient être plus rapides. Si les performances sont inacceptables :
- Essayez une quantification plus petite : Q4_K_M est un bon équilibre. Q3_K_M utilise moins de RAM mais une qualité légèrement inférieure. Q5_K_M utilise plus de RAM mais une meilleure qualité.
- Réduisez la taille du contexte : Abaissez
--ctx-sizeà 4096 ou 2048. Moins de contexte = plus rapide et moins de RAM. - Ajustez les couches GPU : Sur Apple Silicon, essayez
--n-gpu-layers 99. Si vous avez un GPU dédié, expérimentez avec le nombre. - Utilisez un modèle plus petit : Passez de 8B à 7B ou 3B de paramètres si la vitesse est critique.
- Fermez les autres applications : Les modèles locaux se disputent la RAM. Fermez les onglets du navigateur et les autres applications lourdes avant d'exécuter l'inférence.
Avantages et compromis en matière de confidentialité
L'exécution de modèles localement est la façon la plus privée d'utiliser l'IA — mais elle comporte des compromis. Voici une évaluation honnête :
Avantages
- Rien ne quitte votre machine : Les requêtes, les réponses et les données restent sur votre matériel. Aucun appel réseau vers des API externes.
- Aucune clé API à gérer : Aucun identifiant à divulguer, à renouveler ou à payer. Le modèle est à vous.
- Aucun suivi d'utilisation : Les fournisseurs infonuagiques consignent chaque appel API. Avec les modèles locaux, vous contrôlez toute la journalisation.
- Fonctionne hors ligne : Une fois le modèle téléchargé, vous n'avez pas besoin d'accès Internet. Utile pour les voyages, les sites distants ou les environnements isolés.
- Aucune limite de débit : Exécutez autant de requêtes que vous le souhaitez, aussi vite que votre matériel le permet. Pas de tarification par paliers ni d'anxiété de quota.
Compromis
- Plus lent : Même avec l'accélération GPU, un modèle local 7B est plus lent que les API infonuagiques. Attendez-vous à 10 à 30 jetons/seconde contre 50 à 100+ des fournisseurs infonuagiques.
- Moins performant : Un modèle local 7B ou 8B est nettement moins performant que GPT-4o ou Claude Sonnet 4 — surtout pour le raisonnement complexe, la rédaction longue et le suivi nuancé des instructions.
- Gourmand en RAM : Les modèles consomment beaucoup de mémoire. Une machine de 8 Go exécutant un modèle 7B a peu de RAM restante pour d'autres applications.
- Pas de vision (généralement) : La plupart des modèles GGUF sont textuels seulement. Les modèles locaux compatibles avec la vision existent mais nécessitent plus de configuration et de RAM.
- Maintenance : Vous gérez le processus du serveur llama.cpp — démarrage, arrêt et mise à jour. Ce n'est pas un service infonuagique « configurer et oublier ».
- Appel d'outils limité : Les petits modèles locaux peuvent ne pas produire de manière fiable des appels d'outils structurés. Testez les capacités d'appel d'outils de votre modèle avant de vous y fier pour des flux de travail d'agent complexes.
Résidence des données au Canada et LPRPDE
Pour les organisations canadiennes qui traitent des renseignements personnels en vertu de la LPRPDE, les modèles locaux offrent une proposition convaincante en matière de résidence des données :
- Tout le traitement a lieu sur le sol canadien (votre bureau) — aucune préoccupation de transfert transfrontalier de données
- Aucun processeur tiers à évaluer ou à inclure dans votre évaluation des facteurs relatifs à la vie privée
- Contrôle total sur la conservation et la suppression des données
Cependant, notez que l'exécution d'un modèle local ne vous rend pas automatiquement conforme à la LPRPDE. Vous devez toujours disposer de mesures de protection appropriées, de contrôles d'accès et de politiques de traitement des données. Le modèle élimine simplement le fournisseur d'API tiers de l'équation.
Prochaines étapes
- Configurez des fournisseurs infonuagiques parallèlement à votre modèle local — utilisez le local pour le travail sensible, le nuage pour le raisonnement complexe
- Planifiez des automatisations qui s'exécutent sur votre modèle local pendant la nuit
- Sécurisez votre environnement — même sans clés API, vos fichiers .env et de configuration doivent être protégés
- Explorez l'auto-hébergement sur un serveur Linux dédié avec plus de RAM et de puissance GPU