Comment stocker des modèles LLM locaux sans remplir le SSD de la station de travail

Conservez un petit ensemble actif sur le NVMe de la station de travail, placez la bibliothèque de modèles plus volumineuse sur le stockage partagé et utilisez des chemins explicites pour chaque environnement d’exécution.

Cette organisation fonctionne lorsque les poids des modèles sont principalement lus au démarrage, que le réseau peut fournir des temps de chargement acceptables et que les fine-tunings irremplaçables sont protégés séparément des fichiers téléchargeables. Elle échoue lorsque chaque cache revient silencieusement au SSD de démarrage ou lorsqu’un NAS indisponible oblige le service d’inférence à retélécharger les modèles dans un nouveau répertoire local.

Classez les fichiers de modèles selon l’ensemble de travail et le coût de reconstruction

Commencez par un inventaire plutôt que de déplacer un immense répertoire de cache. Les poids de base et les variantes quantifiées peuvent être téléchargés à nouveau, mais les adaptateurs, les fine-tunings, les modèles de prompts, les manifestes, les résultats d’évaluation et les fichiers convertis localement peuvent être uniques. Marquez chaque élément comme actif, tiède, froid ou irremplaçable, puis notez quelle application utilise son chemin.

L’ensemble actif contient les modèles utilisés quotidiennement et doit tenir dans un budget fixe de la station de travail. Les modèles tièdes peuvent résider sur le NAS et être copiés localement avant un projet. Les expériences froides peuvent rester uniquement dans la bibliothèque partagée. Les résultats irremplaçables nécessitent une sauvegarde versionnée, même si leur modèle parent peut être téléchargé à nouveau.

Cette classification évite deux erreurs courantes : sauvegarder des centaines de gigaoctets faciles à recréer et supprimer un petit adaptateur ou manifeste difficile à recréer à moindre coût. Elle fournit également le premier chiffre de capacité : la taille de l’ensemble actif plus l’espace libre nécessaire pour un modèle entrant, et non la taille de tous les modèles que vous pourriez tester un jour.

Attribuez les rôles au NVMe local, au stockage partagé et aux archives

Un cluster d’IA local utilisé dans le monde réel stockait les fichiers de modèles sur un NAS et les chargeait via 10GbE, montrant que cette approche est viable lorsque le réseau et le chemin de stockage sont conçus pour les lectures volumineuses. La leçon utile de ce flux de diffusion de modèles reposant sur un NAS est la séparation des rôles : la bibliothèque partagée est la source, tandis que le calcul et la mémoire restent sur le nœud d’inférence.

Ne dirigez pas tous les environnements d’exécution vers le même dossier réseau accessible en écriture. Une conversion échouée, une tâche de nettoyage ou un changement de version pourrait modifier des fichiers utilisés par un autre outil. Gardez la bibliothèque canonique principalement en lecture, préparez les modifications dans l’espace temporaire, vérifiez-les et publiez délibérément les artefacts terminés.

Créez un chemin de modèles et une politique de cache prévisibles

Choisissez un point de montage canonique, comme /srv/models sous Linux ou une lettre de lecteur stable sous Windows, et rendez-le disponible avant le démarrage d’Ollama, de vLLM, de LM Studio ou des conteneurs de développement. Configurez explicitement les paramètres de modèles et de cache de chaque outil. Un lien symbolique est acceptable uniquement si la vérification du montage s’exécute en premier et si la destination ne change jamais entre les redémarrages.

Les utilisateurs de la communauté qui envisagent un NAS séparé identifient régulièrement le temps de chargement des modèles comme limite. Dans une discussion sur une station de travail d’IA et un NAS, les contributeurs ont recommandé de conserver les modèles fréquemment utilisés sur le NVMe local, car les poids volumineux peuvent mettre plusieurs minutes à transiter par une liaison plus lente.

Utilisez une liste blanche pour le cache local actif plutôt que de mettre en miroir l’intégralité du NAS. Après un chargement ou une copie réussie, vérifiez la taille du fichier ou sa somme de contrôle, puis mettez à jour un alias atomique tel que current/model-name. N’évincez que les modèles qui ne sont ni en cours d’exécution ni épinglés. Conservez au moins la plus grande valeur entre 15 % d’espace libre et un téléchargement de modèle correspondant à la taille maximale attendue, afin qu’une mise à jour ne remplisse pas le volume de démarrage en cours de route.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Protégez les manifestes et les fine-tunings, pas chaque téléchargement

Sauvegardez les informations nécessaires pour reconstruire la bibliothèque : URL source ou identifiant du dépôt, révision exacte, nom de fichier, quantification, somme de contrôle, remarques sur la licence, configuration de l’environnement d’exécution et chemin utilisé en production. Ce manifeste est peu volumineux, facile à rechercher et plus utile lors d’une restauration qu’un répertoire rempli de fichiers aux noms ambigus.

Sauvegardez les adaptateurs uniques, les modèles fusionnés, les données d’étalonnage et les résultats d’évaluation avec une conservation versionnée normale. Pour les poids de base publics, déterminez si le délai de restauration justifie une copie supplémentaire. Une connexion Internet lente ou un modèle susceptible de disparaître peut rendre certains poids dignes d’être protégés, mais mettre en miroir chaque expérience gaspille généralement la capacité de sauvegarde.

Si la couche de fichiers d’IA globale n’est pas encore définie, la comparaison de ZimaSpace entre un cloud personnel et le stockage local sur PC pour les fichiers d’IA constitue l’étape de planification suivante. Elle sépare les données sources persistantes et les index de la machine qui effectue l’inférence.

Validez le temps de chargement, le fonctionnement hors ligne et le déclencheur d’extension

Testez trois chemins avec le service de modèles arrêté : un chargement local actif, un chargement froid depuis le NAS et une panne du NAS. Mesurez le délai avant la première réponse exploitable, le débit réseau maximal, l’espace libre de la station de travail avant et après, ainsi que la création éventuelle par un outil d’un répertoire de secours sur le disque de démarrage. Répétez le test après un redémarrage afin de tester l’ordre des montages plutôt que de le supposer.

La configuration est validée lorsque les modèles quotidiens se chargent localement dans le délai attendu, que les modèles froids peuvent être préparés sans modifier manuellement les chemins, que les artefacts uniques sont restaurés depuis la sauvegarde et qu’un NAS manquant provoque une erreur claire plutôt qu’un retéléchargement silencieux. Ajoutez un réseau plus rapide ou un niveau local plus volumineux uniquement lorsque le délai de chargement à froid mesuré perturbe le travail ; ajoutez de la capacité au NAS lorsque la bibliothèque canonique approche du seuil défini d’espace libre.

Cessez d’utiliser des lectures réseau directes pour une charge de travail qui effectue fréquemment des accès dispersés entre les fragments d’un modèle, exige une faible latence de démarrage prévisible ou doit fonctionner lorsque le NAS est hors ligne. Dans ce cas, conservez le NAS comme bibliothèque et copiez les modèles complets sur un SSD local dédié plus volumineux avant le lancement.

Règle de configuration finale

Conservez la bibliothèque canonique de modèles sur le stockage partagé, épinglez l’ensemble de travail quotidien sur le NVMe local, isolez les caches jetables et protégez uniquement les artefacts et les manifestes qui ne peuvent pas être recréés. Étendez la configuration lorsque le temps de chargement ou la capacité mesurée dépasse un seuil défini par écrit.