Comment choisir, quantifier et évaluer un modèle de langage local

1. Définir le problème avant de choisir le modèle

Un modèle local effectue l’inférence sur du matériel que vous contrôlez, au lieu d’envoyer chaque requête à un service distant. Cela peut réduire l’exposition des données à des tiers et permettre de travailler hors ligne après le téléchargement du modèle et de ses dépendances. Cela ne garantit pas à lui seul la confidentialité : une interface, un module complémentaire, un journal d’activité ou un outil connecté peut encore transmettre des informations.

Commencez par décrire la tâche, les données autorisées, le niveau de qualité minimal et le volume prévu. Un petit modèle peut suffire pour classer des messages ou extraire des champs ; un assistant qui utilise des outils, interprète des documents complexes ou gère de longues conversations exige des tests plus approfondis. Le nombre de paramètres ne prédit pas à lui seul les résultats pour votre cas d’usage.

2. Choisir le modèle, la licence et le format

Comparez des modèles susceptibles de fonctionner dans votre environnement et dont la licence autorise l’usage prévu. Consultez la fiche officielle du modèle : architecture, taille, limites de contexte, langues, capacités multimodales et conditions de redistribution. Vérifiez également que le moteur d’inférence choisi prend en charge cette architecture et cette variante précise des poids. Un grand nombre de paramètres ou une communauté active ne prouvent pas qu’un modèle convient à la production.

GGUF est un format courant dans les flux de travail fondés sur llama.cpp et les outils compatibles, mais il n’est pas indispensable pour exécuter une inférence locale. D’autres piles utilisent des formats et des moteurs différents. Pour chaque candidat, consignez l’identifiant exact, la révision des poids, le format, la quantification, le moteur et la configuration. Vous pourrez ainsi reproduire les tests et repérer les changements lors d’une mise à jour.

3. Quantifier seulement après avoir établi une référence

La quantification réduit la précision numérique des poids ou d’autres valeurs du modèle afin d’économiser de la mémoire et, selon le matériel et le moteur, peut modifier la vitesse d’inférence. Les économies réalisées peuvent permettre de charger des modèles qui ne tiendraient pas dans leur représentation de plus haute précision, mais la qualité peut diminuer. L’effet dépend du modèle, de la méthode, de la tâche et du backend : il ne faut pas promettre une perte fixe ni supposer qu’une étiquette à quatre ou cinq bits suffit à prévoir le résultat.

Q4_0, Q5_1 et Q4_K_M ne sont pas des appellations interchangeables. Ces variantes correspondent à des formats et à des schémas différents ; avant le téléchargement, vérifiez la description de la quantification et la taille réelle du fichier. LoRA, en revanche, est une technique d’adaptation qui ajoute des paramètres ; ce n’est pas un niveau de quantification. Elle peut être combinée à certains flux de quantification, mais ne constitue pas une solution équivalente à Q4 ou Q5.

4. Dimensionner la mémoire et le matériel en prévoyant une marge

Pour estimer la place requise par les poids, multipliez le nombre de paramètres par le nombre d’octets utilisé pour les représenter. Par exemple, un modèle de sept milliards de paramètres en FP16 nécessite environ quatorze milliards d’octets pour ses poids, avant prise en compte des autres consommations. Avec une quantification sur quatre bits, le calcul théorique des poids est inférieur, mais la taille du fichier et la mémoire occupée ne correspondent pas exactement à ce minimum : il faut tenir compte des métadonnées, des échelles, des tenseurs conservés à une autre précision et des besoins du moteur.

La VRAM est importante lorsque des couches sont transférées sur un processeur graphique ; la RAM système permet l’exécution sur processeur ou l’hébergement des parties qui ne tiennent pas dans la mémoire graphique. Le contexte de la conversation, le cache KV, les activations et les requêtes simultanées consomment également de la mémoire. Un fichier qui semble tenir dans la VRAM peut donc échouer au démarrage ou provoquer une saturation avec de longs contextes. La taille du fichier aide à éliminer des options, mais ne suffit pas à finaliser le dimensionnement.

5. Configurer la confidentialité et le fonctionnement hors ligne

L’inférence locale peut maintenir les données sur l’appareil, mais « local » ne signifie pas automatiquement « isolé ». Les téléchargements de modèles, les mises à jour, la télémétrie, les interfaces web, les proxys, les extensions et les journaux peuvent générer des communications. Identifiez chaque composant et déterminez les destinations réseau dont il a besoin. Si le système doit fonctionner sans Internet, téléchargez et vérifiez au préalable les poids, les dépendances et les licences ; testez ensuite le blocage du trafic sortant dans l’environnement réel.

Utilisez la segmentation réseau et des règles de pare-feu fondées sur le moindre privilège. Limitez les accès au point de terminaison d’inférence, évitez de l’exposer directement aux réseaux publics et protégez les journaux. Traitez les prompts, les réponses et les documents comme des données sensibles s’ils contiennent des informations internes. Un test de déconnexion doit confirmer que l’application fonctionne sans appels externes, et pas seulement que le modèle a déjà été téléchargé.

6. Évaluer la qualité, la latence et les performances

Évaluez chaque configuration sur un jeu de tests représentatif et stable, distinct des exemples utilisés pour ajuster les prompts. Pour la qualité, choisissez des métriques adaptées à la tâche : exactitude ou F1 pour la classification, taux de champs corrects pour l’extraction et évaluation humaine fondée sur des critères communs pour les réponses ouvertes. BLEU et ROUGE peuvent être utiles dans certains problèmes de comparaison de textes, mais ne remplacent pas l’évaluation de la factualité, du respect des consignes ou des risques. Un fort recouvrement lexical ne prouve pas que la réponse est correcte.

Mesurez le temps de chargement, le délai avant le premier jeton, le temps total et les jetons par seconde. Distinguez une exécution à froid d’une exécution lorsque le modèle est déjà chargé. Consignez le matériel, le pilote, le moteur, la version du modèle, la quantification, le contexte, la taille des lots et le nombre de requêtes simultanées. L’inférence locale élimine une partie de la latence réseau, mais ne garantit pas une latence totale plus faible : celle-ci dépend de la machine, du modèle et de la charge.

7. Versionner et maintenir le service

Fixez les versions des poids, de la quantification, du moteur, des bibliothèques et de la configuration. Lorsque c’est possible, conservez les sommes de contrôle des artefacts et stockez les modèles dans des emplacements contrôlés. Avant une mise à jour, relancez les tests de qualité, de performance, de compatibilité et d’isolation. Une mise à jour peut modifier les réponses, la consommation mémoire ou le comportement des outils, même si le nom commercial du modèle reste proche.

Surveillez les erreurs, la saturation mémoire, la latence et la disponibilité. Définissez une procédure de retour à une version testée ainsi qu’une politique de retrait des artefacts vulnérables ou dont la licence n’est pas adaptée. Si le système utilise des outils, appliquez le principe du moindre privilège et validez les appels avant leur exécution ; un modèle local peut lui aussi produire des instructions incorrectes ou du contenu manipulé.

8. Liste de contrôle et critères de décision pratiques

La bonne configuration est la plus petite et la plus simple qui satisfasse aux exigences mesurées, pas nécessairement le plus grand modèle ni la quantification la plus agressive. Si une option n’atteint pas le niveau de qualité minimal, changez de modèle ou de configuration et recommencez l’évaluation. Si elle dépasse les limites de mémoire ou de latence, examinez d’abord le contexte, la concurrence et la répartition entre processeur et processeur graphique.

Les sources disponibles étayent les principes généraux de quantification et documentent les options d’une plateforme précise, mais elles n’établissent ni une perte de qualité universelle entre FP16 et une quantification donnée, ni des besoins universels en VRAM pour les modèles 7B ou 13B. Ces valeurs doivent être vérifiées avec l’artefact, le moteur, la tâche et le matériel concernés.

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.