Serviços
Contate-nos

Múltiplo-GPU Benchmark: B200 vs H200 vs H100 vs MI300X

Sedat Dogan
Sedat Dogan
atualizado em 30 jun. 2026

Por mais de duas décadas, otimizar o desempenho de computação tem sido uma pedra angular do meu trabalho. Realizamos benchmark das B200, H200, H100 da NVIDIA e MI300X da AMD para avaliar quão bem elas escalam para inferência de Modelo de Linguagem Grande (LLM). Usando o framework vLLM com o modelo meta-llama/Llama-3.1-8B-Instruct, executamos testes em 1, 2, 4 e 8 GPUs.

Analisamos a taxa de transferência e a eficiência de escalabilidade para ilustrar como cada arquitetura de GPU lida com cargas de trabalho paralelizadas e intensivas em computação.

Resultados do benchmark de múltiplo-GPU

Taxa de transferência total vs. contagem de GPU

Loading Chart
  • Taxa de transferência total (tokens/segundo): Esta métrica representa o poder de processamento bruto de todo o sistema de múltiplo-GPU. Ela mede o número total de tokens de entrada e saída processados por segundo, tornando-se o indicador mais importante de desempenho máximo sob uma carga de trabalho saturada e offline.

Para entender como calculamos a pontuação, veja nosso metodologia de benchmark de múltiplo-GPU.

Principais insights de desempenho:

Análise de desempenho: A NVIDIA H200 oferece a maior taxa de transferência em todas as configurações testadas, com melhorias de desempenho de 9-10% sobre a H100. O sistema atinge 99,8% de eficiência de escalabilidade com configurações de dual-GPU, indicando utilização de recursos quase ideal.

Características de desempenho da AMD MI300X: A AMD MI300X atinge uma taxa de transferência de single-GPU de 18.752 tokens por segundo, representando aproximadamente 74% do desempenho da H200. O sistema mantém eficiências de escalabilidade de 95% e 81% para configurações de two-GPU e four-GPU, respectivamente.

Latência média de inferência vs. contagem de GPU

  • Latência média de inferência (milissegundos): Esta métrica mede o tempo médio que leva para processar uma única solicitação do início ao fim. Menor latência se traduz em uma experiência mais rápida e responsiva para os usuários finais.

Principais insights de desempenho:

Análise de desempenho de latência: A NVIDIA B200 exibe as medições de latência mais baixas em todas as configurações avaliadas, atingindo 2,40ms com implementações de eight-GPU. Essas características de desempenho o posicionam para aplicações que exigem tempos de resposta mínimos, como sistemas interativos em tempo real onde latência sub-3ms é um requisito de design.

Observações de eficiência de escalabilidade: A análise revela retornos decrescentes na redução de latência à medida que a contagem de GPU aumenta em todas as plataformas. A maior redução de latência ocorre durante a transição de configurações de single para dual-GPU (aproximadamente 50% em todas as plataformas). Configurações com mais de 4 GPUs mostram melhorias de latência progressivamente menores.

Análise comparativa H200 e H100: A H200 demonstra latência 5-8% menor que a H100 em todas as escalas, com a diferença absoluta diminuindo em contagens de GPU mais altas (2,81ms versus 2,86ms em oito GPUs, uma diferença de 0,05ms). Essa diferença marginal de desempenho, quando comparada com a diferença de preço de 41%, sugere que a H100 pode oferecer características de custo-desempenho mais favoráveis para implantações sensíveis à latência.

Características de latência da AMD MI300X: A MI300X demonstra valores de latência 37-75% mais altos que a H200 em configurações testadas, o que pode ser atribuído às diferenças atuais na maturidade da pilha de software entre as implementações vLLM ROCm e CUDA. Em uma escala de eight-GPU, a MI300X atinge latência de 4,20ms, que permanece dentro de parâmetros aceitáveis para numerosas aplicações de produção, apesar da diferença de desempenho em relação às plataformas NVIDIA.

Desempenho vs. preço: Uma análise de eficiência de custo

Embora métricas de desempenho bruto sejam cruciais, a decisão final para qualquer organização depende da eficiência de custo. Para analisar o retorno sobre o investimento (ROI) de cada plataforma, mapeamos nossos resultados de taxa de transferência contra os preços horários sob demanda do RunPod no momento do teste. Isso nos permite calcular uma pontuação de "desempenho por dólar", revelando qual configuração oferece o poder computacional mais baixo pelo menor custo.

Nota: Todas as informações de preço refletem as taxas sob demanda disponíveis na plataforma RunPod Cloud no momento do benchmark (setembro de 2025) e estão sujeitas a alterações. Os custos são apresentados para análise comparativa e não incluem taxas de armazenamento ou rede.

Como calculamos a taxa de transferência por dólar

Para gerar este gráfico, processamos nossos dados de desempenho bruto contra os custos horários. A fórmula de cálculo é:

  • Preparação de Dados: Para cada ponto de dados em nossa tabela de resultados, recuperamos o custo horário correspondente para a configuração específica de GPU (por exemplo, 4x H100 custa $10,76).
  • Cálculo: Em seguida, aplicamos a fórmula para calcular o valor throughput_per_dollar. Por exemplo, a H100 em 1x GPU entregou 23.243 tokens/s a um custo de $2,69/hr, resultando em uma pontuação de 8.642 tokens/s por dólar.

Essa pontuação de eficiência fornece uma ferramenta de tomada de decisão, movendo a conversa de "qual é o mais rápido?" para "qual é o investimento mais inteligente para nossa carga de trabalho?"

O que é escalabilidade de múltiplo-GPU?

A escalabilidade de múltiplo-GPU refere-se à capacidade de um sistema de aumentar seu desempenho distribuindo uma única tarefa grande entre múltiplas GPUs. Para inferência de LLM, isso pode ser alcançado através de paralelismo de dados, onde cópias independentes do modelo são executadas em cada GPU, com um balanceador de carga distribuindo solicitações recebidas entre todas as instâncias.

Idealmente, usar duas GPUs entregaria o dobro do desempenho de uma única GPU (2x speedup). No entanto, na realidade, os ganhos de desempenho são limitados por gargalos de CPU e do sistema, o tempo que o sistema hospedeiro gasta gerenciando múltiplos processos concorrentes, restrições de largura de banda de memória e contenção de recursos. Nosso benchmark mede quão eficientemente cada plataforma gerencia essas restrições de nível de sistema, um fator crítico para construir servidores de inferência de IA de alto desempenho e custo-efetivos para modelos pequenos a médios.

Quais são os desafios nos testes de escalabilidade de múltiplo-GPU?

Realizar benchmark de sistemas de múltiplo-GPU apresenta desafios únicos que podem afetar significativamente o desempenho.

Sobrecarga de comunicação e gargalos de interconexão

Quando um modelo é dividido entre GPUs, a interconexão, como o NVLink da NVIDIA ou o Infinity Fabric da AMD, torna-se um gargalo de desempenho crítico. A eficiência da comunicação inter-GPU impacta diretamente a escalabilidade. Se o tempo gasto esperando por dados de outra GPU exceder o tempo economizado ao paralelizar o cálculo, os ganhos de desempenho diminuirão. Esse efeito é particularmente pronunciado em modelos que não são grandes o suficiente para saturar totalmente a capacidade computacional de cada GPU.

Maturidade do ecossistema de software

O desempenho não é apenas uma função de hardware. A pilha de software, incluindo drivers, bibliotecas de comunicação (como NCCL para NVIDIA e RCCL para AMD) e o motor de inferência (vLLM), desempenha um papel monumental. Descobrimos que o desempenho de uma plataforma está profundamente ligado à maturidade de seu suporte de software. Um ecossistema estabelecido como o CUDA da NVIDIA muitas vezes se beneficia de anos de ajuste fino e otimização, o que pode levar a uma eficiência de escalabilidade superior em comparação com integrações mais recentes como o ROCm da AMD, mesmo em hardware poderoso.

Otimizações específicas da plataforma

Como nossos testes revelaram, atingir o desempenho ideal muitas vezes requer configurações específicas da plataforma. Usar uma abordagem genérica, "tamanho único", pode levar a um desempenho enganosamente baixo. A imagem Docker correta, variáveis de ambiente (por exemplo, habilitando kernels personalizados da AMD) e até mesmo tipos de dados do modelo (por exemplo, bfloat16 para Blackwell) são essenciais para desbloquear o verdadeiro potencial do hardware. Isso torna comparações justas "de maçã com maçã" um desafio técnico significativo.

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.
GoogleAdicionar como fonte preferencial

Metodologia de benchmark de múltiplo-GPU

Testamos as arquiteturas de GPU de alto desempenho mais recentes de ambas as NVIDIA e AMD para avaliar suas capacidades de escalabilidade. Nosso benchmark mediu o desempenho de configurações de single e multi-GPU (1x, 2x, 4x, 8x) usando o padrão meta-llama/Llama-3.1-8B-Instruct1 modelo e o motor de inferência vLLM2 .

Ambiente e processo de teste

  • Plataforma: Todos os benchmarks foram executados no RunPod Cloud para garantir acesso consistente ao hardware.
  • Motor de inferência: vLLM (ferramenta vllm bench throughput) foi usado como o motor padronizado.
  • Modelo: meta-llama/Llama-3.1-8B-Instruct.
  • Dataset: Dataset ShareGPT Vicuna (25.000 prompts) para simular uma carga de trabalho conversacional.
  • Estratégia: Paralelismo de dados; cada teste de multi-GPU executou uma instância independente do vLLM em cada GPU. A carga total de prompts foi distribuída uniformemente entre as instâncias, que foram executadas simultaneamente para simular um ambiente de produção balanceado por carga. Essa abordagem elimina a comunicação inter-GPU (NVLink/PCIe) como um gargalo, deslocando os limitadores de desempenho para o sistema hospedeiro (CPU, RAM).
  • Automação: Scripts Bash personalizados foram usados para automatizar a configuração do ambiente, execução de teste, monitoramento de recursos (nvidia-smi, rocm-smi) e agregação de resultados.

Configurações específicas da plataforma

Alcançar o desempenho ideal exigiu configurações personalizadas para cada arquitetura.

Plataformas NVIDIA (H100, H200, B200)

  • Imagem base: runpod/pytorch:2.8.0-py3.11-cuda12.8.1.
  • Instalação do vLLM:
    • H100/H200 (Hopper): Instalação padrão via pip install vllm.
    • B200 (Blackwell): vLLM foi compilado a partir do código-fonte (pip install -e .) para habilitar suporte nativo para a nova arquitetura, resolvendo erros "no kernel image".
  • Parâmetros chave:
  • Variável de Ambiente Crítica:

Plataforma AMD (MI300X)

  • Imagem base: rocm/vllm:rocm6.4.1_vllm_0.10.1_20250909
  • Instalação do vLLM: Nenhuma instalação foi necessária, pois a versão otimizada estava incluída na imagem.
  • Parâmetros e otimizações chave: O ajuste extensivo identificou as seguintes configurações não padrão como críticas para atingir a taxa de transferência máxima:
  • Variáveis de ambiente específicas da AMD:
  • Visibilidade do dispositivo: ROCR_VISIBLE_DEVICES foi usado em vez do equivalente do CUDA para atribuir instâncias a GPUs específicas.

Fases de execução do benchmark

Cada execução de benchmark seguiu um protocolo de execução de três fases para garantir resultados precisos e reproduzíveis:

Fase 1: Warmup

Antes de cada teste de configuração de multi-GPU, realizamos uma fase de warmup dedicada para eliminar efeitos de inicialização fria:

  • Duração: 100 prompts processados na GPU 0
  • Propósito: Carregamento do modelo, inicialização do cache KV e compilação de kernel CUDA/ROCm
  • Saída: Descartada (não incluída nas medições)
  • Comportamento específico da plataforma:
    • NVIDIA (CUDA): Compilação de kernel e otimização de grafo CUDA (~30-60 segundos)
    • AMD (ROCm): Compilação de kernel e ajuste opcional TunableOp (varia com base na configuração PYTORCH_TUNABLEOP_ENABLED)

Fase 2: Inicialização de monitoramento de GPU

Concorrente com a execução do benchmark, lançamos processos de monitoramento dedicados para cada GPU:

  • Taxa de amostragem: Intervalos de 1 segundo
  • Métricas coletadas: Utilização de GPU, uso de memória, temperatura, consumo de energia
  • Ferramentas: nvidia-smi (NVIDIA) ou rocm-smi (AMD)
  • Saída: Logs CSV para pós-análise

Fase 3: Execução paralela do benchmark

Após a conclusão do warmup, todas as instâncias de GPU foram lançadas simultaneamente:

  • Cada GPU processou uma parte igual dos 25.000 prompts totais
  • Todas as instâncias iniciaram dentro do mesmo segundo para simular o balanceamento de carga de produção
  • Taxa de transferência total é medida como a soma de todas as saídas de GPU
  • Tempo de execução medido desde o início da primeira instância até a conclusão da última instância

Impacto de desempenho no mundo real dos testes

Nossos testes revelaram que erros de configuração menores podem levar a resultados de desempenho significativos e enganosos. A tabela a seguir ilustra o impacto de configurações incorretas específicas da plataforma:

Conclusão

Para servir modelos na classe 8B-13B, o paralelismo de dados é uma estratégia altamente eficiente. A escolha do hardware depende das prioridades específicas de implantação.

Para cargas de trabalho onde a relação custo-benefício é uma consideração primária, a NVIDIA H100 oferece características favoráveis, equilibrando métricas de desempenho, custos de aquisição e comportamento de escalabilidade previsível.

Quando a maximização da taxa de transferência é o objetivo principal sem restrições orçamentárias, a NVIDIA H200 exibe as medições de desempenho mais altas entre as plataformas avaliadas.

A AMD MI300X apresenta características notáveis para estratégias de implantação de longo prazo e ambientes de infraestrutura baseados em AMD. Melhorias de desempenho são antecipadas através de iterações de otimização de software, e a capacidade substancial de VRAM da plataforma permite o acomodamento de arquiteturas de modelo maiores.

A NVIDIA B200 demonstra limitações nesta configuração específica de carga de trabalho, exibindo restrições de desempenho relacionadas à CPU e eficiência de custo subótima. A arquitetura parece mais adequada para implementações que usam modelos de grande escala com estratégias de paralelismo de tensor.

Leitura adicional

Explore outras pesquisas de hardware de IA, como:

Cite este benchmark

Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.

Sedat Dogan and Ekrem Sarı (2026) - "Múltiplo-GPU Benchmark: B200 vs H200 vs H100 vs MI300X". Publicado on-line em AIMultiple.com. Acessado em 30 Junho 2026, em: https://aimultiple.com/multi-gpu [Recurso on-line]

Dogan, S., & Sarı, E. (2026, 30 Junho). Múltiplo-GPU Benchmark: B200 vs H200 vs H100 vs MI300X. AIMultiple. https://aimultiple.com/multi-gpu

@misc{dogan2026,
  author = {Dogan, Sedat and Sarı, Ekrem},
  title  = {{Múltiplo-GPU Benchmark: B200 vs H200 vs H100 vs MI300X}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/multi-gpu}},
  note   = {AIMultiple. Acessado em 30 Junho 2026}
}
Sedat Dogan
Sedat Dogan
CTO
Sedat é um líder em tecnologia e segurança da informação com experiência em desenvolvimento de software, coleta de dados web e cibersegurança. Sedat: - Possui 20 anos de experiência como hacker ético e guru de desenvolvimento, com vasta expertise em linguagens de programação e arquiteturas de servidores. - É consultor de executivos de alto nível e membros do conselho de administração de empresas com operações tecnológicas de alto tráfego e missão crítica, como infraestrutura de pagamentos. - Possui grande perspicácia comercial, além de sua expertise técnica.
Ver perfil completo
Pesquisado por
Ekrem Sarı
Ekrem Sarı
Pesquisador de IA
Ekrem é pesquisador de IA na AIMultiple, com foco em automação inteligente, GPUs, agentes de IA e frameworks RAG.
Ver perfil completo

Seja o primeiro a comentar

Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.

0/450