Tokens por segundo: o que muda na comparação de LLMs

A taxa que o painel do Artificial Analysis publica mudou de base em 03/11/2026: a versão 3.0.0 passou a incluir o tempo até o primeiro token, trocou a janela de 72 horas por cinco dias e mudou a contagem de tokens e as regras de falha. A Nexforce não fez benchmark próprio.

Quadro de fatos-chave Evento: metodologia 3.0.0 do Artificial Analysis, em 03/11/2026. O que muda: o tempo até o primeiro token entra na taxa, a janela vira cinco dias e falha de endpoint conta como zero. Fonte: metodologia 3.0.0, consultada em 12/11/2026; sem medição da Nexforce.

O que mudou na medição de tokens por segundo?

No Artificial Analysis, a velocidade de saída agora vai do envio até o último bloco com token, incluindo a espera inicial, e a janela passou de 72 horas para cinco dias em 03/11/2026. Duas leituras separadas pela revisão não formam série comparável.

A unidade continua tokens por segundo, e a métrica não é a mesma. Não há conversão confiável entre os agregados publicados apenas com os números do painel; por chamada, o recálculo depende dos marcos e das contagens. A fronteira do relógio, a janela e a população do agregado mudaram no mesmo intervalo, e comparar provedores exige a mesma definição dos dois lados. Tratar painéis distintos como se medissem a mesma coisa produz conclusão que os dados não sustentam. A saída honesta é declarar a definição de cada número. Quem tem duas capturas não pode somar as duas: mediana de uma carga e média de medianas de cinco dias descrevem populações diferentes. O histórico não atribui a variação de um modelo específico às mudanças de método, e a Nexforce também não. O tamanho do efeito não foi medido.

O que aconteceu

A versão 3.0.0, datada de 03/11/2026, redefiniu a velocidade de saída, a janela, o conjunto de cargas e o tratamento de falhas do painel do Artificial Analysis. O histórico descreve cada mudança sem atribuir a ela a variação de um modelo.

O Artificial Analysis mede a velocidade do envio ao último bloco com token, intervalo que inclui a espera pelo primeiro token e o raciocínio contabilizado pelo provedor. Com t0 no envio, t1 no primeiro token e tf no último bloco, a taxa é tokens de resposta e raciocínio sobre tf - t0. Na variante que começa em t1, o primeiro token fica fora do intervalo e do numerador. A fórmula histórica completa, seu numerador e eventuais exceções não foram verificados nesta consulta. O numerador não é só texto visível: o raciocínio reportado entra, e sem reporte da API a contagem vem do texto. Em sessões com várias chamadas, o tempo das ferramentas fica fora, então não mede a duração de uma tarefa. Erro do endpoint conta como velocidade zero, e sessão incompleta considera só as respostas obtidas.

Figura: a barra de cima vai do envio (t0) ao último bloco (tf); a barra de baixo vai do primeiro token (t1) ao último bloco (tf), com o trecho t0-t1 marcado. Intervalos de tempo, sem escala. Fonte: metodologia 3.0.0, 03/11/2026.

Por que isso importa para quem contrata inferência

A mudança impede tratar leituras de regimes diferentes como série homogênea. Quem compara provedores precisa declarar a fronteira, a janela e a população de cada número, porque uma taxa que inclui a espera inicial não é intercambiável com outra que começa no primeiro token.

O histórico da fonte registra a troca de janela: antes, o número principal era a mediana da carga de 10 mil tokens de entrada das últimas 72 horas; agora, é a média das medianas por carga medida em cinco dias. Não é ganho de velocidade. A leitura correta é de definição, não de melhora. Cinco dias são 120 horas, 48 a mais que a janela anterior, o que dá 66,7% de período adicional. O agregado também mudou: cargas diferentes passaram a entrar no número principal, e carga sem medição para aquele endpoint não entra na média. A divisão não produz taxa comparável, porque dividir dois agregados publicados em datas distintas não reconstrói uma chamada. Um p95 só sobre sucessos esconde quem ficou de fora, como detalha o artigo sobre latência de gateway e contexto.

O que muda na prática

O que muda para quem lê o painel do Artificial Analysis é a régua, não o fornecedor. A tabela separa o regime anterior do atual em cinco pontos que alteram comparações entre datas, e a última coluna registra o efeito.

Quatro linhas da tabela descrevem mudanças documentadas pela metodologia 3.0.0 e uma descreve lacuna da fonte atual. Não há conversão retroativa. Quem monta um comparativo refaz a medição na própria carga ou aceita que o número do painel vale apenas para a definição publicada naquele dia, e isso desloca a pergunta da renovação: não é qual endpoint tem o maior número, e sim qual definição de velocidade a operação precisa. A coluna de efeito descreve consequência direta de cada mudança, não medição de desempenho. Um comparativo sério fixa a fronteira, a janela e a população antes de olhar o resultado, e o guia de métricas de roteadores detalha critérios para essa escolha. Quem registra data, versão e configuração compara o que foi medido, e a conversão entre os dois regimes fica com quem mede.

O que fazer agora

Cinco decisões reduzem o risco de contratar inferência com base em número de painel que não mede o que a operação precisa. Valem para a renovação, a troca de rota e o primeiro teste de um provedor novo, e nenhuma depende de fornecedor.

O teste que sustenta uma decisão de rota repete as mesmas tarefas nos endpoints candidatos, em ordem alternada, registrando concorrência, região, versão e data. O tempo até o primeiro token, a duração total e os percentis de sucesso entram separados, cada um com a população declarada e a contagem de falhas na mesma janela, porque p95 só sobre sucessos esconde os timeouts. A avaliação por tarefa cobre a escolha por qualidade, e a medição de desempenho orienta a comparação de cargas. Nenhuma das duas substitui o teste na sua carga, e o resultado útil é uma tabela com fronteira, janela e numerador declarados. Repetir a mesma carga em horários diferentes expõe variação de desempenho, e a parcela da fila só aparece com instrumentação que meça a espera; sem esse registro, a comparação vira opinião.

1. Fixe a fronteira no contrato. Declare fronteira, numerador e janela.
2. Peça p50 e p95 por métrica. Exija TTFT, duração total e taxa de erro com população declarada.
3. Meça na própria carga. Repita as tarefas, com ordem alternada e região.
4. Preserve as falhas. Erro sobre tentativas, e percentis só de sucesso à parte.
5. Registre o tokenizador. Raciocínio não reportado entra como limitação, nunca como equivalência.

Perguntas frequentes sobre tokens por segundo

Tokens por segundo mede a taxa de saída de uma requisição, e o número muda conforme a fronteira do relógio, a janela e o que conta no numerador. No Artificial Analysis, a espera inicial passou a entrar nesse divisor na versão 3.0.0, de 03/11/2026.

A página do Artificial Analysis exibe leituras recentes sob a metodologia 3.0.0, publicada em 03/11/2026, e as capturas de 19/10 e 09/11 de 2026 não foram reproduzidas. Como fórmula, janela e população mudaram no mesmo intervalo, a diferença entre uma leitura antiga e a atual não separa método de desempenho. A página publica média por endpoint e por carga na janela de cinco dias, e ela não comprova o desempenho na operação do comprador. As amostras por trás da média não apareceram na consulta, então o agregado não se refaz. Medir um endpoint exige repetir a carga e registrar definição, janela e data usadas. O agregado do painel descreve a definição dele, não a latência da sua carga, e uma comparação operacional completa pede população de tentativas, taxa de falhas e percentis calculados sobre sucessos.

Tokens por segundo incluem o tempo até o primeiro token?

Na metodologia atual do Artificial Analysis, sim. A duração vai do envio da requisição até o último bloco com token, então a espera inicial entra no divisor. Uma taxa calculada a partir do primeiro token declara outra fronteira de medição.

TTFT é o mesmo que tempo até o primeiro token de resposta?

Não necessariamente. Em um modelo que raciocina, o primeiro token que chega pode ser de raciocínio e anteceder o de resposta visível. Quando o protocolo não distingue os dois, registre a limitação e não trate os tempos dos dois provedores como equivalentes.

O p95 substitui a taxa de falhas?

Não. O p95 descreve uma distribuição de tempos para a população definida, enquanto a taxa de falhas usa o total de tentativas como denominador. Se só sucessos entram no percentil, erros e timeouts desaparecem do resultado, e uma rota que falha parece estável.

Uma velocidade menor no painel prova que o endpoint ficou mais lento?

Não por si só. A comparação exige capturas verificadas, configurações equivalentes e conhecimento das mudanças de fórmula, carga e agregação. Sem essa base, a diferença não separa método de desempenho real, e o caminho é repetir a carga na própria operação.

Referências e Leitura Complementar

A referência principal é a metodologia de desempenho do Artificial Analysis, versão 3.0.0, publicada em 03/11/2026 e consultada em 12/11/2026. Cada definição citada aqui sai dela, e as fontes abaixo permitem conferir a fronteira, as cargas e as regras de agregação.

A metodologia de desempenho descreve a fronteira da requisição, as cargas e as regras de agregação e de falha que sustentam os achados. A página do K2 Horizon 375B A23B e o painel de provedores são fontes dinâmicas, não capturas. A conta é de janela. Somar leituras de janelas distintas não reconstrói uma chamada. A conversão entre janelas é aritmética: 120 horas menos 72, dividido por 72. Reproduzir o valor de um endpoint dependeria dos dados individuais, das cargas, da configuração e do conjunto de execuções que compõem o agregado, além das regras de falha e da janela escolhida. Uma leitura dinâmica não confirma uma captura antiga, então preserve a data de consulta e identifique mudanças de escopo em cada leitura publicada. O trace de chamadas de LLM complementa a leitura sobre registros individuais.

O que observar nos próximos dias

A próxima versão da metodologia do Artificial Analysis é o evento a acompanhar, não a diferença entre dois números de painel. Até a próxima versão, cada leitura publicada é um retrato datado de uma definição específica, com fonte, limites explícitos e data.

Vale observar três sinais: a publicação de uma nova versão do histórico, a mudança no conjunto de cargas medidas e a forma como o painel apresenta falhas. O Nexforce Router oferece teste de um prompt em múltiplos modelos, rastreamento de chamadas, logs e métricas, e serve como instrumentação para uma política de rota baseada em medição comparável, sujeita ao que estiver disponível e validado no próprio ambiente. Nenhum número de painel vira SLA por causa de uma página pública. A observabilidade de LLMs ajuda a planejar a coleta que sustenta essa decisão. Cada versão datada define a regra. Enquanto a versão não muda, a regra prática é comparar apenas leituras feitas sob a mesma definição, com o número ao lado da fronteira que ele usa, porque a página pública não recria a captura antiga.

A decisão do comprador é medir cargas equivalentes, qualidade e falhas antes de renovar uma rota, com o Router como instrumento.