GPU H200: arquitectura, rendimiento y guía de implementación en la nube
La GPU NVIDIA H200 es un acelerador para centros de datos de la generación Hopper cuya característica definitoria para la implementación es la memoria: 141 GB de HBM3e y 4,8 TB/s de ancho de banda de memoria por GPU. Esto cambia la forma de planificar la inferencia de contexto largo, los lotes grandes y los trabajos de HPC limitados por memoria, pero no hace que la planificación de capacidad ni la validación en la nube sean opcionales.
Esta guía explica qué es la GPU H200, en qué se diferencian H200 SXM y H200 NVL, cuándo encaja en una carga de trabajo y cómo validar una implementación en la nube antes de comprometerse con una flota más grande. Evita deliberadamente instantáneas de precios volátiles de proveedores. Utilice la lista de verificación a continuación con la región, el tipo de máquina, la topología y el contrato exactos que tenga disponibles.
La respuesta breve
Elija una GPU H200 cuando su carga de trabajo esté limitada por la capacidad o el ancho de banda de la memoria de la GPU, y cuando pueda validar el sistema circundante, no solo el acelerador. Para un servidor de modelos con una sola GPU, esto significa demostrar que los pesos del modelo, el espacio de trabajo del tiempo de ejecución y la caché KV caben con margen. Para entrenamiento o servicio con varias GPU, significa demostrar el tejido de interconexión de GPU a GPU y, cuando corresponda, la red entre nodos.
La GPU H200 no es una actualización universal. Si las solicitudes son cortas, los tamaños de lote son bajos o la carga de trabajo está limitada por CPU, almacenamiento o red, su memoria adicional puede no cambiar el resultado que importa. Comience con una descripción de la carga de trabajo y, después, pruebe una traza representativa.
Especificaciones de la GPU H200: qué cambia su plan de implementación
NVIDIA presenta la H200 como una GPU de arquitectura Hopper con 141 GB de memoria HBM3e y 4,8 TB/s de ancho de banda de memoria. Está disponible como H200 SXM y H200 NVL, con las mismas cifras principales de memoria, pero con distintos factores de forma, límites de potencia y opciones de escalado. Las cifras máximas publicadas por NVIDIA para Tensor Core son útiles para comparar configuraciones de productos, pero no son una garantía del rendimiento de la aplicación: las cifras incluyen condiciones de prueba declaradas y supuestos de dispersión. Revise las especificaciones actuales del producto H200 antes de seleccionar una SKU.
| Especificación relevante para la implementación | H200 SXM | H200 NVL | Por qué es importante |
|---|---|---|---|
| Arquitectura | Hopper | Hopper | La compatibilidad de software y las funciones admitidas comienzan por la plataforma, no por el nombre de un modelo. |
| Memoria de GPU | 141 GB HBM3e | 141 GB HBM3e | Más espacio para pesos, caché KV, activaciones y margen de ejecución. |
| Ancho de banda de memoria | 4,8 TB/s | 4,8 TB/s | Importante para cargas de trabajo que mueven repetidamente grandes conjuntos de trabajo a través de la memoria. |
| Factor de forma | SXM | PCIe de doble ranura y refrigeración por aire | Determina qué diseños de servidor y opciones de tejido de interconexión están disponibles. |
| TDP máximo indicado | Hasta 700 W, configurable | Hasta 600 W, configurable | Afecta a las opciones de alimentación del host, refrigeración, rack e instancia en la nube. |
| Interconexión de GPU | NVLink, indicado en 900 GB/s | Puente NVLink de 2 o 4 vías, indicado en 900 GB/s por GPU; PCIe Gen5 | La topología debe comprobarse antes de asumir el rendimiento de las operaciones colectivas con varias GPU. |
| Particionamiento | Hasta siete MIG de 18 GB cada uno | Hasta siete MIG de 16,5 GB cada uno | Permite el uso compartido controlado, pero cambia el modelo de recursos y observabilidad. |
Estas son cifras publicadas por el proveedor, y NVIDIA las etiqueta como preliminares en su página de producto. Trátelas como una referencia de configuración y, después, verifique la SKU de nube exacta y su topología en el entorno donde ejecutará la carga de trabajo.
Por qué HBM3e es importante para la inferencia de LLM
Para servir LLM, la memoria de la GPU se consume por más elementos que los pesos del modelo. Una ecuación útil para una primera estimación de capacidad es:
memoria de GPU requerida = pesos + espacio de trabajo del tiempo de ejecución + caché KV en contexto y concurrencia p95 + margen operativo
La GPU H200 puede ser atractiva cuando la caché KV se convierte en el término limitante: prompts más largos, más secuencias simultáneas o un lote más grande pueden incrementarla. La HBM adicional no elimina el riesgo de falta de memoria, porque la política de caché, el comportamiento del asignador, la cuantización, el paralelismo de modelos y la forma del tráfico siguen siendo importantes. Para implementaciones de contexto largo, combine esta decisión con un plan de descarga y segmentación por niveles de la caché KV en lugar de asumir que más memoria local es la solución completa.
H200 SXM o H200 NVL: elija la topología, no solo la tarjeta
El factor de forma es una decisión de implementación.
- H200 SXM encaja en diseños de sistemas HGX H200 y NVIDIA-Certified con cuatro u ocho GPU. Suele ser el punto de partida adecuado cuando una carga de trabajo necesita un sistema de varias GPU estrechamente acoplado y la aplicación intercambiará datos con frecuencia entre GPU.
- H200 NVL es un diseño PCIe de doble ranura y refrigeración por aire. NVIDIA indica configuraciones de puente NVLink de 2 o 4 vías, mientras que los sistemas de socios y certificados pueden contener hasta ocho GPU. No infiera que cada servidor de ocho GPU proporciona la misma ruta directa de GPU a GPU; inspeccione la topología real y evalúe comparativamente las operaciones colectivas que utiliza su tiempo de ejecución.
- Réplicas independientes no necesitan automáticamente el tejido de interconexión más estrechamente acoplado. Si cada réplica atiende sus propias solicitudes, priorice la capacidad, la disponibilidad, los recursos del host y un límite de programación claro antes de pagar por una topología que la carga de trabajo no utilizará.
| Patrón de carga de trabajo | Pregunta inicial de diseño para H200 | Qué validar primero |
|---|---|---|
| Un servidor de modelos en un acelerador | ¿El presupuesto de memoria p95 encaja con un margen de seguridad? | Estabilidad de la asignación, TTFT, latencia entre tokens y marca de agua de memoria. |
| Un modelo dividido entre GPU | ¿La estrategia de paralelismo de modelo coincide con la topología real de NVLink/NVSwitch? | nvidia-smi topo -m, comportamiento de las operaciones colectivas y latencia de extremo a extremo. |
| Múltiples réplicas de servicio | ¿Las réplicas son independientes o comparten un host o una red con cuello de botella? | Rendimiento por réplica, formación de colas, comportamiento de vecinos ruidosos y E/S del host. |
| Entrenamiento distribuido o ajuste fino | ¿La estructura de interconexión y la red entre nodos se ajustan al patrón colectivo? | Inicio de NCCL, ancho de banda colectivo, E/S de puntos de control y tasa de rezagados. |
| Inferencia multiinquilino | ¿Una GPU completa, una instancia MIG o un recurso con partición temporal es el nivel de aislamiento correcto? | Aislamiento de memoria, aislamiento de fallos, refacturación y observabilidad por inquilino. |
NVIDIA documenta la capacidad MIG de H200, pero no trate los modos de uso compartido de GPU como intercambiables. En Kubernetes, MIG crea instancias de GPU aisladas por hardware, mientras que la partición temporal intercala el trabajo y no proporciona aislamiento de memoria ni de fallos entre réplicas. La guía de uso compartido de GPU Operator explica esta disyuntiva y sus límites de monitorización.
Para una comparación de compra más detallada, consulte H200 vs. H100. Esa comparación es útil para la decisión; esta página es la guía de implementación una vez que H200 es la opción candidata.
Cuándo una GPU H200 es la opción adecuada
Por lo general, vale la pena probar una GPU H200 cuando una de estas restricciones es real en producción:
- Inferencia de LLM limitada por memoria. La longitud de contexto p95 o la concurrencia agota el presupuesto práctico de memoria antes de que el cómputo se use por completo.
- IA o HPC sensible al ancho de banda. El perfilado muestra que el trabajo dedica un tiempo significativo a esperar el movimiento de memoria, en lugar de simplemente saturar las operaciones de Tensor Core.
- Un conjunto de trabajo residente en memoria más grande. Necesita más espacio para un modelo, contexto de recuperación, lote, caché o estructura de datos científicos sin añadir inmediatamente otra GPU.
- Trabajo multi-GPU estrechamente acoplado. Puede utilizar un sistema estilo H200 SXM/HGX y tiene evidencias de que la aplicación se beneficia de su estructura de interconexión.
- Un requisito de particionamiento controlado. Tiene un motivo claro para usar las configuraciones MIG indicadas, además de un programador y un modelo de refacturación que se ajustan a ellas.
No seleccione la GPU H200 basándose únicamente en el número de parámetros del modelo. El número de parámetros dice poco sobre la precisión, el espacio de trabajo del entorno de ejecución, la política de caché KV, el contexto máximo, la forma del lote y el margen de disponibilidad. Tampoco dice nada sobre el cuello de botella de CPU del host, RAM, almacenamiento o red que puede dominar una carga de trabajo en la nube.
Elabore un plan de capacidad para H200 antes de alquilar una GPU en la nube
Utilice este resumen de una página antes de crear una instancia o solicitar un grupo de nodos de clúster.
| Entrada | Registrar | Por qué cambia el resultado |
|---|---|---|
| Modelo y precisión | Revisión exacta del modelo, formato de pesos, cuantización y entorno de ejecución | Determina el límite base de memoria y la pila de software compatible. |
| Distribución de solicitudes | Tokens de prompt p50/p95, tokens de salida, tasa de llegada y concurrencia | Los promedios ocultan las condiciones de caché y formación de colas que incumplen los SLO de latencia. |
| Objetivo de servicio | Tiempo p95 hasta el primer token, latencia p95 entre tokens, presupuesto de errores y objetivo de recuperación | Define si necesita réplicas, capacidad disponible en caliente o una estructura de interconexión más rápida. |
| Plan de paralelismo | Una sola GPU, paralelismo de tensor, paralelismo de canalización, paralelismo de datos o réplicas independientes | Determina si la memoria local, NVLink o la red es la ruta crítica. |
| Superficie de implementación | Una sola VM, grupo de nodos gestionado o clúster de Kubernetes | Cambia la propiedad de los controladores, la programación, la observabilidad y la responsabilidad de las actualizaciones. |
| Ruta de datos | Origen del artefacto del modelo, almacén de puntos de control, índice vectorial, ruta de salida y política de red | Evita que un acelerador rápido espere al almacenamiento o a la red. |
| Unidad financiera | Solicitud aceptada, lote completado, época de trabajo o millón de tokens aceptados | Evita que una cotización por hora de GPU se convierta en la única métrica de coste. |
El valor de este resumen es que hace visible una mala adecuación desde el principio. Por ejemplo, una configuración de una GPU puede fallar debido al contexto p95 y a la presión de caché, incluso cuando una prueba sintética con prompts cortos parece excelente. Por el contrario, una configuración multi-GPU puede rendir por debajo de lo esperado si se divide entre una estructura de interconexión que el entorno de ejecución no utiliza de forma eficiente.
Implementación en la nube: una guía operativa por etapas para GPU H200
1. Confirme la configuración exacta de la nube
Solicite al proveedor o al equipo de plataforma el factor de forma exacto del acelerador, el número de GPU, la asignación de CPU/RAM, el almacenamiento local y persistente, las características de red y la topología de GPU. Registre la respuesta en el ticket de implementación. «H200» por sí solo no es información suficiente para prever el rendimiento multi-GPU.
Antes de reservar capacidad, valide estos detalles en un piloto de corta duración:
- H200 SXM o H200 NVL
- Recuento de GPU y la salida de
nvidia-smi topo -m - si la instancia es exclusiva, está particionada o se comparte por intervalos de tiempo
- versiones del controlador, CUDA, entorno de ejecución de contenedores y framework
- RAM de host disponible, núcleos de CPU, rendimiento de almacenamiento y ruta de red
- tiempos de extracción de imágenes, descarga de modelos, puntos de control y reinicio
2. Instale una ruta de software compatible
Para una implementación de Kubernetes, el GPU Operator de NVIDIA puede gestionar el controlador de NVIDIA, el kit de herramientas para contenedores, el complemento de dispositivo, GPU Feature Discovery, la supervisión basada en DCGM y componentes relacionados. La guía de instalación oficial destaca la coherencia del sistema operativo de los nodos cuando el Operator gestiona los controladores, así como los requisitos previos de seguridad del entorno de ejecución de contenedores y del espacio de nombres. Siga las instrucciones actuales de instalación de GPU Operator en lugar de copiar una versión obsoleta del gráfico.
Una instalación inicial sigue este patrón; sustituya la versión por una que haya validado con respecto a su clúster y su política de controladores:
helm install --wait gpu-operator \
-n gpu-operator --create-namespace \
oci://nvcr.io/nvidia/cloud-native-charts/gpu-operator \
--version=<validated-operator-version>
Después de la instalación, valide los pods del Operator y el estado de ClusterPolicy antes de enviar la primera carga de trabajo. La guía del Operator también muestra cómo confirmar que los nodos informan de un recurso asignable nvidia.com/gpu.
3. Haga explícita la programación
Comience con una solicitud exclusiva de GPU completa, a menos que haya diseñado deliberadamente un modo de uso compartido:
resources:
limits:
nvidia.com/gpu: 1
Utilice una etiqueta de grupo de nodos propiedad de la plataforma o un selector de nube para dirigirse a nodos H200 verificados; no codifique de forma fija una etiqueta de producto de un clúster de ejemplo. Kubernetes documenta la programación de GPU mediante complementos de dispositivo y recursos extendidos, incluido el patrón de límite de recursos anterior. Consulte la documentación de programación de GPU de Kubernetes para conocer el contrato actual.
Si habilita MIG, primero drene o marque como no programables los nodos pertinentes. NVIDIA señala que cambiar el modo o la geometría de MIG requiere que las cargas de trabajo de los usuarios no estén en las GPU y, en algunos entornos de nube, puede requerir un reinicio. Revise el procedimiento MIG de GPU Operator antes de considerar los cambios de partición como una operación en línea.
4. Compruebe una carga de trabajo simple y luego su carga de trabajo real
Ejecute tres controles en orden:
- Control de plataforma: El controlador y CUDA se cargan; el programador detecta el número esperado de GPU; el contenedor puede crear un contexto CUDA.
- Control de tejido: La topología coincide con el diseño previsto; los entornos de ejecución multi-GPU se inicializan y completan una prueba colectiva representativa.
- Control de aplicación: Una repetición de prompts representativos, tamaños de lote, longitudes de contexto, patrones de puntos de control o entradas de simulación alcanza el objetivo requerido de latencia, rendimiento y errores.
El tercer control es el que determina la decisión. Un benchmark genérico puede indicarle que la GPU funciona; no puede indicarle si funcionan su distribución de tráfico, servidor de modelos y política de caché.
Valide el rendimiento antes de escalar
Construya pruebas de aceptación en torno al cuello de botella que espera y, a continuación, inspeccione el resultado que pueda refutar la suposición.
| Suposición | Prueba | Señal de éxito | Fallo que investigar |
|---|---|---|---|
| El modelo cabe | Ejecute la traza de contexto/concurrencia p95 con una marca de agua de memoria | Asignación estable con margen explícito | OOM, oscilación de expulsiones o picos de latencia a medida que crece la caché. |
| El tejido es suficiente | Ejecute el modo de paralelismo exacto y una prueba colectiva relevante | Sin bloqueos; tiempos colectivos y de extremo a extremo estables | Errores de inicialización de NCCL, rangos desiguales o pares lentos. |
| El servicio cumple su SLO | Mida TTFT p50/p95, latencia entre tokens, latencia de extremo a extremo y solicitudes completadas | Los objetivos se cumplen con una carga representativa | Encolamiento, latencia de cola larga o aumento de reintentos. |
| El nodo está en buen estado | Compruebe la telemetría pasiva y los diagnósticos activos en una ventana de mantenimiento | Sin hallazgos accionables de hardware, tejido o implementación | Eventos ECC/Xid, límites térmicos/de potencia, hallazgos de PCIe/NVLink. |
| La economía es viable | Divida el tiempo con carga completa por el trabajo útil completado | El coste está dentro del umbral de lanzamiento | Capacidad inactiva, trabajo fallido o sobrecarga de almacenamiento/red sin coste asignado. |
NVIDIA DCGM separa la supervisión pasiva del estado de los diagnósticos activos. Sus flujos de trabajo de diagnóstico pueden ejercitar las rutas de implementación, memoria, PCIe, NVLink, computación, alimentación, térmicas y comunicación, pero consumen recursos y pueden entrar en conflicto con el trabajo de producción. Drene los nodos o programe una ventana de mantenimiento antes de ejecutar un diagnóstico invasivo. Utilice las instrucciones actuales de diagnóstico de DCGM para seleccionar el nivel de prueba adecuado.
Para los servicios LLM, realice el seguimiento tanto de las señales de aplicación como de infraestructura:
- tiempo hasta el primer token p50/p95 y latencia entre tokens
- tokens de salida aceptados por segundo y solicitudes completadas por segundo
- profundidad de cola, cancelaciones, reintentos y tasa de errores
- memoria GPU asignada frente a reservada, utilización de GPU, energía y temperatura
- comportamiento de aciertos/descarga de caché y fallos relacionados con la caché
- saturación de la CPU del host, presión de RAM, E/S de modelos/checkpoints y latencia de red
Si una métrica mejora mientras otra empeora, no escale todavía. Una mayor tasa de tokens con una latencia p95 o reintentos crecientes puede ser una regresión para el servicio de cara al cliente.
Optimice el coste por trabajo completado, no por tiempo de GPU por hora
Las tarifas de las GPU H200 en la nube varían según la región, el plazo de reserva, la configuración del host y la disponibilidad, por lo que una tabla de precios estática queda obsoleta rápidamente. En su lugar, use una unidad de carga de trabajo que exponga el tiempo inactivo y el trabajo fallido:
fully loaded hourly cost = accelerator + attached CPU/RAM + storage + network + licenses + operating overhead
cost per completed request = fully loaded hourly cost / completed requests per hour
cost per million accepted output tokens = fully loaded hourly cost / accepted output tokens per hour × 1,000,000
Calcule esto con la mezcla de tráfico que espera lanzar, no con una demostración de rendimiento máximo. Incluya la capacidad reservada para la conmutación por error, la carga de modelos, los checkpoints y el mantenimiento. Para un modelo más detallado, consulte Coste de un LLM autoalojado por millón de tokens.
También hay una cuestión de límites: ¿necesita operar el entorno de ejecución o necesita acceso fiable a las salidas del modelo? Si necesita kernels personalizados, un entorno de ejecución específico, localidad de datos dedicada o experimentación controlada con hardware, puede justificarse un piloto de GPU H200 en la nube. Si principalmente necesita una API de modelo, compare la carga operativa con la opción de API antes de comprometerse con la infraestructura. La guía de implementación de servidores GPU y la guía de clústeres GPU de Kubernetes pueden ayudar a hacer explícito ese límite.
Lista de verificación de implementación de GPU H200
Antes de considerar lista una implementación de H200, verifique todo lo siguiente:
- [ ] Factor de forma exacto de H200, número de GPU y topología registrados
- [ ] Presupuesto de memoria probado con contexto p95 y la concurrencia esperada
- [ ] Compatibilidad de controladores, CUDA, framework e imagen de contenedor validada
- [ ] Estado del GPU Operator/plugin de dispositivos confirmado donde se use Kubernetes
- [ ] El planificador expone la capacidad esperada de
nvidia.com/gpu - [ ] La prueba colectiva multi-GPU se supera en la topología de producción
- [ ] La prueba de carga representativa cumple los objetivos de TTFT, latencia, rendimiento y errores
- [ ] El estado de DCGM y los diagnósticos adecuados durante ventanas de mantenimiento forman parte del runbook
- [ ] Se miden las rutas de almacenamiento, red, carga de modelos, checkpoints y reinicio
- [ ] El coste se calcula por unidad útil completada, incluida la capacidad inactiva y de recuperación
Preguntas frecuentes
¿Cuánta memoria tiene una GPU H200?
NVIDIA indica 141 GB de memoria HBM3e y 4,8 TB/s de ancho de banda de memoria tanto para H200 SXM como para H200 NVL. Confirme el SKU exacto y la configuración del sistema con el proveedor, ya que el factor de forma de la tarjeta y la interconexión difieren. Las especificaciones de H200 de NVIDIA son la fuente de las cifras de esta guía.
¿Es una GPU H200 mejor que una H100 para la inferencia de LLM?
Puede serlo, especialmente cuando la capacidad de memoria o el ancho de banda de memoria limitan la carga de trabajo. La respuesta práctica depende de la precisión del modelo, la longitud del contexto, el comportamiento de la caché KV, la concurrencia, el entorno de ejecución de serving y la topología del sistema. Compare la carga de trabajo con una traza representativa; no considere un benchmark del proveedor como sustituto del SLO de su servicio. Consulte la comparación entre H200 y H100 para conocer el marco de decisión de hardware.
¿Debo elegir H200 SXM o H200 NVL?
Elija partiendo de la topología. H200 SXM es adecuada para configuraciones multi-GPU estrechamente acopladas de estilo HGX. H200 NVL es una opción PCIe refrigerada por aire con configuraciones de puente NVLink de 2 o 4 vías. Verifique la topología, el host y el patrón de comunicación de la carga de trabajo en lugar de elegir basándose solo en la memoria.
¿La GPU H200 admite MIG?
NVIDIA indica hasta siete instancias MIG para H200 SXM y H200 NVL, con diferentes tamaños de memoria por instancia indicados. Use MIG cuando necesite aislamiento de memoria y de fallos respaldado por hardware. No sustituya esto por partición de tiempo cuando se requieran esas propiedades de aislamiento.
¿Cuántas GPU H200 necesito?
Comience con la configuración más pequeña que supere una prueba representativa de memoria, latencia, rendimiento y recuperación. Añada GPU solo cuando lo requieran el presupuesto de memoria, el número de réplicas o el plan de paralelismo validado. Un mayor número de GPU sin una carga de trabajo consciente de la interconexión puede añadir coste y complejidad operativa sin mejorar el resultado de cara al cliente.
Comience con un piloto validado de GPU H200
La implementación correcta de una GPU H200 es un sistema medido: la memoria del acelerador, la topología, el planificador, el entorno de ejecución, la ruta de datos, la observabilidad y la economía de la carga de trabajo deben estar alineados. Comience con un piloto instrumentado, reproduzca tráfico realista, documente los modos de fallo y escale solo después de que la evidencia respalde el siguiente paso de capacidad.
