GPT-6 Sol Latencia: 102 segundos al primer token

Intercambiaste gpt-6-astra por gpt-6-sol porque el precio del token bajó de $10 y $50 por millón a $2 y $10. La factura se ve genial. Entonces, tu tiempo de respuesta p95 supera los dos minutos, tu balanceador de carga comienza a devolver errores de tiempo de espera de la pasarela (gateway timeouts), y el soporte se llena de personas preguntando por qué la página se cuelga.

Nada está roto. Cambiaste la forma de la carga de trabajo, no solo su precio.

Artificial Analysis mide GPT-6 Sol en 115.2 tokens de salida por segundo con un tiempo hasta el primer token de 102.15 segundos. GPT-6 Luna mide 153.9 tokens de salida por segundo con un tiempo hasta el primer token de 124.23 segundos. Esos dos números conllevan grandes advertencias, lo cual es la primera mitad de este artículo. La segunda mitad trata sobre qué hacer al respecto: cómo medir la latencia del primer token de manera honesta en tu propia carga de trabajo, y los cuatro cambios de diseño que evitan que un modelo de 100 segundos derribe tu API.

Para el contexto más amplio de tres lanzamientos de vanguardia en dos días, consulta la guerra de precios de modelos de septiembre de 2026.

El número, y todo lo que está mal al citarlo

Lee la columna de advertencias antes que la columna de cifras.

Tres cosas que esa columna te está diciendo.

Estas son cifras de Artificial Analysis, no de OpenAI. OpenAI publicó precios, contexto, disponibilidad y una pila de puntuaciones de referencia en el lanzamiento. No publicó un número de latencia en el material que leímos. Por lo tanto, los 102.15 segundos son de un tercero ejecutando su propio sistema en su propia red, y debes tratarlo como direccional en lugar de como una especificación. Márcalo en tu propia documentación de la misma manera que lo marcamos aquí.

Describen la variante de razonamiento “máx”. Las etiquetas de esfuerzo aparecen en todas las tablas de rendimiento de ambos proveedores en el lanzamiento: low, medium, high, xhigh, max. Max es la cima de esa escalera, y el esfuerzo de razonamiento es la palanca más grande en la latencia del primer token. Una medición de la configuración más lenta no es una medición de la configuración que ejecutarás en producción.

Son mediciones del punto final de un proveedor en un momento dado. La capacidad de servicio, el enrutamiento y la profundidad de la cola se mueyen. Una cifra de la semana de lanzamiento tomada durante un pico de tráfico es un caso peor que se disfraza de constante.

Lo que sobrevive a las tres advertencias es la dirección, y la dirección es el objetivo de este artículo. El modelo barato no es el modelo rápido. Sol cuesta una quinta parte de Astra por token y Luna cuesta una veinteava parte de Sol, y ninguno de esos descuentos te compra un primer byte más rápido. Según esta medición, el modelo más barato de la familia fue el más lento en comenzar.

Tiempo hasta el primer token es el nombre incorrecto para lo que estás midiendo

En un modelo sin razonamiento, el tiempo hasta el primer token es aproximadamente red más cola más precarga. Escala con la longitud del prompt y se sitúa en cientos de milisegundos.

En un modelo de razonamiento, es una cantidad diferente con la misma etiqueta. El modelo hace su 'pensamiento' antes de emitir cualquier cosa que le hayas pedido, por lo que la brecha antes del primer token visible contiene toda la fase de razonamiento. Esa fase no tiene relación con la longitud de tu prompt. Tiene relación con lo difícil que el modelo decide que es el problema.

Dos consecuencias se derivan, y ambas muerden en producción.

La primera es que una tasa rápida de tokens no te salva. Sol emite a 115.2 tokens por segundo una vez que comienza, lo cual es rápido. No importa mucho, porque casi todo el tiempo transcurrido se gasta antes del primer token.

El tiempo de generación es la longitud de salida dividida por 115.2 tokens por segundo, por lo que esa tabla es aritmética sobre las dos cifras medidas en lugar de una nueva medición. Acortar tus respuestas apenas mueve el total. Recortar una respuesta verbosa de 2,000 tokens a 500 ahorra trece segundos de una llamada de dos minutos.

La segunda consecuencia es que la clasificación se invierte según la longitud de la respuesta. Luna tiene una tasa de tokens más rápida y un inicio más lento. Si comparas las dos líneas, se cruzan aproximadamente en 10,100 tokens de salida: por debajo de eso, Sol termina primero a pesar de generar más lentamente, y por encima, la tasa de Luna finalmente compensa su mayor tiempo de espera. Casi nada de lo que sirves a un usuario es una respuesta de 10,000 tokens, por lo que para la mayoría de las cargas de trabajo, el modelo que arranca más lento es simplemente el modelo más lento.

Qué es lo primero que se rompe

La falla rara vez es la llamada al modelo en sí. Es todo lo que lo rodea, que fue dimensionado para una API rápida.

Tiempos de espera por inactividad. Los balanceadores de carga, proxies inversos, gateways de API y plataformas sin servidor limitan el tiempo que una conexión puede permanecer sin que fluyan bytes. Muchos de esos valores predeterminados están muy por debajo de los dos minutos. No confíes en un número que leas en una publicación de blog, incluida esta: ve y lee tu propia configuración. La solución suele ser una directiva, como proxy_read_timeout en nginx, más la configuración correspondiente en cada salto anterior, incluido el propio tiempo de espera del SDK del cliente.

Reintentos. Una política de reintentos que tenía sentido a 300 milisegundos es peligrosa a 100 segundos. Tres intentos con retroceso (backoff) ahora son una solicitud de cinco minutos, y una ráfaga de reintentos durante un período lento pone más trabajo concurrente en el mismo punto final que ya estaba teniendo dificultades. Limita los intentos, mantén un interruptor de circuito y haz que cada llamada sea idempotente para que un reintento no pueda cobrar o escribir dos veces.

Concurrencia, que es lo que la gente pasa por alto. La Ley de Little dice que el número de solicitudes en curso es igual a la tasa de llegada por el tiempo en el sistema. Con una solicitud por segundo y una llamada de 120 segundos, necesitas 120 solicitudes concurrentes en curso solo para mantenerte al día. Esas conexiones ocupan sockets, hilos o invocaciones de funciones durante dos minutos cada una, y nada de eso aparece en la factura de tokens. Un modelo que es barato por llamada aún puede ser caro por segundo de capacidad mantenida.

La interfaz de usuario. Ningún 'spinner' sobrevive 102 segundos. Si la fase de razonamiento está en tu ruta de solicitud síncrona, la solución es arquitectónica, no cosmética.

Cómo medirlo en tu propia carga de trabajo

Los números de proveedores y terceros son una hipótesis de partida. Tu prompt, tu región, tu configuración de esfuerzo y tu patrón de tráfico deciden la cifra real.

Comienza con la vista a nivel de transporte, que requiere un comando:

curl -N -s -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-sol","input":"Summarise this OpenAPI operation.","stream":true}'

Luego lee first_byte con sospecha. En un endpoint de streaming, los primeros bytes suelen ser un evento de apertura de stream, no un token de contenido, por lo que time_starttransfer mide cuándo el servidor comenzó a hablar en lugar de cuándo el modelo comenzó a responder. Esa brecha es exactamente lo que intentas dimensionar, por lo que un sistema ingenuo informa un número halagador.

Cronometrar el primer delta de contenido es la medición que importa:

import time
from openai import OpenAI

client = OpenAI(timeout=600)

t0 = time.perf_counter()
first_content = None

with client.responses.stream(
    model="gpt-6-sol",
    input=PROMPT,
    reasoning={"effort": "low"},
) as stream:
    for event in stream:
        if event.type == "response.output_text.delta" and first_content is None:
            first_content = time.perf_counter() - t0
    total = time.perf_counter() - t0

print(f"ttft={first_content:.2f}s total={total:.2f}s")

Los nombres de campos y eventos en estos fragmentos provienen de las formas actuales de la API de OpenAI en lugar del anuncio de lanzamiento de GPT-6, así que compáralos con la referencia antes de implementar. La disciplina de medición es lo que se mantiene: registra el tiempo hasta el primer token de contenido y el tiempo total como métricas separadas, manténlas por modelo y por nivel de esfuerzo, e informa p95 en lugar de un promedio. La latencia del primer token en un modelo de razonamiento tiene una cola larga, y un promedio oculta precisamente las solicitudes que agotan el tiempo.

Ejecútalo como una verificación programada en lugar de una única vez. Guarda la solicitud de streaming en Apidog, verifica el tiempo de respuesta y ejecuta el escenario en un horario en CI para que una regresión del proveedor o un cambio en el nivel de esfuerzo aparezca como una prueba fallida en lugar de como un ticket de soporte. El mismo proyecto ofrece al trabajo de frontend una forma de evitar la espera: apunta el cliente a un mock de Apidog de tu propio endpoint para que nadie se bloquee durante dos minutos por iteración mientras la integración real aún se está construyendo. Si deseas los fundamentos detrás de las métricas, nuestra guía sobre latencia de API cubre el vocabulario.

Cuatro cambios que realmente ayudan

Saca la llamada de razonamiento de la ruta síncrona. Acepta la solicitud, devuelve 202 Accepted con un ID de trabajo inmediatamente, y entrega el resultado mediante sondeo o webhook. Este es el único cambio que reduce todos los demás problemas, porque los 102 segundos dejan de vivir dentro de una solicitud HTTP que algo aguas arriba está esperando.

Enruta por esfuerzo, no por modelo. Las cifras medidas describen el razonamiento máximo. La mayor parte del tráfico no lo necesita. Clasifica la tarea primero, envía la mayoría rutinaria con bajo esfuerzo y reserva la configuración costosa para los casos que la merecen. Los propios benchmarks de lanzamiento de OpenAI se informan por nivel de esfuerzo exactamente por esta razón, por lo que la configuración es una decisión de diseño de primera clase en lugar de un detalle de ajuste.

Transmite, y muestra la espera con honestidad. Si un humano está mirando, transmite la respuesta y di lo que está sucediendo. Un estado de progreso que refleja la realidad es mejor que un 'spinner' que sugiere que algo está mal.

Presupuesta el tiempo transcurrido (wall clock) por separado de los tokens. El costo por tarea y la latencia por tarea son ejes independientes, y los lanzamientos de septiembre movieron uno de ellos con fuerza. Mantén un presupuesto de latencia por endpoint junto al presupuesto de costos, y trata una regresión en cualquiera de ellos como un bloqueador de lanzamiento.

Una cosa que no hay que asumir: el lanzamiento del caché de prompts de GPT-6 reduce el precio de las lecturas de entrada en caché en un 90% y aumenta las tasas de acierto, y es un ahorro real. Ningún proveedor publicó una afirmación de latencia para ello, así que trata cualquier mejora del primer token por el uso de caché como algo a medir en lugar de algo en lo que basar la planificación.

El modelo barato no es el modelo rápido

GPT-6 Sol a $2 y $10 por millón de tokens es un movimiento de precio genuino, y los resultados de referencia que lo respaldan son sólidos. Nada de eso lo hace rápido al iniciar. En la única medición de latencia pública disponible, el modelo que te ahorra un 80% en el precio de los tokens de Astra pide más de un minuto y medio antes de decir una palabra, y su hermano más barato pide aún más.

El precio está en la factura. La latencia está en tu arquitectura. Mide tú mismo lo segundo, con un sistema que cronometre el primer token de contenido en lugar del primer byte, antes de promocionar un modelo más barato en una ruta de solicitud que fue construida para uno más rápido.