DEV Community

Cover image for Gemini 4 Argon, 1M tokens de sortie : L'impact d'une réponse d'un million de tokens sur votre stack API
Antoine Laurent
Antoine Laurent

Posted on Originally published at apidog.com

Gemini 4 Argon, 1M tokens de sortie : L'impact d'une réponse d'un million de tokens sur votre stack API

Le chiffre phare de Gemini 4 Argon — 1 million de jetons — correspond à sa limite de sortie, et non à sa fenêtre de contexte. Google affirme qu'une réponse Argon peut atteindre 1 million de jetons, soit environ 16 fois la limite précédente de 64 000 jetons. La fenêtre d'entrée d'Argon n'a pas été publiée. Il n'y a rien à appeler pour l'instant : Argon est réservé aux participants du programme Fairwind ; les clients payants de l'API y auront accès après l'ouverture par Google. Consultez le guide d'accès et de date de sortie.

Essayez Apidog dès aujourd'hui

Une réponse de cette taille invalide trois hypothèses fréquentes dans les piles API :

  • un appel se termine en quelques secondes ;
  • le corps de réponse tient en mémoire ;
  • le coût d'une requête est faible et prévisible.

Voici comment préparer votre client : chiffrer le pire cas, streamer la réponse, configurer les délais d'attente, plafonner la sortie, stocker les données progressivement et tester le flux avant l'ouverture d'Argon dans Apidog.

Pour le contexte sur le modèle, consultez ce qu'est Gemini 4 Argon. Pour les formats de requêtes, consultez le guide de l'API Gemini 4 Argon.

1 million de jetons de sortie n'est pas une fenêtre de contexte de 1 million de jetons

Certaines pages présentent le chiffre de 1 million comme une fenêtre de contexte, voire comme une « fenêtre de contexte 16 fois plus grande ». C'est incorrect.

Le billet de lancement de Google indique que Google a étendu « la limite de jetons de sortie du modèle à 1 million de jetons, un chiffre de pointe dans l'industrie ».

Les 64K correspondent au plafond de sortie de 65 536 jetons de Gemini 3.1 Pro Preview, le précédent modèle Pro haut de gamme de Google.

La limite d'entrée est un nombre distinct, que Google n'a pas communiqué. Sa méthodologie d'évaluation pour le contexte long utilise des invites entre 256K et 1M de jetons. Cela décrit un benchmark, pas une spécification produit.

Attention également à la limite effective exposée par un endpoint : Vals AI rapporte une sortie maximale de 262K pour la configuration Argon testée. Google annonce une limite de modèle de 1 million, mais un évaluateur tiers a observé une limite inférieure sur son point de terminaison.

Modèle Sortie maximale par réponse Fenêtre d'entrée ou de contexte
Gemini 4 Argon 1M (limite déclarée par Google) Non publiée
Gemini 3.1 Pro Preview 65 536 1 048 576
Gemini 3.8 Flash 65 536 1 048 576
GPT-6 Astra 128 000 1 050 000 (922K d'entrée max)
Claude Opus 5.5 128K (300K en mode Batch avec un en-tête bêta) 1M

Chaque concurrent plafonne la sortie synchrone à 128K. La limite déclarée d'Argon est donc environ huit fois supérieure.

Google justifie cette marge par la profondeur du raisonnement : le modèle peut « générer des centaines de milliers de jetons en une seule trajectoire » afin de résoudre des problèmes difficiles en une seule passe.

Pour comparer les stratégies d'exécution longue, consultez les tâches de 18 heures de Claude Opus 5.5 et le guide de l'API GPT-6 Astra.

Illustration Gemini 4 Argon

Chiffrer le coût d'une réponse maximale

Commencez par calculer votre exposition maximale.

La sortie est facturée 10 $ par million de jetons pendant la période de lancement d'Argon, puis 20 $ après :

  • Introduction : 1 000 000 × 10 $ / 1M = 10,00 $
  • Standard : 1 000 000 × 20 $ / 1M = 20,00 $

Ajoutez ensuite le coût d'entrée.

Par exemple, une invite de 200 000 jetons ajoute :

  • 200 000 × 2 $ / 1M = 0,40 $ au tarif d'introduction ;
  • 200 000 × 4 $ / 1M = 0,80 $ au tarif standard.

Un appel maximal avec cette invite coûte donc :

  • 10,40 $ au tarif d'introduction ;
  • 20,80 $ au tarif standard.

Une tâche nocturne qui déclenche 100 appels de ce type peut coûter 1 040 $ au tarif d'introduction.

La réflexion complique l'estimation. Sur les modèles Gemini actuels, les jetons de réflexion sont facturés comme de la sortie. Google n'a pas indiqué si Argon applique exactement la même règle, ni si la réflexion est incluse dans le plafond d'un million.

Par conséquent, une réponse visible courte peut tout de même générer une facture de sortie élevée. Consultez le guide de tarification Gemini 4 Argon pour d'autres scénarios, notamment l'entrée mise en cache avec 95 % de réduction.

Streamer les réponses longues

Sans streaming, votre client ne reçoit rien avant la fin complète de la génération. Avec plusieurs centaines de milliers de jetons, la connexion peut rester silencieuse assez longtemps pour déclencher un délai d'inactivité dans votre client, proxy ou passerelle.

Utilisez plutôt le streaming SSE.

Sur generateContent, remplacez la méthode par :

:streamGenerateContent?alt=sse
Enter fullscreen mode Exit fullscreen mode

Google envoie alors des événements Server-Sent Events contenant des candidats partiels. Traitez chaque événement dès sa réception et écrivez le texte immédiatement. Ne reconstituez pas d'abord toute la réponse en mémoire.

L'exemple suivant fonctionne avec Gemini 3.8 Flash. Le nom du modèle est configurable, car Google n'a pas encore publié l'ID d'Argon. La configuration est détaillée dans le guide de l'API Gemini 3.8 Flash.

import json
import os
import requests

MODEL = os.environ.get("GEMINI_MODEL", "gemini-3.8-flash")
URL = (
    "https://generativelanguage.googleapis.com/v1beta/models/"
    f"{MODEL}:streamGenerateContent?alt=sse"
)

body = {
    "contents": [
        {
            "parts": [
                {
                    "text": "Write a test plan for every endpoint in a payments API."
                }
            ]
        }
    ],
    "generationConfig": {
        "maxOutputTokens": 60000
    },
}

usage = None

with requests.post(
    URL,
    json=body,
    stream=True,
    timeout=(10, 120),
    headers={"x-goog-api-key": os.environ["GEMINI_API_KEY"]},
) as response, open("response.txt", "a", encoding="utf-8") as output:
    response.raise_for_status()

    for line in response.iter_lines(decode_unicode=True):
        if not line or not line.startswith("data:"):
            continue

        event = json.loads(line[5:])

        for candidate in event.get("candidates", []):
            for part in candidate.get("content", {}).get("parts", []):
                output.write(part.get("text", ""))

        output.flush()
        usage = event.get("usageMetadata", usage)

print(usage)
Enter fullscreen mode Exit fullscreen mode

Dans cet exemple :

  • timeout=(10, 120) définit un délai de connexion de 10 secondes ;
  • le délai de lecture est de 120 secondes ;
  • dans requests, ce délai de lecture correspond à l'intervalle maximal entre deux octets, et non à la durée totale de la requête ;
  • un flux qui continue à envoyer des données peut donc durer aussi longtemps que nécessaire ;
  • chaque fragment est écrit sur disque au fur et à mesure ;
  • sur Gemini 3.8 Flash, le dernier usageMetadata fournit les comptes de jetons finaux à enregistrer et à facturer.

Vérifier les délais d'attente à chaque étape

Le client HTTP n'est qu'une étape. Une réponse longue peut traverser un proxy inverse, une passerelle API, un équilibreur de charge et un environnement sans serveur.

Étape Ce qu'il faut vérifier Symptôme en cas d'erreur
Client HTTP Délai de lecture ou d'inactivité, plus un éventuel délai total Exceptions en milieu de flux, uniquement sur les réponses longues
Proxy inverse Délai de lecture et buffering des réponses text/event-stream Événements reçus par rafales ou flux interrompu
Passerelle API Durée maximale de requête Échecs toujours au même temps écoulé
Équilibreur de charge Délai d'inactivité Coupures pendant de longues pauses avant le premier événement
Fonction sans serveur Temps d'exécution maximal La fonction s'arrête alors que le modèle écrit encore

Recherchez en priorité une coupure à durée fixe.

Si les réponses longues échouent toujours après le même temps écoulé, une étape de votre pile applique probablement une limite stricte. Le streaming ne corrige pas une limite de durée maximale : déplacez alors le traitement hors du chemin de la requête.

Exécuter les tâches longues en arrière-plan

Pour les tâches les plus longues, ne maintenez pas une connexion HTTP active.

L'API Interactions prend en charge l'exécution en arrière-plan avec :

background=true
Enter fullscreen mode Exit fullscreen mode

Les exécutions en arrière-plan reposent sur des interactions stockées. La documentation indique que store=false est incompatible avec l'exécution en arrière-plan.

Pour ces requêtes :

  1. activez le stockage de l'interaction ;
  2. envoyez la tâche avec background=true ;
  3. récupérez l'interaction terminée en suivant les endpoints documentés par Google ;
  4. ne devinez pas les endpoints de polling.

Google indique que les nouveaux modèles sont lancés sur l'API Interactions. Prévoyez donc d'y exécuter les tâches Argon de longue durée.

Plafonner volontairement la sortie

La limite d'un million est un plafond technique, pas une cible.

Avec generateContent, utilisez generationConfig.maxOutputTokens pour plafonner chaque réponse :

{
  "generationConfig": {
    "maxOutputTokens": 60000
  }
}
Enter fullscreen mode Exit fullscreen mode

Sur Gemini 3.8 Flash, la réflexion compte pour ce plafond. Dans un test plafonné à 2 000 jetons, le modèle a renvoyé :

  • 1 340 jetons de pensée ;
  • 656 jetons visibles.

Pour l'API Interactions, vérifiez le champ de plafond de sortie dans la documentation Google avant de l'utiliser en production.

Choisissez votre plafond selon le coût maximal acceptable par appel :

Plafond de sortie Coût de sortie maximal, standard (20 $/1M) Introduction (10 $/1M)
64 000 1,28 $ 0,64 $
128 000 2,56 $ 1,28 $
500 000 10,00 $ 5,00 $
1 000 000 20,00 $ 10,00 $

Une réponse qui atteint le plafond peut être incomplète. Vérifiez le finishReason du dernier événement :

MAX_TOKENS
Enter fullscreen mode Exit fullscreen mode

Si cette valeur est présente :

  1. considérez la réponse comme tronquée ;
  2. poursuivez dans un tour de suivi ;
  3. ou augmentez le plafond pour cette tâche spécifique.

Stocker et analyser de très grandes sorties sans buffering

Un million de jetons représente plusieurs mégaoctets de texte par réponse. Appliquez les règles suivantes pour éviter de faire tomber un worker :

  • Écrivez les fragments dès leur arrivée dans un fichier ou dans un upload objet multipartie, au lieu de construire une chaîne unique en mémoire.
  • Conservez le fichier partiel si la connexion est interrompue. Un nouvel essai aveugle régénère — et refacture — la sortie.
  • Demandez des lignes JSON si vous avez besoin d'une structure. Chaque ligne peut alors être analysée indépendamment, sans attendre la fin d'un document géant.
  • Enregistrez usageMetadata et un compteur d'octets plutôt que les corps complets.
  • Vérifiez les limites de colonnes, de messages et de taille de charge utile dans votre base de données et votre file d'attente avant d'y envoyer une réponse de 800K jetons.

Tester le flux dans Apidog avant l'ouverture de l'accès

Vous pouvez valider votre pile dès maintenant avec un substitut. Téléchargez Apidog, puis effectuez ces trois vérifications.

1. Observer un vrai flux SSE

Envoyez une requête de streaming vers Gemini 3.8 Flash avec GEMINI_API_KEY et GEMINI_MODEL comme variables d'environnement.

Apidog analyse les réponses text/event-stream et affiche chaque événement dans la vue Chronologie au fil de l'arrivée. Utilisez-la pour vérifier :

  • la taille des fragments ;
  • les intervalles entre événements ;
  • le usageMetadata final ;
  • le comportement de votre client face aux longues réponses.

2. Diffuser une réponse simulée beaucoup plus longue

Gemini 3.8 Flash est limité à 65 536 jetons de sortie. Pour tester un flux bien plus long, exécutez ce mock local qui produit des événements au format Gemini :

# long_stream_mock.py
# SSE de forme Gemini pour tester les analyseurs et délais d'attente.
# Les données sont factices.

import json
import time
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

EVENTS = 20000
DELAY = 0.005
CHUNK = "lorem ipsum " * 40


class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        self.rfile.read(int(self.headers.get("Content-Length", 0)))

        self.send_response(200)
        self.send_header("Content-Type", "text/event-stream")
        self.end_headers()

        for i in range(EVENTS):
            event = {
                "candidates": [
                    {
                        "content": {
                            "parts": [
                                {"text": CHUNK}
                            ]
                        }
                    }
                ]
            }

            if i == EVENTS - 1:
                event["usageMetadata"] = {
                    "promptTokenCount": 1200,
                    "candidatesTokenCount": 950000,
                    "thoughtsTokenCount": 40000,
                    "totalTokenCount": 991200,
                }

            self.wfile.write(
                f"data: {json.dumps(event)}\n\n".encode()
            )
            self.wfile.flush()
            time.sleep(DELAY)


ThreadingHTTPServer(("127.0.0.1", 8787), Handler).serve_forever()
Enter fullscreen mode Exit fullscreen mode

Démarrez le mock :

python long_stream_mock.py
Enter fullscreen mode Exit fullscreen mode

Configurez ensuite l'URL de base d'un environnement mock vers :

http://127.0.0.1:8787
Enter fullscreen mode Exit fullscreen mode

Envoyez la même requête de streaming vers cet environnement.

Le flux dure environ deux minutes — 128 secondes dans le test — et transporte 9,6 millions de caractères. C'est suffisant pour révéler :

  • un parseur qui bufferise toute la réponse ;
  • un proxy qui retient les événements SSE ;
  • un délai d'inactivité trop court ;
  • une limite de mémoire dans le client ou le worker.

3. Ajouter des assertions sur les jetons et les coûts

Sur une requête generateContent sans streaming, vérifiez que :

candidatesTokenCount + thoughtsTokenCount <= votre plafond
Enter fullscreen mode Exit fullscreen mode

Vérifiez également que le coût calculé reste inférieur à votre budget maximal aux prix d'Argon.

Le guide de l'API Argon contient un script de calcul de coût prêt à l'emploi.

FAQ

1 million est-il la fenêtre de contexte de Gemini 4 Argon ?

Non. Un million correspond à la limite de sortie par réponse, contre 64K auparavant. Google n'a pas publié la fenêtre d'entrée d'Argon.

Combien coûte une réponse Argon de 1 million de jetons ?

La sortie coûte 10 $ aux tarifs d'introduction et 20 $ au tarif standard, auxquels s'ajoute l'entrée. Consultez la tarification de Gemini 4 Argon pour d'autres scénarios.

Puis-je générer une réponse de 1 million de jetons aujourd'hui ?

Non, sauf si votre organisation appartient à la cohorte Fairwind avec accès à Argon. Gemini 3.8 Flash et Gemini 3.1 Pro Preview plafonnent la sortie à 65 536 jetons. Vals AI rapporte une sortie maximale de 262K pour la configuration Argon qu'il a testée.

Dois-je streamer les longues réponses Argon ?

Google n'a pas publié de guide de streaming spécifique à Argon. Cependant, un appel non streamé durant plusieurs minutes est exposé aux délais d'inactivité de toute votre pile. Streamez la réponse ou utilisez l'exécution en arrière-plan avec l'API Interactions.

Comment Argon se compare-t-il à GPT-6 Astra et Claude Opus 5.5 ?

GPT-6 Astra et Claude Opus 5.5 plafonnent la sortie synchrone à 128K. Anthropic autorise 300K en mode Batch avec un en-tête bêta. La limite déclarée d'Argon, à 1 million, est environ huit fois plus élevée.

Votre prochaine étape

Ajoutez dès maintenant le streaming et un plafond de sortie à votre client Gemini en utilisant 3.8 Flash.

Testez ensuite votre pile contre le flux simulé jusqu'à ce qu'aucun composant — client, proxy, passerelle, équilibreur ou worker — n'interrompe la réponse.

Lorsque l'ID du modèle Argon sera disponible, modifiez simplement GEMINI_MODEL, puis relancez les mêmes tests dans Apidog.

Top comments (0)