LLM 101 : Guide pratique (Édition 2026)

Commencez par la boucle. Le texte devient des tokens. Les tokens traversent un Transformer. L’attention décide quels tokens précédents sont importants. Le runtime conserve un cache KV pour que le modèle ne recalcule pas toute la conversation à chaque fois. Ensuite, le modèle choisit le token suivant et recommence.

Un guide pratique sur le fonctionnement des LLMs, comment les modèles pensent un token à la fois, et comment les exécuter localement.

Une fois que cette boucle est comprise, les choix matériels et logiciels deviennent plus faciles à raisonner. VRAM, quantification, longueur de contexte, templates de chat, décodage, RAG, moteurs de service et sélection de modèles découlent tous des mêmes mécanismes.

Commencez par la boucle : tokens en entrée, probabilités en sortie, un token suivant à la fois. Les poids disent au modèle quels motifs il a appris. Le contexte lui dit ce qu’il regarde maintenant. Le cache KV est la mémoire de travail qui rend la boucle utilisable. Le matériel, les runtimes et la sélection de modèles n’ont de sens qu’après avoir compris les règles de mémoire, de contexte et de formatage auxquelles le modèle obéit.

L’objectif est de rendre les mécanismes des LLMs locaux intuitifs d’abord, puis de vous donner un chemin pratique vers le matériel, les runtimes, le service et la recherche actuelle sur les LLMs en date du 21 mai 2026.

Focus

Ceci est un guide centré sur le modèle. Il commence par les mécanismes : inférence, tokens, Transformers, attention, cache KV, préremplissage, décodage, contrôles de décodage, packages de modèles, templates de chat, types de modèles, contexte long, RAG, agents, fine-tuning et modèles multimodaux.

Ensuite, il aborde la couche de déploiement local : ce que « local » signifie vraiment, quantification, calcul de VRAM, niveaux de matériel, choix de runtime, modes de service, licences, sélection de modèles, confidentialité, dépannage, benchmarks, chemins d’installation et cas d’usage pratiques.

Cet ordre est important. Vous devriez comprendre pourquoi une longue invite coûte de la mémoire avant de choisir un GPU. Vous devriez comprendre pourquoi les templates de chat sont importants avant de juger un modèle. Vous devriez comprendre pourquoi le décodage est séquentiel avant de vous soucier des tokens par seconde.

Pour le chemin plus approfondi vers le matériel et le logiciel, j’ai une série en trois parties qui enseigne l’auto-hébergement des LLMs / IA locale :

Partie 1 : Calcul mémoire GPU pour les LLMs (édition 2026)
Partie 2 : Bande passante mémoire pour le matériel IA local (édition 2026)
Partie 3 : Moteurs d’inférence pour LLMs et matériel IA local (édition 2026)

Les deux premières pièces expliquent la capacité matérielle et le calcul de bande passante. La troisième explique la couche logicielle qui transforme ce matériel en une inférence utilisable. Cet article vous donne d’abord les fondations côté modèle, puis renvoie à ces couches de déploiement une fois les mécanismes clarifiés.

Ce que fait réellement un LLM

Exécuter un modèle s’appelle l’inférence. Pour un LLM standard de type decodeur seulement, l’inférence est la même boucle répétée encore et encore :

Convertissez votre texte en tokens.
Alimentez le modèle avec ces tokens.
Calculez des scores pour chaque token suivant possible.
Choisissez un token avec une politique de décodage.
Ajoutez ce token à la séquence.
Répétez jusqu’à ce que le modèle s’arrête, que l’utilisateur l’arrête, ou qu’une limite de tokens soit atteinte.

Le modèle n’écrit pas une réponse entière en une seule fois. Il génère un token à la fois. Chaque nouveau token devient une partie de la séquence qui influence le token suivant.

Mathématiquement, le modèle est une fonction apprise :

f(theta, séquence) -> distribution de probabilité sur le token suivant

Où :

theta représente les poids du modèle.
séquence représente l’invite ainsi que les tokens générés jusqu’à présent.
Les logits sont les scores bruts avant softmax.
Les probabilités sont les scores normalisés après softmax.
Le décodage transforme ces probabilités en un token sélectionné.

C’est pourquoi la vitesse de génération locale est mesurée en tokens par seconde. Votre système exécute à plusieurs reprises un passage avant, choisit ou échantillonne un token, met à jour le cache KV et continue.

La perception compte ici. Un long préremplissage signifie une longue pause avant l’apparition du premier mot. Un décodage lent signifie que la réponse arrive lentement. Les constructeurs locaux se préoccupent souvent de la vitesse de décodage car c’est ce que les utilisateurs ressentent, mais le temps de préremplissage est ce qui fait mal quand vous collez un document de 10 000 tokens.

Tokens

Les LLMs ne voient pas le texte brut comme des mots. Ils voient des tokens : de petits morceaux de texte représentés en interne par des identifiants entiers.

Un token peut être :

Un mot entier : « hello »
Un fragment de mot : « inter », « nation », « alization »
Un signe de ponctuation
Une chaîne avec un préfixe d’espace
Un repli au niveau octet
Un marqueur de contrôle spécial tel que <|user|>, <|assistant|>, , ou

Le tokeniseur fait correspondre le texte aux identifiants de tokens et les identifiants de tokens au texte. Les familles courantes de tokeniseurs incluent les tokeniseurs de type BPE et de type SentencePiece. Différentes familles de modèles utilisent différents tokeniseurs, et cela compte. Un document de 4 000 mots peut correspondre à 5 000 tokens avec un tokeniseur et à 7 500 tokens avec un autre.

La taille du vocabulaire compte aussi. Un tokeniseur avec un vocabulaire plus large peut compresser certains textes en moins de tokens, mais cela modifie également la taille des embeddings et de la projection de sortie. C’est une des raisons pour lesquelles les tokens par seconde ne sont pas parfaitement comparables entre familles de modèles.

Les tokens sont importants car ils déterminent :

La quantité de texte qui tient dans la fenêtre de contexte.
La taille du cache KV.
La latence que vous payez pendant le traitement de l’invite.
L’efficacité du texte multilingue ou riche en code.
Si le modèle voit correctement les marqueurs de chat spéciaux.

La fenêtre de contexte d’un modèle est le nombre maximum de tokens qu’il peut traiter à la fois. En 2026, les modèles locaux courants vont de 8K et 32K à 128K, 256K, et même 1M de tokens dans les systèmes de classe serveur.

Mais la longueur de contexte prise en charge n’est pas la même chose qu’un contexte bon marché, rapide ou également précis. Un modèle qui peut techniquement gérer 128K tokens peut ralentir considérablement à 64K et perdre sa cohérence à 100K. Testez toujours les longueurs de contexte que vous prévoyez d’utiliser.

Les tokens sont l’unité de travail. Une fois que vous comprenez cela, le contexte long cesse de paraître magique et devient une facture que vous pouvez estimer.

Exercice utile : essayez mon application de démonstration du tokeniseur pour voir comment le texte est découpé en tokens en temps réel.

Transformers

La plupart des LLMs modernes sont basés sur l’architecture Transformer. La plupart des LLMs de chat locaux sont des Transformers de type decodeur seulement : ils prédisent le token suivant tout en regardant les tokens précédents.

Tout ce qui précède ce point, y compris les tokens, les poids, la configuration et les templates de chat, est une préparation pour le véritable moteur sous-jacent. Le Transformer est le squelette qui déplace les nombres.

Une couche simplifiée de Transformer contient :

Embeddings de tokens : les identifiants de tokens deviennent des vecteurs.
Information positionnelle : le modèle a besoin de l’ordre des tokens. De nombreux LLMs modernes utilisent RoPE (Rotary Position Embeddings), qui encode la position en faisant tourner les représentations.
Self-attention : chaque représentation de token regarde les représentations des tokens précédents et décide ce qui est important.
Bloc MLP / feed-forward : un calcul non linéaire dense qui expande et compresse les représentations. Une grande fraction des paramètres se trouve ici.
Normalisation de couche et connexions résiduelles : elles stabilisent les réseaux profonds et aident l’information à circuler à travers plusieurs couches.
Projection de sortie : l’état caché final devient des logits sur le vocabulaire.

Empilez cette recette des dizaines ou des centaines de fois et vous obtenez un modèle de langage.

Récapitulatif du Transformer : les tokens deviennent des vecteurs, l’attention relie la séquence, les MLPs remodèlent la représentation, RoPE maintient la position droite, et la projection finale transforme le dernier état caché en logits du token suivant.

Attention

L’attention est la façon dont un token décide quels tokens précédents sont importants pour la prédiction suivante. C’est aussi l’une des raisons pour lesquelles l’inférence locale est si sensible à la mémoire.

La MHA classique (multi-head attention) stocke des états clé/valeur séparés pour de nombreuses têtes. Elle donne de la flexibilité au modèle, mais rend le cache KV volumineux.

Les modèles locaux modernes utilisent souvent des conceptions d’attention plus efficaces :

MQA : plusieurs têtes de requête partagent une seule tête clé/valeur. C’est efficace en mémoire, mais peut être moins expressif.
GQA : des groupes de têtes de requête partagent des têtes clé/valeur. C’est le compromis courant dans de nombreux modèles locaux actuels.
MHA : attention multi-têtes complète. Elle peut être puissante, mais le contexte long devient rapidement coûteux.

Des kernels modernes tels que FlashAttention et les implémentations de type SDPA réduisent le trafic mémoire de l’attention et maintiennent le GPU plus occupé. Un runtime avec de bons kernels d’attention peut être considérablement plus rapide qu’un autre, même sur le même modèle et le même matériel.

C’est pourquoi deux modèles 7B peuvent se comporter très différemment en contexte long. Le nombre de paramètres ne fait pas tout. Un modèle 7B MHA avec un contexte de 128K peut épuiser un GPU de 24 Go, tandis qu’un modèle 7B GQA avec le même contexte annoncé peut tenir avec de la marge.

Lorsque vous comparez des modèles, regardez le type d’attention, le nombre de têtes KV, la longueur de contexte et le support du runtime, pas seulement le nombre de paramètres.

Cache KV

Le cache KV est la mémoire de travail du modèle pendant la génération. Il stocke les états d’attention clé/valeur des tokens précédents afin que le modèle n’ait pas à recalculer tout l’historique à partir de zéro à chaque token généré.

Sans cache KV, la génération serait brutalement inefficace. Avec un cache KV, la génération est utilisable, mais le cache consomme une mémoire proportionnelle à :

tokens × couches × têtes_KV × dimension_tête × précision × 2

Le × 2 est pour les clés et les valeurs.

Une règle empirique utile pour les anciens modèles 7B MHA de type Llama est d’environ 0,5 Mio par token en cache KV FP16. Cela signifie que 4K tokens peuvent coûter environ 2 Gio rien que pour le cache KV. À 32K tokens, vous pourriez avoir besoin de 16 Gio de cache KV seul.

Les modèles GQA/MQA plus récents réduisent considérablement cela. Certains runtimes supportent également le cache KV en FP8 ou INT8. C’est souvent le plancher de compression pratique que je recommanderais pour les utilisateurs locaux en 2026.

Ne traitez pas le cache KV en dessous de 8 bits comme une option par défaut. Des systèmes de recherche comme KIVI, KVQuant et des kernels de cache compressé plus récents montrent que le cache KV en 2 à 4 bits peut fonctionner avec des algorithmes minutieux, une calibration et des kernels personnalisés. Ce n’est pas la même chose que d’activer négligemment un toggle KV Q4 dans un runtime de bureau. En dessous de 8 bits, faites des benchmarks rigoureux, surtout pour le codage, les appels d’outils, le JSON, la récupération en contexte long et les tâches où les tokens précédents exacts comptent.

Ne confondez pas non plus la quantification du cache KV avec le décodage spéculatif. DFlash et DDTree, souvent abrégés de manière informelle en DTree, attaquent la latence de décodage en rédigeant des tokens futurs et en les vérifiant. Ils peuvent améliorer la vitesse, mais ils n’effacent pas la facture mémoire du cache KV.

C’est pourquoi un modèle peut tenir avec une invite vide mais planter lorsque vous chargez un long document. Les poids tiennent. La mémoire de travail, non.

Préremplissage et décodage

L’inférence des LLMs a deux régimes de performance différents : le préremplissage et le décodage.

Le préremplissage traite l’invite que vous avez donnée au modèle. Si vous collez un document de 20 000 tokens, le modèle doit traiter ces 20 000 tokens avant de pouvoir produire le premier token de réponse. Le préremplissage est relativement parallélisable, donc les GPU peuvent le gérer efficacement, mais il peut encore être coûteux.

Le temps que vous passez à attendre l’apparition du premier token est généralement le temps de préremplissage.

Le décodage génère de nouveaux tokens un à la fois. Chaque token généré dépend de la séquence jusqu’à présent, donc le décodage est beaucoup plus séquentiel. C’est là que vient l’effet de frappe en continu, et c’est généralement la phase qui détermine si un modèle semble rapide ou lent.

Les longues invites pénalisent le préremplissage. Les longues réponses pénalisent le décodage. Les longues conversations pénalisent les deux, car le cache KV grandit.

Dans une session de chat, chaque tour ajoute au cache. Si vous laissez une conversation atteindre 16K tokens, vous payez le coût mémoire pour les 16K tokens à chaque nouveau token généré. C’est pourquoi les interfaces de chat qui conservent un historique infini finissent par ralentir ou planter.

Décodage

Après que le modèle a produit des logits, il n’a encore rien écrit. Il n’a fait que scorer chaque token suivant possible. Le décodage est la politique qui transforme ces scores en un token réel, ajoute ce token au contexte et répète la boucle.

Le runtime, ou moteur d’inférence, peut choisir les tokens de plusieurs façons. Il peut choisir le token avec la probabilité la plus élevée à chaque fois. Il peut échantillonner à partir d’un ensemble réduit de tokens probables. Il peut pénaliser la répétition. Il peut s’arrêter à un délimiteur. Il peut utiliser une graine fixe pour que la même invite se comporte de manière reproductible.

Ces choix ne modifient pas les poids du modèle, mais ils changent la voix, le déterminisme, la créativité, le profil de risque et la tendance à boucler du modèle.

Les boutons importants répondent à trois questions pratiques :

Aléatoire : combien de variation est autorisée ?
Portée de la queue : jusqu’où le sampler peut-il aller dans les tokens de faible probabilité ?
Limites : qu’est-ce qui empêche les boucles, les divagations, les ruptures de schéma ou les sorties incontrôlées ?

Pour un travail précis, commencez de manière étroite : température basse, limites de tokens max courtes, séquences d’arrêt explicites et décodage contraint lorsque la sortie doit correspondre à du JSON ou à un schéma. Pour un travail créatif, donnez plus de liberté au sampler avec une température plus élevée, top-p, et plusieurs candidats classés ensuite. Pour le codage, gardez le premier passage conservateur, puis échantillonnez des alternatives seulement lorsque vous explorez intentionnellement.

Le décodage glouton n’est pas toujours plus précis. Il est souvent fragile. Un décodeur glouton peut se bloquer dans des boucles ou produire des réponses génériques parce qu’il n’explore jamais d’alternatives. Pour les évaluations, utilisez des paramètres déterministes. Pour l’idéation, laissez le modèle respirer.

Ce que contient un package de modèle

Un LLM local exécutable est plus qu’un seul gros fichier de poids. Un package de modèle comprend généralement :

Architecture/configuration : nombre de couches, taille cachée, type d’attention, paramètres RoPE, taille du vocabulaire, tokens spéciaux et longueur de contexte.
Poids : les paramètres appris, souvent stockés sous forme de safetensors, GGUF, GPTQ, AWQ, EXL2 ou un autre format spécifique au runtime.
Tokeniseur : les règles qui transforment le texte en identifiants de tokens et les identifiants de tokens en texte.
Template de chat : le balisage exact pour les messages système, utilisateur, assistant, outil et raisonnement.
Configuration de génération : valeurs par défaut pour la température, top-p, tokens d’arrêt, pénalités de répétition et tokens max.
Licence et fiche modèle : les instructions légales et opérationnelles sur la façon dont le modèle peut être utilisé.

Les poids sont le fichier le plus volumineux, mais ils ne constituent pas l’intégralité du modèle. Si le tokeniseur, la configuration ou le template de chat est incorrect, les mêmes poids peuvent sembler cassés.

La section package vous indique ce qui doit voyager ensemble. La section suivante explique pourquoi le template de chat est la partie que les gens cassent le plus souvent.

Templates de chat

Un modèle de chat a été entraîné avec un format de conversation spécifique. Par exemple, il peut s’attendre à quelque chose comme :

<|system|> Vous êtes un assistant utile. <|user|> Expliquez le cache KV. <|assistant|>

Un autre modèle peut s’attendre à :

[BOS] [INST] Expliquez le cache KV. [/INST]

Un autre peut utiliser des marqueurs de type ChatML. Un autre peut nécessiter des tokens de raisonnement spéciaux. Un autre peut avoir besoin de wrappers XML ou JSON pour les appels d’outils.

Utiliser le mauvais format peut provoquer du charabia, une confusion des rôles, des invites système ignorées, des invites répétées, des bizarreries de refus, des appels d’outils cassés, de mauvais résultats de benchmark et des conclusions selon lesquelles le modèle est stupide alors que le template est le véritable bug.

Meilleures pratiques :

Utilisez apply_chat_template du tokeniseur lorsque vous utilisez Transformers.
Utilisez des templates spécifiques au modèle dans les frontends basés sur Harbor, llama.cpp, LM Studio, vLLM ou SGLang.
Vérifiez si le modèle est base, instruct, chat, raisonnement ou orienté outils.
Assurez-vous que les tokens BOS/EOS sont corrects.
Gardez les invites système courtes sauf si elles doivent être longues.
Pour l’utilisation d’outils, suivez le schéma exact attendu par le modèle/runtime.

Si vous construisez une application qui permet aux utilisateurs de changer de modèle, vous avez également besoin d’un changement de template. Coder en dur un format de template puis charger un modèle qui en attend un autre est une source courante de mauvaises évaluations de modèles locaux.

Traitez le template comme un contrat API. Si vous vous trompez, vous ne testez pas vraiment le modèle que vous pensez tester.

Types de modèles

Tous les LLMs ne sont pas réglés pour le même comportement.

Pour la plupart des utilisateurs, le point de départ par défaut devrait être un modèle récent de type instruct/chat, dans une taille qui tient confortablement en mémoire.

Ne commencez pas avec un modèle de base sauf si vous savez pourquoi. Les modèles de base complètent votre invite plutôt que d’y répondre. Ils sont utiles pour les chercheurs, les affineurs et les personnes construisant des pipelines personnalisés. Ils sont frustrants pour tout le monde.

Si vous demandez à un modèle de base « Quelle est la capitale de la France ? », il pourrait continuer avec « et quelle est la population de Paris ? » au lieu de répondre « Paris ».

La scission pratique est simple :

Modèle de base : bon pour la recherche en pré-entraînement, le fine-tuning et les pipelines personnalisés.
Modèle instruct : bon pour le suivi direct d’instructions.
Modèle de chat : bon pour les dialogues multi-tours avec formatage des rôles.
Modèle de raisonnement : bon lorsque la tâche bénéficie de tokens de réflexion supplémentaires et de vérification.
Modèle orienté outils : bon lorsque les appels structurés, le JSON ou l’utilisation de fonctions comptent.

Ce que signifie vraiment « local »

Un LLM local est un modèle dont les poids et le runtime d’inférence sont sous votre contrôle. Vous décidez quel modèle s’exécute, comment il s’exécute, quelles données il voit et ce qui arrive aux sorties.

Cette liberté a un prix. Vous êtes maintenant l’équipe ops. Vous gérez les téléchargements, les mises à jour, la compatibilité, les limites de mémoire et la sécurité. Quand quelque chose casse, il n’y a pas de ticket de support à soumettre. Il n’y a que vous, les logs et la documentation.

Local peut signifier :

Un modèle de 2 milliards de paramètres fonctionnant sur un téléphone.
Un modèle de 7 à 14 milliards de paramètres fonctionnant sur un GPU grand public.
Un modèle de 30 à 70 milliards de paramètres fonctionnant sur une station de travail haut de gamme.
Un modèle MoE sparse fonctionnant sur un ou plusieurs GPU de datacenter.
Un déploiement privé utilisant vLLM, SGLang, TensorRT-LLM, llama.cpp, Harbor, LM Studio ou une pile PyTorch personnalisée.

Le point clé : local ne signifie pas automatiquement hors ligne, privé, sûr, bon marché ou open source. Cela signifie seulement que vous exécutez le modèle vous-même. Une application locale peut toujours téléphoner à la maison. Un modèle peut être open-weight mais pas open source. Un modèle peut être local mais dangereux à charger. Un modèle quantifié peut tenir en mémoire mais répondre mal.

Le compromis en vaut la peine lorsque vous avez besoin de confidentialité, de faible latence, de comportement personnalisé, de fonctionnement hors ligne ou de contrôle des coûts à grande échelle. Il n’en vaut pas la peine lorsque vous avez besoin de la meilleure qualité de modèle absolue et que vous n’avez pas le matériel correspondant. Dans ce cas, une API hébergée est l’outil approprié.

Les LLMs locaux sont pratiques lorsque vous comprenez une équation :

Succès d’un LLM local = adéquation du modèle + format d’invite correct + bon runtime + évaluations réalistes.

Tout le reste n’est que détails. Les détails comptent.

Quantification

La quantification stocke les poids dans une précision inférieure pour réduire la mémoire et parfois améliorer le débit.

La règle empirique de 2026 pour les utilisateurs locaux :

FP16/BF16 : meilleure qualité lorsque la mémoire est abondante. Utilisez-le comme base de référence pour l’évaluation.
Q8 / INT8 : quasi sans perte pour de nombreuses tâches, mais toujours volumineux. Bon quand vous avez de la VRAM et que vous voulez une perte de qualité minimale.
Q6 / Q5 : excellente qualité avec des économies modérées. C’est un bon compromis solide.
Q4 : le point idéal grand public par défaut pour de nombreux flux de travail de chat et de documents.
Q3 / Q2 : uniquement lorsque vous devez faire tenir un modèle plus gros. Les maths, le code, les sorties structurées et l’utilisation d’outils se dégradent en premier.

La quantification des poids n’est pas la même chose que la quantification du cache KV. La quantification des poids réduit la taille du modèle. La quantification du cache KV réduit la mémoire de contexte en direct.

Pour le cache KV, traitez FP16/BF16 comme la base propre et FP8/INT8 comme le plancher de compression local pratique. En dessous de 8 bits, c’est lourd en recherche et sensible à la charge de travail. Utilisez-le seulement après avoir mesuré la qualité sur vos vraies invites.

L’échec de la quantification se manifeste d’abord dans les maths, le raisonnement multi-étapes, la correction du code, la fiabilité de l’utilisation d’outils, la conformité JSON/schéma, le suivi subtil d’instructions et la récupération en contexte long.

Un modèle plus petit avec une précision plus élevée peut battre un modèle plus gros écrasé dans trop peu de bits. Ne vénérez pas le nombre de paramètres. Un modèle 7B en Q6 peut battre un modèle 13B en Q2 sur des tâches de raisonnement tout en utilisant moins de mémoire et en tournant plus vite.

Formats de fichier et sécurité de chargement

safetensors est un format de sérialisation de tenseurs sûr, conçu pour stocker des tenseurs sans comportement de pickle Python. Utilisez safetensors lorsque c’est possible, en particulier pour les modèles PyTorch/Transformers.

Évitez les fichiers .bin aléatoires provenant de sources non fiables. Le chargement basé sur pickle PyTorch peut exécuter du code arbitraire pendant la désérialisation. Règle de sécurité numéro un de l’IA locale : ne laissez pas le fichier d’un modèle inconnu devenir une exécution de code inconnue.

GGUF est le format de modèle binaire de l’écosystème llama.cpp. Utilisez GGUF lorsque vous voulez llama.cpp, l’inférence CPU, l’inférence Apple Silicon, des serveurs locaux simples, des modèles quantifiés portables ou des outils de bureau comme LM Studio.

ONNX est utile pour le déploiement standardisé et l’accélération matérielle spécifique, en particulier en dehors de la pile PyTorc habituelle. Si vous déployez sur des NPU Intel, des appareils ARM ou des accélérateurs personnalisés, ONNX est souvent le chemin de moindre résistance.

TensorRT-LLM est le chemin d’inférence haute performance de NVIDIA pour les déploiements GPU de production. Il est puissant, mais plus complexe que llama.cpp ou Harbor. Vous devez généralement convertir un checkpoint en moteurs TensorRT, ce qui prend du temps et de la mémoire GPU, mais offre un excellent débit une fois construit.

Les formats EXL2 / GPTQ / AWQ sont courants dans les communautés d’inférence locale axées sur GPU, en particulier pour faire tenir des modèles plus gros sur un seul GPU.

Le choix du format de fichier n’est pas cosmétique. Il détermine quels runtimes peuvent charger le modèle, quelle quantification vous pouvez utiliser et à quelle vitesse il tourne.

Runtimes et modes de service

Un runtime est le logiciel qui charge le modèle et effectue l’inférence. En 2026, l’écosystème des runtimes LLM locaux est mature, utile et fragmenté.

Pour une seule personne expérimentant localement, commencez avec Harbor, LM Studio ou llama.cpp. Harbor est le meilleur choix lorsque vous voulez une pile locale complète avec des frontends, des backends et des services de support interconnectés. LM Studio est le chemin le plus simple orienté bureau. llama.cpp est le cheval de bataille portable de bas niveau.

Pour une équipe ou un service privé, regardez vLLM ou SGLang. Pour des performances de production NVIDIA maximales, examinez TensorRT-LLM. Pour un déploiement navigateur ou mobile, regardez MLC ou WebLLM.

Le choix du runtime vous enferme souvent dans un écosystème de format. llama.cpp signifie GGUF. vLLM et SGLang signifient généralement safetensors ou checkpoints Hugging Face. TensorRT-LLM signifie ONNX ou moteurs optimisés. Choisissez d’abord le runtime, puis trouvez des modèles dans le bon format.

Il existe trois modes de service pratiques.

Monoutilisateur local signifie une application de bureau, une pile CLI ou un serveur en ligne de commande pour une personne. Harbor, LM Studio, le serveur llama.cpp, ExLlama/TabbyAPI et les petits scripts Transformers entrent tous dans cette catégorie. L’objectif est l’itération rapide : comparer le comportement, la vitesse, l’utilisation mémoire et les formats d’invite sans construire de plateforme ops.

API d’équipe ou privée signifie un point de terminaison compatible OpenAI sur une station de travail ou un serveur. vLLM, SGLang, TensorRT-LLM et le serveur llama.cpp apparaissent ici en fonction de la taille du modèle et des besoins en débit. Lorsque plusieurs personnes ou tâches partagent un modèle, vous avez besoin de surveillance, de gestion des invites/versions, de routage et de mesures de latence réalistes.

La mise en production est un métier différent. Désormais, la conversation inclut le continuous batching, le prefix caching, le speculative decoding, la paged attention, le tensor parallelism, le pipeline parallelism, le quantized serving, les structured outputs, le load balancing, l'utilisation du GPU, les percentiles de latence, le prompt caching, l'admission control, la journalisation, le failover, la confidentialité et le contrôle des coûts.

À l'échelle de la production, « puis-je charger le modèle ? » est la question facile. La question difficile est : puis-je le servir de manière fiable sous un trafic réel ?

Calcul de la VRAM pour les modèles locaux

Il y a trois principaux consommateurs de mémoire :

Les poids du modèle
Le cache KV
La surcharge d'exécution

La formule approximative pour la mémoire des poids est :

poids_mémoire ≈ paramètres × octets_par_paramètre

Ordres de grandeur utiles :

FP16/BF16 : Environ 2 octets par paramètre.
INT8/Q8 : Environ 1 octet par paramètre.
Q4 : Environ 0,5 octet par paramètre, plus la surcharge du format.

Ajoutez ensuite :

Surcharge d'exécution : tampons du framework, overhead CUDA, fragmentation mémoire et tenseurs temporaires.
Cache KV : augmente avec chaque token dans le contexte actif.
Mémoire de batch/concurrence : chaque requête simultanée a besoin de son propre cache.
Mémoire de l'encodeur visuel : les images deviennent aussi des tokens.
Mémoire de décodage spéculatif : les modèles de brouillon, les têtes de brouillon ou les structures de vérification supplémentaires ne sont pas gratuites.
Mémoire des adaptateurs : les adaptateurs LoRA sont petits, mais bien réels.

Les modèles MoE ajoutent une complication supplémentaire. Un modèle peut n'activer qu'une fraction de ses paramètres par token, mais les experts inactifs doivent généralement résider quelque part en mémoire. Les paramètres actifs affectent le coût de calcul. Le nombre total de paramètres affecte toujours le chargement et la planification de capacité.

Une estimation réaliste ressemble à :

mémoire_totale = poids_quantifiés + cache_KV_pour_contexte + surcharge_d'exécution + surcharge_de_batch_ou_concurrence + marge_de_sécurité

Voici le piège : Un modèle 13B en Q4 peut tenir facilement avec un contexte de 8K, puis échouer à 32K parce que le cache KV a quadruplé. Les poids n'ont pas changé. Le contexte, si.

Laissez 10 à 20 % de marge. Fonctionner à 99 % d'utilisation de la VRAM, c'est demander des erreurs de mémoire insuffisante et des échecs de fragmentation.

Niveaux de matériel en pratique

Voici des ordres de grandeur pratiques pour 2026, en supposant une inférence quantifiée et des longueurs de contexte raisonnables. Les résultats exacts dépendent de l'environnement d'exécution, de la quantification, de l'architecture du modèle, du type d'attention, de la longueur du contexte et de la surcharge du système d'exploitation/des pilotes.

Pour la plupart des utilisateurs locaux sérieux en 2026, 16 Go est le niveau GPU minimum confortable, 24 Go est le meilleur rapport qualité-prix pour les passionnés, et 48 Go et plus est là où le monde local plus puissant s'ouvre.

Les performances dépendent de la bande passante mémoire, des FLOPs du GPU, de la capacité VRAM, de la taille du cache KV, de l'implémentation de l'attention, de la quantification, de la taille du batch, de la longueur de l'invite, de la longueur générée et de la maturité de l'environnement d'exécution.

Le décodage est souvent limité par la bande passante mémoire : Le GPU diffuse les poids de manière répétée tout en effectuant relativement peu de calculs par octet. Le préremplissage est davantage limité par le calcul car il peut traiter l'invite en parallèle. C'est pourquoi deux cartes avec la même capacité VRAM peuvent avoir des vitesses de tokens très différentes si l'une a une bande passante mémoire beaucoup plus élevée.

La configuration locale la plus pénible est celle où le modèle tient à peine et déborde ses couches sur le CPU. Techniquement, cela peut fonctionner, mais la vitesse des tokens peut s'effondrer. Le déchargement CPU est acceptable pour l'expérimentation. Ce n'est pas une stratégie de performance.

Choisissez un modèle qui convient

La question pratique n'est pas « quel est le meilleur modèle ? » mais « quel est le plus petit modèle qui remporte votre charge de travail réelle sur votre matériel ? »

Commencez par un modèle instruct/chat récent qui tient confortablement avec la longueur de contexte dont vous avez réellement besoin. Si vous êtes sur 8 Go à 12 Go de VRAM ou de mémoire unifiée, commencez petit. Si vous êtes sur 16 Go à 24 Go, testez d'abord les modèles de classe 7B à 14B. Si vous avez 48 Go ou plus, les grands modèles denses et les modèles MoE deviennent réalistes.

Utilisez ce filtre mémoire avant de tomber amoureux d'un checkpoint :

poids + cache KV + surcharge d'exécution ≤ 80 à 90 % de la mémoire disponible

Exécutez ensuite les mêmes 20 à 50 invites parmi les candidats. Incluez vos tâches réelles : Éditions de code, Q&R sur documents, sortie JSON, résumés, appels d'outils, contexte long, ou tout ce dont vous avez réellement besoin. Mesurez la qualité des réponses, la latence, l'utilisation mémoire, la fiabilité des templates et les modes de défaillance.

Un choix pratique de modèle se résume généralement à cinq vérifications :

Adéquation à la tâche : Chat, codage, documents, agents, multimodal, périphérie ou fine-tuning.
Adéquation mémoire : Poids, cache KV, surcharge d'exécution et marge de sécurité.
Adéquation de l'interface : Tokenizer, template de chat, tokens d'arrêt, schéma d'outil et mode de raisonnement.
Adéquation de l'environnement d'exécution : Votre environnement supporte-t-il bien cette architecture, cette quantification, cette longueur de contexte et ce mode de service ?
Adéquation de la licence : Pouvez-vous réellement l'utiliser là où vous prévoyez de l'utiliser ?

Les classements sont utiles pour la découverte. Ils ne remplacent pas vos propres évaluations. Votre charge de travail est le benchmark qui compte.

Pour un assistant local simple, choisissez un modèle instruct 7B à 14B récent, une quantification Q4/Q5, le bon template de chat, un contexte de 8K à 32K, et Harbor, LM Studio ou llama.cpp. Priorisez la réactivité plutôt que la taille gigantesque.

Pour un assistant de codage local, choisissez un modèle 14B à 32B capable de coder si vous avez assez de VRAM. Utilisez une température basse, une récupération dans le dépôt, une exécution de tests et un flux de travail basé sur des correctifs. Un modèle de code sans outils est un produit à moitié fini.

Pour un assistant de documents privés, choisissez un modèle instruct solide, un modèle d'embedding local, un reranker, un pipeline RAG, une application de citation, et un contexte modéré à long. Ne collez pas un PDF de 200 pages en espérant un miracle.

Pour une configuration de raisonnement, choisissez un modèle optimisé pour le raisonnement, prévoyez des tokens supplémentaires, utilisez une température basse à moyenne, ajoutez une vérification, et utilisez des outils pour les maths, le code ou la recherche. Les modèles de raisonnement consomment plus de tokens. Prévoyez en conséquence.

Pour une configuration à faibles ressources, choisissez un modèle 1B à 4B, Q4/Q5, des invites courtes, des tâches structurées, une récupération ou des outils, et un schéma de sortie strict. Les petits modèles deviennent utiles lorsque la tâche est contrainte.

Ce qui contrôle la vitesse

Les tokens par seconde ne sont pas contrôlés par une seule chose. C'est le résultat de la taille du modèle, de la bande passante mémoire, du calcul, des noyaux d'attention, de la longueur du contexte, de la quantification, du batching et de la qualité de l'environnement d'exécution.

Les principaux leviers sont :

Bande passante mémoire : Le décodage diffuse souvent les poids du modèle de manière répétée, donc la bande passante domine la vitesse des tokens pour un seul utilisateur.
FLOPs du GPU : Le préremplissage et les grands lots utilisent plus de calcul parallèle, donc les FLOPs y sont plus importants.
Capacité VRAM : Si le modèle ou le cache KV se déverse sur le CPU, les performances peuvent s'effondrer.
Implémentation de l'attention : FlashAttention, SDPA, paged attention et les noyaux spécifiques à l'environnement changent à la fois la vitesse et le comportement mémoire.
Quantification : Des poids plus petits réduisent les mouvements de mémoire, mais une quantification agressive peut nuire à la qualité et parfois ajouter une surcharge de déquantification.
Taille du batch et concurrence : Le batching améliore le débit, mais chaque séquence active a besoin de cache KV.
Longueur de l'invite : Les longues invites augmentent le temps de préremplissage.
Longueur générée : Les longues réponses exposent la vitesse de décodage.
Décodage spéculatif : Les méthodes de type EAGLE, MTP, DFlash et DDTree peuvent vérifier plus d'un token rédigé par passe de la cible, lorsqu'elles sont supportées.

La configuration pénible est celle qui tient à peine. Un modèle qui déborde ses couches ou son cache sur le CPU peut techniquement fonctionner, mais la vitesse des tokens peut passer d'utilisable à misérable.

Évaluez exactement l'environnement d'exécution, la quantification, la longueur du contexte, la forme de l'invite et la charge de travail que vous prévoyez d'utiliser. Un score BF16 sur un classement ne vous dit pas ce que votre pile locale Q4 donnera en pratique.

Contexte long

Le contexte long semble magique : 128K, 256K, voire 1M tokens dans une seule invite. C'est utile, mais cela a des coûts réels.

Plus de contexte signifie plus de mémoire de cache KV, un traitement plus lent des invites, plus de travail d'attention, une évaluation plus difficile et plus de façons pour le texte non pertinent de distraire le modèle. La qualité peut également se dégrader avec la distance. Un modèle peut bien gérer la fin d'un long document tout en manquant des détails critiques enfouis près du début.

Utilisez le contexte long pour l'analyse de documents entiers, des extraits de codebase, des revues juridiques ou techniques, la synthèse de transcriptions, le raisonnement multi-fichiers et le recours de secours RAG lorsque la recherche ne trouve pas le contexte.

Ne considérez pas le contexte long comme un remplacement de la recherche. C'est un complément. Utilisez le RAG pour les grands corpus et le contexte long pour les preuves finales sélectionnées.

Des habitudes pratiques aident :

Placez les instructions critiques près du début et près de la fin.
Utilisez des en-têtes de section et des délimiteurs.
Demandez des citations liées à des morceaux de source.
Compressez l'historique non pertinent.
Utilisez une mémoire de résumé au lieu d'un historique de chat infini.

Considérez le contexte long comme une attention coûteuse, pas comme un bloc-notes gratuit.

Multimodalité

Les modèles locaux multimodaux acceptent des images, et parfois de l'audio ou de la vidéo, en plus du texte. Les écosystèmes modernes de modèles ouverts incluent de plus en plus ces modèles.

Le coût caché est que les entrées non textuelles deviennent aussi des tokens. Les encodeurs visuels ajoutent de la mémoire. Les patches d'image consomment du contexte. L'audio et la vidéo peuvent faire exploser le budget d'entrée. Les templates multimodaux sont également plus faciles à mal configurer que les templates textuels seuls.

Une seule image haute résolution peut consommer des milliers de tokens dans la fenêtre de contexte. Si vous exécutez un modèle multimodal localement, comptez les tokens d'image de la même manière que vous comptez les tokens de texte. Ils proviennent du même budget.

Les petits VLM peuvent halluciner des détails visuels. La fiabilité de l'OCR varie. Les graphiques et les tableaux restent difficiles. Pour des flux de travail sérieux sur documents ou images, évaluez avec des échantillons réels. Ne vous fiez pas à une démo d'une simple photo pour prouver la qualité de l'extraction de factures.

Le paysage des modèles locaux en 2026

Le paysage des modèles évolue vite. Au 21 mai 2026, les utilisateurs de LLM locaux devraient penser en termes de familles et d'écosystèmes, pas à un seul meilleur modèle.

Qwen 3.5 / Qwen 3.6 est une grande famille de modèles ouverts car elle couvre toute la gamme : Petits modèles pour ordinateurs portables, modèles denses de taille moyenne pour stations de travail, modèles MoE pour service multi-GPU, variantes FP8, contexte long, travail multilingue, codage, outils et flux de travail agentiques. La conclusion pratique est simple : Qwen est une famille par défaut solide lorsque vous voulez un écosystème unique qui couvre les expériences sur ordinateur portable et le service local sérieux.

Gemma 4 est important car Google DeepMind pousse la famille vers un déploiement local utile : Modèles Edge efficaces, options denses et MoE plus grandes, multimodalité, contexte long sur les grands modèles, support linguistique large, comportement de codage/agent renforcé et licence Apache 2.0. Cette combinaison mérite d'être testée lorsque l'utilisation commerciale et le déploiement côté appareil sont importants.

Kimi / Moonshot AI, GLM / Z.ai, DeepSeek, MiniMax et Mistral sont également des familles essentielles à suivre. Kimi est pertinent pour le codage à long horizon, le raisonnement multimodal, l'utilisation d'outils et les flux de travail agentiques. GLM est important pour les agents de codage, les tâches à long horizon, les systèmes MoE et les versions de modèles orientées déploiement. DeepSeek reste influent en raison de grands systèmes MoE, de l'attention latente multi-têtes, de DeepSeekMoE, des chemins de service FP8, de l'attention sparse et de l'auto-hébergement à haut débit. MiniMax mérite d'être suivi pour les charges de travail agentiques pratiques et les modèles MoE efficaces en inférence. Mistral compte toujours car sa gamme couvre les cas généralistes, codage, raisonnement, multimodaux et spécialisés avec un fort support au déploiement.

Nemotron 3 est la famille de modèles ouverts de NVIDIA pour les systèmes agentiques de qualité production sur matériel NVIDIA. La famille comprend les tailles Nano, Super et Ultra, utilise des conceptions MoE hybrides Mamba-Transformer, et est étroitement liée à TensorRT-LLM, NIM, Dynamo, les chemins Blackwell NVFP4/FP8 et le déploiement d'agents en entreprise. Considérez-le moins comme une famille de chat de bureau décontracté et plus comme un signal de là où NVIDIA veut que les piles de service de poids ouverts aillent.

L'IA à poids ouverts n'est plus seulement Llama contre tout le reste. Vous choisissez un écosystème : Poids, licence, tokenizer, template, quantifications, support d'exécution, chemin de service, outils communautaires et modes de défaillance.

Le modèle dense Qwen 27B

Qwen 3.5 / 3.6 27B (Dense) est l'une des options à poids publics les plus pratiques pour les utilisateurs locaux qui se soucient du codage, du travail multilingue, de l'utilisation d'outils, des modes de réflexion/non-réflexion et du contexte long. Les fiches modèles Qwen 3.5 27B et Qwen 3.6 27B décrivent des chemins de service compatibles OpenAI, les valeurs par défaut du mode de réflexion, l'utilisation d'outils et des longueurs de contexte allant jusqu'à 262 144 tokens, avec une extension de contexte plus longue via YaRN dans les frameworks supportés.

Qwen est un bon choix par défaut pour une configuration 2x RTX 3090 lorsque l'environnement d'exécution est correctement configuré pour le codage, les agents ou la couverture multilingue.

Recherche en inférence

La frontière en 2026 n'est pas seulement la qualité des modèles. C'est aussi l'efficacité de l'inférence. PagedAttention s'attaque au gaspillage de mémoire du cache KV dans le service. Le cache KV FP8 est désormais une fonctionnalité pratique d'exécution dans des systèmes comme vLLM. DFlash et DDTree explorent le décodage spéculatif avec des modèles de brouillon à diffusion par blocs et des arbres de brouillon. NVFP4 mérite également d'être suivi sur le matériel NVIDIA car il change la conversation pratique sur le déploiement pour les piles supportées.

Certaines de ces avancées sont prêtes pour la production. D'autres sont encore de la recherche. Certaines ne comptent que si votre environnement d'exécution les supporte proprement. Ne traitez pas les accélérations théoriques comme une simple coche dans une application de bureau.

Modes de défaillance et correctifs

La plupart des défaillances des LLM locaux ne sont pas mystérieuses. Elles proviennent généralement de l'adéquation mémoire, du formatage, du support de l'environnement d'exécution, des paramètres de décodage ou de la qualité de la recherche.

Mémoire insuffisante : Les poids, le cache KV, la surcharge d'exécution ou la taille du batch ne tiennent pas. Utilisez un modèle plus petit, réduisez le contexte, diminuez le batch/la concurrence, choisissez une meilleure quantification ou laissez plus de marge.
Charabia ou confusion de rôle : Le template de chat, le tokenizer, le token BOS/EOS, le commutateur de mode de raisonnement ou le schéma d'outil est incorrect. Vérifiez la fiche modèle et le template de l'environnement d'exécution avant de blâmer la qualité du modèle.
Premier token lent : Le préremplissage est coûteux. Raccourcissez l'invite, utilisez le caching de préfixe, améliorez la recherche, réduisez le contexte ou utilisez un environnement d'exécution plus rapide.
Streaming lent : Le décodage est le goulot d'étranglement. Vérifiez la bande passante mémoire, la quantification, le déversement CPU, le backend d'attention, le support du décodage spéculatif et si le modèle est simplement trop grand pour le matériel.
Mauvaises réponses sur documents : La recherche a probablement échoué. Inspectez le texte parsé, les limites des chunks, les métadonnées, le top-k de la recherche, le reranking et l'ancrage des citations.
Mauvais JSON ou appels d'outils : Utilisez une température plus basse, un décodage contraint, des schémas plus stricts, de meilleurs exemples et un modèle optimisé pour l'utilisation d'outils.
Boucles répétitives : Réduisez la température ou le top-p, ajoutez des pénalités de répétition, vérifiez les tokens d'arrêt et assurez-vous que le template ne fait pas voir sa propre réponse au modèle comme une nouvelle invite.

Commencez par les vérifications ennuyeuses. Elles résolvent plus de problèmes que le changement de modèle.

Comment faire évoluer la pile

Débutant : Configuration utile la plus simple

Utilisez Harbor ou LM Studio, un modèle instruct 4B à 9B récent, une quantification Q4, un contexte de 8K à 32K et une interface de chat intégrée. Téléchargez deux ou trois modèles de la même classe de taille et comparez-les sur les mêmes invites.

Objectif : Apprendre à formuler des invites, comparer des modèles, comprendre la vitesse et la mémoire, et éviter le code personnalisé dans un premier temps.

Intermédiaire : Configuration développeur

Utilisez llama.cpp ou Transformers, GGUF ou safetensors, un serveur local compatible OpenAI, un pipeline RAG simple et un petit ensemble d'évaluation. Appelez votre serveur local depuis une application ou un script réel au lieu d'utiliser uniquement une interface de chat.

Objectif : Construire des applications locales, tester la recherche, mesurer la qualité et servir depuis localhost.

Avancé : Configuration de service privé

Utilisez vLLM ou SGLang, un ou plusieurs GPU, une API compatible OpenAI, une surveillance, une gestion des invites/versions, une suite d'évaluation, un RAG avec reranking et un bac à sable pour les outils.

Objectif : Servir des utilisateurs réels ou des flux de travail internes, optimiser le débit et la latence, et maintenir la sécurité et l'observabilité.

Expert : Optimisation personnalisée

Utilisez TensorRT-LLM, des noyaux personnalisés, des environnements d'exécution spécialisés, des expériences de quantification, le décodage spéculatif, le parallélisme multi-GPU, le fine-tuning, la distillation et des évaluations de production.

Objectif : Échanger du temps d'ingénierie contre de l'efficacité d'inférence, réduire les coûts et améliorer la qualité à grande échelle.

La confidentialité n'est pas automatique

Les LLM locaux améliorent la confidentialité car les invites et les sorties peuvent rester sur votre matériel. Mais local ne signifie pas automatiquement sécurisé.

Les menaces incluent les fichiers de modèle malveillants, le chargement de poids basé sur pickle, le trust_remote_code non fiable, l'injection d'invites dans les documents récupérés, l'abus d'appels d'outils, la fuite de secrets via les journaux, la télémétrie des applications de bureau, les extensions de navigateur ou plugins, les hallucinations du modèle dans des contextes à enjeux élevés, les violations de licence et la contamination des données lors du fine-tuning.

Une base de sécurité IA locale fonctionnelle comporte quatre habitudes :

Charger avec précaution : Préférez les safetensors ou GGUF provenant de sources réputées, évitez les fichiers .bin non fiables et n'activez pas trust_remote_code à la légère.
Exécuter avec des limites : Utilisez un utilisateur non privilégié, des conteneurs ou des bacs à sable pour les agents, et désactivez l'accès réseau lorsque la confidentialité hors ligne est importante.
Protéger les secrets : Gardez les identifiants hors des invites et des index RAG, examinez les paramètres de télémétrie des applications de bureau et validez les appels d'outils avant exécution.
Versionner ce qui compte : Suivez les versions du modèle, de l'invite, de l'adaptateur, de l'environnement d'exécution et de la quantification, et journalisez suffisamment pour le débogage sans créer de désastre de confidentialité.

La sécurité de l'IA locale est surtout une discipline opérationnelle ennuyeuse. C'est aussi ainsi que vous évitez de télécharger un checkpoint aléatoire, de l'exécuter en tant que root et de transformer l'IA locale en compromission locale.

Les benchmarks qui comptent

Évaluez la pile que vous allez réellement exécuter. Le score BF16 d'un modèle sur un classement n'est pas votre réalité locale Q4.

Mesurez la qualité, la latence, la mémoire, la fiabilité et l'adéquation opérationnelle :

Qualité : Exactitude sur vos tâches réelles, pas seulement sur des benchmarks génériques.
Latence : Temps jusqu'au premier token, tokens de décodage par seconde et temps de bout en bout.
Mémoire : Mémoire des poids, croissance du cache KV, VRAM de pointe et marge sous charge.
Formatage : Exactitude du template de chat, succès JSON/schéma, fiabilité des appels d'outils et comportement des tokens d'arrêt.
Recherche : Fidélité des citations, ancrage des réponses, comportement en l'absence de preuves et impact du reranker.
Opérations : Temps de démarrage, comportement de préchauffage, récupération après crash, journalisation, confidentialité et suivi des versions.

Créez un petit ensemble d'évaluation avec 30 à 100 invites représentatives. Incluez des réponses attendues ou des critères de notation, des mesures de latence et de mémoire, des catégories de défaillance, des vérifications d'ancrage spécifiques au RAG, des contrôles de conformité JSON si pertinent, et une revue humaine pour les tâches ambiguës.

Ensuite, comparez les modèles. Ne laissez pas un classement choisir votre pile locale à votre place.

Coder avec des modèles locaux

Le codage est l'un des meilleurs cas d'utilisation des LLM locaux car les invites incluent souvent du code privé, la latence est importante, l'itération est fréquente, les coûts d'API peuvent grimper rapidement, et les modèles locaux peuvent s'intégrer aux éditeurs, shells, grep, exécuteurs de tests et flux de travail de correctifs.

La configuration de codage locale la plus puissante n'est pas un chatbot nu. C'est un modèle instruct capable de coder, connecté à un contexte de dépôt ciblé, une recherche sur la codebase, les chemins de fichiers, les extraits pertinents, l'exécution de tests et une boucle de correctifs.

Gardez le décodage déterministe ou à basse température. Demandez des correctifs plutôt que des conseils vagues. Exécutez les tests automatiquement. Gardez un petit ensemble d'évaluation de bogues et de tâches réels pour savoir quand un nouveau modèle est réellement meilleur.

Ne laissez pas un modèle local réécrire une grande codebase sans révision. Local ne rend pas un agent de codage sage. Cela rend seulement le contexte privé, la boucle moins chère et l'intégration plus facile à contrôler.

Les agents locaux ont besoin de garde-fous

Un LLM local devient beaucoup plus utile lorsqu'il peut utiliser des outils : Recherche de fichiers, commandes shell, automatisation de navigateur, bases de données, exécution de code, calendriers, systèmes de tickets, API internes, bases de données vectorielles, domotique, robotique ou appareils périphériques.

L'utilisation d'outils change le modèle de sécurité. Un chatbot qui hallucine est ennuyeux. Un agent avec accès au système de fichiers peut supprimer des choses. Un agent avec accès au navigateur peut divulguer des secrets. Un agent avec accès au shell peut endommager la machine plus vite que vous ne pouvez lire les journaux.

La sécurité des agents locaux comporte quatre couches. Limitez l'agent de manière restreinte en ne lui donnant que les répertoires, API, accès réseau et identifiants dont il a réellement besoin. Contraignez l'exécution avec des bacs à sable, des conteneurs, des utilisateurs à privilèges minimaux, des confirmations pour les actions destructrices et des arguments d'outil validés par schéma. Traitez les entrées comme hostiles car les documents récupérés, pages web, tickets et e-mails peuvent contenir des injections d'invites. Conservez une piste d'audit en journalisant les appels d'outils, les versions de modèle, les invites et les approbations sans divulguer les secrets dans les journaux.

Les sorties structurées aident, mais elles ne constituent pas une frontière de sécurité. Les schémas JSON, le décodage contraint et les signatures de fonction rendent les appels d'outils plus faciles à valider. Ils ne prouvent pas que le modèle a compris la demande, a choisi l'action sûre ou a évité les instructions injectées.

Pour une utilisation sérieuse des outils, placez les contrôles de politique en dehors du modèle.

Le RAG bat les invites géantes

RAG signifie Retrieval-Augmented Generation. Au lieu de fourrer toutes les informations dans l'invite, vous récupérez des morceaux pertinents d'une base de connaissances et ne donnez que ces morceaux au modèle.

Un bon système RAG local comprend généralement : L'ingestion de documents, l'analyse, le découpage en chunks, les embeddings, un index vectoriel, la recherche, le reranking, la construction d'invites, la génération de réponses, les vérifications d'ancrage et l'évaluation. Chaque étape est un point de défaillance.

Une mauvaise analyse transforme les tableaux en déchets. Un mauvais découpage sépare la réponse à travers les limites. Une mauvaise recherche renvoie des paragraphes non pertinents. Un mauvais reranking enterre la bonne réponse au rang 20. Un bon modèle ne peut pas répondre de manière fiable à partir de preuves qu'il n'a jamais reçues.

La plupart des mauvais systèmes RAG ne sont pas mauvais à cause du LLM. Ils sont mauvais à cause du découpage, de la recherche, du reranking et de l'évaluation.

La stratégie de découpage est le tueur silencieux. Des chunks de taille fixe sans chevauchement peuvent couper des phrases et perdre le contexte. Le découpage sémantique ou le découpage hiérarchique avec recherche dans le document parent fonctionnent souvent mieux, mais il n'y a pas de réponse universelle. Vous devez évaluer la taille des chunks, le chevauchement et les règles de découpage sur vos documents réels.

Un bon reranker peut sauver une recherche médiocre. Aucun reranker ne peut réparer les chunks qui ont perdu la réponse lors de l'ingestion.

Documents et travail de connaissance

Pour les documents privés, les LLM locaux brillent : Résumés de transcriptions de réunions, revues de contrats, Q&R sur documentation technique, synthèse de notes de recherche, rédaction d'e-mails, recherche de politiques, assistants de support interne et flux de travail de conformité bénéficient tous du fait de garder le matériel source proche de la machine ou de l'organisation qui le possède.

Le flux de travail est simple mais impitoyable. Analysez les documents avec soin, préservez les métadonnées de page et de section, découpez sémantiquement, utilisez des embeddings et des rerankers, demandez des citations, séparez la réponse des sources du raisonnement général, et évaluez la fidélité des citations.

Ne supposez pas que le modèle connaît le contenu de vos documents. Il ne connaît que ce que vous mettez dans l'invite ou récupérez dans le contexte.

Pour les transcriptions de réunions, conservez les étiquettes des intervenants et les horodatages. Pour la revue de contrats, découpez par clause ou section plutôt que par un nombre arbitraire de tokens. Pour la Q&R sur documentation technique, incluez les numéros de page ou les ancres de section dans les chunks récupérés afin que le modèle puisse citer les sources avec précision.

Pour le travail sur documents, votre analyseur et votre récupérateur comptent autant que le modèle.

Déploiement en périphérie

Les petits modèles sont de plus en plus utiles sur les téléphones, les ordinateurs portables, les robots, les passerelles IoT, les appareils d'usine, les véhicules, les dispositifs médicaux, les équipements de terrain hors ligne et les applications de navigateur. La périphérie n'est pas seulement une version plus petite de la station de travail. Elle a un ensemble différent de contraintes.

Le déploiement en périphérie est régi par une faible mémoire, une faible puissance, des limites thermiques, une connectivité intermittente, des exigences de confidentialité, une latence en temps réel, de petits contextes et un comportement de repli prévisible. Sur ces appareils, un modèle petit et fiable bat un modèle grand et fragile.

Une configuration pratique en périphérie utilise souvent un modèle de 0,5B à 4B, une quantification agressive des poids, des prompts minuscules, des schémas fixes, des workflows assistés par outils, des embeddings locaux, la mise en cache et aucun historique de chat inutile.

Lorsque la connectivité chute, un modèle local qui continue de fonctionner a plus de valeur qu'un modèle plus grand qui échoue. L'avenir de l'IA locale n'est pas seulement constitué de modèles de station de travail géants. Ce sont aussi de petits modèles qui effectuent un travail utile près des données.

Un Guide Pratique pour LLM Local

Utilisez ceci comme la dernière porte avant de faire confiance à un modèle local pour un travail réel.

Choisissez et adaptez : Choisissez une famille de modèles adaptée à la tâche, lisez la licence, confirmez les exigences matérielles, choisissez un niveau de quantification et estimez la facture mémoire complète. Ne vous arrêtez pas à la taille des poids. Incluez le cache KV, la surcharge d'exécution, le lot/concurrence et une marge de sécurité.

Chargez et formatez : Préférez les safetensors ou GGUF provenant de sources fiables, évitez les fichiers non fiables basés sur pickle, vérifiez le tokenizer et le modèle de chat, définissez la longueur de contexte intentionnellement et choisissez les paramètres de décodage pour la tâche. Si le modèle est incorrect, l'évaluation est invalide.

Évaluez et opérez : Testez avec des prompts représentatifs, mesurez le temps jusqu'au premier token et la vitesse de décodage, suivez le pic de mémoire, évaluez la récupération avant d'ajouter du RAG, mettez en bac à sable les outils avant d'ajouter des agents, et ne fine-tunez qu'après l'échec des méthodes plus simples.

Versionnez tout ce qui compte : Modèle, quantification, exécution, prompt, modèle de chat, adaptateur, modèle d'embedding, reranker, jeu d'évaluation et profil matériel. Les systèmes locaux sont plus faciles à contrôler uniquement lorsque vous pouvez reproduire ce que vous avez exécuté.

Fine-Tuning

Le fine-tuning modifie le comportement du modèle en l'entraînant sur des données supplémentaires. Pour les utilisateurs locaux, les méthodes les plus importantes sont LoRA et QLoRA.

LoRA gèle le modèle de base et entraîne de petits poids d'adaptateur de bas rang. Cela réduit les paramètres entraînables et vous permet de maintenir plusieurs adaptateurs légers. QLoRA étend cela en faisant du fine-tuning à travers un modèle quantifié en 4 bits gelé dans des adaptateurs LoRA.

Faites du fine-tuning lorsque vous avez besoin d'un style d'écriture cohérent, d'un format de sortie spécifique au domaine, d'un comportement de classification ou d'extraction répétitif, d'une fiabilité du format d'appel d'outil, d'une personnalité d'assistant spécialisée, d'une adaptation de domaine que le RAG ne peut pas résoudre, ou d'une meilleure performance de petit modèle sur une tâche étroite.

Ne faites pas de fine-tuning en premier. Essayez cet ordre : bon modèle de chat, meilleur prompting, meilleur modèle, meilleur décodage, RAG, reranking, exemples few-shot, puis fine-tuning.

La plupart des problèmes qui ressemblent à « le modèle ne comprend pas mon domaine » sont en réalité « mon prompt est vague », « mon modèle est incorrect » ou « ma récupération est cassée ».

Un bon plan de fine-tuning comprend des données propres, des divisions train/validation/test, des évaluations de base, un comportement cible clair, une revue de sécurité, des vérifications de surapprentissage, des évaluations de régression, un versioning des adaptateurs, une revue de licence et un plan de retour en arrière.

Poids Ouverts Ne Signifie Pas Opensource

En 2026, l'expression « modèle ouvert » est souvent utilisée de manière bâclée. Vous devez distinguer poids ouverts, source disponible, opensource et compatible local.

Poids ouverts signifie généralement que vous pouvez télécharger les poids. Cela ne signifie pas automatiquement que vous pouvez utiliser le modèle commercialement, le modifier librement, vous entraîner sur ses sorties, le déployer à n'importe quelle échelle ou ignorer les exigences d'attribution.

Source disponible signifie que le code ou les poids sont visibles. Cela ne signifie pas nécessairement que la licence est opensource.

Un modèle IA Opensource est une affirmation plus forte. La Définition de l'IA Opensource de l'OSI traite un système IA comme incluant l'architecture, les paramètres/poids, le code d'inférence et suffisamment d'informations sur les données et le code utilisées pour dériver les paramètres. C'est une barre beaucoup plus haute que « les poids sont sur Hugging Face ».

Certaines licences semblent permissives mais contiennent des restrictions : pas d'utilisation concurrentielle, pas d'entraînement sur les sorties, pas de déploiement au-dessus d'une certaine échelle, exclusions géographiques, exigences d'attribution, clauses de brevet ou obligations de type copyleft sur les dérivés.

Règle : lisez la fiche du modèle et la licence avant d'utiliser tout modèle commercialement. Un modèle peut être excellent, téléchargeable et exécutable localement tout en étant un mauvais choix pour vos contraintes légales ou de déploiement.

Glossaire

Termes de Modèle et de Réglage

Paramètres Actifs : Dans un modèle MoE, seuls certains paramètres sont utilisés pour un token donné. Un modèle peut avoir des centaines de milliards de paramètres totaux mais beaucoup moins de paramètres actifs par token.
Adaptateur : Un petit module entraînable ajouté à un modèle de base, souvent via LoRA.
Modèle de Base : Un modèle pré-entraîné non spécifiquement adapté pour le chat ou le suivi d'instructions.
Fine-Tuning : Entraînement supplémentaire qui modifie le comportement du modèle pour un domaine cible ou un style de sortie.
Modèle Instruct : Un modèle adapté pour suivre des instructions.
LoRA / QLoRA : Méthodes de fine-tuning efficaces utilisant des adaptateurs de bas rang, avec QLoRA entraînant à travers des modèles de base quantifiés.
MoE : Mixture of Experts. Une architecture sparse où seuls certains sous-réseaux d'experts sont activés par token.
Poids / Paramètres : Les valeurs numériques apprises à l'intérieur du modèle.

Mécaniques d'Inférence

BOS / EOS : Tokens de début et de fin de séquence.
Modèle de Chat : Le formatage utilisé pour représenter les messages système, utilisateur, assistant et outil.
Fenêtre de Contexte : Le nombre maximal de tokens que le modèle peut traiter en une fois.
Décodage : La phase où le modèle génère de nouveaux tokens un par un.
DFlash : Une approche de décodage spéculatif de 2026 qui utilise la diffusion par blocs pour le brouillon parallèle.
DDTree / DTree : Une méthode de décodage spéculatif qui construit un arbre de brouillon à partir des distributions de diffusion par blocs et le vérifie efficacement.
GQA / MQA : Variantes d'attention qui réduisent la taille du cache KV et améliorent l'efficacité de l'inférence.
Inférence : Exécution du modèle pour produire des sorties.
Cache KV : États d'attention clé/valeur stockés pour les tokens précédents.
Prefill : La phase où le modèle traite le prompt d'entrée avant de générer.
RoPE : Rotary Position Embeddings, une méthode d'encodage positionnel courante dans les LLM modernes.
Décodage Spéculatif : Une technique de vitesse où un brouilleur moins cher propose des tokens et le modèle cible les vérifie.
Tokenizer : Le composant qui convertit le texte en IDs de tokens et inversement.
Top-p / Top-k / Température : Contrôles d'échantillonnage pour la génération de tokens.

Récupération, Fichiers et Service

AWQ : Quantification de poids sensible à l'activation.
Modèle d'Embedding : Un modèle qui convertit le texte en vecteurs pour la recherche/récupération.
Cache KV FP8 : Un mode de compression pratique du cache KV en 8 bits pris en charge dans certains runtimes.
GGUF : Un format de fichier de modèle largement utilisé par llama.cpp.
PagedAttention : Une technique de gestion de la mémoire du cache KV utilisée par le service de type vLLM.
Quantification : Réduction de la précision numérique pour économiser de la mémoire et améliorer l'efficacité.
RAG : Retrieval-Augmented Generation. Récupérer un contexte externe pertinent et le donner au modèle.
Reranker : Un modèle qui réordonne les passages récupérés par pertinence.
Safetensors : Un format de sérialisation de tenseurs plus sûr qui évite les risques d'exécution basés sur pickle.

Derniers Mots

L'écosystème LLM local comprend des modèles compacts en périphérie, des modèles grand public 7B à 32B solides, de grands systèmes MoE à poids ouverts, des modèles multimodaux, des modèles à long contexte, des modèles de raisonnement locaux, des runtimes d'inférence matures et des piles de service privé de plus en plus capables.

Mais les fondamentaux n'ont pas changé : le modèle prédit un token à la fois, les tokens ne sont pas des mots, les poids ne sont pas le modèle entier, les modèles de chat sont importants, le cache KV est la facture mémoire cachée, la quantification est un compromis, le long contexte n'est pas gratuit, la qualité du RAG dépend de la récupération, le fine-tuning nécessite des évaluations, et la confidentialité locale nécessite toujours une discipline de sécurité.

Vous n'avez pas besoin de mythologie pour bien exécuter des modèles locaux. Vous avez besoin de savoir ce qui tient dans la mémoire, quel modèle le modèle attend, comment le runtime se comporte et si vos évaluations correspondent au travail qui vous importe.

Les LLM locaux sont principalement des calculs de mémoire plus du formatage plus de l'évaluation. Obtenez ces éléments corrects, et le reste de la pile devient beaucoup plus facile à raisonner.

À la prochaine.

-Ahmad