Accueil / Articles / Pourquoi un téléchargement du modèle de 17 Go ne signifie pas 17 Go de mémoire pour le faire fonctionner

LLMLocal AIMixture of ExpertsInferenceMachine Learning

Pourquoi un téléchargement du modèle de 17 Go ne signifie pas 17 Go de mémoire pour le faire fonctionner

Découvrez comment les paramètres actifs, le nombre total de paramètres, la croissance du cache KV et l’effort de raisonnement déterminent le coût réel en mémoire et en calcul pour exécuter un modèle de langage localement.

2722 mots

Un nouveau modèle ouvert est annoncé ; l’article titre que celui-ci rivalise avec des systèmes bien plus volumineux, et un chiffre attire particulièrement l’attention : la taille du téléchargement n’est que de 17 Go. Cela semble rendre une aide sérieuse à la programmation accessible à n’importe quel poste de travail ordinaire, jusqu’à ce que l’on charge un véritable ensemble de codes ou une longue conversation, et que le processus manque de mémoire. La taille du fichier, le nombre de paramètres actifs et la quantité de mémoire réellement nécessaire à un modèle en exécution sont trois grandeurs distinctes. Cet article explique comment elles sont liées, afin que vous puissiez estimer le coût réel de l’exécution d’un modèle avant de planifier votre matériel en vous basant uniquement sur les titres des articles.

Le nombre de paramètres est un indicateur moins fiable qu’auparavant

Lors de la comparaison des modèles de langage, la plupart des gens examinent d’abord le nombre de paramètres. C’est un instinct raisonnable : les paramètres représentent les poids appris par le réseau, et il semble logique que plus ils soient nombreux, plus le modèle sera grand, intelligent et coûteux.

Les architectures modernes ont rendu cette relation beaucoup moins stricte. Un tournant important a été la recherche menée par DeepMind sur Chinchilla, axée sur un entraînement optimal en termes de ressources informatiques. Elle a montré qu’un modèle de 70 milliards de paramètres, entraîné sur bien plus de données, pouvait surpasser des modèles beaucoup plus gros, y compris Gopher avec ses 280 milliards de paramètres, lorsque tous deux utilisaient une quantité comparable de ressources d’entraînement.

La conclusion n’était pas que les petits modèles l’emportent. Elle était plus nuancée et plus utile : la manière dont un modèle utilise ses paramètres peut être tout aussi importante que leur nombre. Cette idée est devenue centrale pour une autre architecture qui domine aujourd’hui les discussions sur les modèles efficaces, à savoir le Mixture of Experts.

Paramètres actifs par rapport au nombre total de paramètres

  • Le nombre de paramètres actifs correspond approximativement au nombre de paramètres impliqués dans la génération d’un token.
  • Le nombre total de paramètres indique l’ensemble des paramètres présents dans le modèle.

L’écart entre les deux peut être énorme. DeepSeek-V3 en est un exemple bien connu : il compte environ 671 milliards de paramètres au total, avec près de 37 milliards activés par token. Générer un token est donc bien moins coûteux que ce serait pour un modèle dense de 671 milliards de paramètres. Cela ne signifie pas pour autant que DeepSeek-V3 se comporte comme un modèle de 37 milliards de paramètres sous tous les aspects pratiques, et c’est précisément là que de nombreuses comparaisons se trompent.

Le coût de calcul et le coût mémoire sont des budgets distincts

Les paramètres actifs constituent un bon indicateur du calcul : ils indiquent le nombre d’opérations de multiplication-accumulation nécessaires pour chaque token, et donc la vitesse à laquelle les tokens peuvent être générés sur un matériel donné.

La mémoire constitue un budget distinct. Le moteur d’inférence ne peut pas évincer les experts qui n’ont pas été choisis pour le token actuel, car le routage peut en sélectionner n’importe lequel pour le suivant. Tous doivent rester accessibles, généralement dans une GPU ou une mémoire unifiée, car charger les poids depuis le disque pour chaque token serait bien trop lent.

Ainsi, un modèle peut être peu coûteux à calculer tout en nécessitant beaucoup de mémoire. Une règle concise le résume ainsi :

Les paramètres actifs indiquent combien de calculs chaque token nécessite. La taille totale du modèle indique quelle quantité de mémoire doit être disponible.

Ces deux mesures sont liées, mais elles répondent à des questions différentes et ne peuvent pas se substituer l’une à l’autre.

Ce qu’un téléchargement de 17 GB contient réellement

C’est pourquoi l’expression « un modèle d’IA de 17 GB » est trompeuse. Un fichier de poids quantifié peut effectivement atteindre cette taille. La quantification stocke chaque poids avec moins de bits, par exemple 4 bits au lieu de 16, ce qui réduit considérablement la taille du fichier au prix d’une légère perte de qualité.

Cependant, le fichier sur votre SSD n’est qu’un des éléments nécessaires au fonctionnement du processus. En plus de celui-ci, vous avez besoin de mémoire pour :

  • les poids une fois chargés en mémoire,
  • les coûts opérationnels propres au temps d’exécution des calculs,
  • les buffers temporaires utilisés pendant les calculs,
  • le contexte, stocké dans le cache KV,
  • ainsi que tout ce que l’ système d’exploitation et les autres logiciels utilisent déjà.

Ainsi, un fichier de 17 GB ne signifie pas qu’une machine disposant de 17 GB de mémoire libre pourra exécuter le modèle sans problème, ni même qu’elle pourra le faire lorsque le contexte s’agrandit.

Les mesures effectuées au sein de la communauté sur Qwen3.8-27B illustrent bien ce point. Une version quantisée d’environ 17 GB peut nécessiter beaucoup plus de mémoire une fois qu’un contexte long est chargé, et avec la longueur de contexte native du modèle de 262 144 tokens, la seule cache KV devient très volumineuse. Pour comprendre pourquoi, il faut examiner comment le modèle mémorise une conversation.

La conversation elle-même occupe de la mémoire

Un modèle transformer ne lit pas votre demande une seule fois avant de l’ignorer. Lorsqu’il génère chaque nouveau token, il prend en compte tous les tokens précédents du contexte. Recalculer la représentation interne de tout le contexte pour chaque nouveau token serait extrêmement lent, c’est pourquoi les moteurs d’inférence stockent plutôt les résultats intermédiaires.

Cette mémoire est la KV cache, abréviation de key/value cache. Pour chaque token du contexte, chaque couche d’attention conserve un vecteur clé et un vecteur de valeur. La mémoire augmente donc de manière approximativement linéaire avec la longueur du contexte : un modèle qui fonctionne facilement pour une conversation courte peut devenir beaucoup plus lourd lorsqu’on lui fournit des dizaines ou des centaines de milliers de tokens, par exemple un répertoire entier.

D’après la fiche du modèle Qwen3.8-27B sur Hugging Face, ce modèle prend en charge un contexte natif de 262 144 tokens. Il utilise une conception hybride dans laquelle seules certaines couches emploient l’attention conventionnelle, ce qui permet justement d’utiliser une fenêtre aussi longue.

Une analyse communautaire de l’architecture estime qu’environ 64 KB de données de cache KV en FP16 par token sont nécessaires pour les couches qui conservent encore un cache traditionnel. En multipliant ce chiffre par 262 144 tokens, on obtient approximativement 16,8 GB de cache KV, sans compter les autres éléments. Un budget mémoire approximatif pour une session à contexte complet se présente donc comme suit :

  • Poids du modèle : environ 17 GB
  • Cache KV pour un contexte complet : environ 17 GB
  • Surcoûts de fonctionnement et buffers : en plus de cela

Le modèle n’a jamais réduit sa taille pour devenir un programme de 17 GB. Vous avez téléchargé 17 GB de poids quantifiés, mais la charge réelle peut être environ deux fois plus élevée ou même davantage. Vous comprenez également pourquoi la longueur du contexte est l’élément à ajuster lorsque la mémoire est limitée : diviser par deux la longueur du contexte réduit à peu près de moitié l’espace de cache, et de nombreux environnements d’exécution peuvent quantifier le cache KV lui-même pour le réduire encore, au prix d’une légère perte en précision. Ces valeurs communautaires sont des estimations ; comparez-les à l’utilisation mémoire indiquée par votre propre environnement d’exécution.

Comment l’attention hybride permet de gérer des contextes longs

C’est ici que l’architecture devient intéressante. Dans un transformateur classique, chaque couche d’attention conserve ses propres entrées KV, ce qui fait que l’espace de cache augmente à la fois avec le nombre de couches et celui des tokens.

D’après les analyses publiées sur sa conception, Qwen3.8-27B adopte une approche hybride. Sur ses 64 couches, seules un nombre relativement faible utilisent l’attention complète, tandis que la plupart emploient l’attention linéaire. Les couches à attention linéaire résument le passé en un état de taille fixe au lieu de stocker des clés et des valeurs pour chaque token, ce qui évite d’augmenter la taille de la mémoire temporaire. Seules les couches à attention complète entraînent des coûts par token, d’où le faible chiffre indiqué ci-dessus.

Ces astuces sont ce qui rend possibles des fenêtres de contexte très longues. Sans elles, la mémoire nécessaire pour un quart de million de tokens deviendrait rapidement impraticable, sauf sur du matériel dédié aux data centers.

Ainsi, chaque fois qu’un modèle affiche une fenêtre de contexte très large, posez-vous la question suivante : quelle est l’architecture mise en œuvre pour rendre ce contexte gérable ? La seule longueur du contexte ne suffit pas à vous renseigner.

Une victoire sur un test de référence n’est pas une victoire globale

Les gros titres ont une autre habitude : un modèle « bat Claude » ou « bat GPT » sur un test de référence, et on en conclut qu’il est meilleur dans l’ensemble. Les tests de référence évaluent des tâches spécifiques dans des conditions précises, et un seul score ne dit pas grand-chose sur le reste.

Qwen3.8-27B illustre bien ce point. Ses résultats publiés montrent de bons scores en programmation :

  • Terminal-Bench 2.1, qui teste le travail d’agent dans une terminal : 73,0
  • SWE-bench Pro, qui teste la correction de problèmes réels dans des dépôts : 61,7
  • GPQA Diamond, un ensemble de questions scientifiques de niveau universitaire : 89,2

Lorsqu’on compare les performances de l’Opus 4.6 Max avec celles des autres modèles sur la même fiche de comparaison, les résultats sont mitigés. Sur Terminal-Bench 2.1, Qwen est inférieur à la note de 78,2 obtenue par l’Opus 4.6 Max. Sur SWE-bench Pro, sa note de 61,7 est supérieure à celle de 53,4 obtenue par l’Opus. Sur GPQA Diamond, sa note de 89,2 est inférieure à une note de 91,3.

Quel modèle est le meilleur ? Cela dépend de la tâche. Le travail avec des terminaux autonomes, la correction de bugs au niveau des répertoires et les questions scientifiques de niveau universitaire exigent des compétences différentes, tout comme les tâches à long terme pour des agents autonomes. Chaque benchmark ne mesure qu’une capacité spécifique, et non un classement universel de l’intelligence.

La méthodologie est également importante. L’outil d’évaluation, la stratégie de sollicitation, les outils disponibles, la méthode de notation et la configuration du modèle peuvent tous influencer les scores, et les fournisseurs ne mettent pas toujours en compétition des modèles dans des conditions identiques. Une affirmation du type « Le modèle X bat le modèle Y » omet l’élément essentiel. La version précise ressemble plutôt à ceci :

Sous ces conditions, le modèle X a obtenu un score plus élevé que le modèle Y lors de cette évaluation.

C’est moins spectaculaire, mais bien plus utile.

Les efforts de raisonnement constituent un multiplicateur de coûts caché

Même une fois que les paramètres et la mémoire sont compris, une autre variable peut silencieusement modifier le coût de fonctionnement d’un modèle : la quantité de raisonnement qu’il effectue avant de répondre.

Les modèles axés sur le raisonnement offrent de plus en plus une option pour cela. Qwen3.8 prend en charge un paramètre reasoning_effort avec des niveaux tels que low, medium et xhigh, xhigh étant la valeur par défaut ; sa documentation décrit explicitement ces niveaux comme des contrôles de la profondeur et du coût du raisonnement.

L’équilibre à trouver est simple : un plus grand niveau de raisonnement peut aider sur des problèmes difficiles, mais chaque étape de raisonnement génère des tokens, ce qui entraîne plus de calculs, plus de latence et, pour des chaînes de raisonnement longues, une utilisation accrue de la mémoire cache KV. Deux personnes utilisant le même modèle peuvent donc observer des coûts très différents uniquement en raison de cette seule configuration.

Cela est particulièrement pertinent pour les agents de codage, qui s’occupent de tâches de difficulté très variée. Comparez une demande de renommer une variable à une demande d’explorer un répertoire inconnu, de trouver une faille architecturale, de modifier six fichiers, d’exécuter les tests, de diagnostiquer les pannes et de créer un correctif. La première ne nécessite absolument pas le même niveau de raisonnement que la seconde. Faire appel au maximum de capacités de raisonnement pour chaque demande, c’est comme faire participer un ingénieur senior à une réunion sur l’étiquette d’un bouton : cela fonctionne, mais c’est un mauvais usage des ressources.

Il existe une réservation, soulignée dans la documentation même de Qwen. Réduire l’effort peut accélérer chaque tour individuel, mais provoquer davantage de tentatives ou d’échecs dans les tâches d’agent à plusieurs étapes, ce qui peut annuler les économies réalisées. L’approche pratique consiste à mesurer le coût global de la tâche, et non la latence par tour, ainsi qu’à diriger les tâches faciles et difficiles vers des paramètres différents si vos outils le permettent. Aucun paramètre unique ne convient à tout.

Pourquoi un calcul actif efficace reste très important

Malgré toutes ces réserves, il serait facile de penser que l’idée de petits modèles locaux performants n’est qu’un bruit médiatique. Ce n’est pas le cas. Les progrès sont réels : des modèles disposant d’un budget de calcul actif modeste peuvent désormais gérer des travaux sérieux en ingénierie logicielle qui auraient été très difficiles à exécuter localement il y a seulement quelques années.

La seule correction nécessaire est de comprendre que le calcul efficace ne signifie pas automatiquement une faible consommation mémoire.

Cette distinction est d’autant plus importante à l’échelle des data centers. Un fournisseur qui sert des milliers d’utilisateurs charge les poids une seule fois et les partage entre toutes les requêtes. En revanche, le cache KV appartient à chaque conversation individuelle. Réduire la mémoire nécessaire pour chaque conversation active permet d’accueillir davantage d’utilisateurs simultanés sur le même matériel, ce qui diminue directement le coût de mise à disposition du modèle.

Vu sous cet angle, des détails architecturaux qui semblent être de simples astuces de recherche obscures, tels que l’attention hybride ou la compression du cache KV, deviennent des facteurs économiques importants. Un modèle n’a pas besoin d’être petit partout ; il doit être efficace là où l’infrastructure est soumise à la plus forte pression.

Lorsqu’un modèle de 17 GB représente véritablement une excellente affaire

Il y a aussi un aspect très positif. De nombreuses tâches réelles reposent sur un contexte restreint :

  • un seul fichier,
  • un problème de codage bien ciblé,
  • un petit projet,
  • une conversation ordinaire.

Dans de tels cas, un modèle bien quantifié de cette catégorie peut être véritablement impressionnant. Vous n’avez pas besoin d’un grand serveur cloud pour l’essayer. Vous pouvez exécuter un modèle performant sur du matériel grand public, conserver vos données sur votre propre machine et éviter les frais API par token pour chaque expérience. Pour un exemple concret de ce flux de travail, consultez la création d’un clone local d’Angry Birds avec Qwen3.8-27B et Pi.

Cela élargit le cercle des personnes pouvant expérimenter avec de l’IA sérieuse, ce qui est sans doute plus important que le fait qu’un score de benchmark soit supérieur de trois points à un autre.

Quatre questions à se poser plutôt que « combien de paramètres ? »

La prochaine fois qu’un titre met en avant un faible nombre de paramètres ou une petite taille de téléchargement, réfléchissez à ces quatre questions.

Combien de paramètres sont actifs ?

Cela vous indique le calcul par token, et donc approximativement la vitesse à laquelle le modèle peut générer sur votre matériel.

Combien de paramètres existent au total ?

Cela vous donne une idée de l’impact global, et c’est le principal facteur déterminant la quantité de mémoire nécessaire pour les poids du modèle.

Quelle est la taille de la mémoire cache KV ?

Cela dépend de l’architecture ainsi que de la longueur de contexte que vous prévoyez d’utiliser, et ce facteur devient dominant avec des contextes longs.

Combien de temps le modèle prend-il pour raisonner avant de répondre ?

Cela influence la latence, la consommation de tokens et le coût, et cela peut être ajusté en fonction de chaque tâche.

Ces quatre réponses ensemble vous en disent bien plus qu’une taille de téléchargement ne pourra jamais le faire.

Les modèles sont devenus plus efficaces, pas nécessairement plus petits

La tendance générale est bien un gain réel d’efficacité dans l’ensemble du système : de meilleures stratégies d’entraînement et d’échelle des données, un meilleur routage par experts, une meilleure quantification, de meilleures architectures d’attention, ainsi que des capacités de raisonnement pouvant être configurées au moment de l’inference.

Rien de tout cela ne fait de l’efficacité computationnelle une équivalence avec une petite empreinte mémoire :

  • Un modèle MoE peut activer une fraction de ses paramètres par token tout en conservant un réseau très vaste.
  • Un modèle quantifié peut occuper une petite quantité d’espace disque tout en nécessitant beaucoup plus de mémoire au moment de l’inference.
  • Une fenêtre de contexte longue peut faire en sorte que la conversation elle-même consomme des gigaoctets.
  • Un niveau de raisonnement plus élevé peut rendre la même requête bien plus coûteuse en termes de calcul.

La meilleure question n’est donc pas de savoir combien de paramètres possède un modèle. Elle est plutôt la suivante :

Quelle quantité de mémoire et de puissance de calcul ce travail spécifique nécessite, depuis le chargement du modèle jusqu’à la génération du token final ?

Points clés

  • La taille du téléchargement d’un modèle ne couvre que ses poids ; le cache KV, les surcoûts de fonctionnement et les buffers s’ajoutent et peuvent doubler les besoins réels pour des contextes longs.
  • Les paramètres actifs décrivent la puissance de calcul par token, tandis que le nombre total de paramètres détermine la quantité de mémoire qui doit rester disponible.
  • La taille du cache KV augmente avec la longueur du contexte et dépend fortement de l’architecture, c’est pourquoi les conceptions d’attention hybrides sont importantes pour des fenêtres longues.
  • Les victoires dans les benchmarks sont spécifiques à la tâche et dépendent de la méthodologie ; interprétez-les comme « meilleures pour cette évaluation », et non « meilleures en général ».
  • L’effort de raisonnement constitue un véritable levier de réduction des coûts, mais il convient d’évaluer le coût total de la tâche, car un effort moindre peut entraîner des tentatives répétées qui annulent les économies réalisées.
  • Lorsqu’un titre promet un modèle de petite taille capable de surpasser un modèle géant, il est nécessaire d’examiner les benchmarks, la configuration, les paramètres actifs et totaux, la quantification, la longueur du contexte ainsi que le budget alloué au raisonnement avant de le croire ou de l’ignorer.

    • Lectures complémentaires

    Tous les articlesEnvoyer le brief