Comment lire les spécifications d'un modèle : famille, taille, contexte

À chaque sortie d'un nouveau modèle, on reçoit sa « fiche technique » : un nom avec des lettres et des chiffres, des milliards de paramètres, une fenêtre de contexte, une liste de benchmarks. On la lit comme celle d'un smartphone, mais les règles de comparaison sont différentes.

Ici, apprenez à décoder la fiche d'un modèle d'IA, ligne par ligne. À la fin, la méthode s'applique à un modèle réel.

1. La famille : le nom raconte la moitié de l'histoire

Les noms des modèles suivent un schéma : Qwen 3, Llama 3.1, Gemma 3, Mistral 7B. La famille est la lignée, le numéro est la version : même architecture, même méthode d'entraînement, donc les spécifications d'une version sont un point de départ fiable pour la suivante.

Pourquoi est-ce important ? Parce que la famille raconte le caractère : multilingue, technique, mathématiques, multimodal. Si une famille a bonne réputation pour votre tâche, une nouvelle version est presque toujours un pari sûr — même sans benchmarks disponibles.

Deux détails pratiques :

• « Instruct » et base : « instruct » (ou « -it ») dans le nom = préparé pour la conversation. Un modèle de base est un moteur de complétion de texte, utile pour le fine-tuning, pas pour le chat.
• Les numéros de version : de 2.5 à 3, c'est un saut important, avec des spécifications qui changent beaucoup. Au sein d'une version (7B → 14B), les différences sont de taille, pas d'approche.

2. La taille : ce que veulent dire les « B »

« B » signifie milliard (de paramètres) : un 7B a 7 milliards de valeurs internes qui déterminent son comportement. La taille décide la qualité et la mémoire nécessaire.

Règle pratique : en pleine précision (16 bits), comptez environ 2 Go de RAM ou VRAM par milliard de paramètres, plus une marge pour le contexte :

• 1-4B : tourne partout, même sur un portable daté. Bon pour des résumés simples et des brouillons.
• 7-14B : le point d'équilibre. Avec 16-32 Go, on obtient une qualité que beaucoup de services en ligne ne proposent pas.
• 32B et au-delà : excellente qualité, mais il faut un matériel sérieux ou une quantification agressive.

Il y a aussi une loi des rendements décroissants : le saut 3B→7B est souvent plus grand que le saut 7B→14B. La taille est le premier chiffre à lire, pas le seul.

3. Paramètres actifs : le chiffre qui change tout

Un chiffre apparaît de plus en plus dans les fiches : les paramètres actifs. C'est l'architecture MoE (Mixture of Experts).

Dans un modèle MoE, le modèle contient beaucoup de milliards de paramètres au total, mais pour chaque token n'en active qu'une petite partie. Qwen3 30B-A3B signifie : 30 milliards au total, 3 actifs par token. DeepSeek V4.1 Flash en a 552 milliards au total, mais seulement 8 à 16 actifs.

Deux chiffres différents déterminent deux besoins différents :

• Les paramètres totaux déterminent la mémoire pour charger le modèle (tous les poids doivent tenir, même non utilisés ensemble).
• Les paramètres actifs déterminent la vitesse de la réponse.

Un MoE donne donc la qualité d'un grand modèle à la vitesse d'un petit — à condition d'avoir la mémoire pour le poids entier. Quand vous lisez « 552B », pensez à « un modèle qui raisonne avec 16 milliards, mais dont le cerveau en occupe 552 ».

4. Le contexte : combien il peut retenir

Le contexte est le nombre maximal de tokens qu'un modèle peut gérer d'un seul coup : ce que vous envoyez + ce qu'il répond. Un token vaut environ trois quarts d'un mot.

Traduction pratique :

• 8-32K : conversations courtes, petits documents.
• 64-128K : documents entiers, longs fichiers de code.
• 1M+ : la nouvelle génération (DeepSeek V4.1 Flash, Llama 4) traite un livre entier ou une base de code complète en un seul passage.

Deux avertissements. Premier : un contexte grand coûte — en mémoire (le cache KV croît avec la conversation) et en qualité, car le modèle perd le fil au milieu d'une entrée très longue. Second : le contexte déclaré est le maximum, pas le défaut. Un contexte de 1M sur 16 Go de mémoire signifie un contexte réel bien plus petit.

5. La quantification : le même modèle en différentes tailles

Vous verrez souvent le même modèle en versions 4 bits, 5 bits, 8 bits : la quantification compresse la précision des poids (un 7B passe d'environ 14 Go à 16 bits à environ 4,5 Go en Q4).

Que perd-on ? Peu. Entre 8 bits et pleine précision, la perte est quasi imperceptible ; entre 4 bits et 8 bits, on peut percevoir une différence dans le raisonnement complexe, mais la version 4 bits d'un bon modèle bat celle 8 bits d'un modèle médiocre :

• 8 bits (Q8) : si votre matériel le permet, c'est la qualité à viser.
• 4 bits (Q4) : la norme pour l'usage local, le meilleur compromis entre taille et qualité.
• 2 bits (Q2) : seulement si rien d'autre ne tient. La dégradation devient perceptible.

Le format compte : GGUF est la norme pour l'IA locale (Ollama, LM Studio). Si une version GGUF existe, la communauté locale y travaille déjà.

6. Les benchmarks : des chiffres utiles, à lire avec méthode

Les benchmarks sont des tests standardisés : GPQA (raisonnement scientifique), MMLU (connaissances générales), SWE-bench (code réel), AIME (mathématiques). Trois pièges :

Piège 1 : ils mesurent ce sur quoi le modèle a été entraîné. Un score proche du plafond n'est pas toujours bonne nouvelle : cela peut indiquer une contamination du test. Piège 2 : le chiffre seul ne dit rien. Les chiffres sont comparables seulement s'ils sont sur le même test, dans les mêmes conditions, avec la même quantification. Piège 3 : le benchmark mauvais pour votre usage. Un benchmark multilingue (MMMLU) est plus informatif qu'un benchmark de code si vous avez besoin d'un bon support de votre langue ; SWE-bench l'emporte sur un score de connaissances générales si le modèle servira à programmer.

La bonne posture : les benchmarks disent si un modèle est suffisamment capable ; seul un test avec vos données réelles dit s'il est fait pour vous.

7. La licence : la ligne invisible

C'est la ligne que tout le monde saute, et celle qui décide de ce que vous pouvez vraiment faire. Quatre classes :

• MIT / Apache 2.0 : usage commercial libre, aucune obligation. Le meilleur cas.
• Licences communautaires (la licence Llama) : usage libre avec conditions — souvent aucune obligation sous un seuil d'utilisateurs mensuels, au-dessus un accord avec le fabricant.
• Open-weight avec restrictions : les poids sont téléchargeables, mais la licence limite l'usage commercial ou la redistribution.
• Fermés : les poids ne sont pas publiés ; le modèle s'utilise uniquement via le service.

Deux mots à ne pas confondre : open source (code, poids, souvent données et méthode publics) et open-weight (seuls les poids sont publics). La plupart des modèles modernes sont open-weight, pas open source. Avant d'intégrer un modèle dans un produit, lisez la licence.

8. Lire une fiche réelle

Mettons la méthode à l'épreuve avec DeepSeek V4.1 Flash, sorti en septembre 2026 — toutes les lignes y sont :

• Famille : DeepSeek V4, la lignée qui a défini le rapport qualité/prix de l'année. « Flash » est le petit de la famille.
• Taille : 552B au total, 8B actifs en lecture (prefill), 16B en réponse (decode). MoE.
• Contexte : 1M de tokens — un livre entier ou une base de code en un seul passage.
• Benchmarks : 90,6 sur Terminal-Bench 2.1 et 74,2 sur DeepSWE (chiffres du fabricant), pour un modèle qui « pense » avec 16 milliards.
• Licence : MIT — usage commercial libre, sans conditions.

Comment se lit cela ? Les 552B disent qu'en local il faut un serveur (à 4 bits, environ 300 Go), pas une workstation. Les 16B actifs disent pourquoi c'est rapide chez un provider. Les 1M de contexte sont la vraie nouveauté ; la licence MIT dit que vous pouvez l'utiliser dans un produit sans parler à personne. Même fiche, quatre histoires différentes.

9. La méthode : cinq questions avant de télécharger

Quand le prochain modèle sortira, avant de cliquer sur télécharger, demandez-vous :

1. Quelle famille ? Bonne réputation pour mon usage ?
2. Taille totale vs active ? Combien de Go me faut-il vraiment (environ 2 Go/B à pleine précision, 0,6-0,8 Go/B à 4 bits) ?
3. Contexte ? Suffisant pour mes documents et mes conversations ?
4. Quantification ? Laquelle tient dans mon matériel ? Version GGUF ?
5. Licence ? Puis-je l'utiliser comme je veux ?

Si vous répondez aux cinq, vous avez fait 80 % du travail. Les 20 % restants : télécharger et tester avec vos prompts réels — la fiche dit ce qu'un modèle sait faire, seul le test dit s'il le fait bien.

Article généré par IA