GPU NVIDIA H100: guía de arquitectura, rendimiento e implementación en la nube

GPU NVIDIA H100: guía de arquitectura, rendimiento e implementación en la nube

La GPU NVIDIA H100 es un acelerador para centros de datos de la generación Hopper, diseñado para el entrenamiento de IA, la inferencia de alto rendimiento y la computación técnica. Su valor en la nube no proviene únicamente de una cifra destacada de FLOPS. La pregunta útil es si su capacidad de memoria, ancho de banda de memoria, compatibilidad con precisiones, interconexión de GPU a GPU y modelo operativo se ajustan al modelo y servicio que necesita ejecutar.

Para un desarrollador de IA o un ingeniero de infraestructura de ML, una decisión sobre la GPU NVIDIA H100 tiene tres niveles:

1. ¿El modelo, la caché KV, el estado del optimizador y el espacio de trabajo caben con un margen seguro?
2. ¿La carga de trabajo necesita una GPU, un nodo multi-GPU estrechamente conectado o un clúster distribuido?
3. ¿La implementación puede cumplir un objetivo de latencia, rendimiento, fiabilidad y coste después de instrumentarse en producción?

Esta guía traduce la hoja de especificaciones en esas decisiones de implementación. Se centra en hechos actuales y verificables sobre el hardware y en un proceso repetible de despliegue en la nube, no en una instantánea no verificada de precios de proveedores.

Para qué está diseñada la GPU NVIDIA H100

La GPU NVIDIA H100 se basa en la arquitectura NVIDIA Hopper. Hopper introdujo Tensor Cores de cuarta generación, un Transformer Engine compatible con FP8, memoria HBM3 en la configuración H100 SXM, NVLink y capacidad Multi-Instance GPU (MIG). Estas características importan por motivos distintos:

• Los Tensor Cores y el Transformer Engine afectan a las rutas de precisión mixta que puede utilizar un framework de IA o un motor de inferencia.
• La capacidad y el ancho de banda de HBM influyen en si los pesos del modelo, las activaciones y la caché KV caben, y en la rapidez con que las cargas de trabajo limitadas por memoria pueden mover datos.
• NVLink y la topología del sistema afectan al coste de comunicación cuando una carga de trabajo abarca varias GPU.
• MIG puede particionar una GPU compatible en instancias aisladas para cargas de trabajo más pequeñas y compatibles.

La familia de productos H100 no es una única configuración de nube. Antes de comparar ofertas, determine si está evaluando un sistema H100 SXM, una configuración H100 NVL u otra oferta H100 basada en PCIe. El factor de forma y la interconexión pueden cambiar el paralelismo, la planificación y el plan de benchmarking adecuados.

Arquitectura de la GPU NVIDIA H100: datos relevantes para la implementación

NVIDIA indica que la H100 SXM tiene 80 GB de memoria HBM3, 3,35 TB/s de ancho de banda de memoria de GPU, hasta 900 GB/s de ancho de banda NVLink y hasta siete instancias MIG de 10 GB. NVIDIA enumera por separado la H100 NVL con 94 GB de memoria, 3,9 TB/s de ancho de banda, hasta 600 GB/s de ancho de banda NVLink y un factor de forma PCIe de doble ranura refrigerado por aire. Considere estos datos como características de configuración del producto, no como una promesa de que cada oferta en la nube exponga la misma topología o capacidad utilizable. Confirme la configuración exacta de la instancia antes de realizar el despliegue. Especificaciones del producto NVIDIA H100

Los detalles de la arquitectura Hopper de NVIDIA explican por qué estos componentes van juntos: los Tensor Cores de cuarta generación incorporan FP8 y el Transformer Engine, mientras que H100 SXM combina HBM3 con más de 3 TB/s de ancho de banda de memoria. Resumen de la arquitectura NVIDIA Hopper

No use el rendimiento de cálculo máximo como estimación de implementación

El rendimiento máximo de los Tensor Cores es útil para comparar hardware, pero no es un SLA de aplicación. En producción, el rendimiento medido depende de la arquitectura del modelo, la precisión, el tamaño de lote, la combinación de longitudes de secuencia, la selección de kernels, el almacenamiento en caché, la carga de datos, la sobrecarga de comunicación y los límites de latencia del nivel de servicio.

Para una nueva implementación de GPU NVIDIA H100, defina primero la prueba de aceptación de la carga de trabajo. Para un servicio de LLM, normalmente incluye tiempo hasta el primer token, latencia entre tokens, latencia p50/p95 de extremo a extremo, tokens de salida aceptados por segundo, tiempo en cola, tasa de errores y comprobaciones de calidad. Para el entrenamiento, controle el tiempo por paso, las muestras por segundo, el tiempo de checkpoint, el comportamiento de convergencia y el estado de all-reduce.

Elija la topología H100 antes de elegir el contrato de nube

El mismo acelerador puede implementarse de formas muy diferentes. Empiece por el patrón de comunicación, no por el nombre de la GPU.

Una GPU NVIDIA H100 en una VM con una sola GPU puede ser un primer paso de producción sensato. Una implementación H100 con varias GPU debe tratarse como un sistema: la topología del host, la interconexión, la red, la CPU, el almacenamiento, la pila de software y el planificador contribuyen al resultado. Para una visión más amplia del sistema de hardware, consulte la guía de implementación de servidores GPU de Flatkey.

Un flujo de trabajo práctico para la implementación en la nube

1. Redacte un resumen de la carga de trabajo antes del aprovisionamiento

Registre los datos que hacen que una prueba de rendimiento sea reproducible:

• Nombre del modelo, revisión, número de parámetros y precisión.
• Longitud de contexto objetivo, combinación de entrada/salida y perfil de concurrencia.
• Objetivo de entrenamiento, ajuste fino, inferencia por lotes o servicio en línea.
• SLO de latencia, objetivo de rendimiento y umbral de calidad o precisión.
• Región requerida, límite de datos, almacenamiento persistente, exposición de red y objetivo de tiempo de recuperación.

Para la inferencia de LLM, dimensione la memoria como un presupuesto en lugar de como un cálculo basado únicamente en los pesos del modelo:

memoria de GPU necesaria = pesos del modelo + caché KV en la concurrencia objetivo
                         + espacio de trabajo de tiempo de ejecución + búferes de comunicación
                         + margen de seguridad para fragmentación y variación en el despliegue

El valor adecuado proviene de una prueba de carga representativa. Un modelo que se inicia correctamente aún puede no alcanzar su objetivo de concurrencia o de contexto largo cuando crece la caché KV.

2. Inspeccione la instancia, no solo la etiqueta del acelerador

Antes de reservar capacidad, registre los detalles exactos de la oferta en la nube:

• Variante de H100, cantidad de GPU y VRAM por dispositivo.
• Topología de GPU a GPU y si la oferta expone NVLink o un nodo respaldado por NVSwitch.
• Núcleos de CPU, RAM del host, NVMe local e interfaz de red.
• Compatibilidad de controladores, CUDA, tiempo de ejecución de contenedores y framework.
• Si la capacidad es dedicada, interrumpible o está sujeta a una política de recuperación.
• Cómo funcionan las instantáneas, los puntos de control, las redes privadas y la exportación de métricas.

Utilice una nueva configuración de GPU como una hipótesis, no como un diseño terminado. Ejecute una pequeña prueba previa antes de migrar tráfico o comprometerse con una reserva a largo plazo.

3. Valide el hardware y el tejido

Como mínimo, verifique que el sistema operativo, el tiempo de ejecución de contenedores y la carga de trabajo puedan ver los dispositivos esperados. En un nodo con varias GPU, registre la topología y pruebe la ruta colectiva que utilizará su motor de entrenamiento o servicio.

nvidia-smi
nvidia-smi topo -m

# Ejecute dentro de la misma imagen compatible con CUDA que utilizará su carga de trabajo.
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv

Para un trabajo multinodo, amplíe la prueba de aceptación a la ruta de red real, la colocación de rangos, las lecturas de almacenamiento, las escrituras de puntos de control y el comportamiento de reinicio. Un inventario de GPU en buen estado por sí solo no demuestra que un trabajo distribuido pueda mantener el rendimiento.

4. Use Kubernetes solo cuando resuelva un problema operativo

Kubernetes es útil cuando varios equipos o servicios necesitan planificación, cuotas, aislamiento, despliegues repetibles u observabilidad en todo el clúster. No es obligatorio para una VM cuidadosamente gestionada.

Para implementaciones de Kubernetes, GPU Operator de NVIDIA automatiza el controlador NVIDIA, Container Toolkit, el complemento de dispositivos, GPU Feature Discovery, la supervisión basada en DCGM y otros componentes de GPU relacionados. Su instalación predeterminada también despliega un MIG Manager en los trabajadores de GPU. Revise la matriz de compatibilidad actual y los requisitos previos de instalación antes de instalarlo; las ofertas de Kubernetes gestionado pueden proporcionar ya parte de la pila. Documentación de NVIDIA GPU Operator Guía de instalación

Una solicitud mínima de dispositivo es intencionadamente sencilla:

resources:
  limits:
    nvidia.com/gpu: 1

Esa solicitud es solo el comienzo. Agregue una política de selección de nodos, tolerancias, una cuota de recursos, comprobaciones de compatibilidad de imágenes, comportamiento de volúmenes persistentes y métricas de nivel de servicio antes de considerar la carga de trabajo lista para producción. Si está creando operaciones multinodo, la guía de clústeres GPU de Kubernetes de Flatkey cubre los controles a nivel de plataforma que debe planificar.

5. Seleccione deliberadamente una pila de inferencia o entrenamiento

El hardware H100 no elige por usted el tiempo de ejecución adecuado. Use una pila de servicio que admita su modelo y sus restricciones operativas, y luego valídela con tráfico representativo de producción. TensorRT-LLM, por ejemplo, proporciona API y tiempos de ejecución para inferencia de LLM optimizada en GPU NVIDIA; su rendimiento aún debe medirse con su modelo, precisión, política de lotes y objetivo de latencia. Documentación de TensorRT-LLM

Para un despliegue de inferencia en producción:

1. Comience con una réplica y un rastro de solicitudes representativo.
2. Mida la calidad, la latencia, el rendimiento, la memoria, las colas y el comportamiento ante errores.
3. Cambie un factor a la vez: precisión, lote máximo, límite de contexto, paralelismo de tensores o número de réplicas.
4. Repita la misma prueba después de un cambio de controlador, tiempo de ejecución, modelo o topología.
5. Desplace el tráfico gradualmente y mantenga una ruta de reversión con el último artefacto conocido como bueno.

6. Instrumente la GPU NVIDIA H100 como parte del servicio

Supervise tanto las señales de hardware como las de la aplicación. Una GPU NVIDIA H100 totalmente utilizada puede indicar lotes saludables, una ruta de solicitudes bloqueada o un cuello de botella en otra parte; la interpretación requiere las métricas del servicio junto a ella.

Defina alertas en torno a un síntoma visible para el usuario. Por ejemplo, alerte ante una degradación sostenida del tiempo p95 hasta el primer token más una cola creciente, y luego use la telemetría de GPU y del tejido para investigar la causa. Una alerta de utilización sin procesar rara vez es suficiente.

Optimización del rendimiento: un orden seguro de operaciones

Cuando un servicio con GPU NVIDIA H100 no cumple un objetivo, optimice en esta secuencia:

1. Confirme el objetivo. ¿El fallo es de latencia, rendimiento, coste por tarea completada, calidad o fiabilidad?
2. Verifique la línea base. Vuelva a ejecutar el mismo rastro con el mismo modelo, imagen, controlador, topología y concurrencia.
3. Encuentre el recurso limitante. Puede ser VRAM, ancho de banda de memoria, cómputo, tokenización de CPU, comunicación PCIe/NVLink, red, almacenamiento o una política de colas.
4. Cambie una variable. Algunos ejemplos incluyen la política de lotes, el contexto máximo, el grado de paralelismo de tensores, la precisión, el número de réplicas o la configuración de caché.
5. Vuelva a ejecutar las validaciones funcionales y de calidad. Una salida más rápida no es una mejora si aumenta los tiempos de espera o cambia la calidad del modelo más allá del rango aceptado.
6. Documente el rango operativo. Registre la configuración, el resultado medido y las condiciones que hicieron válido el resultado.

Este enfoque evita un error común: pasar directamente a más GPU cuando el verdadero cuello de botella es una política de contexto sobredimensionada, una ruta de solicitudes limitada por CPU o una mala división del tráfico.

Control de costes sin una comparación frágil de precios por hora

Los precios, la disponibilidad y las condiciones de facturación de H100 en la nube varían según el proveedor, la región, el compromiso y el tipo de capacidad. En lugar de utilizar una tabla de tarifas desactualizada como regla de decisión, compare el trabajo completado:

coste por resultado exitoso =
  (tiempo de instancia de GPU + almacenamiento + red + gastos generales de operaciones)
  / resultados exitosos en la misma ventana de medición

Para un servicio de inferencia, defina «resultado exitoso» con precisión: tokens aceptados, solicitudes completadas, imágenes generadas, documentos evaluados u otra salida que cumpla sus criterios de calidad y SLO. Incluya el tiempo pagado pero inactivo y los reintentos. Luego compare ese número con una alternativa de API de modelo gestionado cuando el producto no necesite control a nivel de GPU.

Use la guía de costes por millón de tokens de LLM autoalojados de Flatkey para obtener un modelo de costes reproducible, y la guía de nube de GPU frente a API de modelo para determinar el límite de decisión entre la propiedad de la infraestructura y el acceso al modelo.

Lista de verificación para el despliegue de GPU NVIDIA H100

Antes de declarar que el servicio está listo, verifique todo lo siguiente:

• [ ] Se documentan la configuración exacta de la H100, la VRAM, la topología, la CPU/RAM, el almacenamiento y la red.
• [ ] El presupuesto de memoria del modelo incluye pesos, caché KV, espacio de trabajo de ejecución, búferes de comunicación y margen.
• [ ] Se ha probado la compatibilidad del controlador, CUDA, el framework y la imagen de contenedor en la configuración objetivo.
• [ ] Se superan las pruebas de GPU única y, cuando corresponde, de topología multi-GPU y operaciones colectivas.
• [ ] Una traza representativa de producción cumple los objetivos de latencia, rendimiento, calidad y errores.
• [ ] Las señales de GPU, tejido de interconexión, tiempo de ejecución, experiencia de usuario y coste son visibles en una única vista operativa.
• [ ] Se definen un despliegue gradual, un artefacto de reversión, una estrategia de puntos de control y un responsable de incidentes.
• [ ] El coste del trabajo completado se compara con la alternativa más creíble, no solo con el precio horario de la GPU.

Cómo encaja la H100 en la selección de una GPU para IA

La GPU NVIDIA H100 encaja bien cuando una carga de trabajo se beneficia de las funciones de Tensor Core de la generación Hopper, del alto ancho de banda de HBM, de la topología multi-GPU o de un despliegue que requiere control sobre el tiempo de ejecución y el flujo de datos. No es automáticamente la opción adecuada para todas las tareas de IA. Un acelerador más pequeño, una GPU más reciente centrada en la memoria o una API de modelos gestionada pueden ser más apropiados cuando el modelo es modesto, la demanda es intermitente, el equipo no puede operar un servicio de GPU o una optimización específica de hardware no cambia el resultado del producto.

Para decisiones relacionadas, compare H100 vs. A100 al evaluar la generación anterior, y lea la guía de despliegue de la GPU H200 cuando una mayor capacidad HBM3e pueda cambiar la idoneidad para inferencia.

Para una comparación lado a lado de la H100 y su variante con más memoria, lea H200 vs H100 (2026).

Preguntas frecuentes

¿Para qué se utiliza la GPU NVIDIA H100?

La GPU NVIDIA H100 se utiliza para entrenamiento de IA, ajuste fino, inferencia de LLM, computación científica y otras cargas de trabajo aceleradas. La configuración adecuada depende de la huella de memoria del modelo, el patrón de comunicación, la precisión, la concurrencia y los requisitos operativos.

¿Es diferente la H100 SXM de una oferta H100 PCIe o H100 NVL?

Sí. El factor de forma, la configuración de memoria, el ancho de banda NVLink, el límite de potencia, la refrigeración y la topología del sistema pueden diferir. Lea la especificación exacta de la oferta en la nube en lugar de considerar «H100» como una descripción completa de la configuración.

¿Cuánta memoria GPU tiene una H100?

NVIDIA indica que la H100 SXM cuenta con 80 GB de memoria HBM3 y la H100 NVL con 94 GB. El cálculo de capacidad adecuado también debe incluir el espacio de trabajo de ejecución, la caché KV, la memoria de activación o entrenamiento, los búferes de comunicación y un margen de seguridad. Especificaciones de NVIDIA H100

¿Necesito Kubernetes para ejecutar una carga de trabajo H100 en la nube?

No. Una VM puede ser el punto de partida adecuado para una única carga de trabajo con una responsabilidad clara. Kubernetes resulta más útil cuando necesita planificación, multi-tenencia, cuotas, despliegue repetible u observabilidad compartida entre trabajadores de GPU.

¿Debo elegir H100 o H200 para la inferencia de LLM?

Comience por los requisitos de memoria y concurrencia. Si la longitud de contexto objetivo y la caché KV necesitan más margen de memoria, la H200 puede encajar mejor; si la carga de trabajo cabe holgadamente y su prueba de rendimiento cumple el SLO, un despliegue con H100 puede ser suficiente. Compare el sistema completo y el coste del trabajo completado en lugar de elegir basándose únicamente en el nombre de una familia.

Conclusión

Una GPU NVIDIA H100 solo resulta útil en producción cuando su arquitectura se vincula a una carga de trabajo medida y a un modelo operativo fiable. Verifique la configuración exacta en la nube, el presupuesto de memoria del modelo, la topología, la compatibilidad del tiempo de ejecución y las métricas de aceptación antes de escalar. Después, optimice el cuello de botella real y compare el coste por trabajo completado con éxito, no por la etiqueta de la GPU ni por una tarifa horaria aislada.

Si aún está seleccionando la capa de infraestructura, utilice la guía de selección de GPU para IA de Flatkey para comparar la idoneidad de las cargas de trabajo entre familias de GPU y modelos de despliegue.