GPT-6 Sol: Latência de 102 Segundos para o Primeiro Token

Você trocou gpt-6-astra por gpt-6-sol porque o preço do token caiu de $10 e $50 por milhão para $2 e $10. A fatura parece ótima. Então, seu tempo de resposta p95 ultrapassa dois minutos, seu balanceador de carga começa a retornar timeouts de gateway, e o suporte se enche de pessoas perguntando por que a página trava.

Nada está quebrado. Você mudou o formato da carga de trabalho, não apenas o preço.

A Artificial Analysis mede o GPT-6 Sol em 115,2 tokens de saída por segundo com um tempo para o primeiro token de 102,15 segundos. O GPT-6 Luna mede 153,9 tokens de saída por segundo com 124,23 segundos para o primeiro token. Esses dois números vêm com sérias ressalvas, o que constitui a primeira metade deste artigo. A segunda metade é o que fazer a respeito: como medir a latência do primeiro token de forma honesta em sua própria carga de trabalho, e as quatro mudanças de design que impedem que um modelo de 100 segundos derrube sua API.

Para o contexto mais amplo de três lançamentos de fronteira em dois dias, veja a guerra de preços de modelos de setembro de 2026.

O número, e tudo de errado em citá-lo

Leia a coluna de ressalvas antes da coluna de valores.

Três coisas que essa coluna está te dizendo.

Estes são dados da Artificial Analysis, não da OpenAI. A OpenAI publicou preço, contexto, disponibilidade e uma pilha de pontuações de benchmark no lançamento. Não publicou um número de latência no material que lemos. Portanto, os 102,15 segundos são de um terceiro executando sua própria estrutura em sua própria rede, e você deve tratá-lo como direcional, e não como uma especificação. Marque-o em sua própria documentação da mesma forma que o marcamos aqui.

Eles descrevem a variante de raciocínio “máx”. Etiquetas de esforço aparecem em todas as tabelas de benchmark de ambos os fornecedores no lançamento: baixo, médio, alto, xalto, máx. Máx é o topo dessa escada, e o esforço de raciocínio é a maior alavanca na latência do primeiro token. Uma medição da configuração mais lenta não é uma medição da configuração que você executará em produção.

São medições do endpoint de um provedor em um determinado momento. Capacidade de serviço, roteamento e profundidade da fila mudam. Um número da semana de lançamento, tirado durante um pico de tráfego, é um pior caso disfarçado de constante.

O que sobrevive a todas as três ressalvas é a direção, e a direção é o ponto deste artigo. O modelo barato não é o modelo rápido. O Sol custa um quinto do Astra por token e o Luna custa um vigésimo do Sol, e nenhum desses descontos compra um primeiro byte mais rápido. Nesta medição, o modelo mais barato da família foi o mais lento para iniciar.

Tempo para o primeiro token é o nome errado para o que você está medindo

Em um modelo sem raciocínio, o tempo para o primeiro token é aproximadamente rede mais fila mais pré-preenchimento. Ele escala com o comprimento do prompt e fica na casa das centenas de milissegundos.

Em um modelo de raciocínio, é uma quantidade diferente usando o mesmo rótulo. O modelo faz seu raciocínio antes de emitir qualquer coisa que você pediu, então a lacuna antes do primeiro token visível contém toda a fase de raciocínio. Essa fase não tem relação com o comprimento do seu prompt. Ela tem relação com o quão difícil o modelo decide que o problema é.

Duas consequências se seguem, e ambas causam problemas em produção.

A primeira é que uma taxa rápida de tokens não o salva. O Sol emite 115,2 tokens por segundo assim que começa, o que é rápido. Não importa muito, porque quase todo o tempo de relógio é gasto antes do primeiro token.

O tempo de geração é o comprimento da saída dividido por 115,2 tokens por segundo, então essa tabela é um cálculo aritmético sobre os dois valores medidos, e não uma nova medição. Encurtar suas respostas mal altera o total. Reduzir uma resposta prolixa de 2.000 tokens para 500 economiza treze segundos em uma chamada de dois minutos.

A segunda consequência é que a classificação se inverte dependendo do comprimento da resposta. O Luna tem uma taxa de token mais rápida e um início mais lento. Compare as duas linhas e elas se cruzam em aproximadamente 10.100 tokens de saída: abaixo disso, o Sol termina primeiro apesar de gerar mais lentamente, e acima disso a taxa do Luna finalmente compensa sua espera mais longa. Quase nada que você serve a um usuário é uma resposta de 10.000 tokens, então para a maioria das cargas de trabalho, o modelo que começa mais lento é simplesmente o modelo mais lento.

O que quebra primeiro

A falha raramente é a própria chamada do modelo. É tudo o que a envolve e foi dimensionado para uma API rápida.

Timeouts de inatividade. Balanceadores de carga, proxies reversos, gateways de API e plataformas serverless limitam o tempo que uma conexão pode ficar sem fluxo de bytes. Muitos desses padrões ficam bem abaixo de dois minutos. Não confie em um número que você lê em um post de blog, incluindo este: vá e leia sua própria configuração. A correção geralmente é uma diretiva, como proxy_read_timeout no nginx, mais a configuração correspondente em cada salto à frente, incluindo o próprio timeout do SDK do cliente.

Tentativas. Uma política de novas tentativas que fazia sentido em 300 milissegundos é perigosa em 100 segundos. Três tentativas com backoff agora são uma requisição de cinco minutos, e um surto de retries durante um período lento coloca mais trabalho concorrente no endpoint exato que já estava com dificuldades. Limite as tentativas, mantenha um circuit breaker e torne cada chamada idempotente para que uma nova tentativa não possa cobrar ou gravar duas vezes.

Concorrência, que é o que as pessoas esquecem. A Lei de Little diz que o número de requisições em andamento é igual à taxa de chegada vezes o tempo no sistema. Com uma requisição por segundo e uma chamada de 120 segundos, você precisa de 120 requisições simultâneas em andamento apenas para manter o ritmo. Essas conexões ocupam sockets, threads ou invocações de função por dois minutos cada, e nada disso aparece na conta de tokens. Um modelo que é barato por chamada ainda pode ser caro por segundo de capacidade retida.

A interface do usuário. Nenhum spinner sobrevive 102 segundos. Se a fase de raciocínio estiver no seu caminho de requisição síncrona, a correção é arquitetônica, não cosmética.

Como medir isso em sua própria carga de trabalho

Números de fornecedores e de terceiros são uma hipótese inicial. Seu prompt, sua região, sua configuração de esforço e seu padrão de tráfego decidem o valor real.

Comece com a visualização em nível de transporte, que leva um 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}'

Em seguida, leia first_byte com suspeita. Em um endpoint de streaming, os primeiros bytes geralmente são um evento de abertura de stream, não um token de conteúdo, então time_starttransfer mede quando o servidor começou a falar, e não quando o modelo começou a responder. Essa lacuna é exatamente o que você está tentando dimensionar, e é por isso que um sistema ingênuo relata um número lisonjeiro.

Cronometrar o primeiro delta de conteúdo é a medição 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")

Os nomes de campos e eventos nesses trechos vêm das formas atuais da API da OpenAI, e não do anúncio de lançamento do GPT-6, então verifique-os em relação à referência antes de implantar. A disciplina de medição é o que se mantém: registre o tempo até o primeiro token de conteúdo e o tempo total como métricas separadas, mantenha-as por modelo e por nível de esforço, e reporte o p95 em vez de uma média. A latência do primeiro token em um modelo de raciocínio tem uma longa cauda, e uma média oculta precisamente as requisições que expiram.

Execute isso como uma verificação agendada, e não como algo único. Salve a requisição de streaming no Apidog, faça asserções sobre o tempo de resposta e execute o cenário em um agendamento na CI para que uma regressão no provedor ou uma mudança no nível de esforço apareça como um teste falho, em vez de um ticket de suporte. O mesmo projeto oferece ao trabalho de frontend uma maneira de contornar a espera: aponte o cliente para um mock do Apidog do seu próprio endpoint para que ninguém fique bloqueado por dois minutos por iteração enquanto a integração real ainda está sendo construída. Se você quiser os fundamentos por trás das métricas, nosso guia sobre latência de API aborda o vocabulário.

Quatro mudanças que realmente ajudam

Tire a chamada de raciocínio do caminho síncrono. Aceite a requisição, retorne 202 Accepted com um ID de trabalho imediatamente e entregue o resultado por polling ou webhook. Esta é a única mudança que torna todos os outros problemas menores, porque os 102 segundos deixam de viver dentro de uma requisição HTTP que algo upstream está esperando.

Roteie por esforço, não por modelo. Os valores medidos descrevem o raciocínio máximo. A maior parte do tráfego não precisa disso. Classifique a tarefa primeiro, envie a maioria rotineira com baixo esforço e reserve a configuração cara para os casos que a merecem. Os próprios benchmarks de lançamento da OpenAI são relatados por nível de esforço exatamente por essa razão, então a configuração é uma decisão de design de primeira classe, e não um detalhe de ajuste.

Transmita e mostre a espera honestamente. Se um humano estiver assistindo, transmita a resposta e diga o que está acontecendo. Um estado de progresso que reflete a realidade é melhor do que um spinner que sugere que algo está errado.

Orçamente o tempo real separadamente dos tokens. Custo por tarefa e latência por tarefa são eixos independentes, e os lançamentos de setembro moveram um deles drasticamente. Mantenha um orçamento de latência por endpoint ao lado do orçamento de custo, e trate uma regressão em qualquer um deles como um bloqueador de lançamento.

Uma coisa a não assumir: o lançamento do cache de prompt do GPT-6 reduz o preço das leituras de entrada em cache em 90% e aumenta as taxas de acerto, e é uma economia real. Nenhum dos fornecedores publicou uma declaração de latência para isso, então trate qualquer melhoria de primeiro token vinda do cache como algo a ser medido, e não algo para planejar antecipadamente.

O modelo barato não é o modelo rápido

O GPT-6 Sol a $2 e $10 por milhão de tokens é um movimento de preço genuíno, e os resultados de benchmark por trás dele são fortes. Nada disso o torna rápido para iniciar. Na única medição pública de latência disponível, o modelo que economiza 80% no preço do token do Astra pede mais de um minuto e meio antes de dizer uma palavra, e seu irmão mais barato pede ainda mais tempo.

O preço está na fatura. A latência está em sua arquitetura. Meça o segundo por conta própria, com um sistema que cronometre o primeiro token de conteúdo, e não o primeiro byte, antes de promover um modelo mais barato para um caminho de requisição que foi construído para um mais rápido.