Voies d'inférence en production de Gemini 3.6 Flash et Gemini 3.5 Flash comparées sur la vitesse et le coût

Comparison

Gemini 3.6 Flash vs Gemini 3.5 Flash : faut-il migrer vos charges de production ?

Jacey

Founder

21 juillet 2026

20 min de lecture

Dernière vérification : 2026-07-21. Rédigé par Jacey, avec 216 appels d'API que nous avons exécutés le jour du lancement ; la méthode est décrite intégralement là où ces résultats apparaissent. EvoLink exploite une passerelle d'API qui route vers des modèles tiers, y compris les deux modèles évoqués ici.

La version courte

Migrez maintenant si les tokens de sortie dominent votre facture. Les boucles d'agent, la génération de code longue et le travail à forte charge de raisonnement tombent dans une fourchette 26% à 29% moins chère.
Gain modeste si votre trafic est dominé par l'entrée. Un pipeline documentaire tournant à environ 20 tokens d'entrée par token de sortie économise 7.1%, parce que le prix d'entrée n'a pas changé du tout.
L'intelligence est stable. Une mesure indépendante place les deux modèles à 50.1 et 50.2 sur le même indice. Ce qui a bougé, c'est la vitesse : de 165 à 304 tokens de sortie par seconde, et de 2.7 à 1.3 minute par tâche.
Testez d'abord si votre charge de travail est à forte composante de connaissances ou génère des interfaces front-end. Ce sont les deux endroits où les preuves publiées pointent dans l'autre sens.
Le niveau de réflexion déplace votre facture plus que le modèle. Dans nos propres tests, passer du medium par défaut à minimal a réduit le coût d'une passe de 73.6% sans perte de précision sur notre jeu de tâches. Réglez-le délibérément quel que soit le modèle que vous exécutez.
Ce n'est pas un simple changement de chaîne de modèle. temperature, top_p et top_k sont désormais acceptés puis ignorés sans erreur, et thinking_budget n'existe plus.

La réponse courte, par charge de travail

La valeur de cette mise à niveau dépend presque entièrement de deux choses : le ratio entre tokens d'entrée et tokens de sortie dans votre trafic, et le fait que la latence soit actuellement un motif de plainte.

Votre charge de travail	Verdict	Pourquoi
Agents multi-tours, boucles d'appel d'outils, génération de code longue	Migrer	Les tokens de sortie et de réflexion dominent, et c'est la seule partie du prix qui a baissé
Tout cas où la latence par tâche est le problème	Migrer	Le temps par tâche à peu près divisé par deux dans une mesure indépendante
Questions-réponses à forte composante de connaissances	Tester en shadow d'abord	Le seul score de connaissances directement comparable entre générations a baissé
Génération de front-end et d'interfaces	Tester en shadow d'abord	Google documente ici deux régressions spécifiques, toutes deux corrigeables au niveau du prompt
Traitement de documents et RAG à environ 20:1	Rien ne presse	L'économie est de 7.1%, ce qui reste dans le bruit d'un mois normal

Si la question que vous vous posez réellement est de savoir s'il faut plutôt exécuter Gemini 3.5 Flash-Lite, c'est une décision différente avec une réponse différente, et nous la traitons dans Gemini 3.6 Flash contre 3.5 Flash-Lite. Flash-Lite est un palier de capacité inférieur, pas une version plus récente du modèle que vous exécutez, donc aucun des chiffres ci-dessous ne s'y transpose.

Ce qui a réellement changé

Gemini 3.6 Flash n'est pas une nouvelle génération de modèle. Sa fiche modèle indique qu'il est construit sur Gemini 3.5 Flash, ce qui en fait une mise à jour post-entraînement sur la même base. Ce seul fait explique l'essentiel de ce qui suit : les capacités ont bougé latéralement, tandis que ce que le post-entraînement et le service peuvent faire bouger — la vitesse et l'efficacité en tokens — a beaucoup bougé.

Voici les détails pratiques, tirés de la documentation des modèles de Google.

Identifiant du modèle : gemini-3.6-flash. Une seule version stable, sans suffixe preview ni horodatage, donc aucune décision d'alias à prendre.
Contexte : 1,048,576 tokens en entrée et 65,536 tokens en sortie, inchangé. Texte, image, vidéo, audio et PDF en entrée ; texte uniquement en sortie.
Niveau de réflexion par défaut : medium, sélectionnable parmi minimal, low, medium et high.
Prix : l'entrée est restée à $1.50 par million de tokens. La sortie est passée de $9.00 à $7.50, une baisse de 16.67%. Les lectures en cache sont à $0.15 par million. Voir la page de tarifs de Google pour les paliers batch et priority.

Ce sont les champs qui comptent pour la décision de cette page. Pour la matrice complète des capacités et une première requête fonctionnelle sur le nouvel identifiant de modèle, consultez notre guide Gemini 3.6 Flash.

Une correction à faire, car elle circule : le prix d'entrée n'a pas augmenté. gemini-3.5-flash et gemini-3.6-flash facturent tous deux $1.50 par million de tokens d'entrée. L'affirmation d'une hausse cachée vient d'une comparaison avec un prix d'une génération Flash antérieure.

Ce qui arrive à votre facture

Deux choses distinctes sont censées réduire votre coût : le prix de sortie est 16.67% plus bas, et le modèle utiliserait moins de tokens de sortie pour la même tâche. Cumulé, la dépense côté sortie chute de 30.8%.

Ce chiffre est réel, et c'est aussi la raison pour laquelle tant d'articles sur cette sortie surestiment l'économie. Le prix d'entrée n'a pas bougé. Donc plus votre trafic est dominé par l'entrée, moins vous voyez réellement de ces 30.8%.

Comparaison des coûts par charge de travail de Gemini 3.6 Flash montrant pourquoi les charges d'IA dominées par la sortie captent plus d'économies que les pipelines dominés par l'entrée

Les économies de Gemini 3.6 Flash se concentrent côté sortie, donc les ratios de tokens de la charge de travail déterminent l'impact sur le coût de production.

Ratio entrée:sortie	Charge de travail typique	Sur 3.5 Flash	Sur 3.6 Flash	Variation
20:1	Traitement de documents, RAG	$39.00	$36.23	7.1% moins cher
5:1	Questions-réponses générales	$16.50	$13.72	16.8% moins cher
1:1	Agents multi-tours avec réflexion activée	$10.50	$7.72	26.4% moins cher
1:3	Travail à forte charge de raisonnement, génération de code longue	$28.50	$20.17	29.2% moins cher

Lisez le tableau ainsi. Chaque ligne chiffre une charge de travail normalisée à 1 million de tokens de sortie sur 3.5 Flash, avec les tokens d'entrée fixés par le ratio indiqué, au tarif standard. Elle suppose 17% de tokens de sortie en moins sur le modèle plus récent et des tokens d'entrée identiques.

Cette hypothèse de 17% mérite qu'on en pose les conditions, car tout le tableau repose dessus. Google cite le chiffre plutôt que de le mesurer, et la source est Artificial Analysis. Les comptes absolus de tokens publiés sur cette même page, 59 millions contre 75 millions, donnent 21.3%. Les deux chiffres n'ont pas été réconciliés publiquement. Nous avons utilisé le 17% plus conservateur partout, alors considérez le tableau comme le bas de la fourchette plutôt que comme une promesse.

Les tokens de réflexion sont facturés au tarif de sortie. C'est pourquoi les lignes d'agent bougent le plus : sur un agent multi-tours, le budget de réflexion n'est pas une erreur d'arrondi sur la facture, c'en est une large part.

Puis nous l'avons mesuré, et le tableau s'est avéré optimiste. Notre jeu de tâches tourne à environ 1 token d'entrée pour 1.5 token de sortie facturé, ce qui se situe entre les lignes 1:1 et 1:3, où le tableau prédit une économie de 26% à 29%. Nous avons mesuré 13.6% au niveau de réflexion medium et 20.1% en high.

Tout l'écart tient à l'hypothèse d'efficacité en tokens. En medium, le modèle plus récent a facturé 1.7% de tokens de sortie en plus que son prédécesseur, et non 17% en moins, si bien que presque toute l'économie obtenue venait de la baisse de prix plutôt que de l'efficacité en tokens. En high, la réduction est en partie apparue, à 6.4% de tokens de sortie en moins. La méthode et les chiffres complets sont dans la section suivante.

Lisez donc le tableau comme l'arithmétique induite par l'affirmation du fournisseur, et nos chiffres comme ce qu'une charge de travail réelle a effectivement produit. Si votre travail ressemble plus au nôtre qu'à un jeu de benchmarks, misez sur le chiffre le plus bas.

Même intelligence, vitesse à peu près doublée

Artificial Analysis a obtenu un accès avant la sortie et est actuellement la seule source indépendante avec une ventilation complète. Leurs chiffres, mesurés au niveau de réflexion high :

Métrique	3.6 Flash	3.5 Flash
Indice d'intelligence v4.1	50.1	50.2
Humanity's Last Exam	38.3%	40.2%
GPQA Diamond	92.8%	92.2%
SciCode	52.7%	53.1%
Raisonnement à long contexte (AA-LCR)	69.7%	69.3%
Vitesse de sortie	303.6 tok/s	165.4 tok/s
Temps jusqu'au premier token	11.54 s	20.22 s
Temps moyen par question	1.3 min	2.7 min
Coût moyen par question	$0.50	$0.59

Deux conditions s'appliquent à chaque ligne. Elles ont été mesurées au niveau de réflexion high alors que la valeur par défaut de l'API est medium, donc exécuter la configuration par défaut n'est pas la même expérience. Et les chiffres de vitesse et de latence sont des médianes sur 72 heures prises sur un modèle sorti le jour même, ce qui signifie que la fenêtre d'échantillonnage est inférieure à une journée et devrait évoluer.

Cela dit, la forme est claire et c'est un compromis plutôt qu'une régression. La parité de l'indice d'intelligence à 50.1 contre 50.2 est une différence d'arrondi. Les scores de raisonnement et de long contexte ont légèrement progressé. Le seul score à forte composante de connaissances directement comparable entre les deux générations, Humanity's Last Exam, a baissé de 1.9 point. Pendant ce temps, la vitesse de sortie a augmenté de 84% et le temps par question a été à peu près divisé par deux.

Donc si ce que vous vouliez de cette sortie était un modèle plus intelligent, cette mise à niveau n'a pas été conçue pour vous, et rester sur gemini-3.5-flash ne vous coûte rien sur cet axe. Si ce que vous vouliez était un travail de même qualité terminé en moitié moins de temps à un coût unitaire plus bas, c'est exactement ce qui est sorti.

La réserve sur les connaissances mérite une étape de plus, pas une inquiétude de plus. Un mouvement de 1.9 point sur un seul benchmark est un signal pour vérifier votre propre jeu d'évaluation, pas une raison de sauter cette sortie.

Le niveau de réflexion déplace la facture plus que le modèle

Chaque chiffre publié ci-dessus décrit le niveau de réflexion high, alors que la valeur par défaut de l'API est medium. Cet écart est assez grand pour changer une décision d'achat, alors nous avons mené notre propre test le jour du lancement.

Les niveaux de réflexion de Gemini 3.6 Flash accumulent progressivement plus de tokens de raisonnement tandis que la sortie finale de production reste compacte

Le niveau de réflexion peut changer la sortie facturée plus que le changement de modèle lui-même, donc les équipes de production devraient le régler et l'évaluer explicitement.

Le protocole : neuf tâches en trois groupes, extraction structurée depuis des factures, des logs et du HTML de produit ; appel d'outils multi-tours sur trois à cinq étapes contre des outils simulés ; et localisation et réparation de code, où une description de bug doit devenir un correctif exécutable. Les entrées vont de 1,000 à 4,000 tokens, donc cela ne couvre pas le travail à long contexte. Chaque tâche a été exécutée trois fois contre chacune des huit configurations de modèle et de niveau de réflexion, 216 appels au total, envoyés en série via OpenRouter avec le fournisseur fixé sur Google AI Studio. Les tokens de réponse et les tokens de réflexion ont été enregistrés séparément, et tout est chiffré au tarif standard de Google plutôt qu'à la facturation propre de la passerelle. Aucun paramètre d'échantillonnage n'a été défini, puisqu'ils ne font plus rien.

Configuration	Tokens de réponse	Tokens de réflexion	Part de réflexion	Coût par passe	Correct
3.6 Flash `minimal`	1,162	0	0%	$0.0158	9/9
3.6 Flash `low`	1,056	1,095	51%	$0.0232	9/9
3.6 Flash `medium` (par défaut)	1,080	5,944	85%	$0.0598	9/9
3.6 Flash `high`	1,092	6,679	86%	$0.0653	9/9
3.5 Flash `medium`	1,078	5,827	84%	$0.0692	9/9
3.5 Flash `high`	1,113	7,185	87%	$0.0818	9/9

Trois choses ressortent.

Les tokens de réflexion, c'est la facture. En medium et high, ils représentent 84% à 87% de tout ce que vous payez côté sortie. La longueur des réponses bouge à peine sur l'ensemble du tableau. Le modèle que vous choisissez change votre coût bien moins que le niveau que vous choisissez.

minimal ne veut pas dire « réfléchir moins », mais « ne pas réfléchir ». Les tokens de réflexion sont revenus à exactement zéro, une passe coûtait 73.6% de moins que le medium par défaut, et le score était le même, neuf sur neuf. Si vous êtes en medium parce que vous n'avez jamais choisi de niveau, c'est le plus grand levier de coût à votre disposition, et il fonctionne sur le modèle que vous exécutez déjà.

high n'a coûté que 9.3% de plus que medium ici, parce que le budget supplémentaire n'a pas été dépensé : la réflexion est passée de 5,944 tokens à 6,679. C'est un fait à propos de ces tâches plutôt qu'à propos du modèle. Sur un travail plus difficile, cet écart se creuse.

Là où nos chiffres divergent de l'autre test indépendant

aibenchy a exécuté 22 courtes questions de benchmark après la sortie et a trouvé le modèle plus récent 29.4% plus cher en medium et 9.7% moins cher en high. Nous l'avons trouvé moins cher aux deux niveaux, de 13.6% et 20.1%. Les résultats en high concordent dans la direction. Les résultats en medium pointent en sens inverse, et la raison est visible dans un seul chiffre : ils ont mesuré 66.2% de réflexion en plus sur le modèle plus récent en medium, nous avons mesuré 2.0% de plus.

Nous n'allons pas dire que leur résultat est faux. Deux jeux de tâches ont produit des réponses opposées à la même question, et c'est là le constat à retenir : le fait que ce modèle vous fasse économiser des tokens dépend de ce sur quoi vous l'exécutez, pas du modèle seul. Le « 17% de tokens de sortie en moins » de Google ne nomme ni niveau de réflexion ni jeu de tâches, c'est pourquoi il se reproduit sur certaines charges de travail et pas sur d'autres.

Ce que notre test ne peut pas vous dire. Neuf tâches n'étaient pas assez difficiles pour séparer les niveaux sur la qualité. Chaque configuration a obtenu neuf sur neuf. Ces chiffres soutiennent donc une recommandation fondée sur le coût quant au niveau à exécuter, mais ils ne localisent pas le point où la qualité commence à chuter. Les exécutions répétées ont aussi varié : les tokens de réflexion bougeaient de 6% à 51% entre des exécutions identiques de la même tâche, c'est pourquoi les chiffres ci-dessus sont des moyennes sur trois exécutions. Une série plus difficile visant à trouver le coude de qualité est en cours séparément, et nous mettrons cette page à jour avec.

La partie actionnable est simple : quel que soit le modèle que vous exécutez, réglez le niveau de réflexion explicitement et chiffrez le niveau que vous exécutez réellement, pas celui auquel les benchmarks ont été publiés.

Deux choses que Google reconnaît que le nouveau modèle fait moins bien

Google publie deux faiblesses spécifiques dans son billet de lancement, et toutes deux se concentrent au même endroit.

Il explore avant de modifier. Le modèle est plus enclin que 3.5 Flash à effectuer une passe de diagnostic avant de changer le code. Sur les tâches complexes, cela augmente la précision. Sur les tâches front-end simples, il produit des étapes d'exploration supplémentaires dont vous n'aviez pas besoin et que vous ne vouliez pas payer.

Les évaluateurs humains ont préféré la sortie visuelle de l'ancien modèle. Sur la mise en page visuelle et le style en particulier, les évaluateurs ont favorisé le modèle antérieur. La mesure d'atténuation indiquée par Google est d'écrire vos règles de design dans le prompt plutôt que de laisser le style aux valeurs par défaut du modèle.

La fiche modèle liste aussi l'hallucination et des réponses parfois lentes ou des dépassements de délai parmi les limitations connues.

Rien de tout cela ne plaide contre la mise à niveau. Cela plaide pour scinder la décision par surface. Si vous avez un palier agent et un palier de génération d'interface, ce sont des charges de travail différentes avec des preuves différentes, et aucune règle n'impose qu'elles exécutent le même identifiant de modèle.

Changer n'est pas une modification de la chaîne de modèle

C'est la partie qui piège les équipes, et c'est pourquoi une recommandation du jour même du type « changez juste le nom du modèle » est désormais fausse. À partir de cette sortie, et explicitement pour tous les modèles qui la suivent, plusieurs paramètres ont changé de comportement. La liste complète est dans le changelog de l'API Google ; ceux qui cassent la production en silence sont les suivants.

temperature, top_p et top_k sont ignorés, et aucune erreur n'est levée. La documentation de Google indique qu'une future génération de modèle renverra un HTTP 400, mais aujourd'hui les valeurs sont simplement écartées. Si vous comptez sur temperature=0 pour garder un pipeline d'extraction ou de classification déterministe, cette garantie disparaît sans ligne de log, sans exception et sans alerte. L'approche de remplacement consiste à mettre la règle dans l'instruction système.

Il existe une version au second degré à vérifier. Les métadonnées de modèle d'OpenRouter listent toujours temperature, top_p et seed parmi les paramètres pris en charge, donc une passerelle acceptera votre valeur et la transmettra, et le modèle l'ignorera. Quiconque règle la température aujourd'hui pour améliorer la qualité de sortie règle une opération sans effet.

thinking_budget est remplacé par thinking_level. L'ancien budget numérique devient une énumération de chaînes. Envoyer les deux dans une même requête renvoie un 400.

Trois plus petits. candidate_count n'est pas pris en charge sur Gemini 3.x. Une requête dont le message final porte le rôle model renvoie désormais 400, ce qui supprime le préremplissage de réponse. Et chaque FunctionResponse doit désormais porter à la fois call_id et name.

Pour la version ligne par ligne, y compris l'outillage de migration automatisé de Google et le calendrier de retrait des modèles que celui-ci remplace, consultez notre guide de migration Gemini 3.6 Flash. Une mise en garde si vous cherchez cela vous-même : les guides écrits pour des mises à niveau Gemini antérieures, y compris le nôtre sur le passage de Gemini 3 Flash Preview à Gemini 3.5 Flash, décrivent encore les paramètres d'échantillonnage comme fonctionnels, parce que sur cette paire de modèles ils l'étaient. Les dépréciations ci-dessus commencent avec cette génération.

Une note pratique pour tester les deux côte à côte : parce que les deux identifiants de modèle sont exposés via un seul endpoint compatible OpenAI sur EvoLink, vous pouvez pointer base_url vers une seule passerelle et changer la chaîne de modèle pour les comparer en A/B contre vos propres prompts, sans monter d'abord une seconde intégration. C'est le moyen le moins coûteux de répondre aux questions ci-dessus sur les connaissances et l'interface pour votre propre trafic.

Avant de basculer

Les chiffres publiés resserrent la question. Quatre mesures la referment.

Journalisez séparément les tokens de réponse et les tokens de réflexion. Une métrique de tokens totaux ne vous dira pas pourquoi votre facture a bougé, car un seul des deux composants se comporte différemment entre ces modèles.
Fixez le niveau de réflexion explicitement. N'héritez pas de medium par accident, et chiffrez le niveau que vous exécutez réellement plutôt que le niveau high utilisé par les benchmarks publiés. Sur notre jeu de tâches, cela valait plus que le changement de modèle : minimal coûtait 73.6% de moins que le medium par défaut pour la même précision. Vérifiez si votre propre travail le tolère avant de supposer qu'il en va de même.
Faites tourner en shadow votre vrai mélange de prompts, pas un jeu de benchmarks. Cela compte surtout si votre trafic est à forte composante de connaissances, qui est le seul axe où le score comparable a baissé.
Faites un grep avant de basculer. Cherchez dans votre base de code temperature, top_p, top_k, thinking_budget et candidate_count. Les trois premiers échouent silencieusement, ce qui signifie que vos tests passeront et que vos sorties dériveront.

FAQ

Gemini 3.6 Flash est-il un Gemini 3.5 Pro renommé ? Cette spéculation a circulé après le lancement. La réponse communautaire la plus votée l'a rejetée, arguant qu'il n'y a aucun indice d'un modèle Pro renommé et qu'il s'agit d'une mise à niveau de Flash. La fiche modèle appuie cette lecture : elle indique que le modèle est construit sur Gemini 3.5 Flash. Nous consignons la spéculation, sans la cautionner.

gemini-3.5-flash va-t-il être arrêté ? Les dates de retrait annoncées par Google sont 2026-10-16 pour gemini-2.5-flash et gemini-2.5-flash-lite, et 2027-05-07 pour gemini-3.1-flash-lite. Aucune date de retrait n'a été annoncée pour les modèles sortis le 2026-07-21. Aucune échéance annoncée ne force cette décision, vous pouvez donc prendre le temps de mesurer.

Le prix d'entrée a-t-il augmenté ? Non. Les deux modèles facturent $1.50 par million de tokens d'entrée au tarif standard. Seul le prix de sortie a changé, de $9.00 à $7.50.

Puis-je continuer à utiliser temperature=0 pour une sortie déterministe ? Non, et c'est le mode de défaillance à surveiller. Le paramètre est accepté et ignoré sans erreur. Déplacez la contrainte dans l'instruction système et vérifiez la sortie plutôt que la requête.

3.6 Flash est-il nettement moins cher pour le RAG ? À environ 20 tokens d'entrée par token de sortie, les chiffres publiés impliquent une économie de 7.1%. Elle est réelle mais faible, car le côté entrée de votre facture n'a pas changé. Considérez cela comme le plafond plutôt que comme l'estimation : sur nos propres tâches, l'économie effective est ressortie en dessous de ce que la même arithmétique prédisait, et notre test ne couvrait pas du tout la recherche à long contexte. Les équipes RAG devraient considérer cette sortie d'abord comme une amélioration de latence et ensuite comme une amélioration de coût.

Quel identifiant de modèle dois-je utiliser ? gemini-3.6-flash. Il y a une seule version stable, sans suffixe preview et sans variante datée entre lesquelles choisir.