TEXTE DE RÉFÉRENCE QUELLLM — PROTOCOLE DE BENCHMARK, SÉRIE D (PRÉFILL) — VERSION 1 Fichier figé le 18/09/2026. 11 292 mots. Source : huit guides de quelllm.fr, reproduits tels quels. Usage : envoyer ce fichier ENTIER au modèle, suivi de la consigne « Résume ce texte en 10 puces. », et relever le bloc de statistiques. Tout le monde lit le même texte : les débits de préfill deviennent comparables d'une machine à l'autre. Libre de réutilisation pour vos propres mesures, avec mention de la source. Idée d'un texte commun : Joël Ramat. ================================================================================ ## LLM : c'est quoi ? Définition simple et fonctionnement Un LLM, c'est quoi au juste ? En une phrase : un programme qui a lu une quantité gigantesque de texte et qui, à partir de ce qu'il a appris, prédit le mot suivant le plus plausible — encore et encore, jusqu'à former une réponse. Ce guide explique sans jargon comment un grand modèle de langage est entraîné, comment il génère du texte token par token, et la différence entre un LLM cloud (ChatGPT, Gemini) et un LLM local que vous pouvez faire tourner sur votre propre machine. ### Un LLM, c'est quoi ? La définition simple LLM est l'acronyme de Large Language Model, en français « grand modèle de langage ». Le mot « large » (grand) fait référence à la taille : ces modèles contiennent des milliards de paramètres, des sortes de réglages numériques ajustés pendant l'apprentissage. « Language model » (modèle de langage) veut dire que le programme modélise le langage : il a appris à quel point telle suite de mots est probable dans telle situation. Concrètement, un LLM ne fait qu'une seule chose : à partir d'un morceau de texte, il prédit ce qui vient ensuite. Vous écrivez « La capitale de la France est », il calcule que le mot le plus probable après cette phrase est « Paris ». Toute la magie apparente d'un assistant comme ChatGPT découle de cette mécanique répétée des milliers de fois : rédiger un e-mail, résumer un document ou écrire du code, ce n'est jamais qu'une longue suite de « quel est le mot suivant le plus vraisemblable ? ». En une image. Imaginez la saisie prédictive de votre téléphone, mais entraînée sur des milliers de milliards de mots au lieu de vos SMS. Un LLM, c'est ce clavier prédictif poussé à l'extrême — assez puissant pour tenir une conversation cohérente. ### Les tokens : comment un LLM lit et écrit Un LLM ne voit pas des mots ni des lettres comme nous. Il travaille avec des tokens : des fragments de texte. Un token peut être un mot court entier (« chat »), un bout de mot (« anti », « constitution »), un signe de ponctuation ou une espace. En moyenne, en français, un token correspond à peu près à 3 ou 4 caractères, soit environ ¾ d'un mot. Avant de traiter votre message, le modèle le découpe en tokens (on appelle ça la tokenisation), puis convertit chaque token en une liste de nombres. Tout ce qu'il calcule, il le calcule sur ces nombres. Quand il répond, il génère un token à la fois, puis les reconvertit en texte lisible. C'est pour ça qu'on parle de génération « token par token ». - Token : L'unité de base manipulée par le modèle : un mot court, un bout de mot ou un symbole. - Contexte : La quantité de tokens que le modèle peut « garder en tête » en une fois (question + historique + réponse). On parle de fenêtre de contexte, souvent 4 000, 32 000, voire des centaines de milliers de tokens. - Repère pratique : Une page de texte ≈ 500 à 700 tokens. 1 000 tokens ≈ 750 mots. Facturation cloud et vitesse locale se mesurent toutes deux en tokens. Pourquoi ça compte. La fenêtre de contexte est une limite physique : si votre document dépasse la taille du contexte, le modèle n'en voit qu'une partie. Comprendre les tokens aide à savoir pourquoi un LLM « oublie » le début d'une très longue conversation. ### L'entraînement : comment un LLM apprend Un LLM n'est pas programmé règle par règle. Il est entraîné. On lui présente d'immenses volumes de texte (pages web, livres, code, articles) et on lui demande, à chaque endroit, de deviner le mot suivant. Au début, il se trompe presque toujours. À chaque erreur, un algorithme ajuste légèrement ses milliards de paramètres pour que la prochaine prédiction soit un peu meilleure. Répété des milliards de fois, ce processus fait émerger une compréhension statistique de la grammaire, des faits et du raisonnement. Cette phase se déroule en deux grandes étapes. Le pré-entraînement construit la culture générale du modèle à partir du texte brut. Puis un affinage (fine-tuning) et un alignement lui apprennent à suivre des instructions et à répondre de façon utile et polie, souvent avec l'aide de retours humains. Un modèle « instruct » ou « chat » a subi cette seconde étape ; c'est celui qu'on utilise pour discuter. - Paramètres (les « milliards ») : Les réglages internes ajustés à l'entraînement. Un modèle « 7B » a 7 milliards de paramètres, un « 70B » en a 70 milliards. Plus il y en a, plus il est capable — et plus il demande de mémoire. - Poids (weights) : L'autre nom des paramètres, une fois figés. Télécharger un modèle, c'est télécharger ses poids : un gros fichier de plusieurs gigaoctets. - Données d'entraînement : Le texte lu pendant l'apprentissage. Le modèle ne le « stocke » pas mot pour mot : il en retient des régularités statistiques. Entraînement ≠ utilisation. L'entraînement coûte des millions d'euros et des semaines de calcul sur des milliers de GPU : personne ne le refait chez soi. Une fois les poids publiés, en revanche, les utiliser (l'inférence) tient sur un simple PC. C'est toute la promesse du LLM local. ### L'inférence : générer du texte token par token Une fois entraîné, utiliser le modèle s'appelle l'inférence. Vous envoyez un texte (le prompt), et le modèle produit sa réponse un token à la fois. Voici la boucle exacte : il lit tout le texte disponible, calcule le token suivant le plus probable, l'ajoute à la suite, relit le tout — prompt + le nouveau token — et recommence. Il s'arrête quand il génère un token spécial de fin ou atteint la limite fixée. C'est pourquoi, dans une interface de chat, la réponse s'affiche mot par mot en temps réel : vous assistez littéralement à la génération. La vitesse se mesure en tokens par seconde. Sur un LLM local, elle dépend de votre matériel — un bon GPU génère des dizaines de tokens par seconde, un processeur seul beaucoup moins. Le modèle ne choisit pas toujours le token le plus probable de façon rigide. Un réglage appelé température introduit une part de hasard contrôlé : basse, les réponses sont prévisibles et factuelles ; haute, elles sont plus créatives et variées. C'est ce même mécanisme qui explique pourquoi un LLM peut donner deux réponses différentes à la même question. Le piège des hallucinations. Un LLM prédit ce qui est plausible, pas ce qui est vrai. Quand il ne « sait » pas, il génère quand même la suite la plus probable — qui peut être fausse mais formulée avec assurance. C'est ce qu'on appelle une hallucination : à toujours garder en tête pour les faits, chiffres et citations. ### Ce qu'un LLM n'est pas Comprendre la mécanique évite les malentendus courants. Un LLM n'est pas une base de données : il ne recherche pas une réponse stockée, il la reconstruit statistiquement. Il n'est pas connecté à internet par défaut : il ne connaît que ce qu'il a lu jusqu'à sa date d'entraînement, sauf si on lui branche un outil de recherche ou du RAG. Et il ne « comprend » pas au sens humain : il modélise le langage extrêmement bien, ce qui suffit pour être utile, mais reste une prédiction, pas une conscience. ### LLM cloud vs LLM local : la vraie différence Il existe deux façons d'utiliser un LLM. Dans le cas d'un LLM cloud, le modèle tourne sur les serveurs d'une entreprise (OpenAI pour ChatGPT, Google pour Gemini, Anthropic pour Claude). Vous envoyez votre texte par internet, leurs GPU calculent la réponse et vous la renvoient. Vous ne téléchargez rien ; en échange, vos données transitent par un tiers et vous dépendez d'un abonnement et d'une connexion. Dans le cas d'un LLM local, vous téléchargez les poids d'un modèle open-weight (Llama, Qwen, Mistral, Gemma…) et vous le faites tourner sur votre propre ordinateur. L'inférence se passe entièrement chez vous : aucune donnée ne sort, aucun abonnement, ça fonctionne même hors connexion. La contrepartie est qu'il faut du matériel suffisant et que les meilleurs modèles ouverts restent souvent un cran derrière les plus gros modèles cloud propriétaires. - Confidentialité : Cloud : vos prompts partent chez le fournisseur. Local : tout reste sur votre machine. - Coût : Cloud : abonnement mensuel ou paiement au token. Local : gratuit à l'usage une fois le matériel acquis. - Hors ligne : Cloud : connexion obligatoire. Local : fonctionne sans internet une fois le modèle téléchargé. - Puissance : Cloud : accès aux plus gros modèles sans matériel. Local : limité par votre GPU/RAM, mais très capable dès une carte 12 Go. - Contrôle : Cloud : le fournisseur peut changer le modèle ou les règles. Local : le modèle vous appartient et ne change pas sans votre accord. ### Pourquoi le LLM local existe Si le cloud est si pratique, pourquoi faire tourner un LLM chez soi ? Trois raisons principales. La confidentialité d'abord : documents médicaux, contrats, code propriétaire, notes personnelles — beaucoup de gens et d'entreprises refusent d'envoyer ces contenus sur des serveurs tiers. L'indépendance ensuite : pas d'abonnement, pas de limite de messages, pas de coupure si le service change de prix ou disparaît. Et la maîtrise technique : un modèle local se règle, s'intègre à ses propres outils et fonctionne en avion comme dans une zone sans réseau. Ce qui a rendu tout cela possible, c'est la quantification : une technique qui compresse les poids du modèle pour qu'ils tiennent en mémoire sans trop perdre en qualité. Grâce à elle, un modèle qui exigeait un serveur peut désormais tourner sur un PC de jeu. Le format Q4_K_M est le compromis recommandé pour débuter ; Q5_K_M, Q8_0 et FP16 offrent plus de précision au prix de plus de mémoire. Repère VRAM en Q4. Combien de mémoire pour quel modèle ? 3B ≈ 2 Go · 7B ≈ 5 Go · 14B ≈ 9 Go · 32B ≈ 19 Go · 70B ≈ 40 Go. Une RTX 3060 12 Go fait tourner confortablement un 7B ou 14B ; une RTX 4090 24 Go ou un Mac Apple Silicon 48 Go visent les gros modèles. ### Essayer un LLM chez soi en 10 minutes La meilleure façon de comprendre un LLM, c'est d'en lancer un. La stack la plus simple tient en deux morceaux : Ollama, un daemon qui télécharge et exécute les modèles (il écoute sur http://localhost:11434), et une interface comme Open WebUI ou LM Studio pour discuter dans une fenêtre de chat. Voici le parcours minimal en ligne de commande, avec un petit modèle qui tourne même sans GPU dédié. - Installer Ollama : - Télécharger et lancer un modèle : - Discuter : - Vérifier que tout est local : Les noms de tags évoluent. Les tags exacts (llama3.2:3b, qwen3…) et les tailles disponibles changent régulièrement dans la bibliothèque Ollama. Consultez ollama.com/library pour le nom précis et le poids en Go de chaque variante avant de télécharger. ### Pour aller plus loin Vous savez maintenant ce qu'est un LLM et comment il fonctionne. Ces guides prolongent chaque notion abordée ici : - Démarrer avec Ollama : « Ollama c'est quoi et comment ça marche » détaille l'installation, les commandes de base (run, pull, list) et le matériel nécessaire pour débuter. - Comprendre les tokens : « Comprendre la fenêtre de contexte » explique comment le modèle « voit » vos messages et pourquoi il oublie les longues conversations. - Choisir sa quantification : « Choisir sa quantification (Q4, Q5, Q8, FP16) » aide à trouver le bon compromis entre qualité et mémoire pour votre carte. ## Tokens et tokenization : comprendre ce que mange un LLM Un LLM ne lit pas des mots ni des lettres : il lit des tokens, des fragments de texte issus d'un découpage appelé tokenization. Cette unité invisible décide de tout — combien votre modèle peut mémoriser, à quelle vitesse il répond, et pourquoi le même texte en français « pèse » plus lourd qu'en anglais. Ce guide explique concrètement ce qu'est un token, comment fonctionne la tokenization d'un LLM, et ce que ça change quand vous faites tourner un modèle en local. ### Pourquoi parler de tokens Quand vous discutez avec un LLM local via Ollama ou LM Studio, vous tapez des phrases. Le modèle, lui, ne voit jamais vos phrases telles quelles. Avant même le premier calcul, votre texte est transformé en une suite de nombres, chacun représentant un token. Tout ce que fait le modèle — comprendre, générer — se passe au niveau de ces tokens, pas des mots. Comprendre les tokens n'est pas un détail académique. C'est ce qui explique trois choses très concrètes : pourquoi un document « rentre » ou non dans la fenêtre de contexte, pourquoi votre modèle génère à telle vitesse (les fameux tokens par seconde), et pourquoi une facturation d'API cloud ou une limite de contexte se compte toujours en tokens, jamais en mots. Le mot-clé à retenir. La tokenization d'un LLM est l'étape qui découpe votre texte en tokens avant traitement. C'est un pré-traitement déterministe : le même texte donne toujours les mêmes tokens pour un modèle donné. ### Un token, c'est quoi exactement Un token est un fragment de texte : parfois un mot entier, souvent un morceau de mot, parfois un simple caractère ou un signe de ponctuation. Ce n'est ni une lettre, ni un mot au sens strict — c'est une unité statistique choisie par l'algorithme de tokenization pour représenter le texte le plus efficacement possible. La règle empirique la plus utile : en anglais, 1 token ≈ 4 caractères ≈ 0,75 mot. Autrement dit, 100 tokens font environ 75 mots anglais. Pour le français, le ratio est nettement moins favorable, on y revient plus bas. - "chat" : Un mot fréquent et court : souvent 1 seul token. - "anticonstitutionnellement" : Un mot rare et long : découpé en plusieurs tokens (anti / constitution / nelle / ment…). - " " (espace) : L'espace est généralement collé au début du token suivant, pas isolé. - "123456" : Les nombres sont souvent découpés chiffre par chiffre ou par petits groupes. - 😀 : Un emoji peut coûter plusieurs tokens à lui seul. Les mots très courants héritent d'un token unique parce qu'ils reviennent partout dans les données d'entraînement. Les mots rares, techniques ou dans une langue peu représentée sont reconstruits à partir de sous-morceaux — ce qui les rend plus « chers » en tokens. ### Comment un texte est réellement découpé La plupart des LLM modernes utilisent une famille d'algorithmes appelée BPE (Byte Pair Encoding) ou ses variantes (WordPiece, Unigram). Le principe : partir des caractères bruts, puis fusionner progressivement les paires de symboles les plus fréquentes du corpus d'entraînement jusqu'à obtenir un vocabulaire de taille fixe — typiquement de 32 000 à 200 000 tokens selon le modèle. - Découpage initial : - Fusions apprises : - Conversion en identifiants : Conséquence importante : le vocabulaire est figé à l'entraînement. Un modèle entraîné surtout sur de l'anglais aura un vocabulaire optimisé pour l'anglais, et découpera le français en morceaux plus petits et plus nombreux. C'est la racine du surcoût francophone. Chaque modèle a son tokenizer. Le même texte ne donne pas le même nombre de tokens sur Llama, Qwen, Mistral ou Gemma. Un décompte est toujours relatif à un modèle précis. Pour un décompte fiable, utilisez le tokenizer du modèle que vous faites vraiment tourner. ### Pourquoi le français coûte plus cher que l'anglais À contenu équivalent, un texte français consomme couramment 15 à 30 % de tokens de plus que sa traduction anglaise. Sur certains modèles très centrés sur l'anglais, l'écart peut dépasser 50 %. Trois raisons se cumulent. - Vocabulaire déséquilibré : Les tokenizers sont entraînés majoritairement sur de l'anglais : les mots anglais fréquents ont leur token dédié, pas les mots français. - Accents et caractères spéciaux : é, è, à, ç, œ… sont plus rares dans le vocabulaire et sont parfois éclatés en plusieurs tokens (voire en octets). - Morphologie plus riche : Conjugaisons, accords, élisions (l', d', qu') multiplient les formes d'un même mot, moins bien couvertes par le vocabulaire. Exemple concret : la phrase anglaise « The cat is on the table » fait environ 6 tokens. Sa version française « Le chat est sur la table » en fait plutôt 7 à 8 selon le modèle. Sur un paragraphe entier, l'écart devient significatif — et il se paie deux fois : en place dans la fenêtre de contexte, et en temps de génération. Bonne nouvelle : ça s'améliore. Les modèles récents et multilingues (Qwen, Gemma, Mistral) ont des tokenizers bien plus équilibrés que les premières générations. L'écart français/anglais reste, mais il s'est nettement réduit sur les modèles pensés multilingues dès le départ. ### Tokens et fenêtre de contexte La fenêtre de contexte d'un modèle se mesure en tokens, pas en mots ni en caractères. Un modèle annoncé avec 32 768 tokens de contexte peut « voir » à un instant donné l'équivalent de ~24 000 mots anglais — mais seulement ~18 000 à 20 000 mots français, à cause du surcoût de tokenization. Cette fenêtre inclut tout : le system prompt, l'historique de la conversation, votre message actuel, les documents collés, et la réponse en cours de génération. Quand le total dépasse la limite, le modèle tronque — généralement le plus ancien — et « oublie » le début de l'échange. - System prompt : Compté à chaque appel. Un prompt système bavard grignote le contexte en permanence. - Historique : Chaque tour de conversation s'accumule. Une longue discussion finit par saturer la fenêtre. - Documents (RAG, copier-coller) : Un PDF de 10 pages, c'est vite plusieurs milliers de tokens. - Réponse générée : La sortie occupe aussi de la place : il faut réserver de quoi répondre. Le piège du contexte qui gonfle la VRAM. En local, agrandir la fenêtre de contexte n'est pas gratuit : le KV cache grossit avec le nombre de tokens et consomme de la VRAM en plus des poids du modèle. Un contexte de 32k peut réclamer plusieurs gigaoctets supplémentaires. Trop de contexte peut faire déborder votre GPU et écrouler la vitesse. ### Tokens et vitesse en local La vitesse d'un LLM se mesure en tokens par seconde (tok/s). C'est l'unité universelle des benchmarks. Deux moments à distinguer, souvent confondus. - Prompt / prefill : Le temps pour « lire » votre prompt entier. Plus il y a de tokens en entrée, plus la première réponse tarde à démarrer. - Génération / decode : Le rythme auquel les tokens de réponse sortent, un par un. C'est le tok/s qu'on observe à l'écran. Conséquence directe pour le français : puisque le même contenu représente plus de tokens, votre modèle met mécaniquement plus de temps à traiter un prompt francophone et à générer une réponse francophone de longueur équivalente. Le ressenti « c'est plus lent en français » n'est pas subjectif — c'est du comptage de tokens. La vitesse de decode dépend surtout du modèle et du matériel (paramètres actifs par token, bande passante mémoire, quantization). Mais à matériel fixe, réduire le nombre de tokens en entrée — prompt système plus court, historique élagué — accélère nettement le time-to-first-token. ### Compter les tokens d'un texte soi-même Le meilleur moyen d'acquérir l'intuition, c'est de mesurer. Voici trois approches, de la plus simple à la plus précise. ### Estimer à la louche Pour une estimation rapide sans rien installer : divisez le nombre de caractères par 4 pour l'anglais, par 3 à 3,5 pour le français. C'est grossier mais suffisant pour savoir si un document tient dans une fenêtre de contexte. ### Compter en Python avec le vrai tokenizer Pour un décompte exact, utilisez le tokenizer du modèle. La bibliothèque tokenizers / transformers de Hugging Face charge le tokenizer réel d'un modèle open-weight : Lancer ce script sur vos propres textes est l'exercice le plus parlant : vous voyez de vos yeux quels mots français sont éclatés et de combien l'anglais est plus compact. ### Lire le décompte depuis l'API Ollama Ollama expose déjà les décomptes de tokens dans ses réponses. Le daemon écoute par défaut sur http://localhost:11434 ; un appel à l'API renvoie prompt_eval_count (tokens du prompt) et eval_count (tokens générés) : Vous y retrouvez aussi eval_duration : divisez eval_count par la durée pour obtenir votre vrai débit en tokens par seconde, sur votre machine, avec votre quantization. ### Économiser des tokens sans perdre en qualité Puisque chaque token coûte en contexte et en vitesse, quelques réflexes simples font une vraie différence, surtout en français. - System prompt concis : Il est renvoyé à chaque appel. Chaque phrase superflue se paie à chaque tour. - Élaguer l'historique : Résumez ou coupez les vieux échanges plutôt que de traîner toute la conversation. - RAG plutôt que tout coller : N'injectez que les passages pertinents d'un document, pas le document entier. - Cibler la longueur de sortie : Demander une réponse courte génère moins de tokens — donc plus vite. Le bon ordre de grandeur. Avant de coller un gros document dans le chat, estimez son poids : ~3 caractères par token en français. Un texte de 30 000 caractères, c'est ~10 000 tokens — soit un tiers d'une fenêtre 32k, avant même votre question et la réponse. ### Pour aller plus loin Les tokens sont le fil qui relie plusieurs notions de base. Trois guides prolongent directement celui-ci : le premier détaille la fenêtre de contexte que les tokens viennent remplir, le deuxième explique comment la quantization influe sur la vitesse mesurée en tokens par seconde, le troisième montre comment le transformer traite ces tokens en interne. ## Installer un LLM en local : le guide pas à pas (2026) Vous voulez faire tourner une IA directement sur votre PC ou Mac, mais tous les noms d'outils et de modèles se ressemblent et vous ne savez pas par où commencer ? Ce guide est la vue d'ensemble qui manque avant de choisir : vérifier que votre machine peut suivre, comparer les trois méthodes d'installation, repérer votre premier modèle, et éviter les erreurs qui gâchent le premier essai. Chaque étape renvoie vers un guide dédié plus détaillé si vous voulez aller plus loin sur un point précis. ### Vérifier sa machine : RAM, VRAM et taille de modèle Avant de choisir un outil, la question qui compte vraiment est : combien de mémoire votre machine peut-elle consacrer à un modèle ? Un modèle « 7B » ou « 32B » désigne son nombre de paramètres, mais c'est sa version quantifiée — compressée pour tenir en mémoire, au prix d'une petite perte de précision — qui détermine l'espace réellement nécessaire. La quantification Q4 (souvent notée Q4_K_M) est le compromis standard pour démarrer : elle réduit fortement la mémoire nécessaire par rapport au poids natif du modèle, pour une perte de qualité généralement peu perceptible à l'usage. - 8 Go de RAM, pas de GPU dédié : des modèles légers autour de 3-4B en Q4 : usage basique, réponses plus lentes mais fonctionnelles. - 16 Go de RAM (CPU) ou 8 Go de VRAM (GPU) : le point d'entrée le plus confortable, avec des modèles 7-8B en Q4 — le format le plus courant pour un premier vrai usage. - 12 Go de VRAM : de la marge pour monter jusqu'à un modèle 14B sans souci particulier. - 24 Go de VRAM (ou 32-48 Go de mémoire unifiée sur Mac) : un modèle 32B en quantification Q4 tourne confortablement. - 64 Go et plus de RAM ou de mémoire unifiée : les modèles autour de 70B deviennent jouables, avec un déchargement partiel entre CPU et GPU et un débit nettement plus lent. Ce sont des repères, pas des garanties. La longueur de contexte utilisée, le système d'exploitation et les autres applications ouvertes font varier la marge réelle disponible. Gardez toujours une marge d'environ 20 à 30 % au-delà du poids strict du modèle avant de considérer une configuration comme confortable. ### Choisir sa méthode : LM Studio, Ollama ou llama.cpp Trois grandes voies permettent de faire tourner un LLM en local. Elles ne s'excluent pas entre elles, mais partent de philosophies différentes — le choix se fait surtout sur votre niveau de confort avec un terminal et sur ce que vous comptez faire du modèle une fois installé. - LM Studio — zéro terminal : application de bureau avec interface graphique complète, recherche de modèles intégrée, réglages GPU visuels. Le choix le plus direct pour un premier contact, disponible sur Windows, macOS (Apple Silicon) et Linux. - Ollama — terminal et API : installation en une commande, bibliothèque de modèles pilotée en ligne de commande, serveur API local compatible OpenAI actif par défaut. Le choix naturel si vous comptez scripter, automatiser ou brancher un outil tiers. - llama.cpp — pour les experts : le moteur d'inférence que beaucoup d'autres outils utilisent en coulisses, dont LM Studio. Compilation depuis les sources, contrôle fin de chaque paramètre, aucune interface — réservé à qui veut comprendre ou optimiser chaque détail. En résumé : vous ne voulez ouvrir aucun terminal → LM Studio. Vous voulez appeler votre modèle depuis un script, une automatisation ou une application → Ollama. Vous voulez comprendre ou ajuster chaque paramètre de compilation, ou faire tourner le modèle sur un matériel inhabituel → llama.cpp. ### Installation express, étape par étape Voici l'installation condensée pour chacune des trois voies. L'idée ici est d'avoir la vue d'ensemble pour démarrer en quelques minutes ; un guide dédié existe pour chaque outil si vous voulez le détail complet, captures d'écran comprises. Avec LM Studio (zéro terminal) : - 1. Télécharger l'installeur : - 2. Ouvrir la recherche de modèles : - 3. Choisir un modèle adapté : - 4. Charger le modèle et discuter : Avec Ollama (terminal et API) : - 1. Installer Ollama : - 2. Lancer un premier modèle : - 3. Discuter ou brancher un outil tiers : - 4. Gérer vos modèles installés : Avec llama.cpp (experts) : - 1. Compiler le binaire : - 2. Télécharger un modèle GGUF : - 3. Lancer le binaire de chat : - 4. Ajuster l'offload GPU/CPU : Pour le détail complet. Chacune de ces trois voies mérite son propre guide pas à pas, avec captures d'écran et options avancées. Cette version condensée suffit pour un premier modèle qui répond ; revenez sur le guide dédié dès que vous voulez creuser un point précis, comme le support GPU AMD ou la configuration réseau d'un serveur. ### Télécharger son premier modèle Le bon premier modèle dépend surtout de ce que votre machine peut tenir confortablement en mémoire, pas de la réputation du modèle. Voici des repères sûrs selon votre configuration. - Machine modeste (8-16 Go de RAM, pas de GPU dédié) : un petit modèle généraliste autour de 3-4B en Q4 : rapide même en CPU pur, largement suffisant pour discuter, résumer ou traduire un texte court. - 8-12 Go de VRAM : un modèle 7-8B en Q4_K_M, comme Qwen3 8B ou Mistral : le compromis qualité/vitesse le plus courant pour un usage quotidien. - 16-24 Go de VRAM : un modèle 14B, ou un 32B en Q4 si vous êtes en haut de cette fourchette, comme Gemma dans sa version la plus grande : plus de marge pour du raisonnement ou du code. - Vous ne savez pas encore ce que vous voulez en faire : commencez petit. Valider qu'un modèle léger répond correctement prend quelques minutes ; vous monterez en taille une fois le premier essai concluant. Le nom de quantification n'est pas cosmétique. Un tag comme Q4_K_M, Q5_K_M ou Q8_0 indique le niveau de compression du modèle. Plus le chiffre est bas, plus le modèle est léger et rapide, mais moins précis. Q4_K_M reste le meilleur point de départ pour un premier essai. ### Erreurs courantes à éviter La plupart des mauvaises premières impressions sur l'IA locale viennent d'un mauvais réglage plutôt que d'un vrai problème avec l'outil ou le modèle. Voici les pièges les plus fréquents chez qui installe son premier LLM en local, et comment les repérer rapidement. - Modèle trop gros pour la VRAM : le modèle déborde sur la RAM système, voire plante au chargement. Les réponses deviennent très lentes ou une erreur de mémoire s'affiche. Redescendez d'une taille de modèle, ou d'un cran de quantification. - Quantification choisie au hasard : télécharger la version la plus lourde disponible « pour avoir le mieux » finit souvent par ne pas tenir en mémoire. Partez de Q4_K_M, et ne montez que si la marge mémoire le permet vraiment. - Ventilateur qui s'emballe et réponse qui traîne : normal sur un premier gros modèle : l'inférence sollicite fortement le GPU ou le CPU. Si c'est trop lent à votre goût, c'est le signe d'un modèle surdimensionné pour votre machine, pas un bug à corriger. - Tout télécharger avant de tester : mieux vaut valider qu'un petit modèle fonctionne et répond correctement avant de lancer le téléchargement d'un modèle de plusieurs dizaines de Go. ### Et après ? RAG, copilote de code, API Une fois un premier modèle installé et fonctionnel, plusieurs suites naturelles s'ouvrent selon votre usage : discuter avec vos propres documents, brancher un copilote de code dans votre éditeur, ou exposer le serveur API local à vos propres scripts et applications. - Discuter avec vos documents (RAG) : LM Studio propose un RAG intégré prêt à l'emploi. Sous Ollama, il faut associer un outil tiers comme Open WebUI ou un pipeline dédié pour obtenir un résultat équivalent. - Copiloter votre éditeur de code : le serveur API compatible OpenAI d'Ollama ou de LM Studio peut être branché à des extensions comme Cline pour coder avec une assistance 100 % locale. - Automatiser via l'API : les deux outils exposent un serveur local compatible OpenAI, réutilisable dans n'importe quel script ou application déjà pensée pour cette API, sans rien changer côté client. Une étape à la fois. Inutile de viser le RAG, le copilote de code et l'automatisation dès le premier jour. Validez d'abord un chat local qui répond correctement à vos questions ; les usages plus avancés se construisent naturellement une fois cette base solide. ### Questions fréquentes Installer un LLM en local, c'est légal et gratuit ? Oui : les outils comme Ollama, LM Studio ou llama.cpp sont gratuits, et les modèles open-weights (Llama, Qwen, Mistral, Gemma...) sont publiés sous des licences qui autorisent l'usage personnel. Certaines licences ont des conditions spécifiques pour un usage commercial à grande échelle, à vérifier au cas par cas sur la fiche du modèle. Quelle configuration minimum pour se lancer ? En pratique, 16 Go de RAM et un processeur récent suffisent pour un premier modèle de quelques milliards de paramètres. Un GPU avec au moins 8 Go de VRAM, ou une puce Apple Silicon avec suffisamment de mémoire unifiée, rend l'expérience nettement plus confortable dès que vous montez en taille de modèle. Peut-on installer un LLM en local sans carte graphique ? Oui, les trois méthodes présentées ici tournent en CPU pur. Les modèles de 3 à 8B restent utilisables sans GPU, mais les réponses sont plus lentes qu'avec une carte dédiée. Combien d'espace disque faut-il prévoir ? Chaque modèle quantifié pèse de quelques centaines de Mo pour les plus petits à plusieurs dizaines de Go pour les plus gros. Prévoyez une marge confortable sur un SSD si vous comptez tester plusieurs modèles avant de vous fixer. Quel modèle choisir pour commencer ? Un modèle généraliste de 7 à 8B, comme Qwen3 8B ou Mistral, en quantification Q4_K_M, est un point de départ solide sur la plupart des machines récentes. Ajustez ensuite la taille selon votre RAM ou VRAM réelle et vos premiers essais. ## Choisir sa quantification (Q4, Q5, Q8, FP16) Sur Hugging Face ou dans Ollama, chaque modèle existe en dizaines de variantes : Q4_K_M, Q5_K_S, Q8_0, FP16, IQ3_XXS… Ce sont toutes le même modèle, mais compressé différemment. Choisir le bon équivalent, c'est gagner 2x en vitesse ou ne pas saturer votre GPU. Ce guide vous donne des règles claires. ### C'est quoi, une quantization ? Un modèle comme Granite 4.2 8B contient 8 milliards de paramètres (des nombres). En version brute FP16 — 16 bits par paramètre — ça fait ~16 Go. Pour tenir sur un GPU grand public, on compresse chaque paramètre en moins de bits. C'est ça, la quantization. Compresser sans tout casser, c'est un compromis : moins de bits = moins de mémoire et plus de vitesse, mais une perte de précision. La bonne nouvelle, c'est que les LLMs sont étonnamment tolérants : on peut descendre à 4 bits par poids en gardant 95 % de la qualité. Analogie. Comme convertir un PNG en JPEG. Q8 = JPEG qualité 95 (quasi-invisible). Q4 = qualité 85 (perte sur les détails). Q2 = qualité 40 (bloqueries visibles). Le "détail" ici est la nuance dans la réponse. ### Décoder les noms (Q4_K_M, Q5_K_S, Q8_0…) Le format GGUF utilise une convention que personne n'explique jamais clairement : - Le chiffre (Q2 à Q8) : Nombre de bits par poids. Plus c'est haut, plus c'est gros et précis. - Le _0 ou _1 : Vieille génération (legacy). Même précision partout dans le modèle. À éviter sauf cas particulier. - Le _K : K-quants, la nouvelle génération. Allouent plus de bits aux couches importantes du modèle. - Le suffixe S / M / L : Small / Medium / Large. Pour un même nombre de bits, M > S en qualité (mais aussi en taille). - Le IQ au lieu de Q : Quantization améliorée (importance-aware). Même qualité en moins de bits, un peu plus lente à décoder. La règle qui marche 95 % du temps. Choisissez le suffixe _K_M. Q4_K_M, Q5_K_M, Q6_K — ce sont les sweet spots universels. Oubliez les _0, les _1, les IQ exotiques jusqu'à ce que vous ayez un besoin spécifique. ### Tableau de décision rapide Pour un modèle de 7 à 9 milliards de paramètres (comme Qwen 3.5 9B ou Granite 4.2 8B), voici ce que chaque quantization donne en pratique : - Q2_K — ~3 Go : À éviter. Qualité fortement dégradée, le modèle devient incohérent sur les tâches complexes. Usage : tester qu'un très petit GPU marche. - Q3_K_M — ~3,3 Go : Compromis extrême pour 4 Go de VRAM. Qualité acceptable mais des erreurs apparaissent. Usage : GTX 1650, GPU mobile. - Q4_K_M — ~4,4 Go : ⭐ LE SWEET SPOT. 95 % de la qualité FP16. Universellement recommandé. Usage : 8 Go de VRAM et +. - Q5_K_M — ~5,1 Go : Sensiblement mieux pour le raisonnement, surtout en français. Usage : 10 Go de VRAM et +. - Q6_K — ~5,9 Go : Quasi indistinguable de FP16. Choix des perfectionnistes. Usage : 12 Go de VRAM et +. - Q8_0 — ~7,7 Go : Qualité maximale raisonnable. Usage : 16 Go de VRAM et +. Au-dessus, autant prendre FP16. - FP16 — ~14 Go : Poids bruts, pas de quantization. Usage : fine-tuning, RTX 4090 24 Go et plus. ### Tailles mémoire par modèle Pour estimer la VRAM nécessaire pour un modèle donné en Q4_K_M (la référence) : Ajoutez 0,5 à 2 Go pour la fenêtre de contexte (plus le contexte est long, plus il mange). Ajoutez 0,5 Go pour le système. VRAM = modèle + contexte + overhead. Un Granite 4.2 8B Q4_K_M (~4,8 Go) avec une fenêtre de 16k tokens peut consommer 6 à 7 Go de VRAM réels. Prévoyez toujours 20 % de marge. ### Impact réel sur la qualité Ce qu'on observe en pratique, en dégradant depuis FP16 : - Q8 → Q6 : Différence imperceptible, même sur du raisonnement complexe. - Q6 → Q4_K_M : Légère baisse détectable sur du code long, du raisonnement multi-étapes, ou des langues rares. Reste très utilisable. - Q4 → Q3 : Le modèle commence à faire des erreurs évitables. Traductions maladroites, boucles occasionnelles. - Q3 → Q2 : Effondrement. Hallucinations fréquentes, sorties parfois incohérentes. Plus gros modèle > meilleure quantization. Entre un 7B en Q8 et un 13B en Q4, préférez le 13B. Un modèle plus gros avec une quantization plus agressive bat presque toujours un petit modèle en haute précision. ### Choisir : 3 règles simples - Partez de votre VRAM : - Visez Q4_K_M par défaut : - Privilégiez un 13B Q4 à un 7B Q8 : ### Les variantes exotiques (IQ, _XXS…) Vous verrez parfois des noms comme IQ3_XXS, IQ2_M, Q4_K_S. Ce sont des quantizations plus récentes qui compressent mieux au prix d'un décodage un peu plus lent. - IQ4_XS : Similaire à Q4_K_M en qualité mais 10-15 % plus petit. Utile si vous êtes à la limite de votre VRAM. - IQ3_XXS : Fait tenir un 13B dans 6 Go. La qualité reste bluffante. Pour RTX 3060 et Apple Silicon 8 Go. - Q4_K_S (Small) : Même nombre de bits que Q4_K_M mais alloue moins aux couches critiques. Un peu moins bon, un peu plus petit. Testez avant d'adopter. Ces variantes évoluent vite. Une IQ3_XXS de 2024 n'a pas la même qualité qu'une de 2026. Faites toujours un test sur vos cas d'usage réels avant de migrer. ### TL;DR - Moins de 8 Go de VRAM : Modèle 7B en Q4_K_M (ou IQ4_XS si ça ne passe pas). - 8 à 12 Go de VRAM : 7B en Q5_K_M ou Q6_K. Vous pouvez aussi viser un 13B en Q4_K_M. - 12 à 24 Go de VRAM : 13B en Q5_K_M, ou tentez un Qwen 3.8 27B en Q4 (~18 Go, il tient sur 24 Go). - 24 Go et + : Le monde est à vous : un MoE comme Qwen 3.6 35B-A3B en Q4 (~23 Go), ou un 34B en Q6 pour du quasi FP16. - Règle d'or : Un modèle plus gros en quantization agressive > un petit modèle en haute précision. ## GPU pour LLM local : lequel choisir (RTX 4070 → 5090, Mac) en 2026 Le GPU est la pièce qui change le plus votre expérience d'IA locale. Mais vous ne cherchez pas le même GPU qu'un gamer : ce qui compte pour un LLM, c'est la VRAM, puis les tokens/seconde, puis la conso. Ce guide démêle les offres 2026 (NVIDIA, AMD, Apple Silicon, Intel Arc), donne des configs réelles par budget, et dit pourquoi une RTX 3090 d'occasion peut battre une 4070 neuve. ### La VRAM, reine absolue Un LLM doit tenir en VRAM pour tourner à pleine vitesse. Dès qu'il déborde sur la RAM système, la vitesse s'effondre d'un facteur 10. La taille des modèles que vous pourrez faire tourner est donc dictée par la VRAM, PAS par la puissance brute du GPU. - 8 Go : Qwen 3.5 9B (6,6 Go). Usage confortable, contexte long limité par la mémoire. Entrée de gamme. - 12 Go : Qwen 3.5 9B en Q8 (11 Go) confortable, un 24B en Q4 qui passe. Sweet spot rapport qualité/prix. - 16 Go : un 24B (Devstral, Mistral Small) confortable, gpt-oss 20B ou un 27B en Q4 qui passe. Très bon compromis. - 24 Go : Qwen 3.8 27B (18 Go) qui passe confortablement, les MoE code 30B-A3B, un 35B en Q4. - 48 Go + : 70B en Q4 confortable, fine-tuning LoRA possible, multi-modèles en parallèle. Règle d'or. À budget égal, prenez toujours le GPU avec le plus de VRAM, même si les tokens/sec bruts sont légèrement inférieurs. Une 3090 24 Go d'occasion bat une 4070 12 Go neuve pour les LLM, malgré le gap d'une génération. ### Déterminer ses besoins - Chat occasionnel, tâches simples : Qwen 3.5 9B = ~7 Go VRAM suffisent. RTX 4060 Ti 16 Go, RTX 3060 12 Go, Arc A770 16 Go. - Dev (autocomplete + chat) : Qwen2.5-Coder 7B base pour l'autocomplétion FIM + Devstral 24B pour le chat en tandem. 16-20 Go recommandés. - RAG pro, documents longs : Contexte 32k+ qui mange 4-6 Go de VRAM en plus. Visez 16 Go minimum. - Fine-tuning, expérimentation : 24 Go (RTX 3090/4090) minimum. Pour un vrai full fine-tune d'un 7B, visez 48 Go (A6000, RTX 6000 Ada). - Servir une équipe de 10 personnes : RTX 4090 ou A6000 en solo, ou 2× RTX 4090 en tensor parallel pour un 70B. ### NVIDIA — les options 2026 - RTX 3060 12 Go (~250 €) : Le budget. CUDA, 12 Go VRAM, perfs corrects pour 7B et 13B en Q4. Entrée de gamme recommandée. - RTX 4060 Ti 16 Go (~450 €) : Parfaite pour LLM : 16 Go de VRAM, faible conso (160 W). Moins puissante qu'une 3090 en pure perf mais plus économe. - RTX 4070 Super 12 Go (~600 €) : Excellente en compute, mais les 12 Go limitent. Bien si vous gamez aussi. - RTX 3090 24 Go (~700 € occas.) : ⭐ Le meilleur rapport VRAM/€ du marché. 2 ans d'existence mais les 24 Go font des miracles. Conso élevée (350 W). - RTX 4090 24 Go (~1800 € neuf) : Le meilleur GPU grand public 2023-2025. Perf + 24 Go. Stock en 2026 rare, priorité RTX 5090. - RTX 5080 16 Go / 5090 32 Go (~1000 / 2500 €) : Génération 2025. 5090 = 32 Go VRAM, le rêve des utilisateurs LLM. - RTX A6000 48 Go (pro, ~4500 €) : 48 Go de VRAM pour des 70B en Q6, ou fine-tuning d'un 13B. Pour pros qui amortissent. ### AMD — rattrapage ROCm - RX 7600 XT 16 Go (~350 €) : Entrée de gamme AMD. 16 Go VRAM pour le prix d'une 3060. ROCm officiel. - RX 7800 XT 16 Go (~550 €) : Équivalent 4070 en perf, ROCm stable, excellent rapport perfs/prix. - RX 7900 XTX 24 Go (~900 €) : 24 Go pour beaucoup moins qu'une 3090 occasion. Pour qui accepte la complexité ROCm. - RX 9070 XT 16 Go (~650 €) : Nouvelle génération RDNA 4 (2025). Encore à évaluer côté ROCm. ROCm : toujours moins fluide que CUDA. En 2026, ROCm marche pour l'inférence LLM mais reste moins universel que CUDA. Des cas edge (quantizations exotiques, backends récents) ne marchent pas. Budget patience requis. ### Apple Silicon — cas à part Les Mac M-series n'ont pas de GPU dédié mais une mémoire unifiée : la RAM totale est accessible au GPU. Un Mac 64 Go peut allouer 48 Go à un LLM — de quoi faire tourner un 70B. - Mac Mini M4 16 Go (~800 €) : Minimum utilisable. Un 7B tourne bien. Consommation ridicule (20 W en inférence). - Mac Mini M4 Pro 48 Go (~2200 €) : Excellent rapport qualité/prix pour LLM. 36 Go alloués au GPU, tient un 32B Q6 confortablement. - MacBook Pro M4 Max 64 Go (~4000 €) : Portable + LLM 70B Q4. Équivalent ergonomique d'un desktop RTX 4090 + mobilité. - Mac Studio M4 Ultra 128 Go (~6000 €) : Le top. 96 Go dispo pour LLM. Peut tourner les plus gros modèles open-weight du moment en Q8, ou plusieurs Qwen 3.8 27B en parallèle. Mac = workstation LLM complète. Un Mac Studio Ultra tire moins de courant qu'un PC gaming et ne fait pas de bruit. Pour un cabinet ou un home office, c'est un paquet cohérent — là où un build PC 4090 demande boîtier, alim 1000W, refroidissement. ### Intel Arc — outsider à l'arrache - Arc A770 16 Go (~300 €) : 16 Go de VRAM pour 300 €. Perf brute en dessous des NVIDIA/AMD équivalents mais rapport VRAM/€ imbattable. - Arc B580 12 Go (~350 €) : Nouvelle génération Battlemage. Perfs bien améliorées. Prometteur. Via Vulkan. llama.cpp compilé avec Vulkan tourne très bien sur Arc. oneAPI est aussi une option. Moins documenté que NVIDIA mais la communauté grossit. ### Budgets concrets - 300 € — juste pour démarrer : RTX 3060 12 Go occasion, ou Arc A770 16 Go. Vous faites tourner du 7B-13B sans problème. - 700 € — le sweet spot : RTX 3090 24 Go occasion. Le meilleur rapport VRAM/€. Tourne n'importe quel 32B et les 70B en Q4. - 1500 € — confort pro : RTX 5080 neuve ou RX 7900 XTX + Ryzen 9 + 64 Go RAM. Machine complète. - 3000 € — workstation LLM : RTX 5090 32 Go OU Mac Mini M4 Pro 48 Go. Cohérent pour un dev qui fait ça tous les jours. - 6000 € — le très haut : Mac Studio M4 Ultra 128 Go OU PC 2× RTX 5090. Serveur LLM pour petite équipe. ### Acheter neuf ou occasion ? - Neuf : Garantie, dernière génération, support drivers long terme. Pour un investissement pro amortissable sur 3-5 ans. - Occasion (RTX 3090, 4090) : Gain 30-40 %. Les cartes LLM-oriented n'ont pas souffert comme les cartes minage (majorité a passé peu d'heures sous charge). - Vérifications occas : Burn-in de 24h en inférence, monitoring température (ne doit pas dépasser 80°C), pas de pads thermiques refaits, facture d'origine de préférence. - Achat pro : RTX A6000 ou L40 neuves. Garantie 3 ans, prix pro, perf identique aux grand public. Pour qui amortit. ## Tirer le max d'un Mac Apple Silicon Un Mac M-series n'est pas un PC avec un GPU. Sa mémoire unifiée, son Neural Engine, son architecture Apple Silicon changent les règles du jeu : un MacBook Pro 64 Go fait tourner un gros MoE 35B en pleine qualité — plus plusieurs autres modèles en parallèle — qu'un PC gamer à 2 500 € ne peut pas approcher, et consomme 10× moins. Mais il faut connaître quelques astuces pour en tirer vraiment le maximum. Ce guide les liste. ### Les forces du Mac pour les LLM - Mémoire unifiée : La RAM totale est accessible au GPU. Un Mac 64 Go peut allouer 48 Go à un modèle — impossible sur PC sans un GPU pro à 5 000 €. - Efficience énergétique : 20-40 W en inférence contre 350-575 W pour un GPU PC équivalent. Le MacBook ne chauffe quasi pas. - Silence : Sur MBP 16" M4 Max, ventilos à peine audibles même sur un 70B. Usage bureau sans aucune gêne. - Écosystème logiciel : Ollama, LM Studio, llama.cpp, MLX : tous optimisés Metal. Marche out of the box. Les limites. Pas de support CUDA (donc bibliothèques qui en dépendent directement échouent), bande passante mémoire plus faible qu'une RTX 4090 (le 4090 fait 1 To/s, un M4 Max fait ~540 Go/s), pas de tensor parallel inter-machine, fine-tuning plus contraint. ### 1. Relever la limite de mémoire GPU Par défaut, macOS réserve environ 2/3 de la RAM pour le GPU. Pour charger un modèle plus gros, il faut relever ce plafond. Combien laisser à macOS. Gardez 6-8 Go pour le système et vos apps. Sur 64 Go : 56 Go au GPU, 8 pour le système. Sur 128 Go (Mac Studio Ultra) : 112 Go GPU, 16 système. ### 2. Choisir les modèles adaptés - Mac 16 Go (M1/M2/M3/M4 de base) : Qwen 3.5 9B Q4 (6,6 Go), Granite 4.2 8B (5,3 Go), Gemma 4 12B (7,6 Go). Confortable, 50-80 tok/s. - Mac 32 Go (Pro) : Mistral Small 24B (14 Go), gpt-oss 20B (14 Go), Qwen 3.8 27B (18 Go). RAG confortable, chat productif. - Mac 64 Go (Pro/Max) : Qwen 3.6 35B-A3B (23 Go), Qwen3-Coder 30B-A3B en Q8 (32 Go), Granite 4.2 30B (18 Go). Un MoE 35B en pleine qualité est un régal. - Mac 128 Go (Ultra) : MoE 35B en Q8, ou plusieurs modèles chargés en parallèle (un généraliste + un spécialiste code). Territoire workstation. ### 3. Quantizations optimales sur Mac Metal aime certaines quantizations plus que d'autres. Sur Apple Silicon, le throughput varie significativement : - ⭐ Q4_K_M : Sweet spot : qualité proche de FP16, vitesse excellente sur Metal. - Q5_K_M / Q6_K : Excellent équilibre qualité/vitesse. Un peu plus lent que Q4 (-10 %). - Q8_0 : Très rapide sur Metal (surprenant), mais gros en RAM. Pour les gros Mac. - IQ3_M / IQ4_XS : Compressent mieux mais lourds en décodage sur Metal. À éviter si Q4_K_M passe. Formats MLX (spécifique Mac). MLX d'Apple propose des formats dédiés (mlx-community/Qwen3.5-9B-4bit). Un peu plus rapides sur certains modèles. À tester si vous êtes sur un M-series et utilisez MLX Studio. ### 4. Metal + Flash Attention Flash Attention, longtemps exclusif CUDA, marche sur Metal depuis llama.cpp fin 2024. Gain important sur les contextes longs. ### 5. KV cache quantifié Sur les contextes longs, le KV cache peut consommer plus de mémoire que le modèle lui-même. Le quantifier (Q8 ou Q4) divise par 2 ou 4 cette empreinte, pour une perte de qualité quasi-nulle. Impact concret. Sur un gros MoE 35B Q4 + contexte 32k, le KV cache passe de ~8 Go à ~4 Go. Sur un Mac 64 Go qui alloue 48 Go au GPU, ça fait la différence entre "ça ne rentre pas" et "ça tourne très bien". ### 6. Outils : MLX, Ollama, LM Studio - Ollama : Le plus simple. Reconnaît automatiquement Metal. Pour un usage quotidien, aucun effort. - LM Studio : UI au top, réglages fins, Mac-native. Excellent pour explorer des modèles. - llama.cpp (compilé maison) : Accès aux dernières optimisations Metal 4-6 semaines avant qu'Ollama les intègre. Utile pour power users. - MLX / mlx-lm : Framework Apple spécifique. Pour du fine-tuning en local et certains modèles MLX-natifs. Communauté grossit. ### Impact batterie Sur MacBook Pro, l'inférence LLM est étonnamment économe — bien plus qu'une exportation vidéo 4K. - Chat Qwen 3.5 9B, batterie : ~15 W de conso, ~6-8h d'autonomie en usage continu. - Chat Qwen 3.6 35B-A3B, batterie : ~25 W de conso, ~4h d'autonomie. - Chat Qwen3-Coder 30B Q8, batterie : ~40 W, ~2h d'autonomie. Mieux sur secteur. Low Power Mode. macOS Low Power Mode en déplacement ralentit le GPU d'environ 30 %. Désactivable à la demande (Réglages → Batterie). L'inférence reste utilisable en mode économie si la vitesse n'est pas critique. ## Benchmarks LLM : comprendre les leaderboards (MMLU, Arena, SWE-bench) Chaque nouveau modèle sort avec un graphique de scores qui le place « au niveau de GPT-5 ». Mais un benchmark LLM ne mesure jamais « l'intelligence » : il mesure une tâche précise, avec un protocole précis, et souvent une faille précise. Ce guide fait le tour des grands leaderboards (MMLU, GPQA, LMArena, SWE-bench), explique leurs pièges — contamination, saturation, cherry-picking — et montre comment évaluer vous-même un modèle local sur ce qui compte vraiment : vos tâches. ### Pourquoi les benchmarks comptent (et vous trompent) Un benchmark LLM, c'est un jeu de questions dont on connaît les réponses, qu'on pose à un modèle pour compter combien il en réussit. Le résultat est un score — un pourcentage, un classement Elo, un taux de résolution. C'est le seul langage commun qui permet de comparer deux modèles sans les tester soi-même pendant des heures, et c'est pour ça que tout le monde s'en sert. Le problème n'est pas le principe, c'est l'écart entre ce que le score dit et ce que vous lisez dedans. Un modèle qui affiche 90 % à MMLU n'est pas « intelligent à 90 % » : il répond correctement à 90 % d'un QCM de culture académique. Ça ne dit rien de sa capacité à suivre vos instructions, à écrire du français correct, à ne pas halluciner sur votre domaine, ou à tenir une conversation de dix tours. Un benchmark mesure une compétence étroite dans des conditions de laboratoire. La règle à garder en tête. Un benchmark répond à la question « ce modèle réussit-il CETTE tâche précise ? » — jamais à « ce modèle est-il meilleur pour MON usage ? ». Les deux se recoupent parfois, souvent partiellement, jamais totalement. On peut ranger les benchmarks en trois grandes familles, qui ne mesurent pas la même chose et ne se manipulent pas de la même façon : les benchmarks académiques (des QCM de connaissance et de raisonnement), les benchmarks de tâches réelles (résoudre un vrai bug, utiliser des outils) et les arènes de préférence humaine (des humains votent pour la meilleure réponse). On va les prendre dans l'ordre. ### Les benchmarks académiques : MMLU, GPQA, MATH C'est la famille historique, celle des tableaux de scores qu'on voit sur les pages de sortie de modèles. Ce sont des ensembles de questions à réponse vérifiable, souvent des QCM, notés automatiquement. Leur force est la reproductibilité ; leur faiblesse est qu'ils sont faciles à saturer et à contaminer. - MMLU : Massive Multitask Language Understanding : ~14 000 questions de QCM réparties sur 57 matières (droit, médecine, histoire, maths…). Le benchmark de connaissance le plus cité. Aujourd'hui largement saturé : les bons modèles dépassent 88-90 %, l'écart entre eux se joue dans le bruit. - MMLU-Pro : Version durcie de MMLU : 10 choix au lieu de 4, questions retriées pour être plus difficiles, plus de raisonnement. Créée précisément parce que MMLU ne discriminait plus les modèles de tête. - GPQA (Diamond) : « Google-Proof Q&A » : questions de niveau doctorat en biologie, physique et chimie, conçues pour qu'une recherche Google ne suffise pas. Le sous-ensemble « Diamond » est le plus dur. Bon indicateur du raisonnement scientifique de pointe. - MATH / AIME : Problèmes de mathématiques (MATH : niveau lycée/concours ; AIME : olympiades américaines). Réponse numérique unique, donc facile à noter. Devenu un marqueur des modèles « à raisonnement » (reasoning) qui réfléchissent en plusieurs étapes. - IFEval : Mesure la capacité à SUIVRE des instructions vérifiables (« réponds en exactement 3 puces », « n'utilise pas la lettre e »). Souvent plus révélateur pour un usage réel qu'un QCM de connaissance. - HLE (Humanity's Last Exam) : Benchmark récent et volontairement extrême : questions expertes multi-domaines pensées pour rester difficiles longtemps. Les meilleurs modèles y plafonnent encore bas, ce qui en fait un bon discriminateur en 2026. Attention au protocole de mesure. Un même modèle peut afficher deux scores MMLU différents selon la méthode : 0-shot vs 5-shot (avec exemples), avec ou sans chain-of-thought, avec un prompt exact vs reformulé. Comparer deux scores mesurés dans des conditions différentes n'a aucun sens. Vérifiez toujours que la comparaison est faite « à protocole égal ». ### Les benchmarks de tâches réelles : SWE-bench et les agents Cette famille est plus jeune et beaucoup plus dure à tricher, parce qu'elle ne pose pas des questions : elle demande d'accomplir une tâche complète dont le résultat est vérifiable objectivement. Résoudre un vrai ticket GitHub, faire passer une suite de tests, naviguer dans un dépôt de code. On en parle en détail dans notre guide dédié aux benchmarks de code ; voici l'essentiel. - SWE-bench Verified : Un sous-ensemble de 500 vrais problèmes GitHub (issues + patch attendu) validés manuellement par OpenAI comme résolvables et bien spécifiés. Le modèle doit produire un patch qui fait passer les tests du dépôt. C'est devenu LE standard pour le code en conditions réelles, bien plus parlant que HumanEval (aujourd'hui saturé à 96-98 %). - SWE-bench (full / Lite) : La version complète (~2 300 tâches) et une version allégée pour itérer vite. Les scores publiés dépendent énormément du « harnais » (l'agent qui orchestre le modèle) : un même modèle peut gagner 15 points selon l'outillage autour. - Tau-bench / agentiques : Benchmarks d'agents qui utilisent des outils (appels de fonctions, API, respect de règles métier) sur plusieurs tours. Mesurent la fiabilité en usage « assistant qui agit », pas seulement qui répond. - LiveCodeBench : Problèmes de programmation compétitive collectés en continu, avec une date de publication. On peut ne noter que les problèmes postérieurs à la date d'entraînement d'un modèle — un antidote direct à la contamination. Pourquoi ces benchmarks sont plus fiables. Un patch qui fait passer les tests, c'est vérifiable objectivement et difficile à mémoriser bêtement : le modèle doit vraiment produire une solution qui marche. C'est pour ça que les benchmarks agentiques résistent mieux à la saturation que les QCM. ### LMArena : le classement par préférence humaine LMArena (l'ex « Chatbot Arena » de LMSYS) fonctionne autrement : deux modèles anonymes répondent à la même question posée par un vrai utilisateur, qui vote pour la meilleure réponse. À partir de millions de duels, on calcule un score Elo (le même système que les échecs). C'est le benchmark le plus proche de « quel modèle les gens préfèrent-ils réellement ? ». - Ce que ça mesure bien : La qualité perçue en conversation ouverte : ton, structure, utilité globale, capacité à donner une réponse agréable. C'est très corrélé à la satisfaction d'usage réel. - Ce que ça mesure mal : La justesse factuelle. Les votants récompensent souvent les réponses longues, bien formatées et confiantes — même quand elles sont fausses. Un modèle « flatteur » peut monter au classement sans être plus exact. - Elo n'est pas un pourcentage : Un écart de 10-20 points Elo est du bruit statistique. Regardez toujours l'intervalle de confiance affiché : deux modèles peuvent être « à égalité » même s'ils ne sont pas sur la même ligne du tableau. - Les sous-classements : LMArena propose des catégories (code, maths, réponses longues, style contrôlé). Le sous-classement « hard prompts » ou « style control » est souvent plus informatif que le classement global, qui mélange tout. Croisez les deux mondes. Un modèle fort en benchmarks académiques mais faible en Arena est souvent « bon élève mais rigide ». Un modèle fort en Arena mais moyen en GPQA est souvent « agréable mais moins fiable sur le fond ». Le bon compromis se lit à l'intersection des deux, pas dans un seul classement. ### Le piège n°1 : la contamination des données La contamination, c'est quand les questions d'un benchmark (ou leurs réponses) se retrouvent, volontairement ou non, dans les données d'entraînement du modèle. Le modèle ne raisonne alors plus : il récite. Les benchmarks publics circulent sur le web, GitHub, Hugging Face — ils finissent mécaniquement dans les corpus de pré-entraînement. Résultat : un score gonflé qui ne prédit rien sur des questions inédites. C'est le talon d'Achille de tous les benchmarks statiques et publics. Plus un benchmark est ancien et célèbre, plus le risque est élevé. Quelques signaux qui doivent alerter : - Écart entre versions : Un modèle qui cartonne sur MMLU mais s'effondre sur MMLU-Pro (mêmes matières, questions neuves) sent la mémorisation plus que la compréhension. - Score anormalement élevé pour la taille : Un petit modèle 7B qui bat des 70B sur UN benchmark précis et un seul : méfiance, souvent un entraînement ciblé (« benchmaxxing ») sur ce jeu de test. - Benchmarks datés : Les évaluations « live » (LiveCodeBench, questions horodatées) contournent le problème : on ne note que ce qui est postérieur à la date de coupe du modèle. - Trous de mémoire suspects : Certains tests injectent des variantes canari (« canary strings ») ou des reformulations pour détecter la récitation. Un gros écart entre question originale et reformulée trahit la contamination. ### Le piège n°2 : la saturation Un benchmark est saturé quand les meilleurs modèles y atteignent des scores si hauts qu'il ne les distingue plus. Quand tout le monde est à 96-99 %, les 3 points restants sont du bruit de mesure (questions ambiguës, erreurs d'étiquetage) plutôt qu'une vraie différence de capacité. HumanEval (code) et MMLU (connaissance) sont les exemples canoniques : ils ont été très utiles, ils ne le sont plus pour départager le haut du classement. C'est pour ça que de nouveaux benchmarks plus durs apparaissent en permanence : MMLU-Pro remplace MMLU, GPQA Diamond et HLE prennent le relais pour le raisonnement, SWE-bench Verified remplace HumanEval pour le code. Un benchmark a une durée de vie utile ; passé un certain niveau moyen, il faut le retirer de vos critères de décision. Ne comparez pas dans la zone de saturation. Choisir entre deux modèles à 97,1 % et 97,8 % sur un benchmark saturé, c'est choisir sur du bruit. Descendez d'un cran : regardez un benchmark plus dur, ou mieux, testez-les sur vos propres tâches. La différence qui compte pour vous n'est presque jamais dans ces 0,7 point. ### Lire un leaderboard sans se faire avoir Voici la méthode à appliquer devant n'importe quel tableau de scores, qu'il vienne d'un communiqué de modèle ou d'un classement public. - Identifiez qui publie : - Vérifiez le protocole : - Regardez les intervalles de confiance : - Croisez plusieurs benchmarks : - Pondérez par VOTRE usage : ### Évaluer un modèle local sur vos propres tâches La conclusion logique de tout ce qui précède : le benchmark le plus fiable pour vous, c'est le vôtre. Il ne peut pas être contaminé (vos questions ne sont pas sur le web), il n'est jamais saturé (vous le calibrez sur vos cas difficiles), et il mesure exactement ce dont vous avez besoin. Pas besoin d'infrastructure lourde : une vingtaine d'exemples représentatifs suffisent pour départager deux modèles. - Constituez un mini-jeu de test : - Installez les modèles à comparer : - Automatisez les appels : - Notez en aveugle : - Mesurez aussi le coût réel : Outils si vous voulez industrialiser. Pour aller plus loin qu'un script maison, des outils comme lm-evaluation-harness (le standard académique, celui qui alimente l'Open LLM Leaderboard) ou promptfoo (orienté comparaison de prompts et de modèles) permettent d'automatiser la notation. Mais pour un choix perso, 20 exemples notés à la main battent n'importe quel score public. ### Pour aller plus loin Ces guides prolongent les notions vues ici, du côté des benchmarks spécialisés et du choix concret d'un modèle local : - Benchmarks de code en détail : « HumanEval est mort : comprendre les benchmarks de code LLM en 2026 » creuse SWE-bench, LiveCodeBench et comment lire les scores de code — le prolongement direct de ce guide côté développement. - Choisir sa quantization : « Quantization GGUF en 2026 : Q4_K_M vs Q5_K_M vs Q6_K » montre comment mesurer l'impact réel d'une quantization sur la qualité — une éval maison appliquée à un cas concret. - Un test de modèle complet : « Qwen 3 en local : test complet et benchmarks réels » illustre la méthode d'évaluation locale (tokens/sec, qualité FR, VRAM) sur un modèle précis. ## Température, top-p, top-k : les paramètres La température à 0,8. Le top-p à 0,95. Le top-k à 40. Ces nombres apparaissent partout et personne n'explique vraiment ce qu'ils font. Ce guide démonte les trois boutons qui changent 90 % du comportement d'un modèle, avec des exemples concrets de ce que vous voyez dans la sortie quand vous les bougez. ### D'abord : comment un LLM choisit le prochain mot À chaque étape de génération, le modèle produit une distribution de probabilités sur tous les tokens du vocabulaire (~150 000 tokens pour un Qwen 3.5, ~256 000 pour un Gemma 4). Il pourrait choisir le plus probable à chaque fois (greedy), mais le résultat serait plat et répétitif. On introduit donc de l'aléatoire — contrôlé par la température, top-p et top-k. Trois filtres en cascade. D'abord la température modifie les probabilités. Puis top-k ne garde que les K meilleurs candidats. Puis top-p ne garde que les candidats dont la probabilité cumulée atteint p. On tire au hasard dans ce qui reste. ### 1. Température La température lisse ou accentue la distribution. T=0 = toujours le token le plus probable (déterministe). T=1 = distribution brute. T>1 = les tokens rares deviennent plus probables (créativité et incohérence). - 0.0 – 0.2 : Factuel, déterministe. Extraction de données, résumé fidèle, code. La même question donne la même réponse. - 0.3 – 0.5 : Précis mais vivant. Support client, rédaction technique, traduction. - 0.7 – 0.9 : Défaut de la plupart des modèles. Équilibre qualité/variété. Conversation, emails, explication. - 1.0 – 1.3 : Créatif. Brainstorming, fiction, poésie. Attention aux hallucinations. - > 1.5 : Zone de chaos. Intéressant pour l'art génératif, risqué pour tout le reste. Règle du déterminisme. Pour tout ce qui doit être parseable (JSON, code, classification), mettez la température à 0 ou 0.1. Toute variabilité = bug potentiel dans votre pipeline. ### 2. Top-p (nucleus sampling) Top-p garde les tokens les plus probables jusqu'à ce que leur probabilité cumulée atteigne p. Top-p = 0.9 signifie : "ne considère que les tokens qui, ensemble, couvrent 90 % de la probabilité". Les 10 % de queue sont jetés. - 0.5 – 0.7 : Très conservateur. Réponses sûres, parfois ennuyeuses. - 0.9 : Défaut courant. Coupe la queue exotique sans étouffer la variété. - 0.95 – 0.99 : Laisse passer quasiment tout. Utile avec des températures basses pour compenser. - 1.0 : Désactivé (pas de filtre nucleus). Température OU top-p. Régler les deux au maximum ou au minimum en même temps n'a pas grand sens. La pratique : fixez top-p à 0.9-0.95 et jouez sur la température. ### 3. Top-k Top-k garde les K tokens les plus probables. Top-k = 40 = "ne considère que les 40 meilleurs candidats à chaque étape". C'est un filtre plus brutal que top-p : il ne tient pas compte de la forme de la distribution. - 1 : Greedy. Équivalent température = 0. - 20 – 40 : Défaut typique. Bon compromis. - 100+ : Peu de filtrage, on s'en remet à top-p et température. - 0 : Désactivé. ### Pénalités : repetition, frequency, presence Moins connus mais très utiles pour les modèles locaux qui ont tendance à boucler : - repetition_penalty : Multiplie la probabilité des tokens déjà utilisés récemment (par défaut 1.1). Passer à 1.2-1.3 si le modèle répète des phrases entières. - frequency_penalty : Pénalise proportionnellement au nombre d'occurrences. Plus subtil. 0.5-0.8 sur les longues générations. - presence_penalty : Pénalise dès qu'un token apparaît une fois. Encourage la diversité de vocabulaire. 0.5 pour plus de variété lexicale. Ne pas trop pénaliser. À partir de repetition_penalty > 1.5, le modèle commence à inventer des mots rares pour éviter les répétitions. Il devient parfois littéralement incompréhensible. ### Presets par usage - Code : temperature 0.1, top-p 0.95, top-k 40. Déterministe, focus sur le token le plus probable. - Résumé factuel : temperature 0.2, top-p 0.9, repetition_penalty 1.15. Peu de latitude, pas de hors-sujet. - Conversation naturelle : temperature 0.7, top-p 0.9, top-k 40. Défaut raisonnable partout. - Brainstorming : temperature 0.9, top-p 0.95, presence_penalty 0.6. Variété lexicale, idées moins convenues. - Fiction / créatif : temperature 1.1, top-p 0.95, frequency_penalty 0.3. Style plus dense, rythme imprévisible. Modèles à raisonnement : baissez l'effort. Les modèles 2026 avec raisonnement intégré (Qwen 3.8 27B, par exemple) ont tendance à sur-réfléchir avec leur réglage par défaut : ils enchaînent de longues chaînes de pensée même pour une question simple. Passez l'effort de raisonnement sur low pour des réponses plus directes et beaucoup moins de tokens gaspillés. ### Symptômes → réglage - Répète la même phrase en boucle : repetition_penalty 1.2, ou relancer avec plus de contexte varié. - Réponses plates et génériques : Montez la température à 0.8-0.9, ou relâchez top-p à 0.95. - Hallucinations (invente des faits) : Baissez la température à 0.2-0.3. Ajoutez au system prompt : "Si tu ne sais pas, dis-le." - Code invalide : temperature 0. Toujours. Pas de créativité en code. - JSON cassé : temperature 0 + JSON mode si dispo. Sinon, very strict format instructions. - Change de langue en cours de route : Rappel explicite en system prompt. Baisser légèrement la température aide.