À quel point la traduction par IA réfléchit-elle vraiment ?

Gemini est une source inépuisable de bonnes surprises. C'est le meilleur LLM de traduction prêt à l'emploi pour la plupart des langues. Grâce à ses capacités de réflexion, vous pouvez venir à bout des défis les plus complexes, comme les expressions idiomatiques, les références d'anime ou votre ton de marque™ unique.

Le problème, c'est que la réflexion prend du temps. Et elle a un coût : chaque token est facturé. En tant que développeur, vous voulez garder la maîtrise de ces deux paramètres.

Avec Gemini 2.5, c'était simple. Gemini 3 a compliqué les choses.

Voici ce que nous avons appris dans les laboratoires de Transept

Ce qui a changé dans Gemini 3

Gemini 2.5 disposait du paramètre thinkingBudget : un plafond numérique limitant les tokens de raisonnement. Gemini 3 l'a abandonné au profit de thinkingLevel, un réglage catégoriel proposant quatre valeurs — minimal, low, medium et high. Ces deux paramètres sont mutuellement exclusifs ; avec les SDK actuels, envoyer les deux à un modèle Gemini 3 renvoie une erreur 400.

Cela change la donne pour le « contrôle des coûts » en pratique. Auparavant, il était possible de fixer une limite stricte à vos dépenses. Désormais, c'est au modèle de dépenser ce qui lui semble correspondre au niveau « medium ».

Nous supposons que cela s'explique par le fait que les modèles sont post-entraînés pour adapter leur longueur de réflexion à la complexité de la tâche, à l'instar des humains. Fixer des limites arbitraires briderait donc cette capacité.

Mais combien de tokens les niveaux low, medium et high consomment-ils réellement ?

Les données

Voici un échantillon de deux semaines de notre trafic de traduction réel, soit environ 1 000 appels répartis sur trois modèles Gemini 3. Les données sur les tokens de réflexion proviennent du champ usageMetadata.thoughtsTokenCount de chaque réponse, ce qui constitue la source la plus précise possible.

Tokens de réflexion par modèle

Ce 15 725 n'est pas une erreur de saisie. Un simple appel de traduction, sur un modèle Flash avec le réglage « medium », a consommé quinze mille jetons de raisonnement.

En général, de telles envolées de jetons surviennent lorsque Gemini laisse fuiter ses jetons de réflexion bruts dans la sortie. Comme vous le savez peut-être, la « réflexion » du modèle n'est pas vraiment le reflet de ses pensées, mais plutôt une synthèse peaufinée ; le raisonnement véritable d'un LLM s'apparente davantage à un flux de conscience.

Il est toutefois intéressant de noter que, dans ce cas précis, Gemini s'est paisiblement acharné sur la traduction anglais-ukrainien d'un passage littéraire contenant une phrase comme « l'acier pur rejette laques et peintures ». Il a testé par force brute une douzaine d'options en les énumérant jusqu'à ce que le résultat lui convienne.

Quelques semaines plus tard, nouveau constat : ce 15,725 n'était pas un excès de zèle isolé de la part de Gemini, mais un comportement systématique sur les tâches complexes.

Avec l'augmentation du trafic, surtout sur gemini-3.1-flash-lite, ce même nombre revient sans cesse. Une fourchette étrangement précise de 15,724 à 15,729 jetons, observée sur des dizaines d'appels, impliquant presque exclusivement des modèles Lite moulinant des audits de glossaires. Curieusement, ils tournent avec un effort de réflexion low, alors qu'on ne s'attendrait pas à ce que ce soit le réglage le plus coûteux.

Un modèle qui aboutit au même chiffre onze fois de suite a atteint un plafond ; ce n'est pas un choix de formulation. Le mode low sature autour de 15,7k jetons. Puisque les petits modèles comme lite sont moins efficaces dans leur réflexion, les tâches complexes les poussent à brûler énormément de jetons. Ce phénomène ne se produit jamais avec les modèles plus puissants, où chaque jeton a plus de chances de représenter une étape concrète vers la solution.

Cette saturation a d'ailleurs un coût. Sur Gemini 3, les jetons de réflexion sont décomptés du paramètre maxOutputTokens. Un appel qui consomme 15,7k jetons en réflexion n'en laisse quasiment aucun pour la réponse ; pourtant, toute cette réflexion est facturée au tarif des jetons de sortie. Avec une limite de 16k, l'audit renvoyait un résultat vide (finishReason=MAX_TOKENS) environ une fois sur deux, même sur de petits documents, ce qui nous a conduits à mener l'enquête.

Augmenter le budget traite le symptôme, pas la cause. Nous avons passé l'enveloppe de l'audit à 32k en mode low, ce qui laisse environ 16k pour la sortie après une réflexion saturée : les réponses vides ont alors cessé. Pour autant, le volume de réflexion n'a pas diminué. On ne peut pas le plafonner sur Gemini 3, il continue donc de brûler ~15,7k jetons ; l'extension du budget offre simplement un espace suffisant à la réponse pour s'afficher.

La seule véritable solution pour contrer cette saturation de la réflexion à 16k était de réduire le périmètre de la tâche.

Le mode minimal est le seul palier qui agit comme une véritable bride, avec un plafond d'environ 2k jetons. Il n'est toutefois disponible que pour les modèles Lite.

Jetons de réflexion par type de tâche (Flash vs Pro, tous deux en mode medium)

Pour une traduction simple, Pro réfléchit presque deux fois moins que Flash. Il ne surpasse Flash en réflexion que sur les tâches de réécriture. L'effort de raisonnement suit la difficulté de la tâche, et non la gamme commerciale du modèle.

On peut avancer que Pro obtient de meilleurs résultats dans les benchmarks de traduction précisément grâce à sa capacité à approfondir sa réflexion quand cela est nécessaire.

Conseils pratiques

• Ne définissez pas de thinkingBudget sur un modèle Gemini 3. Ce paramètre sera soit ignoré, soit il déclenchera une erreur.
• Le paramètre medium est flexible sur sa limite supérieure. Un calcul réaliste table sur environ 4 000 jetons de réflexion (p90) par appel, au lieu de 2 000.
• Si vous avez besoin d'une limite de coût stricte, utilisez minimal dans la mesure du possible. Interrompre la génération n'a aucun sens : vous serez facturé dans tous les cas.
• Consultez usageMetadata.thoughtsTokenCount pour chaque réponse si vous facturez à l'appel. Ce chiffre ne figure pas dans le corps de la réponse, mais il apparaît sur la facture.
• Avec le réglage medium, Pro a tendance à réfléchir moins que sa médiane sur les tâches simples, et davantage sur les tâches complexes. Lite et Flash ne connaissent pas cette variabilité.

Cela fait de Pro le meilleur modèle pour la relecture et l'affinage au-delà des performances de base des LLM, car c'est là que sa créativité s'exprime. La traduction brute, en revanche, est mieux gérée par Flash.

Cela demande toutefois du temps et de l'argent. Chez Transept, nous avons trouvé comment limiter les coûts de Pro en utilisant une logique de relecture intelligente pour ne solliciter Pro que sur les segments les plus ardus. Nous utilisons également Pro pour la planification et la prise de décision, en déléguant l'exécution à des modèles plus légers et à des versions affinées.

C'est ainsi que tout fonctionne.