Installer un modèle d’intelligence artificielle en local demande du temps, de la bande passante et souvent plusieurs essais. Pourtant, beaucoup de sauvegardes se limitent au gros fichier de poids. C’est insuffisant. Le jour où le disque tombe en panne ou lorsqu’il faut reconstruire la machine, on retrouve bien le modèle, mais pas forcément la bonne quantification, le prompt système, le modèle d’embedding, les documents du RAG ni les réglages qui rendaient l’ensemble réellement utilisable.
Je préfère donc considérer une IA locale comme un petit environnement logiciel. Une sauvegarde utile doit permettre de répondre à une question simple : puis-je restaurer le même service, avec le même comportement, sans deviner ce que j’avais fait ? Voici une méthode concrète, sans prétendre qu’une copie de dossier résout tout.
Les poids du modèle ne sont qu’une partie de l’installation
Un fichier GGUF ou Safetensors peut peser plusieurs gigaoctets et attirer toute l’attention. Pourtant, le résultat dépend aussi de nombreux éléments plus petits : gabarit de conversation, prompt système, paramètres de génération, version du moteur d’inférence, modèle d’embedding, découpage des documents et éventuels adaptateurs. Oublier ces fichiers revient à conserver le moteur d’une voiture sans noter comment le reste était monté.
Avant toute copie, j’établis donc un inventaire. Il peut tenir dans un simple fichier texte ou un tableur, à condition qu’il indique au minimum le nom exact du modèle, sa source, sa révision, son format, sa quantification et l’application qui le charge. Le dossier BlackFury sur les licences des modèles d’IA locaux explique pourquoi la source et la licence doivent rester associées aux fichiers.
Ce qu’il faut sauvegarder
| Élément | Pourquoi il compte | À conserver |
|---|---|---|
| Modèles principaux | Ils représentent l’essentiel du volume et déterminent les capacités | Fichiers, identifiant du dépôt, révision et quantification |
| Configuration | Elle influence fortement le comportement | Prompt système, template, température, contexte et paramètres |
| Moteur d’inférence | Deux versions peuvent réagir différemment | Nom, version, méthode d’installation et dépendances utiles |
| RAG | L’index seul ne suffit pas toujours à reconstruire la base | Documents sources, règles de découpage, modèle d’embedding et index |
| Workflows | Ils contiennent souvent la vraie valeur du travail | Prompts, modèles de tâches, scripts et fichiers de configuration |
| Preuves | Elles permettent de vérifier la restauration | Sommes de contrôle, manifeste et test de référence |
Figer la source et la révision du modèle
Le nom commercial d’un modèle n’est pas assez précis. Un dépôt peut évoluer, remplacer un fichier ou ajouter une nouvelle quantification. Je note donc l’identifiant complet du dépôt et, lorsque c’est possible, le hash de la révision téléchargée. Cette précaution évite de restaurer plus tard un fichier portant presque le même nom mais issu d’un état différent.
Le cache local de Hugging Face sépare notamment les références, les blobs et les instantanés par révision. La documentation officielle du cache Hugging Face décrit cette organisation. Sur Windows, le fonctionnement peut être dégradé lorsque les liens symboliques ne sont pas disponibles, avec des copies supplémentaires dans les dossiers d’instantanés. Il faut donc vérifier le volume réel avant de dupliquer aveuglément tout le cache.
Ne pas confondre cache et sauvegarde
Un cache accélère le téléchargement et permet de réutiliser des fichiers déjà présents. Il peut cependant être nettoyé, déplacé ou invalidé. Je ne le considère donc pas comme l’unique copie de sécurité. Pour les modèles indispensables, je préfère une archive clairement nommée, accompagnée d’un manifeste et stockée sur un autre support.
La ligne de commande Hugging Face permet aussi d’inventorier les dépôts et les révisions en cache. La commande hf cache verify peut vérifier les sommes de contrôle d’un dépôt ou d’un répertoire local, comme l’indique la documentation officielle de l’outil hf. Ce contrôle ne remplace pas une restauration complète, mais il aide à détecter un fichier manquant ou altéré.
Conserver les réglages qui changent le comportement
Deux installations utilisant les mêmes poids peuvent produire des réponses très différentes. La taille de contexte, la température, le format de conversation, les instructions système et les paramètres d’échantillonnage comptent. J’enregistre ces réglages dans un fichier lisible plutôt que de compter sur ma mémoire ou sur une capture d’écran.
Je note également la quantification exacte. Le guide BlackFury sur la quantification des LLM en 4 ou 8 bits montre pourquoi deux variantes d’un même modèle n’occupent pas la même mémoire et n’offrent pas le même compromis. Le dossier sur la VRAM, la RAM et le contexte d’un LLM local permet ensuite de vérifier que la machine de restauration pourra réellement charger cette variante.
Pour un RAG, sauvegarder les sources avant l’index
Un index vectoriel est pratique, mais il n’est pas toujours portable entre versions ou moteurs. La copie la plus précieuse reste souvent celle des documents sources, accompagnée de la méthode qui a servi à les nettoyer et à les découper. Il faut aussi noter le modèle d’embedding et ses paramètres : changer d’embedding oblige généralement à reconstruire l’index.
Je conserve donc quatre couches séparées : les documents originaux, les documents nettoyés, un manifeste indiquant les règles d’ingestion, puis l’index généré. Si l’index devient incompatible, les trois premières couches permettent de le recréer. Le dossier BlackFury RAG local : fonctionnement, limites et méthode de test complète cette logique avec une procédure d’évaluation.
Séparer les secrets du reste de l’archive
Une configuration peut contenir des jetons d’accès, des mots de passe ou des chemins révélant des informations personnelles. Ils ne doivent pas finir en clair dans une archive partagée ou dans un stockage synchronisé sans protection. Je conserve plutôt un fichier d’exemple décrivant les variables attendues, tandis que les vraies valeurs restent dans un gestionnaire de secrets ou une archive chiffrée distincte.
Cette séparation facilite aussi la restauration : la configuration technique reste lisible et partageable, tandis que les données sensibles suivent leur propre politique. Pour les documents envoyés à un modèle, notre guide sur la confidentialité des prompts et documents IA rappelle les vérifications à effectuer avant toute synchronisation.
Une méthode 3-2-1 adaptée aux gros modèles
Le principe 3-2-1 reste utile : trois copies, sur deux types de supports, dont une hors de la machine principale. Avec des modèles très lourds, il n’est pas nécessaire de multiplier toutes les variantes téléchargées. Je classe les fichiers en trois groupes :
- indispensables : modèles réellement utilisés, configurations et documents sources ;
- reconstructibles : caches et index qui peuvent être régénérés à partir de sources conservées ;
- temporaires : essais abandonnés, téléchargements incomplets et variantes inutilisées.
Cette hiérarchie évite de remplir plusieurs disques avec des doublons sans valeur. Une copie locale rapide protège contre une mauvaise manipulation ; une seconde copie déconnectée protège mieux contre une panne ou un logiciel malveillant ; une copie distante chiffrée peut couvrir le vol ou le sinistre.
Tester la restauration avant d’en avoir besoin
Une sauvegarde jamais restaurée reste une hypothèse. Je recommande un test simple sur un dossier propre ou une autre machine :
- réinstaller la version documentée du moteur d’inférence ;
- restaurer un seul modèle et sa configuration ;
- vérifier les fichiers avec les sommes de contrôle ;
- exécuter un petit jeu de prompts de référence ;
- restaurer ou reconstruire le RAG ;
- comparer les réponses, les sources citées et le temps de chargement ;
- noter ce qui manquait dans le manifeste.
Le but n’est pas d’obtenir des réponses mot pour mot identiques dans tous les cas. Selon le moteur et les paramètres, une génération peut varier. Il faut plutôt vérifier que le bon modèle se charge, que le contexte et les outils sont présents, et que les documents attendus peuvent être retrouvés.
La checklist BlackFury
- Identifiant du modèle, source, licence et révision notés.
- Format et quantification enregistrés.
- Prompt système, template et paramètres exportés.
- Version du moteur d’inférence documentée.
- Documents sources du RAG conservés séparément.
- Modèle d’embedding et règles de découpage notés.
- Secrets retirés de l’archive principale.
- Sommes de contrôle générées ou vérifiées.
- Au moins une copie hors de la machine.
- Restauration réellement testée.
Conclusion : sauvegarder un environnement, pas seulement un fichier
La taille des poids donne l’impression qu’ils constituent toute l’IA locale. En pratique, la valeur se trouve aussi dans les réglages, les sources, les workflows et la capacité à reproduire l’installation. Une sauvegarde bien organisée coûte un peu de temps aujourd’hui, mais elle évite de reconstruire des semaines de décisions le jour où le stockage ou le système doit être remplacé.
