gemini-3.1-flash-lite-image prend-il en charge le mode de raisonnement ? 3 séries de données de tests réels pour expliquer clairement l’utilisation de thinkingLevel

“gemini-3.1-flash-lite-image supporte-t-il vraiment le mode de raisonnement ?” C’est l’une des questions qui revient le plus souvent dans les groupes autour des appels API. La réponse est oui, et ce n’est pas une supposition — nous avons croisé la documentation officielle de Google avec trois séries d’expériences comparatives via la passerelle APIYI, puis récupéré des données réelles de consommation de tokens et de latence. Cet article va expliquer clairement l’interrupteur thinkingLevel sous trois angles : structure des paramètres, mesures réelles et règles de facturation.

Valeur clé : à la fin de cet article, vous saurez précisément comment activer le mode de raisonnement de gemini-3.1-flash-lite-image, combien de tokens il coûte en plus, et dans quels cas ça vaut la peine d’accepter cette latence supplémentaire.

Conclusion clé sur le mode de raisonnement de gemini-3.1-flash-lite-image

Commençons par la conclusion, puis entrons dans les détails. La documentation officielle de Google indique clairement qu’avec gemini-3.1-flash-image et gemini-3.1-flash-lite-image, les développeurs peuvent contrôler la quantité de réflexion utilisée par le modèle. Cela signifie que le niveau flash-lite intègre lui aussi une capacité de raisonnement, et que ce n’est pas réservé aux modèles phares. En revanche, tous les modèles image ne prennent pas ce paramètre en charge. Le tableau ci-dessous compare la prise en charge sur trois modèles Gemini image courants.

Il faut préciser un point important : thinkingLevel n’a que deux niveaux, ce n’est pas un budget de réflexion continu comme pour certains modèles de texte. Le texte officiel indique que « minimal thinking » ne veut pas dire que le modèle ne réfléchit pas du tout. Autrement dit, même avec le réglage par défaut, le modèle effectue déjà une certaine quantité de raisonnement de base ; simplement, il ne fait pas de vérifications multi-étapes de composition comme avec le niveau high.

C’est aussi un signal intéressant pour le secteur. Dans les générations précédentes de modèles de génération d’images, que ce soit nano banana ou la première version de flash-image, les interfaces officielles n’exposaient pas ce type de paramètre de niveau de réflexion. Le modèle générait soit selon une stratégie fixe, soit en s’appuyant entièrement sur le prompt engineering pour compenser les défauts de composition. Avec la génération 3.1, Google a ouvert le mécanisme « planifier d’abord, générer ensuite » à la famille flash. En pratique, cela revient à transférer vers la génération d’images un paradigme de réflexion jusque-là validé surtout sur les modèles de texte. Comprendre ce contexte aide à anticiper si d’autres éditeurs de modèles image suivront la même voie.

🎯 Conseil technique : si vous appelez les modèles Gemini image via APIYI apiyi.com, commencez par le niveau minimal par défaut pour valider le flux métier, puis passez à high seulement si la qualité de sortie le justifie. La plateforme fournit une interface unifiée, et gemini-3.1-flash-image, flash-lite-image et pro-image peuvent être appelés avec le même code, ce qui facilite les comparaisons A/B.

Détails du paramètre thinkingLevel et mode d’appel

thinkingLevel n’est pas un paramètre autonome : il se trouve dans l’objet thinkingConfig, lui-même imbriqué sous generationConfig, et il s’utilise avec includeThoughts. includeThoughts détermine si le résumé de réflexion du modèle est renvoyé à l’appelant, tandis que thinkingLevel règle l’« intensité » de cette réflexion. Ce sont deux interrupteurs distincts et découplés, donc il ne faut pas les confondre.

Le tableau ci-dessous résume le type et la plage de valeurs des deux champs clés de thinkingConfig.

En pratique, la structure d’appel est la même dans les trois langages principaux : on ajoute simplement un objet thinkingConfig dans config. Prenons Python comme exemple :

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Appel via la passerelle unifiée APIYI
)

response = client.chat.completions.create(
    model="gemini-3.1-flash-lite-image",
    messages=[{"role": "user", "content": "Dessine un chat qui boit un café au pied d'une montagne enneigée"}],
    extra_body={
        "thinkingConfig": {
            "thinkingLevel": "high",
            "includeThoughts": True
        }
    }
)
print(response.choices[0].message.content)

{
  "contents": [{"parts": [{"text": "Dessine un chat qui boit un café au pied d'une montagne enneigée"}]}],
  "generationConfig": {
    "responseModalities": ["IMAGE"],
    "thinkingConfig": {
      "thinkingLevel": "high",
      "includeThoughts": true
    }
  }
}

Conseil : passez par APIYI apiyi.com pour obtenir un quota de test gratuit et vérifier directement côté passerelle si thinkingConfig est bien transmis, c’est plus simple que de demander une clé officielle juste pour déboguer.

Données de test APIYI : impact réel de thinkingLevel sur les tokens et la latence

Même une documentation très claire reste abstraite tant qu’on n’a pas une série de mesures réelles. Avec la même invite, nous avons testé via la passerelle APIYI une génération d’images en 1K, en comparant gemini-3.1-flash-image en mode minimal, en mode high, ainsi que gemini-3-pro-image avec un paramètre high forcé.

Ces résultats montrent trois choses importantes. Premièrement, quand on passe thinkingLevel sur high, thoughtsTokenCount grimpe directement de 0 dans le mode par défaut — au point que le champ n’apparaît même pas dans la réponse — à une plage de 700 à 800 tokens. La consommation totale augmente alors d’environ 50 %, et la latence passe de 12-13 secondes à 18-23 secondes : la réflexion coûte donc vraiment du temps et des ressources. Deuxièmement, que l’on soit en minimal ou en high, le nombre de tokens liés à l’image produite reste toujours à 1120, ce qui montre que thinkingLevel ne modifie que la façon dont le modèle « pense », pas la résolution de l’image ni sa facturation propre. Troisièmement, envoyer high à gemini-3-pro-image ne provoque pas d’erreur, mais les 181-214 tokens de réflexion restent pratiquement identiques au comportement par défaut, ce qui confirme l’indication de la documentation officielle : le comportement de réflexion de pro-image est fixe et ne se règle pas de l’extérieur.

Autrement dit, si votre logique métier applique un thinkingConfig uniforme et le transmet en bloc aux modèles flash, flash-lite et pro, pro-image va simplement ignorer ce paramètre sans erreur ni interruption, mais il n’ajustera pas réellement l’intensité de réflexion comme vous pourriez l’attendre.

Dernier point à préciser : les chiffres ci-dessus ne viennent pas d’une seule requête, mais d’une série de requêtes répétées avec la même invite pour chaque réglage, puis ramenées sous forme de plage. C’est pour ça que high affiche un intervalle comme 700-792 pour thoughtsTokenCount, et pas une valeur fixe. Les tâches de réflexion gardent une part de variabilité : à chaque génération, le chemin de raisonnement intermédiaire peut légèrement changer, ce qui entraîne de petites fluctuations de consommation de tokens. En revanche, l’ordre de grandeur et la tendance de latence restent stables et reproductibles : on ne verra pas un high plus rapide qu’un minimal, ni une explosion anormale de plusieurs milliers de tokens de réflexion.

Jetons de réflexion et règles de facturation pour les modèles d’images

Quand ils voient pour la première fois le champ thoughtsTokenCount, beaucoup de développeurs le comparent spontanément au coût de réflexion d’un modèle texte. En réalité, pour un modèle d’images, le mécanisme de réflexion est facturé en deux parties. Bien comprendre ce point est essentiel pour maîtriser les coûts.

La documentation officielle insiste sur un point : que includeThoughts soit true ou false, les jetons générés pendant la réflexion sont facturés normalement. Nos tests l’ont confirmé : une fois includeThoughts activé, la structure de retour et le total facturé ne changent pas ; on obtient juste un résumé de réflexion en plus, utile pour le debug. Autrement dit, includeThoughts est un interrupteur “voir ou ne pas voir”, pas un interrupteur “payer ou ne pas payer”. C’est un détail facile à mal interpréter.

Ce qui compte encore plus, c’est que le gros du coût de réflexion d’un modèle d’images ne se trouve pas dans le champ thoughtsTokenCount, mais dans les images temporaires de composition générées pendant l’inférence. D’après la documentation officielle, le modèle peut créer jusqu’à deux images temporaires pendant sa phase de réflexion pour tester la composition et la cohérence logique. Ces croquis sont renvoyés comme des part image ordinaires et comptés dans candidatesTokenCount, donc facturés au tarif standard des images de sortie. En pratique, une génération d’image en mode high peut donc ajouter discrètement une ou deux facturations de croquis “invisibles”, ce qu’on oublie facilement dans une estimation de coût.

Un calcul rapide rend les choses plus parlantes. Imaginons une requête de génération d’image en 1K de résolution avec le mode high : la réflexion textuelle consomme environ 750 tokens. Si le modèle génère effectivement deux croquis temporaires pendant l’inférence, puis l’image finale, on obtient théoriquement trois part image. À raison d’environ 1120 tokens et 0,0336 $ par image, le coût de sortie des trois images approche 0,1 $, auxquels s’ajoute le coût du texte de réflexion. Au total, on peut facilement arriver à une facture 2 à 3 fois supérieure à celle du mode minimal. En réalité, le déclenchement des deux croquis dépend de l’évaluation que fait le modèle de votre invite ; une requête en mode high ne produira pas systématiquement deux croquis. C’est pour ça que, dans les tests, le total de tokens observé tombe souvent dans une plage comme 2243 à 2375, plutôt que de doubler de façon exacte.

💰 Optimisation des coûts : si votre équipe est sensible au coût par token, commencez par vérifier le totalTokenCount réel dans les journaux d’appel de la plateforme APIYI apiyi.com, puis décidez si vous devez laisser le mode high activé en permanence. Vous éviterez ainsi de dépasser le budget à cause d’une sous-estimation de la facturation des croquis.

Dans quels cas activer high, et quand rester sur le mode minimal par défaut

En s’appuyant sur les tests, voici un guide de décision simple.

En résumé, le mode high est surtout adapté aux cas où “obtenir le bon rendu du premier coup” est plus important que “sortir vite l’image”. Si votre application doit souvent réessayer et ajuster l’invite pour obtenir une composition satisfaisante, autant activer directement high : vous payez un peu plus à chaque requête, mais vous augmentez le taux de réussite du premier coup. Au final, c’est souvent plus rentable.

En production, la méthode la plus prudente consiste à rendre thinkingLevel configurable plutôt que de le coder en dur. Par exemple, vous pouvez router automatiquement selon le type de tâche transmis par l’appelant : minimal par défaut pour les traitements en lot, high pour les requêtes qui exigent une mise en page précise ou plusieurs sujets avec des relations spatiales complexes. Vous gardez ainsi le coût moyen sous contrôle sans sacrifier la qualité dans les cas critiques. Si votre équipe maintient en parallèle la logique d’appel pour les modèles flash, flash-lite et pro, il est préférable de centraliser le traitement des paramètres dans une couche d’encapsulation, et de n’envoyer thinkingLevel qu’aux modèles qui le supportent. Cela évite de propager des paramètres inutiles vers pro-image et de compliquer le diagnostic.

🚀 Démarrage rapide : pour prototyper vite, la plateforme APIYI apiyi.com est une bonne option. Avec le même base_url, vous pouvez basculer entre les réglages minimal et high pour comparer les tests, sans avoir à configurer séparément les informations d’authentification pour chaque niveau.

FAQ

Conclusion

gemini-3.1-flash-lite-image prend bien en charge le mode de réflexion, et cela a été confirmé à la fois par la documentation officielle et par les mesures de l’équipe APIYI. thinkingLevel ne propose que deux niveaux, minimal et high. En mode high, les tokens de réflexion montent au-delà de 700 et le temps total augmente d’environ 5 à 10 secondes, mais cela ne change pas la consommation de tokens de l’image finale. En revanche, même si gemini-3-pro-image accepte ce paramètre sans erreur, il n’a en réalité aucun effet. Comprendre cette logique de double comptage — “le texte de réflexion passe par thoughtsTokenCount, l’esquisse de composition par candidatesTokenCount” — est un levier essentiel pour maîtriser le coût de génération d’images. Si vous devez tester rapidement plusieurs modèles d’images Gemini, le plus simple est de passer par la passerelle unifiée APIYI apiyi.com, afin d’éviter de gérer une clé API et du code d’appel séparés pour chaque modèle.

Les données de cet article proviennent des tests de l’équipe technique d’APIYI. Si vous souhaitez échanger sur les détails d’appel des modèles d’images Gemini, n’hésitez pas à contacter le support technique via APIYI apiyi.com.

Références

1. Documentation officielle de l’API Gemini – Génération d’images : description du paramètre de niveau de réflexion (thinking levels)
   • Lien : ai.google.dev/gemini-api/docs/generate-content/image-generation