Benchmark multi-GPU: B200 vs H200 vs H100 vs MI300X

Durante más de dos décadas, optimizar el rendimiento computacional ha sido un pilar de mi trabajo. Evaluamos la B200 y H200 de NVIDIA, la H100 y la MI300X de AMD para evaluar qué tan bien escalan en la inference de Large Language Model (LLM). Utilizando el framework vLLM con el model meta-llama/Llama-3.1-8B-Instruct, ejecutamos pruebas en 1, 2, 4 y 8 GPUs.

Analizamos el rendimiento y la eficiencia de escalado para ilustrar cómo cada arquitectura GPU maneja cargas de trabajo paralelizadas e intensivas en cómputo.

Resultados del benchmark multi-GPU

Rendimiento total frente a número de GPU

• Rendimiento total (tokens/segundo): Esta métrica representa la potencia de procesamiento bruta de todo el sistema multi-GPU. Mide el número total de tokens de entrada y salida procesados por segundo, lo que la convierte en el indicador más importante del rendimiento máximo bajo una carga de trabajo offline saturada.

Para entender cómo calculamos la puntuación, consulte nuestra metodología de benchmark multi-GPU.

Información clave sobre el rendimiento:

Análisis de rendimiento: La H200 de NVIDIA ofrece el mayor rendimiento en todas las configuraciones probadas, con mejoras de rendimiento del 9-10 % respecto a la H100. El sistema alcanza una eficiencia de escalado del 99,8 % con configuraciones de doble GPU, lo que indica una utilización de recursos casi óptima.

AMD MI300X: características de rendimiento: La MI300X de AMD logra un rendimiento de una sola GPU de 18.752 tokens por segundo, lo que representa aproximadamente el 74 % del rendimiento de la H200. El sistema mantiene eficiencias de escalado del 95 % y del 81 % para configuraciones de dos GPU y cuatro GPU, respectivamente.

Latencia promedio de inference frente a número de GPU

• Latencia promedio de inference (milisegundos): Esta métrica mide el tiempo promedio que se tarda en procesar una única solicitud de principio a fin. Una latencia menor se traduce en una experiencia más rápida y con mayor capacidad de respuesta para los usuarios finales.

Información clave sobre el rendimiento:

Análisis de rendimiento de latencia: La B200 de NVIDIA muestra las mediciones de latencia más bajas en todas las configuraciones evaluadas, alcanzando 2.40ms con implementaciones de ocho GPU. Estas características de rendimiento la posicionan para aplicaciones que requieren tiempos de respuesta mínimos, como sistemas interactivos en tiempo real donde una latencia inferior a 3ms es un requisito de diseño.

Observaciones de eficiencia de escalado: El análisis revela rendimientos decrecientes en la reducción de latencia a medida que aumenta el número de GPU en todas las plataformas. La mayor reducción de latencia ocurre durante la transición de configuraciones de una a dos GPU (aproximadamente 50 % en todas las plataformas). Las configuraciones con más de 4 GPU muestran mejoras de latencia progresivamente menores.

Análisis comparativo de la H200 y la H100: La H200 demuestra una latencia entre un 5 y un 8 % menor que la H100 en todas las escalas, con una diferencia absoluta que disminuye a mayor número de GPU (2.81ms frente a 2.86ms con ocho GPU, una diferencia de 0.05ms). Esta diferencia de rendimiento marginal, comparada con la diferencia de precio del 41 %, sugiere que la H100 puede ofrecer características de costo-rendimiento más favorables para implementaciones sensibles a la latencia.

AMD MI300X: características de latencia: La MI300X demuestra valores de latencia entre 37 y 75 % más altos que la H200 en las configuraciones probadas, lo que puede atribuirse a las diferencias actuales en la madurez del software stack entre las implementaciones vLLM ROCm y CUDA. A escala de ocho GPU, la MI300X logra una latencia de 4.20ms, que se mantiene dentro de parámetros aceptables para numerosas aplicaciones de producción a pesar de la diferencia de rendimiento respecto a las plataformas NVIDIA.

Rendimiento frente a precio: un análisis de costo-eficiencia

Aunque las métricas de rendimiento bruto son cruciales, la decisión final para cualquier organización depende de la costo-eficiencia. Para analizar el retorno de la inversión (ROI) de cada plataforma, hemos comparado nuestros resultados de rendimiento con los precios por hora bajo demanda de RunPod en el momento de las pruebas. Esto nos permite calcular una puntuación de “rendimiento por dólar”, que revela qué configuración ofrece la mayor potencia computacional al menor costo.

Nota: Toda la información de precios refleja las tarifas bajo demanda disponibles en la plataforma RunPod Cloud en el momento del benchmark (septiembre de 2025) y está sujeta a cambios. Los costes se presentan para análisis comparativo y no incluyen tarifas de almacenamiento ni de red.

Cómo calculamos el rendimiento por dólar

Para generar este gráfico, procesamos nuestros datos brutos de rendimiento comparándolos con los costes por hora. La fórmula de cálculo es:

• Preparación de los datos: Para cada punto de datos de nuestra tabla de resultados, recuperamos el costo por hora correspondiente para la configuración de GPU específica (por ejemplo, 4x H100 cuesta $10,76).
• Cálculo: Luego aplicamos la fórmula para calcular el valor de rendimiento_por_dólar. Por ejemplo, la H100 con 1x GPU entregó 23.243 tokens/s a un costo de $2,69/hora, lo que resultó en una puntuación de 8.642 tokens/s por dólar.

Esta puntuación de eficiencia proporciona una herramienta de toma de decisiones, llevando la conversación de “¿cuál es más rápida?” a “¿cuál es la inversión más inteligente para nuestra carga de trabajo?”.

¿Qué es el escalado multi-GPU?

El escalado multi-GPU se refiere a la capacidad de un sistema de aumentar su rendimiento distribuyendo una única tarea grande entre múltiples GPU. Para la inference de LLM, esto puede lograrse mediante paralelismo de datos, donde copias independientes del model se ejecutan en cada GPU, con un balanceador de carga que distribuye las solicitudes entrantes entre todas las instancias.

Idealmente, usar dos GPU ofrecería el doble de rendimiento que una sola GPU (aceleración de 2x). Sin embargo, en realidad, las ganancias de rendimiento están limitadas por CPU y cuellos de botella del sistema, el tiempo que el sistema host dedica a gestionar múltiples procesos concurrentes, las limitaciones de ancho de banda de memoria y la contención de recursos. Nuestro benchmark mide con qué eficiencia gestiona cada plataforma estas limitaciones a nivel de sistema, un factor crítico para construir servidores de inference de IA rentables y de alto rendimiento para models pequeños y medianos.

¿Cuáles son los desafíos en las pruebas de escalado multi-GPU?

Realizar benchmarks de sistemas multi-GPU plantea desafíos únicos que pueden afectar significativamente el rendimiento.

Sobrecarga de comunicación y cuellos de botella de interconexión

Cuando un model se divide entre varias GPU, la interconexión, como NVLink de NVIDIA o Infinity Fabric de AMD, se convierte en un cuello de botella de rendimiento crítico. La eficiencia de la comunicación entre GPU impacta directamente en el escalado. Si el tiempo dedicado a esperar datos de otra GPU supera el tiempo ahorrado al paralelizar el cómputo, las ganancias de rendimiento disminuirán. Este efecto es particularmente pronunciado en models que no son lo suficientemente grandes como para saturar por completo la capacidad computacional de cada GPU.

Madurez del ecosistema de software

El rendimiento no depende únicamente del hardware. El software stack, incluidos los controladores, las bibliotecas de comunicación (como NCCL para NVIDIA y RCCL para AMD) y el motor de inference (vLLM), juega un papel monumental. Descubrimos que el rendimiento de una plataforma está profundamente ligado a la madurez de su soporte de software. Un ecosistema establecido como CUDA de NVIDIA suele beneficiarse de años de fine-tuning y optimización, lo que puede conducir a una eficiencia de escalado superior en comparación con integraciones más nuevas como ROCm de AMD, incluso en hardware potente.

Optimizaciones específicas de la plataforma

Como revelaron nuestras pruebas, lograr un rendimiento óptimo a menudo requiere configuraciones específicas de la plataforma. Usar un enfoque genérico de “talla única” puede dar lugar a un rendimiento engañosamente bajo. La imagen Docker correcta, las variables de entorno (por ejemplo, habilitar kernels personalizados de AMD) e incluso los tipos de datos del model (por ejemplo, bfloat16 para Blackwell) son esenciales para liberar el verdadero potencial del hardware. Esto hace que las comparaciones justas “de manzana a manzana” sean un desafío técnico significativo.

Metodología del benchmark multi-GPU

Probamos las últimas arquitecturas de GPU de alto rendimiento de NVIDIA y AMD para evaluar sus capacidades de escalado. Nuestro benchmark midió el rendimiento de configuraciones de una y múltiples GPU (1x, 2x, 4x, 8x) utilizando el model estándar meta-llama/Llama-3.1-8B-Instruct¹ y el motor de inference vLLM².

Entorno de prueba y proceso

• Plataforma: Todos los benchmarks se ejecutaron en la nube RunPod para garantizar un acceso constante al hardware.
• Motor de inference: Se utilizó vLLM (vllm bench throughput tool) como motor estandarizado.
• Model: meta-llama/Llama-3.1-8B-Instruct.
• Dataset: dataset ShareGPT Vicuna (25.000 prompts) para simular una carga de trabajo conversacional.
• Estrategia: Paralelismo de datos; cada prueba multi-GPU ejecutó una instancia independiente de vLLM en cada GPU. La carga total de prompts se distribuyó uniformemente entre las instancias, que se ejecutaron simultáneamente para simular un entorno de producción balanceado. Este enfoque elimina la comunicación entre GPU (NVLink/PCIe) como cuello de botella, desplazando los limitadores de rendimiento al sistema host (CPU, RAM).
• Automatización: Se utilizaron scripts de Bash personalizados para automatizar la configuración del entorno, la ejecución de las pruebas, la monitorización de recursos (nvidia-smi, rocm-smi) y la agregación de resultados.

Configuraciones específicas de la plataforma

Lograr un rendimiento óptimo requirió configuraciones a medida para cada arquitectura.

NVIDIA plataformas (H100, H200, B200)

• Imagen base: runpod/pytorch:2.8.0-py3.11-cuda12.8.1.
• Instalación de vLLM:
  • H100/H200 (Hopper): Instalación estándar mediante pip install vllm.
  • B200 (Blackwell): vLLM se compiló desde el código fuente (pip install -e .) para habilitar el soporte nativo de la nueva arquitectura, resolviendo errores de “no kernel image”.
• Parámetros clave:

• Variable de entorno crítica:

AMD plataforma (MI300X)

• Imagen base: rocm/vllm:rocm6.4.1_vllm_0.10.1_20250909
• Instalación de vLLM: No fue necesaria ninguna instalación, ya que la versión optimizada estaba incluida en la imagen.
• Parámetros clave y optimizaciones: Un ajuste exhaustivo identificó los siguientes ajustes no predeterminados como críticos para lograr el máximo rendimiento:

• AMD: variables de entorno específicas:

• Visibilidad de dispositivos: Se utilizó ROCR_VISIBLE_DEVICES en lugar del equivalente de CUDA para asignar instancias a GPU específicas.

Fases de ejecución del benchmark

Cada ejecución de benchmark siguió un protocolo de ejecución de tres fases para garantizar resultados precisos y reproducibles:

Fase 1: Calentamiento

Antes de cada prueba de configuración multi-GPU, realizamos una fase de calentamiento dedicada para eliminar los efectos de arranque en frío:

• Duración: 100 prompts procesados en la GPU 0
• Propósito: Carga del model, inicialización de la caché KV y compilación de kernels CUDA/ROCm
• Salida: Descartada (no incluida en las mediciones)
• Comportamiento específico de la plataforma:
  • NVIDIA (CUDA): Compilación de kernels y optimización de grafos CUDA (~30-60 segundos)
  • AMD (ROCm): Compilación de kernels y ajuste opcional de TunableOp (varía según la configuración de PYTORCH_TUNABLEOP_ENABLED)

Fase 2: Inicialización de la monitorización de GPU

De forma concurrente con la ejecución del benchmark, lanzamos procesos de monitorización dedicados para cada GPU:

• Frecuencia de muestreo: intervalos de 1 segundo
• Métricas recopiladas: utilización de la GPU, uso de memoria, temperatura, consumo de energía
• Herramientas: nvidia-smi (NVIDIA) o rocm-smi (AMD)
• Salida: registros CSV para posanálisis

Fase 3: Ejecución paralela del benchmark

Tras completar el calentamiento, todas las instancias de GPU se lanzaron simultáneamente:

• Cada GPU procesó una parte igual de los 25.000 prompts totales
• Todas las instancias comenzaron en el mismo segundo para simular el balanceo de carga en producción
• Rendimiento total medido como la suma de las salidas de todas las GPU
• Tiempo de ejecución medido desde el inicio de la primera instancia hasta la finalización de la última

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Impacto en el rendimiento en el mundo real a partir de las pruebas

Nuestras pruebas revelaron que errores de configuración menores pueden dar lugar a resultados de rendimiento significativos y engañosos. La siguiente tabla ilustra el impacto de las configuraciones incorrectas específicas de la plataforma:

Lecturas adicionales

Explore otras investigaciones sobre hardware de IA, como:

• Los 30 principales proveedores de GPU en la nube y sus GPU
• Benchmark de concurrencia de GPU
• Los más de 25 fabricantes de chips de IA: NVIDIA y sus competidores

Cita este benchmark

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

@misc{dogan2026,
  author = {Dogan, Sedat and Sarı, Ekrem},
  title  = {{Benchmark multi-GPU: B200 vs H200 vs H100 vs MI300X}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/multi-gpu}},
  note   = {AIMultiple. Recuperado el 21 de septiembre de 2026}
}

Registro de cambios

2 actualizaciones

2025

1. 8 de oct

   Actualizado el conjunto de datos en la sección de resultados del benchmark multi-GPU.

2. 6 de oct

   Se eliminó la métrica 'Solicitudes por segundo' de la sección 'Rendimiento total vs. recuento de GPU'.

Enlaces de referencia

1.

meta-llama/Llama-3.1-8B-Instruct · Hugging Face

2.

vLLM easy, fast, and cheap LLM serving for everyone

Sedat Dogan

CTO

Síguenos

Sedat es un líder en tecnología y seguridad de la información con 20 años de experiencia en desarrollo de software, infraestructura de redes y ciberseguridad. Sedat:
- Tiene 20 años de experiencia como hacker de sombrero blanco y gurú del desarrollo, con amplia experiencia en lenguajes de programación y arquitecturas de servidores.
- Es asesor de la junta directiva en un capital de riesgo que invierte en empresas tecnológicas en etapas tempranas y en Ödeal, una plataforma regional de pagos digitales que atiende a 125.000 comercios.
- Ha dirigido la infraestructura tecnológica y la ciberseguridad de siete elecciones nacionales y ha sido reconocido en el Salón de la Fama de la ciberseguridad por líderes tecnológicos globales, incluido Twitter.

Ver perfil completo

Investigado por

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA y científico de datos en AIMultiple. Diseña y ejecuta benchmarks prácticos para sistemas de IA y LLM.

Ver perfil completo

Sé el primero en comentar

Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario