Quais são os tokens por segundo medidos pelo MLPerf e como eles são usados ​​no LLM?

Guia de Hardware » Benchmarks » Quais são os tokens por segundo medidos pelo MLPerf e como eles são usados ​​no LLM?

Se você trabalha com modelos de linguagem, já ouviu o termo "tokens por segundo" milhares de vezes, mas raramente é explicado em detalhes o que ele significa em ambientes reais e, acima de tudo, como o MLPerf o mede. Neste artigo, explicamos claramente o que são tokens, por que a métrica de tokens por segundo é tão importante na inferência e como plataformas como a Databricks e o benchmark MLPerf a utilizam para dimensionar, comparar e escalar. Além disso, incluímos números específicos de fabricantes e expectativas de desempenho entre nuvens e solo..

O problema não é pequeno: o setor padronizou tokens por segundo para avaliar o desempenho do LLM em data centers e na borda. MLPerf, o pacote MLCommons revisado por pares, tornou-se a referência para comparação de hardware e software.Paralelamente, operadores como a Databricks já provisionam seus endpoints de modelo diretamente com base em um intervalo de tokens por segundo. Vamos analisar tudo isso, com números e casos de uso em mãos.

O que é um token e por que ele é importante no LLM?

Os modelos de linguagem não processam letras ou palavras individuais como elas são; eles trabalham com unidades chamadas tokens. Um token geralmente tem cerca de 4 caracteres ou, em média, 0,75 palavras.Essa proporção varia dependendo do idioma e do tokenizador do modelo, mas serve como uma referência rápida: um texto de 10 palavras movimenta entre 13 e 14 tokens.

A segmentação exata depende do modelo: Cada LLM usa seu próprio tokenizador e divide palavras em tokens completos ou subpalavrasFerramentas online permitem que você veja, por exemplo, como o Llama tokeniza uma frase específica. Essa variabilidade, que parece um pequeno detalhe, influencia a latência e os custos computacionais.

Quando falamos sobre taxa de geração, ela geralmente é expressa em termos de tokens por segundo, em vez de palavras por segundo. Isso homogeneíza a métrica entre idiomas, comprimentos de contexto e estilos de saída., e permite calcular com precisão o custo de inferência e a capacidade necessária.

Por que medir o desempenho em tokens por segundo e não em RPS?

Os serviços de API tradicionais focam em RPS (requisições por segundo). No LLM, essa abordagem é insuficiente: Duas solicitações podem levar tempos muito diferentes dependendo dos tokens de entrada e de saídaOu seja, a carga útil real vem em tokens, não em "número de chamadas".

Existem duas fontes principais de variabilidade. Primeiro, o comprimento do contexto de entrada: Um prompt curto pode ter apenas alguns tokens, mas um documento de resumo pode ter centenas ou milhares.Por outro lado, o comprimento da saída: resumir geralmente produz menos tokens; gerar um artigo ou descrição longa aumenta o tempo, porque a decodificação da saída é a parte mais cara.

Portanto, para dimensionar realisticamente um ponto final de inferência, é útil pensar em termos de tokens. A Databricks, por exemplo, provisiona seus endpoints de serviço com uma variedade de tokens por segundo e cobra por hora com base no dimensionamento.Dessa forma, você pode alinhar a capacidade com a carga real sem ser enganado por um RPS que não conta toda a história.

Como Databricks e MLPerf medem tokens por segundo

O Databricks usa uma carga representativa de RAGs como referência e resume: 2048 tokens de entrada e 256 tokens de saída. Ele combina ambas as fases (pré-preenchimento e decodificação) e, por padrão, otimiza o equilíbrio entre taxa de transferência e latência para tamanhos de lote de 1 por solicitação, simulando várias solicitações simultâneas.

Com essa regra, os números ficam assim: se você configurar um endpoint em 2304 tokens por segundo (2048 + 256), Uma solicitação com esses tamanhos leva cerca de um segundoSe você definir para 5600 tokens por segundo, a mesma solicitação cai para cerca de 0,5 s e você pode processar duas solicitações semelhantes por segundo.

Quando sua carga de trabalho muda, a latência muda. Gerar mais tokens de saída penaliza mais do que aumentar os tokens de entrada.Se você estiver fazendo inferência em lote, calcule o número médio de tokens de entrada e saída para seu conjunto de dados e compare-o com o benchmark anterior para estimar os tempos.

Exemplos práticos: com 1000 linhas, uma média de 3000 tokens de entrada e 500 tokens de saída e uma taxa de transferência provisionada de 3500 tokens por segundo, levará mais de 1000 segundos porque suas médias excedem a referência. Se, em vez disso, você tiver uma média de 1500 entradas e 100 saídas com provisionamento de 1600 tokens por segundo, você irá abaixo de 1000 segundos no total para essas 1000 linhas.

Dimensionamento automático sob demanda e cálculo de dimensionamento real

O Databricks Model Serving inclui dimensionamento automático rápido que Aumentar ou diminuir recursos com base na demanda de tokens por segundoO sistema é dimensionado em blocos de capacidade, e a capacidade adicional só é cobrada quando utilizada. Em testes com mais solicitações paralelas, a taxa de transferência provisionada aumenta até se estabilizar em torno de 8000 tokens por segundo quando os recursos estão saturados, aumentando a latência da fila.

Se você notar menos tokens por segundo do que marcou, verifique duas coisas: Concorrência provisionada refletindo métricas de endpoint e tamanho mínimo de largura de banda configurado. Com esses dados, o dimensionamento real é estimado usando a fórmula: simultaneidade provisionada × tamanho mínimo de largura de banda / 4.

Um exemplo concreto: com uma simultaneidade máxima de 8 e um tamanho mínimo de faixa de 850 tokens por segundo, O limite efetivo seria de 1700 tokens por segundo (8 × 850 / 4). Entender esse cálculo evita surpresas e ajuda a ajustar suas configurações aos seus SLOs de latência.

Inferência MLPerf: O que é e o que mede hoje

O MLPerf, desenvolvido pela MLCommons, é o conjunto aberto e padronizado para medir o desempenho da IA ​​no data center e na borda, da visão ao LLM. Seu objetivo é comparar plataformas de forma justa e reproduzível para impulsionar a eficiência do ecossistema.Nos últimos anos, o foco mudou claramente para GenAI e grandes LLMs.

Na quinta edição, o Llama 2 70B consolidou-se como referência estrela, desbancando o ResNet50, e As métricas de tokens por segundo melhoraram até 3,3x no melhor cenário em um ano, com um desempenho médio 5 vezes maior graças às otimizações de hardware e software. A presença de CPUs como o Intel Xeon 6 nos resultados oficiais também demonstrou que Há espaço para soluções generalistas eficientes em certos cenários.

A versão 5.1 do MLPerf Inference deu mais um salto à frente: incorporou três novos benchmarks principais, raciocínio com DeepSeek-R1, conversão de fala em texto com Whisper Large v3 e um pequeno LLM baseado em Llama 3.1 8BNo geral, o consórcio relatou 27 participantes, atingiu a marca de 90.000 resultados e reduziu as métricas de latência em cenários interativos.

Métricas e objetivos nos novos benchmarks

O benchmark de raciocínio com DeepSeek‑R1, um MoE de parâmetros 671B, mostra que Esses modelos produzem longas cadeias de raciocínio antes da resposta. Suporta saídas de até 20.000 tokens, com uma média de 3880 tokens por saída no conjunto de dados, a maior até o momento em inferência.

As regras medem a taxa de transferência no modo offline e no modo servidor com limites rígidos: Tempo para o primeiro token de 2 segundos e latência por token de 80 ms em p99Isso busca equilibrar o orçamento "pensante" com a capacidade de resposta necessária para implementá-lo.

O pequeno benchmark LLM com Llama 3.1‑8B substitui o GPT‑J 6B como gateway. Suporta contextos de até 128.000 tokens e avalia a sumarização no CNN‑DailyMail com 778 tokens de entrada e 73 tokens de saída. A precisão é validada com ROUGE e, em divisão fechada, precisa corresponder a 99% de um benchmark de alta precisão.

Nas métricas de latência, dois indicadores são usados: TTFT (tempo até o primeiro token) e TPOT (tempo por token de saída). No servidor, são observados 2 s de TTFT e 100 ms de TPOT. (cerca de 480 ppm) e, no novo cenário interativo, ele é reduzido para 0,5 s e 30 ms, respectivamente (cerca de 1600 ppm) para casos como bate-papo, codificação ou ferramentas criativas.

Destaques de desempenho por fabricante e operador

• A NVIDIA liderou novamente, desta vez com o Blackwell Ultra no sistema GB300 NVL72, marcando Um recorde em raciocínio com 45% mais rendimento DeepSeek‑R1 do que GB200 NVL72, atingindo 5842 tokens por segundo por GPU offline e 2907 no servidor, com melhorias próximas de 5x em comparação ao Hopper não verificado.
• No novo benchmark interativo Llama 3.1 405B, a NVIDIA aplicou serviço desagregado com Dynamo, separando contexto e geração em diferentes GPUs e transferindo KV Cache via NVLink, alcançando 1,5× mais throughput por GPU do que o serviço tradicional no Blackwell e mais de 5× mais do que sistemas com Hopper.
• Para modelos menores, a NVIDIA relatou Mais de 18.000 tokens por segundo por GPU no Llama 3.1 8B offline e 5667 tokens por segundo por GPU no Whisper, mantendo a liderança da GPU em todos os cenários (offline, servidor e interativo).
• A AMD expandiu sua presença com o primeiro envio da GPU Instinct MI355X, que agora está na faixa 2‑70B. Ele mostrou escalonamento de vários nós e um aumento de 2,7x em tokens por segundo em relação ao MI325X no FP8. Na divisão aberta, a poda estruturada foi aplicada em Llama 3.1‑405B (FP4), aumentando a produtividade em 82% com um modelo de poda de profundidade de 21% e em 90% com um modelo 33% mais refinado, mantendo a precisão.
• Ela também estreou remessas no Llama 2‑70B Interactive, Mixtral‑8×7B e Stable Diffusion XL, e apresentou resultados mistos MI300X/MI325X: Ao escalar para 4 nós, o MI355X atingiu 3,4x mais rendimento do que o MI300X, estendendo-se para 8 nós com boa escalabilidade.
• A HPE, combinando ProLiant e Cray, relatou 14 resultados número 1. O DL380a Gen12 se destacou no DLRM e o Llama 3.1‑8B (Servidor) entre os sistemas PCIe de 8 GPUs; o DL385 Gen11 melhor desempenho de GPU no Whisper com H200 NVL; e o Cray XD670 (8× H200) obteve seis primeiros lugares no RetinaNet, Llama 3.1‑8B, Mixtral e Whisper, além de primeiros lugares com RTX Pro 6000 Blackwell SE e GH200 NVL2 em DLRM.
• O CoreWeave foi a primeira nuvem a relatar resultados com o GB300, entregando 6005 tokens por segundo por GPU no DeepSeek‑R1 offline e demonstrando orquestração e dimensionamento com Slurm no Kubernetes e agendamento com reconhecimento de topologia para aproveitar ao máximo o NVLink.
• A Dell enviou 12 sistemas com aceleradores AMD e NVIDIA, destacando-se no LLaMA 2 70B Interactive com PowerEdge XE9680L e B200, Servidor LLaMA 3.1‑8B em XE9685L+B200, SDXL no XE9685L e Whisper no XE9680L, demonstrando versatilidade da imagem à voz por meio do LLM.
• A Intel enfatizou que continua o único a enviar resultados com CPUs de servidor e mostrou que o Xeon 6 com núcleos P apresenta uma melhora de 1,9x em relação ao Xeon de 5ª geração em cinco benchmarks, consolidando seu papel na inferência de uso geral. Também apresentou estações de trabalho com 8 GPUs Arc Pro B60, com 192 GB de VRAM para atender o Llama2‑70B a vários usuários, e drivers e frameworks integrados para simplificar a implantação de múltiplas GPUs.
• Entre os integradores e parceiros, a ASUSTeK Latência e taxa de transferência otimizadas com quantização, kernels e pilha; A Broadcom demonstrou a virtualização VCF com sobrecarga mínima em comparação ao bare metal em várias cargas de trabalho (Whisper, SDXL, Llama 3.1-405B, Llama2-70B, RGAT, RetinaNet); A Cisco escalou quase linearmente com o UCS C885A M8 (8× H200 SXM) e o UCS C845A M8 (8× H200 NVL ou L40S), suportados por redes One G200.
• O KRAI, usando a API OpenAI e overheads realistas, comparou o SGLang e o vLLM com o Llama3.1‑70B: 31.391 tokens por segundo offline com SGLang 0.4.9 e 26.319 com vLLM 0.9.2 em um único servidor com 8x H200; com quantização dinâmica atingiu 27.697 com SGLang e 30.893 com vLLM, e em vários nós escalou até 87.334 tokens por segundo em três servidores.
• Lambda, com 8x B200 180 GB SXM, mostrou melhorias na taxa de transferência até 7 por cento em SDXL e 15 por cento em Llama 3.1‑405B comparado à rodada anterior e oferece clusters de 16 a 1536 GPUs com Kubernetes gerenciado ou Slurm.
• A MiTAC, com sua série G8825Z5, brilhou na LLaMA 2 70B Interactive com 18.846,1 fichas por segundo e bons resultados em Server e Mixtral; Nebius certificou seu desempenho virtualizado quase no mesmo nível do bare metal em GB200 NVL72, HGX B200 e HGX H200, com 596,11 tokens por segundo no servidor e 855,82 tokens offline no Llama 3.1‑405B com 4 GPUs GB200.
• A Red Hat demonstrou o vLLM como um tempo de execução suportado em seu AI Inference Server, com Kernels CUTLASS para FP8 e FlashAttention‑3 além de um motor vLLM v1 aprimorado, equipa o Llama‑3.1‑8B em H100 e L40S com ótima relação custo-desempenho.
• A Supermicro apresentou resultados líderes com o HGX‑B200 8‑GPU (ar e líquido) com CPUs Intel e AMD, destacando Llama 3.1‑8B e Llama 2‑70B no servidor/offline/interativo e Whisper; em colaborações, mostrou excelente dimensionamento com 32× H100‑SXM e alternativas com MI325X.
• Vultr estreou com Supermicro AS‑8126GS‑TNMR e 8x MI325X, certificando desempenho competitivo como uma GPU em nuvem; GATEOverflow reprodutibilidade promovida com MLCFlow em CPUs RTX 4090 e AMD/Intel; a Giga Computing enviou sistemas EPYC+MI8X e Xeon+HGX B325 refrigerados a ar 200U; a QCT cobriu configurações Xeon 6 com H200 NVL (4 GPUs) e 8 plataformas H200 SXM5 com NVLink e GPUDirect Storage, além de 8 sistemas MI325X.

A academia também teve seu momento. A Universidade da Flórida, com seu DGX B200 SuperPOD integrado ao HiPerGator, foi a primeira instituição a submeter resultados de inferência Atendendo às latências do servidor sob particionamento fechado, usando Apptainer sem Docker/Sudo e se adaptando ao SLURM multiusuário. No extremo oposto, um único envio em um MacBook Pro M1, com ONNX Runtime e CoreML em GPU e Neural Engine, superou a precisão alvo na categoria de borda e demonstrou que a inferência de qualidade pode ser avaliada em hardware de consumidor.

Velocidade percebida pelos usuários e limites práticos

A experiência do usuário não é medida apenas em benchmarks; na vida cotidiana, A sensação de fluidez surge quando você ultrapassa um certo limite de tokens por segundoUm usuário comentou que seu limite para conversação é de 4 tokens por segundo e para escrita de histórias é de cerca de 10 tokens por segundo; abaixo disso, a interação parece lenta.

Se você tentar executar um LLM localmente, existem três realidades. Em uma CPU de desktop, É normal mover-se a 1–2 fichas por segundo, inviável para respostas longas. Com uma GPU gamer de ponta, você pode chegar perto de 5 tokens por segundo. Com uma NVIDIA H100, sim, já estamos falando de 60 tokens por segundo, mas é hardware de data center, não hardware de desktop.

O que está acontecendo na nuvem? Os provedores mais poderosos estão superando esses números graças a hardware especializado e pilhas de inferência otimizadas. Médias de cerca de 119 tokens por segundo foram relatadas no ChatGPT‑4 e 168 no Gemini., enquanto modelos populares de código aberto como o DeepSeek giram em torno de 21 tokens por segundo. Se convertermos isso para palavras, 119 tokens por segundo equivalem a cerca de 90 palavras por segundo.

Conclusão operacional: para a maioria dos usuários, Executar uma IA no computador é possível, mas impraticável devido à lentidãoPara trabalhar em velocidades confortáveis ​​e com latências reduzidas, os serviços gerenciados continuam sendo a opção sensata.

Como dimensionar seu endpoint por TPS e o que esperar da latência

Passos práticos para o dimensionamento. Primeiro, descreva seu caso de uso: Número médio de tokens de entrada e saída, distribuição de comprimento e simultaneidade esperada. Segundo, execute um teste de carga com um conjunto de dados representativo, envolvendo TTFT e tokens por segundo sustentados por solicitação.

Em seguida, alinhe a configuração com o seu padrão. Se a sua carga de trabalho for semelhante à referência do Databricks (2048 entradas, 256 saídas), Escolha um intervalo de tokens por segundo de forma que uma solicitação fique dentro do orçamento de latência desejadoLembre-se de que duplicar a saída geralmente custa mais do que duplicar a entrada e que a simultaneidade efetiva depende do dimensionamento automático real.

Monitore e ajuste. Fique de olho nas métricas. simultaneidade provisionada, filas, TTFT e TPOTe compare-o com seus SLOs. Se você tiver capacidade limitada, expanda o intervalo; se tiver recursos excedentes, diminua-o e ajuste os blocos para economizar. A fórmula de dimensionamento real ajudará você a entender por que o endpoint não está funcionando conforme configurado se não criou réplicas suficientes.

Por fim, esteja atento ao cenário. No modo interativo estilo chatbot, vise um TTFT de 0,5s e 30ms por token Isso lhe proporcionará uma experiência de usuário premium. No modo servidor, 2 s e 100 ms por token são diretrizes razoáveis ​​e, offline, busca-se a máxima taxa de transferência, mantendo a precisão exigida pelo benchmark.

Observando as tendências do MLPerf, o vetor é claro: Mais contexto, mais tokens e melhores técnicas de eficiência —servimento desagregado, FP4/FP8, poda estruturada, kernels personalizados, agendamento de cache KV— estão elevando o teto de tokens pelo segundo ano após ano, tanto por chip quanto por sistema.

O quadro geral desenhado pela Databricks e MLPerf é consistente: Pensar em termos de tokens por segundo é a maneira correta de raciocinar sobre custo, latência e escalabilidade no LLM.Com um bom benchmark representativo, métricas TTFT/TPOT e dimensionamento automático bem calibrado, é possível fornecer respostas rápidas e estáveis ​​sem superdimensionar a infraestrutura.

Artigo relacionado:

NVIDIA Blackwell Ultra GB300: Arquitetura, Memória e NVLink 5