TPUv7 no AgentX: resultados variam por modelo e métrica

Os benchmarks AgentX do Google TPUv7 não apontam um vencedor universal. Em uma análise publicada em 5 de novembro de 2026, a SemiAnalysis relatou quatro envios com resultados que variam conforme o modelo, a precisão numérica, o software de serving e a métrica observada.

O que o AgentX mede

O AgentX avalia inferência para agentes em conversas de várias rodadas, com contextos longos, reaproveitamento de prefixos e picos de atividade de subagentes, segundo a descrição da SemiAnalysis. É uma carga de trabalho específica: os resultados ajudam a comparar aquelas configurações, mas não resumem o desempenho em qualquer tarefa de inferência.

Quatro modelos, resultados diferentes

No envio de Muse Spark Open, modelo de 816 bilhões de parâmetros, a RadixArk usou SGLang-TorchTPU e pesos NVFP4. A SemiAnalysis considerou competitivo o desempenho de decodificação por dólar na base de custo de TPU relatada pela Meta, mas apontou que a latência de ponta a ponta ainda precisava de trabalho, incluindo otimização de kernels de prefill. A análise também descreveu cabeças de atenção de 64 elementos que deixam 25% da matriz sistólica da TPU sem ocupação na atenção de contexto longo.

Para GLM-5.2 com vLLM e FP8, a SemiAnalysis relatou de 1,2 a 2,7 vezes mais tokens por dólar no TPUv7 do que nos B200, B300 e MI355X, entre 60 e 300 tokens por segundo por usuário. No ponto de 150 tokens por segundo por usuário, o TPUv7 registrou 4,4 vezes os tokens por dólar do H200. Já na comparação FP4 de GLM-5.3, a 100 tokens por segundo por usuário, o GB300 FP4 e o GB200 FP4 apresentaram, respectivamente, 3,6 e 3,5 vezes os tokens por dólar do TPUv7. A análise observa que comparações entre FP4 e outra precisão envolvem uma troca de qualidade; o TPUv7 não tem suporte nativo a FP4.

Em Qwen3.5 397B, a submissão inicial com vLLM e FP8 chegou a 1,67 vez os tokens por dólar do GB300 NVL72 com FP4, segundo a SemiAnalysis. Uma submissão posterior da NVIDIA com FP4 teve melhor desempenho de decode, enquanto o TPUv7 permaneceu à frente na métrica de ponta a ponta. Decode é a etapa em que o modelo gera tokens; o resultado de ponta a ponta considera o atendimento completo da solicitação.

A configuração com llm-d usou de 24 a 32 chips TPUv7 por resultado, com quatro chips por host. No ponto mais rápido testado de cada sistema, o tempo p90 até o primeiro token foi de 8,6 segundos no TPUv7 e 11,1 segundos no GB300 FP4. A SemiAnalysis também relatou que o roteamento ciente de cache elevou a taxa de acerto de cache de 56% para 76%.

Para Kimi K3, a configuração usou vLLM e pesos MXFP4. Na comparação inicial, entre 50 e 200 tokens por segundo por usuário, o TPUv7 alcançou de 0,77 a 0,91 vez os tokens por dólar do GB300. Em um teste com um único usuário, a taxa foi de 391 tokens por segundo por usuário no TPUv7 e 251 no GB300. Após quatro atualizações da NVIDIA, a SemiAnalysis relatou que o GB300 FP4 passou a liderar o TPUv7 por um fator de 1,5 a 2,6 em tokens por dólar. Em outro recorte posterior, a análise atribuiu ao TPUv7 de 1,15 a 2,5 vezes os tokens por dólar dos sistemas GB200, B200 e B300.

Antes de comparar os números, confira o modelo, a precisão, o software de serving e a métrica. Sem esse contexto, tokens por dólar e velocidade de geração podem contar histórias diferentes.

Por que custo, decode e resposta completa diferem

Tokens por dólar expressa a quantidade de tokens gerados em relação ao custo de serving; não é uma medida de velocidade isolada. Decode olha para a geração dos tokens, enquanto a métrica de ponta a ponta considera etapas adicionais do atendimento. Por isso, o resultado de Qwen3.5 397B pode favorecer uma configuração em decode e outra no fluxo completo sem que as duas medições sejam equivalentes.

A precisão também muda a comparação. FP8 e FP4 são formatos numéricos com diferentes níveis de precisão, e parte dos resultados põe lado a lado configurações com formatos distintos. A própria análise aponta uma troca de qualidade nas comparações FP4. Some a isso os diferentes alvos de interatividade, modelos e configurações de serving, e fica claro por que os quatro envios não formam um ranking único de aceleradores.

Exemplos de inferência Ironwood na Google Cloud

A biblioteca de exemplos da Google Cloud lista caminhos de serving com vLLM em Ironwood para GPT OSS-120B e Qwen3-Coder-480B, além de exemplos de inferência com PyTorch e TorchTPU. São exemplos de software e modelos para explorar; não são medições de desempenho dos benchmarks AgentX.