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

Durante más de dos décadas, optimizar el rendimiento computacional ha sido una piedra angular de mi trabajo. Evaluamos las GPU NVIDIA B200, H200, H100 y la MI300X de AMD para medir qué tan bien escalan para la inferencia 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 throughput y la eficiencia de escalado para ilustrar cómo cada arquitectura de GPU maneja cargas de trabajo paralelizadas e intensivas en cómputo.

Resultados del benchmark Multi-GPU

Throughput total frente al número de GPU

• Throughput 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 saturada y sin conexión.

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

Información clave de rendimiento:

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

Características de rendimiento de la MI300X de AMD: La MI300X de AMD logra un throughput de una 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 81 % para configuraciones de dos GPU y cuatro GPU, respectivamente.

Latencia media de inferencia frente al número de GPU

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

Información clave de rendimiento:

Análisis de rendimiento de latencia: El NVIDIA B200 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 lo 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 sobre la eficiencia de escalado: El análisis revela rendimientos decrecientes en la reducción de la latencia a medida que aumenta el número de GPU en todas las plataformas. La mayor reducción de latencia se produce durante la transición de configuraciones de una a dos GPU (aproximadamente 50 % en todas las plataformas). Las configuraciones con más de 4 GPUs muestran mejoras de latencia progresivamente menores.

Análisis comparativo entre la H200 y la H100: La H200 muestra una latencia un 5-8 % menor que la H100 en todas las escalas, con la diferencia absoluta disminuyendo a mayor número de GPU (2.81ms frente a 2.86ms con ocho GPUs, una diferencia de 0.05ms). Esta diferencia marginal de rendimiento, 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.

Características de latencia de la MI300X de AMD: La MI300X muestra valores de latencia un 37-75 % más altos que la H200 en las configuraciones probadas, lo que puede atribuirse a las diferencias actuales en la madurez de la pila de software entre las implementaciones vLLM ROCm y CUDA. A una escala de ocho GPU, la MI300X alcanza 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 de NVIDIA.

Rendimiento vs. precio: un análisis de costo-eficiencia

Si bien las métricas de rendimiento bruto son cruciales, la decisión final para cualquier organización depende de la eficiencia de costes. Para analizar el retorno de la inversión (ROI) de cada plataforma, hemos mapeado nuestros resultados de throughput 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 coste.

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 un análisis comparativo y no incluyen tarifas de almacenamiento ni de red.

Cómo calculamos el throughput por dólar

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

• Preparación de datos: Para cada punto de datos en nuestra tabla de resultados, recuperamos el coste por hora correspondiente a la configuración específica de GPU (p. ej., 4x H100 cuesta $10,76).
• Cálculo: Después aplicamos la fórmula para calcular el valor throughput_per_dollar. Por ejemplo, la H100 con 1x GPU entregó 23.243 tokens/s a un coste 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, moviendo la conversación de “¿cuál es más rápido?” 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 GPUs. Para la inferencia 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 GPUs ofrecería el doble de rendimiento que una sola GPU (aceleración de 2x). Sin embargo, en la realidad, las ganancias de rendimiento están limitadas por los cuellos de botella de la CPU y del sistema, el tiempo que el sistema anfitrión dedica a gestionar múltiples procesos concurrentes, las restricciones de ancho de banda de memoria y la contención de recursos. Nuestro benchmark mide con qué eficiencia gestiona cada plataforma estas restricciones a nivel de sistema, un factor crítico para construir servidores de inferencia de IA rentables y de alto rendimiento para models de tamaño pequeño a mediano.

¿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 en la interconexión

Cuando un model se divide entre GPUs, la interconexión, como NVLink de NVIDIA o Infinity Fabric de AMD, se convierte en un cuello de botella crítico de rendimiento. La eficiencia de la comunicación entre GPUs afecta directamente al 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 es únicamente una función del hardware. La pila de software, incluidos los controladores, las bibliotecas de comunicación (como NCCL para NVIDIA y RCCL para AMD) y el motor de inferencia (vLLM), desempeña 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 a menudo se beneficia 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. Utilizar un enfoque genérico de “talla única” puede conducir a un rendimiento engañosamente bajo. La imagen Docker correcta, las variables de entorno (p. ej., habilitar kernels personalizados de AMD) e incluso los tipos de datos del model (p. ej., bfloat16 para Blackwell) son esenciales para liberar el verdadero potencial del hardware. Esto hace que las comparaciones justas “manzana a manzana” sean un desafío técnico importante.

Metodología de 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¹ model y el motor de inferencia vLLM².

Entorno de pruebas y proceso

• Plataforma: Todos los benchmarks se ejecutaron en RunPod Cloud para garantizar un acceso constante al hardware.
• Motor de inferencia: Se utilizó vLLM (herramienta vllm bench throughput) 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 vLLM independiente 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 con balanceo de carga. Este enfoque elimina la comunicación entre GPUs (NVLink/PCIe) como cuello de botella, desplazando los limitadores de rendimiento al sistema anfitrión (CPU, RAM).
• Automatización: Se utilizaron scripts Bash personalizados para automatizar la configuración del entorno, la ejecución de pruebas, la supervisió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.

Plataformas de NVIDIA (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 los errores de “no kernel image”.
• Parámetros clave:

• Variable de entorno crítica:

Plataforma de AMD (MI300X)

• Imagen base: rocm/vllm:rocm6.4.1_vllm_0.10.1_20250909
• Instalación de vLLM: No se necesitó 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 throughput:

• Variables de entorno específicas de AMD:

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

Fases de ejecución del benchmark

Cada ejecución del 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 supervisión de GPU

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

• Frecuencia de muestreo: intervalos de 1 segundo
• Métricas recopiladas: utilización de GPU, uso de memoria, temperatura, consumo de energía
• Herramientas: nvidia-smi (NVIDIA) o rocm-smi (AMD)
• Salida: registros CSV para el 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 se iniciaron en el mismo segundo para simular el balanceo de carga en producción
• Throughput total se mide como la suma de todas las salidas de GPU
• Tiempo de ejecución medido desde el inicio de la primera instancia hasta la finalización de la última instancia

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 del 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 GPUs
• Benchmark de concurrencia de GPU
• Los 25+ principales 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  = jun,
  howpublished    = {\url{https://aimultiple.com/multi-gpu}},
  note   = {AIMultiple. Recuperado el 30 de junio 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