1M Tokens de Salida de Gemini 4 Argon: El Impacto de una Respuesta de Millón de Tokens en tu API Stack

Los 1M tokens de salida de Gemini 4 Argon son un límite de salida, no una ventana de contexto. Cuánto cuesta una respuesta al máximo, además de la transmisión, los tiempos de espera y los topes.

Ashley Goolam

Ashley Goolam

2 October 2026

1M Tokens de Salida de Gemini 4 Argon: El Impacto de una Respuesta de Millón de Tokens en tu API Stack

Apidog para empresas

Despliegue local

SSO & RBAC

Conforme con SOC 2

Explorar Apidog Enterprise

El número principal de Gemini 4 Argon, 1M de tokens, es su límite de salida, no su ventana de contexto. Google dice que una sola respuesta de Argon puede llegar a 1 millón de tokens, aproximadamente 16 veces el límite anterior de 64K, y no ha publicado la ventana de entrada de Argon en absoluto. Todavía no hay nada que invocar: Argon está disponible hoy solo para los defensores del Programa Fairwind, y los clientes de API de pago serán los siguientes una vez que Google abra el acceso (consulte la guía de fecha de lanzamiento y acceso).

Una respuesta tan larga rompe tres suposiciones en las que la mayoría de las pilas de API confían: una llamada finaliza en segundos, el cuerpo cabe en la memoria y una solicitud tiene un costo pequeño y predecible. Esta guía cubre el costo de una respuesta máxima, el streaming, los tiempos de espera, los límites de salida, el almacenamiento y cómo probar todo esto en Apidog antes de que llegue el acceso. Para una descripción general del modelo, consulte qué es Gemini 4 Argon; para las formas de solicitud, consulte la guía de la API de Gemini 4 Argon.

1M de tokens de salida no es una ventana de contexto de 1M

Varias páginas que clasifican para Argon describen la cifra de 1M como una ventana de contexto, y un titular la llama una "ventana de contexto 16 veces más grande". Eso es al revés. La publicación de lanzamiento de Google dice que expandió "el límite de tokens de salida del modelo a un líder de la industria de 1M de tokens". Esos 64K coinciden con el límite de salida de 65,536 tokens en Gemini 3.1 Pro Preview, el modelo Pro superior anterior de Google.

La entrada es un número separado que Google no ha proporcionado. Su evaluación de contexto largo, descrita en la metodología de evaluación, utilizó prompts entre 256K y 1M de tokens. Eso es un subconjunto de referencia, no una especificación. También hay una advertencia en el lado de la salida: Vals AI enumera una salida máxima de 262K para la configuración de Argon que probó. Google dice que el límite del modelo es de 1M; al menos un evaluador externo vio un límite inferior en el endpoint que utilizó.

Modelo Salida máxima por respuesta Ventana de entrada o contexto
Gemini 4 Argon 1M (límite declarado por Google) No publicado
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 entrada máxima)
Claude Opus 5.5 128K (300K en Batch con un encabezado beta) 1M

Todos los competidores limitan la salida síncrona a 128K, por lo que el límite declarado de Argon es aproximadamente 8 veces el de ellos. La razón de Google es la profundidad del razonamiento: con margen, el modelo puede "generar cientos de miles de tokens en una sola trayectoria" y resolver problemas difíciles en una sola pasada. Para saber cómo otros proveedores manejan ejecuciones largas, consulte las tareas de 18 horas de Claude Opus 5.5 y la guía de la API de GPT-6 Astra.

Cuánto cuesta una respuesta máxima

Calcule el límite primero. La salida se factura a $10 por 1M de tokens durante el período de introducción de Argon y $20 después, por lo que una respuesta de longitud completa cuesta:

La entrada se suma. Un prompt de 200,000 tokens añade 200,000 x $2/1M = $0.40 a tarifas de introducción o $0.80 a tarifas estándar, por lo que una sola llamada máxima cuesta $10.40 o $20.80. Un trabajo nocturno que dispara 100 de esos cuesta $1,040 a tarifas de introducción.

Pensar hace que esto sea más difícil de ver. En los modelos actuales de Gemini, los tokens de "pensamiento" se facturan como salida; Google no ha dicho si Argon sigue esa regla o si el pensamiento cuenta para el límite de 1M. De cualquier manera, una respuesta visible corta aún puede implicar una gran factura de salida. La guía de precios de Gemini 4 Argon presenta más escenarios, incluyendo la entrada en caché con un 95% de descuento.

Por qué el streaming es obligatorio

Una llamada sin streaming no devuelve nada hasta que la respuesta completa ha terminado. Con cientos de miles de tokens, esa es una conexión larga y silenciosa, y los tiempos de espera por inactividad en su pila pueden cerrarla antes de que llegue el primer byte.

Transmita en su lugar (Stream instead). En generateContent, cambie el método por :streamGenerateContent?alt=sse y Google enviará eventos enviados por el servidor, un fragmento parcial de candidatos por evento. Lea cada evento a medida que llega y escríbalo; no recopile el cuerpo primero. Esto se ejecuta hoy en Gemini 3.8 Flash, con el modelo en una variable porque Google no ha publicado la ID del modelo de Argon (la configuración se encuentra en nuestra guía de la API de Gemini 3.8 Flash):

import json, os, 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 r, \
        open("response.txt", "a", encoding="utf-8") as out:
    r.raise_for_status()
    for line in r.iter_lines(decode_unicode=True):
        if not line or not line.startswith("data:"):
            continue
        event = json.loads(line[5:])
        for cand in event.get("candidates", []):
            for part in cand.get("content", {}).get("parts", []):
                out.write(part.get("text", ""))
        out.flush()
        usage = event.get("usageMetadata", usage)
print(usage)

timeout=(10, 120) establece un tiempo de espera de conexión de 10 segundos y un tiempo de espera de lectura de 120 segundos. En requests, el tiempo de espera de lectura es la brecha más larga entre bytes, no la duración total, por lo que un stream que sigue enviando puede ejecutarse tanto tiempo como sea necesario. Cada fragmento se escribe en el disco a medida que llega. En 3.8 Flash, cada evento lleva un usageMetadata en ejecución, por lo que el último le da los recuentos finales de tokens para registrar y facturar.

Tiempos de espera en cada salto

Su cliente es un salto. Una transmisión larga también cruza un proxy inverso, una puerta de enlace API, un equilibrador de carga y quizás un entorno de ejecución sin servidor, y cualquiera de ellos puede finalizar la respuesta antes de tiempo:

Salto Qué comprobar Síntoma cuando algo va mal
Cliente HTTP Tiempo de espera de lectura o inactividad, más cualquier tiempo de espera total de la solicitud Excepciones a mitad de la transmisión solo en respuestas largas
Proxy inverso Tiempo de espera de lectura y almacenamiento en búfer de respuesta para text/event-stream Los eventos llegan en ráfagas, o la transmisión se interrumpe
Gateway de API Duración máxima de la solicitud Las solicitudes fallan en el mismo tiempo transcurrido en cada ejecución
Balanceador de carga Tiempo de espera de inactividad Caídas durante pausas largas antes del primer evento
Función sin servidor Tiempo máximo de ejecución La función termina mientras el modelo sigue escribiendo

Esté atento a un corte fijo. Si las respuestas largas siempre fallan en el mismo tiempo transcurrido, algún salto tiene un límite de duración estricto que el streaming no puede solucionar, y ese trabajo debe salir de la ruta de la solicitud.

Ejecutar trabajos largos en segundo plano

Para los trabajos más largos, quite el trabajo de una conexión activa. La API de Interacciones soporta la ejecución en segundo plano para tareas de larga duración utilizando background=true. Las ejecuciones en segundo plano dependen de las interacciones almacenadas: la documentación dice que store=false es incompatible con la ejecución en segundo plano, así que deje el almacenamiento activado para estas solicitudes. Para recuperar una interacción en segundo plano finalizada, siga la documentación de Google; no intente adivinar los endpoints de sondeo. Dado que Google dice que los nuevos modelos se lanzan en la API de Interacciones, planifique que los trabajos largos de Argon se ejecuten allí.

Limitar la salida a propósito

El límite de 1M es un tope, no un objetivo. En generateContent, generationConfig.maxOutputTokens limita cada respuesta; el ejemplo de streaming establece 60,000. En 3.8 Flash, el "pensamiento" cuenta para ese límite: nuestra prueba limitada a 2,000 devolvió 1,340 tokens de pensamiento y 656 visibles. Para la API de Interacciones, confirme el campo de límite de salida en la documentación de Google antes de depender de uno. Luego, elija el límite según el costo que aceptará por llamada:

Límite de salida Costo de salida en el peor de los casos, estándar ($20/1M) Introducción ($10/1M)
64,000 64,000 x $20/1M = $1.28 $0.64
128,000 $2.56 $1.28
500,000 $10.00 $5.00
1,000,000 $20.00 $10.00

Una respuesta que alcanza el límite se detiene antes de tiempo, así que trátela como incompleta. Compruebe el finishReason del evento final: MAX_TOKENS significa que el límite la interrumpió. Luego, continúe en un turno de seguimiento o aumente el límite para ese trabajo.

Almacenar y analizar salidas enormes sin buffering

Un millón de tokens son megabytes de texto por respuesta. Algunas reglas evitan que eso sature un worker:

Pruébalo en Apidog antes de que se abra el acceso

Puede ensayar todo esto con un sustituto. Descargue Apidog y realice tres comprobaciones.

Transmite una respuesta falsa mucho más larga. La salida real de 3.8 Flash alcanza un máximo de 65,536 tokens, así que ejecuta un mock local que transmita mucho más con la misma forma de evento:

# long_stream_mock.py: Gemini-shaped SSE for parser and timeout tests (fake data)
import json, time
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

EVENTS, DELAY, CHUNK = 20000, 0.005, "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:  # fake counts sized like a near-max reply
                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()

Apunte la URL base de un entorno "mock" a http://127.0.0.1:8787 y envíe la misma solicitud de streaming a través de él. El stream se ejecuta durante aproximadamente dos minutos (128 segundos en nuestra prueba) y transporta 9.6 millones de caracteres de texto, suficiente para exponer un analizador con búfer, un proxy que retiene eventos o un tiempo de espera demasiado corto.

Preguntas frecuentes

Su próximo paso

Añada streaming y un límite de salida a su cliente Gemini ahora, en 3.8 Flash, y ejecútelo contra el mock stream largo hasta que nada en su pila lo corte. Cuando se lance la ID de Argon, cambie GEMINI_MODEL y vuelva a ejecutar las mismas pruebas en Apidog.

Practica el diseño de API en Apidog

Descubre una forma más fácil de construir y usar APIs