Un modèle de base, plusieurs adaptateurs : conserver les déploiements sans répéter la base
Un LoRA reste petit jusqu'à ce que son mode d'empaquetage répète cinq fois un grand modèle de base. Lorsque la base et ses adaptateurs forment réellement un ensemble, la question de stockage n'est pas « quel fichier puis-je réduire ? », mais « quelle relation devrai-je récupérer plus tard ? »
Le schéma de base répétée
Il est courant de créer des dossiers de déploiement autonomes, car ils sont pratiques à copier ou à transmettre : un dossier par adaptateur, chacun portant le modèle de base dont il a besoin. Les dossiers sont faciles à comprendre individuellement, mais la bibliothèque devient coûteuse lorsqu'un même modèle de base apparaît dans chaque déploiement.
L'unité utile est la famille liée. Gardez ensemble la base, les adaptateurs et les versions de déploiement lorsque vous pouvez établir la relation en une seule phrase. Ne mélangez pas des modèles non liés simplement parce qu'ils utilisent le même disque.
Pratique localement, mais les mêmes octets peuvent apparaître plusieurs fois sur des versions liées.
Qu'est-ce qui appartient à une même famille ?
- un checkpoint de base avec les LoRAs ou adaptateurs qui lui sont destinés ;
- des déploiements autonomes étroitement liés qui répètent cette base ; ou
- révisions terminées issues d'un projet de modèle unique ayant un objectif de récupération clair.
Ne regroupez pas tous les checkpoints, tous les LoRA et tous les formats de modèles dans une archive gigantesque. Une archive doit réduire l'ambiguïté, pas l'accroître. Si vous ne pouvez pas expliquer pourquoi un fichier appartient à la famille, gardez-le à part.
Ce que montre en réalité le résultat obtenu
Dans l'exemple contrôlé de Tensor Archive portant sur cinq déploiements de modèles et d'adaptateurs, le stockage mesuré atteignait 907.3 MB lorsque chaque déploiement était conservé séparément, contre 261.6 MB au sein d'une famille associée : 71.2% de stockage physique en moins. Ce chiffre illustre le motif de la base répétée, pas une affirmation universelle sur les adaptateurs.
Lisez le périmètre, et pas seulement le pourcentage. Cinq déploiements autonomes associés ont été utilisés, et les restaurations étaient exactes. Un adaptateur individuel, un dossier sans données partagées ou une bibliothèque de modèles non liés peut donner un résultat très différent.
Une méthode sûre pour tester ce motif
- Choisissez la base et uniquement les adaptateurs qui sont véritablement liés à celle-ci.
- Utilisez Add model family → Local folder et exécutez Analyse source.
- Examinez le résultat avant d'archiver ; c'est à ce stade qu'une véritable famille justifie sa place.
- Archivez-le, exécutez Vérifier, puis restaurez une copie séparée.
- Testez la version restaurée dans le workflow qui en a besoin avant de supprimer manuellement toute ancienne copie fonctionnelle.
Gardez le stockage et la transformation séparés
Ce n'est pas une raison pour convertir tous les fichiers ni modifier les poids du modèle. Tensor Archive n'est ni un outil de quantification ni un convertisseur de modèles ; c'est une archive locale de versions associées lorsque la récupération exacte compte. Si le paquet est ambigu, examinez ce que contient un fichier LoRA avant de le regrouper. Pour distinguer stockage et transformation, lisez Stockage SafeTensors ou quantification.
Lorsque la relation est réelle, le workflow est simple : analyser, archiver, vérifier, restaurer, puis choisir manuellement ce qu'il faut supprimer. Téléchargez Tensor Archive pour effectuer ce test sur une famille.
Références
- LoRA : Low-Rank Adaptation of Large Language Models — pourquoi les adaptateurs sont des mises à jour de rang faible séparées d'un modèle de base.
- Résumé du benchmark Tensor Archive — charge de travail de cinq déploiements et preuve de restauration exacte.