Gemini 2.0 Flash vs Gemini 3.1 Flash-Lite

Les deux modèles viennent de Google : même tokeniseur, même surface d'API, même compte de facturation. Passer de l'un à l'autre se résume à changer une chaîne de caractères — pas de nouveau SDK, pas de re-tokenisation de vos prompts pour ré-estimer le coût, pas de second fournisseur à intégrer. Router entre eux coûte donc bien moins cher à mettre en place qu'une répartition entre fournisseurs.

Ce sont le même laboratoire et le même palier, à 15 mois d'écart : c'est donc une question de mise à niveau, pas un choix entre alternatives. Gemini 3.1 Flash-Lite est l'entrée actuelle ; Gemini 2.0 Flash figure ici parce qu'une part notable du trafic de production tourne encore dessus. Pour un nouveau projet, peu de raisons de prendre l'ancien ; si vous y êtes déjà, la question est de savoir si le coût de migration vaut le gain.

Le contexte est à égalité en pratique : 1.0M contre 1.0M. Aucun des deux ne débloque une taille de document que l'autre ne gère pas, cet axe ne devrait donc pas entrer dans la décision. Si vous espériez que le contexte départage, ce ne sera pas le cas.

Le débit est assez proche pour être ignoré : 99/100 contre 98/100. Aucun ne paraîtra sensiblement plus rapide dans un produit interactif ; la latence n'est donc pas un motif de choix entre les deux.

Une asymétrie pratique : Gemini 3.1 Flash-Lite propose une API par lots à 50 % de remise sur les tarifs standard, Gemini 2.0 Flash non. Pour tout ce qui n'exige pas de réponse immédiate — enrichissement nocturne, reprises d'historique, campagnes d'évaluation — cette remise peut valoir plus que l'écart de prix affiché, et elle passe facilement inaperçue quand on compare les tarifs de base.