Comment stocker des modèles LLM locaux sans saturer le SSD de votre station de travail

Gardez un petit ensemble actif sur le NVMe de la station de travail, placez la bibliothèque de modèles plus vaste sur un stockage partagé et configurez explicitement les chemins utilisés par chaque runtime.

Cette configuration fonctionne lorsque les poids des modèles sont principalement lus au démarrage, que le réseau permet des temps de chargement acceptables et que les modèles affinés irremplaçables sont protégés séparément des fichiers téléchargeables. Elle échoue lorsque chaque cache bascule discrètement vers le SSD de démarrage ou lorsqu’un NAS indisponible pousse le service d’inférence à télécharger à nouveau les modèles dans un nouveau répertoire local.

Classez les fichiers de modèles selon leur ensemble de travail et leur coût de recréation

Commencez par dresser un inventaire plutôt que de déplacer un énorme répertoire de cache. Les poids de base et les variantes quantifiées peuvent être téléchargés à nouveau, mais les adaptateurs, les modèles affinés, les modèles de prompt, les manifestes, les résultats d’évaluation et les fichiers convertis localement peuvent être uniques. Classez chaque élément comme actif, utilisé de temps à autre, mis en veille ou irremplaçable, puis notez quelle application utilise son chemin.

L’ensemble actif comprend les modèles utilisés chaque jour et doit tenir dans le budget fixe de la station de travail. Les modèles utilisés de temps à autre peuvent résider sur le NAS et être copiés localement avant un projet. Les expériences mises en veille 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 d’origine 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 à peu de frais. Elle fournit aussi 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 des rôles au NVMe local, au stockage partagé et aux archives

Un véritable cluster d’IA locale stockait les fichiers de modèles sur un NAS et les chargeait via une connexion 10 GbE, dé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 à retenir 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 pointez pas tous les environnements d’exécution vers le même dossier réseau accessible en écriture. Un échec de conversion, 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 en lecture seule dans la mesure du possible, préparez les modifications dans un espace de travail temporaire, vérifiez-les, puis promouvez délibérément les artefacts finalisés.

Définissez un chemin de modèles et une stratégie de cache prévisibles

Choisissez un point de montage canonique, par exemple /srv/models sous Linux ou une lettre de lecteur stable sous Windows, et rendez-le disponible avant le démarrage d’Ollama, vLLM, LM Studio ou des conteneurs de développement. Configurez explicitement les chemins des modèles et du cache de chaque outil. Un lien symbolique convient 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 qui envisagent d’utiliser un NAS séparé identifient régulièrement le temps de chargement des modèles comme un facteur décisif. Dans une discussion sur les stations de travail IA et les NAS, des contributeurs ont recommandé de conserver les modèles fréquemment utilisés sur un NVMe local, car le transfert de poids volumineux via une connexion plus lente peut prendre plusieurs minutes.

Utilisez une liste d’autorisation pour le cache local à accès rapide au lieu de répliquer l’intégralité du NAS. Après un chargement ou une copie réussis, vérifiez la taille du fichier ou sa somme de contrôle, puis mettez à jour un alias atomique tel que current/model-name. Supprimez uniquement les modèles qui ne sont ni en cours d’exécution ni épinglés. Conservez au moins le plus élevé de ces deux volumes : 15 % d’espace libre ou un téléchargement de modèle de taille maximale prévue, afin qu’une mise à jour ne remplisse pas le volume de démarrage en cours d’opération.

Featured

NAS cloud personnel et domestique ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Protégez les manifestes et les modèles affinés, pas chaque téléchargement

Sauvegardez les informations nécessaires à la reconstruction de la bibliothèque : URL source ou identifiant du dépôt, révision exacte, nom de fichier, quantification, somme de contrôle, notes sur la licence, configuration d’exécution et chemin utilisé en production. Ce manifeste est compact, facile à rechercher et plus utile lors d’une récupération 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 selon une politique normale de rétention avec gestion des versions. Pour les poids de base publics, déterminez si le délai de récupération justifie une copie supplémentaire. Une connexion Internet lente ou le risque qu’un modèle disparaisse peut justifier la protection de certains poids, mais mettre en miroir chaque expérience gaspille généralement de l’espace de sauvegarde.

Si le choix d’une couche de fichiers IA plus générale n’est pas encore arrêté, la comparaison ZimaSpace entre le cloud personnel et le stockage local sur PC pour les fichiers IA constitue la prochaine étape de planification. Elle distingue les données source et les index persistants de la machine qui effectue l’inférence.

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

Testez trois scénarios avec le service de modèles à l’arrêt : un chargement local à chaud, un chargement à froid depuis le NAS et une panne du NAS. Notez le temps écoulé avant la première réponse exploitable, le débit réseau de pointe, 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 vérifier l’ordre de montage au lieu de le supposer.

La configuration est validée lorsque les modèles utilisés quotidiennement se chargent localement dans le délai attendu, que les modèles rarement utilisés peuvent être transférés sans modification manuelle des chemins, que les artefacts uniques peuvent être restaurés à partir d’une sauvegarde et que l’absence du NAS provoque une erreur claire plutôt qu’un nouveau téléchargement silencieux. Ajoutez un réseau plus rapide ou un niveau de stockage local plus important uniquement lorsque le délai de chargement à froid mesuré interrompt le travail ; augmentez la capacité du NAS lorsque la bibliothèque de référence approche de son seuil minimum d’espace libre défini.

Cessez d’utiliser les lectures directes sur le réseau pour une charge de travail qui effectue régulièrement des recherches dans les fragments de modèles, nécessite un démarrage à faible latence 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é de plus grande capacité avant le lancement.

Règle de configuration finale

Conservez la bibliothèque de modèles de référence sur un 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. Augmentez la capacité lorsque le temps de chargement mesuré ou l’espace disponible dépasse un seuil défini par écrit.