Protocole de décision pour l'inférence locale : de la contrainte VRAM à la validation de l'isolation réseau

Définition du budget mémoire : poids, cache KV et surcharge

La première étape du protocole consiste à déterminer l'empreinte mémoire réelle d'un modèle, qui ne se limite pas aux paramètres quantifiés. La mémoire totale requise est la somme de quatre composants indépendants : les poids du modèle, le cache clé-valeur (KV cache), les activations transitoires et la surcharge du framework d'inférence.

Une erreur courante consiste à appliquer une marge fixe de 20 % sur les poids, ce qui est inexact car ces termes évoluent de manière différente. Par exemple, pour un modèle de 7 milliards de paramètres avec une quantification Q4_K_M, les poids occupent environ 4,9 Go (0,61 octet par paramètre, et non 0,5 comme le suggère la formule simplifiée de 4 bits). Il faut y ajouter le cache KV, qui croît linéairement avec la longueur du contexte. Pour un contexte de 8 000 jetons, le cache KV peut ajouter entre 1 et 2 Go supplémentaires, selon l'architecture d'attention (GQA ou MHA) et la précision du cache (FP16 ou FP8).

La séparation entre ces composants aide à transformer une simple capacité de stockage en un budget opérationnel utile. Les poids représentent le stockage du modèle chargé, tandis que le cache clé-valeur conserve les informations d'attention associées aux jetons qui restent dans le contexte. Les activations, en revanche, sont des données de travail temporaires qui apparaissent pendant le calcul ; leur volume dépend de la manière dont le moteur d'inférence exécute le processus. La surcharge inclut la mémoire utilisée par le framework et l'environnement de calcul, de sorte que la taille du fichier du modèle ne suffit pas à déterminer si une carte graphique peut l'héberger.

Le cache clé-valeur varie avec la longueur du contexte et avec la structure d'attention. C'est pourquoi deux configurations utilisant les mêmes poids peuvent avoir des besoins en mémoire différents lors du traitement de conversations de longueurs variées. Les architectures GQA et MHA organisent différemment les têtes impliquées dans l'attention, et les précisions FP16 ou FP8 déterminent la quantité de mémoire occupée par chaque valeur stockée dans le cache. L'intervalle de 1 à 2 Go pour 8 000 jetons est une estimation conditionnée par ces variables, et non une exigence fixe pour n'importe quel modèle de 7 milliards de paramètres.

Le tableau offre un calcul indicatif pour une combinaison spécifique : modèle de 7 milliards de paramètres, fichier Q4_K_M et contexte de 8 000 jetons. Ses chiffres approximatifs totalisent environ 7,4 Go avant de prendre en compte les variations propres au modèle et au moteur d'inférence. La valeur d'environ 1,5 Go pour le cache clé-valeur dépend, entre autres éléments, du nombre de têtes de clé-valeur et de la dimension des têtes ; elle ne doit pas être transposée sans modification à une autre architecture. De même, la surcharge indiquée correspond à une estimation minimale de la configuration décrite, et non à une constante universelle applicable à toutes les cartes graphiques.

Une carte graphique avec 8 Go de mémoire peut s'avérer suffisante pour cette estimation, mais le total calculé ne décrit pas à lui seul toutes les conditions d'exécution. Le budget doit également laisser de la place pour les activations transitoires et pour la surcharge effective du framework qui ne serait pas reflétée dans un chiffre simplifié. Le contexte demandé peut augmenter la consommation du cache, et une quantification différente modifie l'espace occupé par les poids. Il est donc préférable de comparer chaque composant avec la configuration concrète, plutôt que d'ajouter automatiquement un pourcentage identique à n'importe quel modèle.

Sélection de la quantification : précision effective vs. bits nominaux

Le choix de la quantification doit se baser sur les bits effectifs, et non sur le nom du fichier. Les formats GGUF mélangent les précisions : Q4_K_M équivaut à environ 4,9 bits effectifs (0,61 octet/paramètre), tandis que Q8_0 sont 8,5 bits (1,06 octet/paramètre). Supposer 4,0 bits pour Q4 sous-dimensionne les poids d'environ 20 %, ce qui peut conduire à un choix de matériel insuffisant.

La dégradation de la qualité varie selon la tâche. Q4_K_M offre un équilibre acceptable pour la plupart des cas d'usage généraux, avec une perte de qualité estimée entre 1 % et 3 % par rapport à FP16. Q5_K_M est recommandée si vous disposez de VRAM supplémentaire et si vous avez besoin d'une plus grande précision en raisonnement ou en code. Q8_0 se rapproche de la qualité originale mais double la consommation mémoire par rapport à Q4, ce qui ne la rend viable que sur du matériel haut de gamme ou pour des tâches d'évaluation critiques.

Les bits nominaux identifient une famille de quantification, mais n'expriment pas nécessairement la moyenne de stockage de chaque paramètre dans le fichier complet. Dans le format GGUF, différents tenseurs peuvent utiliser des précisions distinctes et des valeurs auxiliaires, telles que les échelles par bloc, sont également stockées. Les tenseurs d’embedding qui restent non quantifiés contribuent également à la taille finale. C'est pourquoi Q4_K_M n'équivaut pas à quatre bits exacts par paramètre, et le chiffre effectif d'environ 4,9 bits permet d'estimer mieux l'espace occupé par les poids.

Cette différence a un effet direct sur le calcul de la capacité. Appliquer quatre bits exacts produit une estimation inférieure à celle correspondant à 0,61 octet par paramètre pour Q4_K_M ; l'erreur s'accumule en la multipliant par tous les paramètres du modèle. La même précaution s'applique à Q8_0, dont la valeur indiquée est d'environ 8,5 bits ou 1,06 octet par paramètre. Le nom du format sert à reconnaître la quantification, mais les octets effectifs sont la grandeur pertinente pour estimer la mémoire.

La qualité ne se dégrade pas dans la même proportion pour toutes les tâches ni pour tous les modèles. La perte estimée de 1 % à 3 % pour Q4_K_M par rapport à FP16 doit être lue comme une orientation générale, et non comme une garantie de résultat. Une évaluation concrète peut montrer des différences distinctes selon le type de tâche et le critère utilisé pour la mesurer. Pour la même raison, la recommandation de Q5_K_M lorsque l'on recherche une plus grande précision en raisonnement ou en code exprime une option conditionnée par la mémoire vidéo disponible, et non une promesse que la quantification seule assure une réponse correcte.

Q8_0 utilise approximativement le double de la mémoire que Q4 dans la comparaison décrite et se rapproche de la qualité originale, mais ces formulations ne fixent pas un résultat identique pour chaque modèle ou tâche. Le choix pratique combine l'espace disponible avec le niveau de qualité à évaluer. Si le budget oblige à utiliser Q4_K_M, la taille des poids peut être estimée avec ses octets effectifs, tandis que la variation possible de qualité doit être vérifiée sur la tâche correspondante. Plus de mémoire permet d'envisager une quantification différente ; cela n'élimine pas le besoin de valider le comportement du modèle.

Configuration du runtime d'inférence : Ollama, LM Studio ou vLLM

La sélection du moteur d'inférence dépend de la charge de travail. Pour un seul utilisateur sur un poste de travail, Ollama et LM Studio (basés sur llama.cpp) sont comparables en performance et offrent une API compatible OpenAI en localhost. Ollama se distingue par sa facilité d'utilisation et sa gestion des modèles avec une seule commande, tandis que LM Studio propose une interface graphique plus complète pour l'expérimentation.

Pour les environnements de production avec plusieurs utilisateurs simultanés, vLLM est supérieur grâce à son utilisation de l'attention paginée et du traitement par lots continu. Dans des tests de concurrence, vLLM peut servir jusqu'à 44 fois plus de jetons par seconde que llama.cpp sous forte charge. Cependant, pour un utilisateur unique, la différence est minime, ce qui signifie que le choix doit prioriser la facilité d'audit et l'intégration avec le flux de travail existant.

La charge de travail détermine quelle propriété du moteur d'inférence est la plus importante. En usage de bureau avec une seule personne, la facilité d'installation, la gestion des modèles et la manière d'expérimenter peuvent peser plus lourd que le traitement simultané de nombreuses requêtes. Ollama et LM Studio sont décrits ici comme des options basées sur llama.cpp, avec des performances comparables pour cet usage et une API compatible avec OpenAI accessible en local. Cette comparaison n'implique pas que toutes leurs versions, modèles ou configurations aient des performances identiques.

Ollama privilégie une gestion simple depuis la ligne de commande, tandis que LM Studio offre une interface graphique plus large pour l'expérimentation. Le tableau distingue également l'intégration de la gestion de vecteurs associée à LM Studio et le moindre contrôle sur les paramètres avancés attribué à Ollama. Ces caractéristiques aident à choisir selon le flux de travail, mais ne remplacent pas la vérification des exigences concrètes de matériel et de logiciel. L'étiquette « cas d'usage idéal » résume une orientation, elle ne limite pas les outils à un unique objectif.

vLLM est orienté vers les charges avec plusieurs requêtes simultanées et emploie l'attention paginée et le traitement par lots continu. Ces techniques permettent d'exploiter le traitement conjoint sous certaines conditions. Le chiffre de jusqu'à 44 fois plus de jetons par seconde par rapport à llama.cpp correspond à un test de concurrence spécifique ; il ne constitue pas une proportion que l'on peut attendre pour n'importe quel modèle, carte graphique ou configuration. Le résultat dépend des conditions du benchmark et de la manière dont la charge est configurée, de sorte qu'il ne sert pas à lui seul à anticiper les performances d'une installation différente.

La différence entre les moteurs d'inférence se réduit pour un utilisateur unique dans la comparaison décrite, de sorte que les meilleures performances sous forte concurrence ne transforment pas automatiquement vLLM en l'option la plus appropriée pour tous. Sa configuration et ses exigences de carte graphique font également partie de la décision. Pour une installation personnelle, il peut être préférable de privilégier la facilité d'audit et l'intégration avec le flux existant ; en production avec des requêtes simultanées, le traitement par lots peut être plus pertinent. Dans les deux cas, une comparaison représentative doit maintenir constants le modèle, le matériel et les conditions de charge.

Audit de l'isolation réseau : vérifier la confidentialité

L'isolation réseau est une stratégie de sécurité qui consiste à diviser le réseau en segments indépendants pour prévenir l'accès non autorisé ou la fuite de données. Dans le contexte de l'inférence locale, l'objectif est de garantir que le processus d'inférence n'établit pas de connexions sortantes non autorisées, maintenant les données dans la juridiction contrôlée par l'opérateur.

Pour vérifier empiriquement l'isolation, il faut utiliser des outils de surveillance du trafic tels que Wireshark ou tcpdump pour capturer les connexions du processus d'inférence. De plus, des règles de pare-feu peuvent être configurées pour bloquer tout le trafic sortant sauf les connexions nécessaires (s'il y en a). Dans les environnements d'entreprise, cela s'aligne avec les pratiques d'isolation réseau administrée, où l'accès sortant est contrôlé via des points de connexion privés et des étiquettes de service.

L'isolation divise un réseau en segments pour contrôler quelles communications peuvent traverser entre eux. Dans une installation d'inférence locale, cette conception vise à limiter les connexions sortantes du processus et à maintenir les données sous le contrôle de celui qui opère l'environnement. Exécuter le modèle sur une machine locale ne démontre pas à lui seul que le processus est dépourvu d'accès au réseau : la confidentialité dépend également des routes habilitées, des connexions distantes et des règles appliquées à l'équipement.

Wireshark et tcpdump permettent d'observer le trafic pendant un test, tandis que les règles de pare-feu peuvent bloquer les sorties non autorisées. La capture montre les communications qui se sont produites pendant l'intervalle et les conditions examinées ; elle ne démontre pas qu'aucune autre connexion ne puisse se produire sous une charge ou une configuration différente. C'est pourquoi la procédure propose de répéter l'observation avec des charges variées et de la combiner avec des contrôles de pare-feu, au lieu de traiter une capture unique comme une certification absolue.

La révision doit distinguer les connexions attendues de celles qui ne sont pas autorisées pour l'installation. Si le système nécessite une connexion sortante, la règle peut l'autoriser de manière explicite ; s'il ne la nécessite pas, le blocage général réduit les routes disponibles. Les commandes et mécanismes de pare-feu mentionnés correspondent à des exemples d'outils, et non à une politique complète applicable sans adaptation à n'importe quel système d'exploitation ou réseau d'entreprise. La configuration concrète doit refléter l'infrastructure et les services que l'opérateur a autorisés.

Une interface locale ne détermine pas à elle seule la politique de confidentialité de tout le flux. Les routes qui recourent à des modèles cloud, à la recherche web, à des API distantes, à des serveurs MCP externes ou à des téléversements peuvent envoyer des données hors de l'équipement, même si l'interface principale s'exécute localement. Par conséquent, l'audit doit porter sur les connexions du processus et sur les services effectivement activés. L'isolation réseau aide à contrôler ces routes, mais son étendue dépend des règles et des composants inclus dans le test.

Validation de l'intégrité de l'artefact et test de fumée

Avant d'intégrer le modèle dans le flux de travail, il est crucial de vérifier l'intégrité de l'artefact téléchargé. Cela implique de comparer la somme de contrôle (checksum) du fichier GGUF ou safetensors avec celle publiée par le fournisseur ou la communauté. Une divergence indique une possible corruption ou manipulation du fichier.

Une fois l'intégrité validée, un test de fumée minimal doit être exécuté : générer une réponse simple pour confirmer que le modèle se charge correctement en mémoire et produit une sortie cohérente. Ce test doit être réalisé dans un environnement réseau isolé pour ne pas compromettre l'audit de confidentialité. Si le test échoue, il faut revoir la compatibilité entre la quantification, le runtime et le matériel avant de procéder.

La somme de contrôle permet de vérifier si les octets de l'artefact correspondent à une référence publiée. Pour que la comparaison soit utile, la valeur attendue doit correspondre au même fichier et à une source que l'opérateur considère comme valide. Si les deux valeurs diffèrent, le fichier ne correspond pas à cette référence ; la divergence peut être due à une corruption ou à une manipulation, mais le résultat à lui seul n'identifie pas la cause. Un hash concordant ne démontre pas non plus que le modèle est sûr ou que son comportement est correct : il vérifie l'identité des données comparées.

Le test de fumée répond à une question plus ciblée : si le moteur d'inférence peut charger l'artefact dans la configuration actuelle et générer une réponse simple. Une sortie cohérente dans ce test ne valide pas de manière exhaustive la qualité, la précision ni la sécurité du modèle. Il ne démontre pas non plus que tous les contextes ou charges fonctionneront. Si le chargement échoue, examiner la compatibilité entre la quantification, le moteur d'inférence et le matériel permet de localiser d'éventuelles incompatibilités avant d'intégrer le modèle dans le flux de travail.

Maintenir le test dans un environnement réseau isolé évite que la vérification du chargement dépende de connexions sortantes non prévues. La capture de trafic et les règles de pare-feu complètent le calcul de la mémoire et la vérification de la somme de contrôle : chaque contrôle répond à un aspect distinct. La somme de contrôle compare le fichier à une référence ; le test de fumée observe une exécution de base ; l'audit réseau examine les communications dans les conditions testées. Aucune de ces étapes ne remplace les autres ni ne transforme une vérification limitée en une certification complète.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.