Développement IA

Pourquoi les modèles d'IA deviennent-ils toujours plus grands ? Paramètres, tokens, context window et JSON

Environ 16 min

Des centaines de milliards de paramètres et des fenêtres d'un million de tokens se vendent comme le progrès lui-même. Pour qui écrit du JSON, plus grand veut souvent dire le même objet commande coûte plus, se coupe plus tôt, et sort plus difficilement comme structure légale. Cet article sépare trois mots mélangés—paramètres, tokens, context window—et atterrit sur le JSON en 2026.

Aperçu rapide

Idée En une ligne Angle JSON
Paramètres Poids apprenables — mesure approximative de capacité Influe sur la stabilité du JSON légal
Token Unité de mesure et de facturation du texte Accolades, guillemets et clés répétées se paient
Context Window Plafond de tokens d'une seule requête Le gros JSON et les résultats d'outils multi-étapes le heurtent d'abord

Plus grand ≠ meilleur en JSON. Les paramètres sont la capacité, les tokens la facture, la context window le seau. Quand le seau grandit, le premier geste n'est pas d'y verser toute une réponse API.

Pourquoi les grands modèles deviennent-ils encore plus grands ?

La règle empirique est simple : si les données et le calcul suivent, plus de paramètres et un entraînement plus long améliorent en général la courbe de perte. Les fournisseurs font donc de « plus grand » le récit par défaut — plus facile à vendre sur un classement, en démo et sur une liste d'achat.

De 2024 à 2026, « grand » s'est fendu en trois axes. Ce n'est plus seulement un nombre de paramètres :

  • Échelle de paramètres : les modèles denses grandissent encore ; le MoE garde un total élevé mais n'active qu'une tranche par token.
  • Context window : 8K et 32K sont devenus 128K, puis un million. Agents et longs documents sont le prétexte habituel.
  • Contraintes de sortie : Structured Outputs / JSON Schema forcent « plus grand » à signifier « objet plus stable », pas un plus long paragraphe.

Si vous écrivez du JSON, les questions utiles ne sont pas « combien de B ? ». Elles sont : stabilité sur le Schema, prix au millier de tokens, et si le résultat d'outil tient encore dans la fenêtre.

Que sont les paramètres ?

Les paramètres sont les poids restés dans le modèle après l'entraînement. À l'inférence ils ne se mettent plus à jour ; ils calculent. 7B, 70B, 405B (milliards) décrivent la capacité — pas le nombre de caractères lus par cette requête.

Plus de paramètres veulent en général dire trois choses :

  • Meilleur ajustement aux contraintes complexes. Objets imbriqués, enum et required cassent moins souvent.
  • Inférence plus chère et plus lente. Le même JSON coûte plus de latence et d'argent par token sur un plus grand modèle.
  • Ce n'est pas une plus grande context window. Un petit modèle peut tenir sur 128K ; un énorme peut rester à 32K.

Les pages produit 2026 aiment afficher côte à côte le total MoE et les paramètres actifs. Demandez lequel facture et lequel fixe la latence. Comme l'écrit le guide GPT-6 Astra : pour le JSON, des Structured Outputs stables battent souvent une classe de taille plus dense.

Qu'est-ce qu'un token ?

Un token est un morceau coupé par le tokenizer — ni un caractère ni un mot. L'anglais tombe souvent vers 1 token ≈ 4 caractères. Le chinois, le code et la ponctuation JSON se fragmentent plus : la même longueur visuelle coûte plus.

Les API facturent et tronquent au token. Prompt système, définitions d'outils, historique, JSON renvoyé par l'outil et JSON émis par le modèle partagent le même grand livre.

Le JSON est cher par nature. Accolades, guillemets, virgules, espaces d'indentation et clés répétées peuvent chacun prendre un token. Cette « commande complète » se lit bien et se gaspille à l'envoi :

{
  "order": {
    "order_id": "A-1042",
    "customer": {
      "full_name": "Ada Lovelace",
      "email": "ada@example.com",
      "locale": "en-GB"
    },
    "line_items": [
      {"sku": "KB-1", "title": "Keyboard", "qty": 1, "price": 99.00}
    ],
    "shipping": {"city": "London", "method": "express"},
    "debug": {"trace_id": "tr_9f", "retries": 0}
  }
}

Pour le saut d'agent suivant, le même métier n'a souvent besoin que de :

{
  "order_id": "A-1042",
  "amount": 99.00,
  "status": "paid"
}

Formatez localement avec formatage pour voir la forme, extraire order_id / amount / status avec extraction JSONPath, puis minify avant le modèle. Pretty-print pour déboguer, mince pour inférer. Ce n'est pas le même payload.

Qu'est-ce qu'une context window ?

La context window est le plafond de tokens d'une seule requête. Certains fournisseurs comptent entrée et sortie dans une fenêtre ; d'autres réservent une tranche pour la sortie. Tant que la doc n'est pas claire : « entrée + sortie réservée ≤ fenêtre ».

Passer de 8K à 128K puis à un million ne rend pas le JSON automatiquement plus simple. Cela rend seulement « coller toute la réponse » apparemment faisable. Faisable n'est ni bon marché ni stable.

Dans une boucle d'agent, la fenêtre se mange en général ainsi :

{
  "context_window": 128000,
  "spent": {
    "system": 1200,
    "tools": 3400,
    "history": 18000,
    "tool_result_json": 42000
  },
  "reserved_output": 4000,
  "remaining": 59400
}

Le tableau est illustratif, pas une facture. L'idée : le JSON de résultat d'outil est souvent plus gras que le prompt. Un le guide Agent IA multi-étapes sans projection ni résumé tronquera un demi-objet au troisième saut — le suivant le traitera comme une commande complète.

Comment s'empilent paramètres, tokens et fenêtre ?

Les trois mots s'aplatissent en « le modèle est plus grand ». Leurs métiers diffèrent :

  1. Les paramètres fixent le plafond de qualité : suit-il le Schema, ou improvise-t-il au-delà de additionalProperties ?
  2. Les tokens fixent la facture et la latence de chaque saut. Un JSON gras dans la même fenêtre chasse l'historique et la marge de sortie.
  3. La context window fixe ce qu'un appel peut voir. Un plus grand seau ne répare ni « trop peu de paramètres pour la contrainte » ni « tokens trop chers pour réessayer ».

L'incident 2026 par défaut : vous avez acheté une grande fenêtre, versé 2 Mo de JSON pretty-print, puis reproché au modèle d'« oublier » les champs d'avant. Il n'a pas oublié. Vous avez d'abord rempli la fenêtre.

Que cela signifie-t-il pour le traitement JSON ?

Sur un pipeline quotidien, les trois couches deviennent très concrètes :

  • Pretty-print pour les humains, compact pour le modèle. L'indentation se rentabilise dans l'éditeur et n'est que du gaspillage sur la facture de tokens.
  • Projeter plutôt que coller. Si un outil renvoie 80 champs, ne gardez que les clés required du saut suivant.
  • Le Schema est une assurance retry. Structured Outputs échange de la validation contre moins de JSON illégal — moins de tokens de sortie.
  • Les arguments stringifiés paient la forme deux fois. Les guillemets échappés sont illisibles et dépensent le budget ; l'hôte doit encore parser.
  • Le long contexte n'est pas une base. Interrogez avec un outil ; comparez avec un Diff local. N'enfoncez pas deux fichiers de 5000 lignes dans un message.

Pourquoi les agents IA ont désormais besoin de JSON Schema a fait du Schema une barrière d'exécution ; l'intro syntaxique est le tutoriel JSON Schema. En cas de dérive, JSON Diff l'objet de la semaine dernière contre le refus d'aujourd'hui avant d'acheter un plus grand modèle.

Couper les coûts en 2026 (le JSON d'abord, le modèle ensuite)

  1. Une liste blanche de champs par étape d'agent, pas JSON.stringify(fullResponse).
  2. Amaigrir aussi les définitions d'outils : contraintes dans description, supprimer la prose qui ne change aucun appel.
  3. Activer strict: true / json_schema et dépenser de la validation plutôt que des retries.
  4. Garder l'historique comme objet d'état, pas le transcript d'outil. Les checkpoints sont du petit JSON, pas le journal de chat.
  5. Inspecter et couper secrets et champs utilisateur en local. Ne les uploadez pas sur un site JSON public, et ne les envoyez pas au modèle sans raison.

L'ordre : projeter → compacter → Schema → puis envisager un modèle plus petit ou plus grand. L'inverse gaspille la fenêtre et les paramètres.

Pièges fréquents

  • Prendre le nombre de paramètres pour la context window. 70B et 128K sont deux lignes d'achat, même sur la même slide.
  • Estimer les tokens au nombre de caractères. La ponctuation JSON et le chinois plafonnent un objet qui « n'a pas l'air long ».
  • Arrêter de projeter parce que la fenêtre a grandi. Un million de tokens se facture encore. Le JSON gras n'allonge que la facture.
  • Acheter un plus grand modèle pour réparer du JSON illégal. Vérifiez d'abord le Schema et le validateur hôte. Beaucoup de « le modèle a empiré » sont un required en trop.
  • Expédier le pretty JSON comme payload live. Les espaces de l'éditeur n'ont rien à faire dans la requête d'inférence.

FAQ

Plus de paramètres rendent-ils le JSON plus légal ?

Cela aide, cela ne garantit rien. Sans Schema ni contrôle hôte, un grand modèle omet encore des champs et écrit des nombres en chaînes. La capacité baisse le taux d'accidents ; la barrière décide si l'accident atteint le saut suivant.

Puis-je convertir tokens et caractères à 4:1 ?

En règle empirique pour la prose anglaise, oui. Pas pour le JSON, le code ou le chinois. Utilisez le tokenizer du fournisseur ou l'API officielle de comptage. Ne facturez pas depuis le compteur de l'éditeur.

La context window inclut-elle la sortie du modèle ?

La plupart des API Chat / Responses comptent la sortie dans le même budget ou fixent un max output. Pire cas : entrée + sortie réservée ≤ fenêtre, pour ne pas couper la dernière accolade.

J'ai déjà une fenêtre 1M — faut-il encore couper le JSON ?

Oui. La fenêtre répond à « est-ce que ça rentre », pas à « pouvez-vous le payer » ni « le saut suivant reste-t-il stable ». Projection et minify restent le défaut.

Comment vérifier en local si un JSON va faire sauter le contexte ?

Formatez pour voir la forme, projetez les champs, puis comptez la chaîne que vous enverrez vraiment. JSONSort formate, extrait et diff dans le navigateur, sans upload.

Conclusion

Les modèles grandissent parce que plus de paramètres, de plus longues fenêtres et plus de données se vendent encore sur les evals. Si vous traitez du JSON, les paramètres sont la capacité, les tokens la facture, la context window le seau. Verser du pretty JSON dans un plus grand seau n'est qu'une autre façon de trop dépenser.

Commencez aujourd'hui par « quelles clés peuvent entrer dans ce saut », puis décidez si vous avez besoin d'un plus grand modèle. Les modèles continueront de grandir. Le diamètre devrait d'abord rétrécir.

Pour aller plus loin

Journal : première publication