Seedance 2.5 is live — 30-second cinematic video with native audio & real-person references
Tokens de sortie des LLM : limites API et contexte
2026/09/08

Tokens de sortie des LLM : limites API et contexte

Comparez les limites de sortie des LLM, budgets de raisonnement et paramètres API. Distinguez contexte, plafonds, valeurs par défaut et traitement par lots.

Une fenêtre de contexte d'un million de tokens renseigne peu sur la longueur de la réponse qu'un LLM peut produire. GPT-5.6 Luna annonce une fenêtre de 1 050 000 tokens, mais une sortie maximale de 128 000 tokens. L'API native de MiniMax M3 publie un plafond de génération de 524 288 tokens. Ce sont des contraintes différentes, avant même que le raisonnement consomme une partie du budget de réponse.[1][2]

La comparaison utile porte sur la tâche qui peut tenir dans ces limites : l'entrée, le travail généré et l'interface qui le livre. Ce guide compare le nombre maximal de tokens de sortie des LLM pour les longs rapports, l'extraction structurée et la génération de code. Il distingue les spécifications des API natives des fournisseurs de l'interface publiée par reAPI, ainsi que les requêtes synchrones du traitement par lots. Les spécifications ont été vérifiées le 8 septembre 2026 ; un plafond documenté ne promet pas que le modèle produira autant de tokens utiles.

L'essentiel

  • Le plafond de sortie est distinct de la fenêtre de contexte. Luna autorise 128 000 tokens de sortie dans sa fenêtre de 1 050 000 tokens. Une capacité d'entrée supplémentaire n'augmente pas la sortie maximale.[1]
  • Une recommandation ne définit pas une valeur par défaut. MiniMax recommande 131 072 tokens pour M3 et en autorise jusqu'à 524 288. Sa page API actuelle ne présente pas 131 072 comme la valeur utilisée lorsque le champ est omis.[2]
  • La plus grande valeur acceptée peut ne pas tenir avec votre entrée. Kimi K3 autorise max_completion_tokens jusqu'à 1 048 576, mais rejette une requête si l'entrée plus ce plafond dépassent sa fenêtre de contexte.[3]
  • La fenêtre de DeepSeek est partagée. V4 Flash et Pro annoncent 1M de contexte et une sortie maximale de 384K. L'API limite l'ensemble des tokens d'entrée et des tokens générés.[4][5]

Tokens de sortie maximaux par modèle et par API

Le tableau décrit les API des fournisseurs eux-mêmes. « Non précisé » signifie que la spécification consultée ne donne pas de valeur numérique par défaut. Cela ne signifie pas une sortie illimitée.

Modèle et APIFenêtre de contexteBudget maximal de générationValeur par défaut ou recommandationParamètre de sortie
Kimi K3, Chat Completions natif1M, selon la notation du fournisseurLe paramètre peut atteindre 1 048 576 ; l'entrée plus le plafond doivent tenir dans la fenêtreValeur par défaut : 131 072max_completion_tokens
DeepSeek V4 Flash / Pro, Chat Completions natif1M384K ; également limité par le contexte disponibleValeur numérique par défaut non précisée sur les pages actuellesmax_tokens
MiniMax M3, API native compatible OpenAI1M524 288Recommandation : 131 072 ; valeur numérique par défaut non préciséemax_completion_tokens
GPT-5.6 Luna / GPT-6 Astra, API native1 050 000128 000Valeur numérique de sortie par défaut non précisée sur les pages des modèlesChat Completions : max_completion_tokens ; Responses : max_output_tokens
Claude Opus 5 / Opus 4.8, Messages synchrone1M128KDéfinir un budget de requête ; les valeurs des exemples ne sont pas des valeurs par défautmax_tokens
Claude Opus 5 / Opus 4.8, Message Batches avec extension bêta de sortie1M300 000Nécessite la fonction de traitement par lots concernée et l'en-tête bêtamax_tokens

Sources : pages de paramètres et de modèles de Kimi ; tarifs et référence API de DeepSeek ; référence API de MiniMax ; pages des modèles Luna et Astra d'OpenAI ; documentation d'Anthropic sur le contexte et le traitement par lots.[3][6][4][5][2][1][7][8][9]

Conservez les unités de la source. DeepSeek publie 384K sans entier exact sur ces pages. MiniMax associe explicitement 512K à 524 288. Convertir le « K » de chaque fournisseur avec le même multiplicateur ajouterait une précision que les sources ne permettent pas.

La ligne consacrée aux lots Claude décrit une capacité distincte. Elle nécessite output-300k-2026-03-24 sur l'API Message Batches, et non sur l'API Messages synchrone. Anthropic indique actuellement une prise en charge sur la Claude API et Claude Platform on AWS, à l'exclusion des autres plateformes d'hébergement. La prise en charge des lots par un modèle natif ne prouve pas qu'une autre passerelle expose cette fonction.[9]

Réserver de la place au travail que le lecteur ne verra pas

La référence Chat Completions d'OpenAI définit max_completion_tokens comme un plafond couvrant la sortie visible et les tokens de raisonnement. Le guide Responses inclut aussi les tokens de mise en forme non visibles dans son budget de génération. Claude comptabilise également la réflexion dans max_tokens.[10][11][8]

Un calcul de planification peut donc ressembler à ceci :

Budget de la requête :             30 000 tokens générés
Part prévue pour le raisonnement : 10 000 tokens
Place restante pour la sortie :    20 000 tokens visibles

Il s'agit de répartitions illustratives, pas de mesures ni d'une promesse sur la longueur du raisonnement d'un modèle. Si une réponse consomme plus de raisonnement que prévu, il reste moins de cette même enveloppe pour la réponse visible. Augmenter l'effort peut modifier le travail réalisé sans relever le plafond envoyé.

Pour une tâche à sortie longue, notez deux besoins : l'entrée qui doit rester disponible et le budget de génération nécessaire. Comptez les instructions système, les messages conservés, les définitions d'outils et leurs résultats lorsque le point d'accès les inclut. Vérifiez ensuite le plafond de sortie et la contrainte de contexte. Une requête peut respecter l'un et échouer sur l'autre.[8]

Cette distinction compte pour le choix du modèle. Un budget de génération nécessaire de 150 000 tokens dépasse le maximum de 128 000 de Luna et d'Astra, quel que soit le contexte inutilisé. L'extension par lots de Claude peut accueillir un budget de cette taille dans les conditions documentées. Cela ne dit toujours rien sur la complétude, l'exactitude ou la rentabilité du document obtenu.[1][7][9]

Le raisonnement toujours actif de Kimi est une raison supplémentaire de ne pas présenter sa plus grande valeur de paramètre comme une réponse finale d'un million de tokens. Son API vérifie l'entrée plus le plafond avant la génération. La page de MiniMax décrit une limite de longueur de génération, sans promettre que toute l'enveloppe deviendra du texte utile. Définissez un plafond explicite et examinez ce que contient réellement la réponse.[3][12][2]

Adapter le paramètre au point d'accès

La compatibilité OpenAI ne rend pas tous les paramètres interchangeables. OpenAI utilise max_completion_tokens pour Chat Completions et max_output_tokens pour Responses. L'API Chat Completions native de DeepSeek utilise max_tokens. La référence native actuelle de MiniMax, compatible OpenAI, déclare max_tokens obsolète au profit de max_completion_tokens.[10][11][5][2]

Les réglages du raisonnement diffèrent aussi. Kimi K3 accepte low, high et max, avec max par défaut. DeepSeek accepte ces trois valeurs et utilise high par défaut ; ses alias de compatibilité medium et xhigh correspondent à high. Luna accepte none et plusieurs niveaux de raisonnement, avec medium par défaut. Astra ne prend pas en charge none ; sa page actuelle ne précise pas l'effort par défaut.[12][13][1][7]

Claude règle l'effort par output_config.effort. Pour Opus 5 et 4.8, le niveau supérieur s'écrit xhigh, et non extra. La valeur par défaut documentée est high. Opus 5 active la réflexion adaptative par défaut et n'autorise sa désactivation qu'au niveau high ou en dessous. Sur Opus 4.8, la réflexion reste désactivée tant qu'elle n'a pas été activée.[14][15]

Pour reAPI, partez du catalogue actuel des modèles et de la documentation liée au modèle choisi. La page du modèle Luna indique les limites de contexte et de sortie, tandis que la référence API de Kimi identifie le champ de requête. Traitez comme des faits distincts la valeur par défaut du fournisseur natif, la valeur explicite d'un exemple et le comportement réel d'une passerelle. Définir le plafond souhaité élimine une ambiguïté évitable.

Lire l'erreur avant de changer de modèle

Les API ne traitent pas toutes une fenêtre pleine de la même manière :

InterfaceSignal documentéPoints à vérifier
Kimi, Chat Completions natifinvalid_request_error si l'entrée plus le plafond demandé dépassent le contexteRéduire l'entrée ou le plafond demandé avant de réessayer
DeepSeek, Chat Completions natiffinish_reason: length peut signaler le plafond de sortie ou la limite de contexteComparer le plafond demandé, la consommation et l'entrée conservée
OpenAI Responsesstatus: incomplete, avec incomplete_details.reason: max_output_tokensVérifier la consommation de raisonnement en plus de la sortie visible
Claude Messages, Claude 4.5 et versions ultérieuresUne entrée qui dépasse à elle seule le contexte est rejetée ; une génération qui atteint la limite peut s'arrêter avec model_context_window_exceededDistinguer un prompt trop volumineux d'un épuisement de la fenêtre pendant la génération

Ce sont des règles propres à chaque point d'accès, pas des noms de champs interchangeables.[3][5][11][8]

Une application agentique peut aussi s'arrêter avant que le modèle atteigne sa limite. Conservez la réponse brute du fournisseur avec l'erreur de l'application et les budgets configurés. Une mention comme « limite de tokens de sortie atteinte » ne suffit pas à déterminer si la borne vient du fournisseur, du SDK ou de l'agent. Pour DeepSeek, le guide existant sur le contexte 1M détaille le calcul de la fenêtre partagée.

Questions fréquentes

Puis-je envoyer 1M de tokens d'entrée et recevoir quand même la sortie maximale ?

Ne le supposez pas. DeepSeek limite ensemble l'entrée et la sortie générée. Kimi vérifie l'entrée plus le plafond demandé. La fenêtre de Claude inclut aussi la sortie générée et la réflexion. Lisez la règle du point d'accès choisi avant de remplir le prompt jusqu'à la capacité annoncée.[5][3][8]

Le modèle au plus grand plafond de sortie est-il le meilleur pour un long rapport ?

Ce plafond indique si le budget demandé est possible avec cette interface. Il ne mesure ni l'exactitude factuelle, ni le respect des instructions, ni la quantité de texte utile requise par la tâche. Après avoir vérifié la limite, évaluez un rapport représentatif selon ses critères de complétude.

La réception en flux augmente-t-elle le plafond de tokens ?

Les limites de cette comparaison sont des limites de génération. La réception en flux modifie la manière de recevoir la réponse ; ce n'est pas l'extension réservée aux lots qui porte le plafond de Claude à 300 000. Sélectionnez explicitement cette fonction lorsque la tâche s'y prête.[9]

Faut-il reprendre 4096 ou 8192 d'un exemple comme valeur par défaut du modèle ?

Un exemple montre une requête que l'auteur a choisi d'envoyer. N'utilisez une valeur comme valeur par défaut que si la spécification du point d'accès la désigne explicitement ainsi. Les 131 072 de MiniMax sont une recommandation ; Moonshot documente explicitement les 131 072 de Kimi comme valeur native par défaut.[2][3]

Une réponse peut-elle épuiser ses tokens de sortie sans produire de réponse visible ?

Oui, avec le comportement d'OpenAI Responses documenté ici : le raisonnement peut consommer le budget avant l'apparition d'une sortie visible. Examinez le statut incomplet et la consommation de tokens au lieu de conclure, à partir d'une réponse vide, qu'aucun travail n'a été effectué.[11]

Quelles données conserver pour une vérification en production ?

Conservez l'identifiant du modèle, le point d'accès, le plafond de sortie demandé, le réglage d'effort, la consommation d'entrée et de sortie déclarée, la raison de fin ou d'arrêt, et le résultat des contrôles de complétude de la tâche. Enregistrez ces données ensemble. Elles permettent de comparer le nombre maximal de tokens de sortie des LLM au budget réellement utilisé par votre application.

Choisir un budget avant de choisir un modèle

Comparez les sorties maximales des LLM à partir d'une tâche représentative : l'entrée à conserver, le budget de génération nécessaire et la possibilité d'utiliser une interface par lots. Définissez explicitement le plafond, menez une petite évaluation et vérifiez la qualité d'achèvement avec la consommation de tokens. Si la tâche exige plusieurs appels, découpez-la à une frontière pertinente du document ou du code, puis conservez l'état nécessaire à la requête suivante. Une fenêtre annoncée plus grande ne résout pas, à elle seule, une limite de sortie.

Références

  1. OpenAI. Modèle GPT-5.6 Luna. Consulté le 8 septembre 2026 sur developers.openai.com/api/docs/models/gpt-5.6-luna.
  2. MiniMax. API Chat Completions. Consulté le 8 septembre 2026 sur platform.minimax.io/docs/api-reference/text-chat-openai.
  3. Moonshot AI. API Chat Completions. Consulté le 8 septembre 2026 sur platform.kimi.ai/docs/api/chat.
  4. DeepSeek. Modèles et tarifs. Consulté le 8 septembre 2026 sur api-docs.deepseek.com/zh-cn/quick_start/pricing.
  5. DeepSeek. API Chat Completions. Consulté le 8 septembre 2026 sur api-docs.deepseek.com/zh-cn/api/create-chat-completion.
  6. Moonshot AI. Liste des modèles. Consulté le 8 septembre 2026 sur platform.kimi.ai/docs/models.
  7. OpenAI. Modèle GPT-6 Astra. Consulté le 8 septembre 2026 sur developers.openai.com/api/docs/models/gpt-6-astra.
  8. Anthropic. Fenêtres de contexte. Consulté le 8 septembre 2026 sur platform.claude.com/docs/en/build-with-claude/context-windows.
  9. Anthropic. Traitement par lots : extension bêta de sortie. Consulté le 8 septembre 2026 sur platform.claude.com/docs/en/build-with-claude/batch-processing.
  10. OpenAI. Créer une réponse Chat Completions. Consulté le 8 septembre 2026 sur developers.openai.com/api/reference/resources/chat/subresources/completions/methods/create.
  11. OpenAI. Modèles de raisonnement. Consulté le 8 septembre 2026 sur developers.openai.com/api/docs/guides/reasoning.
  12. Moonshot AI. Effort de raisonnement. Consulté le 8 septembre 2026 sur platform.kimi.ai/docs/guide/use-reasoning-effort.
  13. DeepSeek. Mode de raisonnement. Consulté le 8 septembre 2026 sur api-docs.deepseek.com/zh-cn/guides/thinking_mode.
  14. Anthropic. Effort. Consulté le 8 septembre 2026 sur platform.claude.com/docs/en/build-with-claude/effort.
  15. Anthropic. Réflexion. Consulté le 8 septembre 2026 sur platform.claude.com/docs/en/build-with-claude/thinking.