NVIDIA H200

Hay una escena que se repite cuando uno empieza a trabajar con modelos grandes. El modelo carga, la primera respuesta llega rápido y durante unos minutos parece que el problema está resuelto. Luego se abre un contexto más largo, aparecen varias peticiones al mismo tiempo y la GPU que en la demo se veía sobrada comienza a quedarse sin aire. No necesariamente por falta de cálculo. A veces se queda corta por algo más básico: no tiene dónde guardar todo lo que necesita para seguir respondiendo.

Ese es el punto desde el que tiene sentido mirar una NVIDIA H200. No como la siguiente GPU de una tabla, ni como el objeto brillante que un fabricante quiere vender, sino como una pista sobre el momento actual de la infraestructura para IA. Estamos construyendo servicios donde el tamaño de la memoria y la velocidad con la que se mueve el dato pueden decidir tanto como la potencia de cálculo. Para alguien que administra sistemas, esto resulta familiar: un servidor no falla solo porque la CPU sea lenta; puede fallar porque el disco espera, porque la red se atasca o porque la memoria se agotó en el peor momento. En un LLM ocurre algo parecido, solo que la memoria crítica está pegada al acelerador y cada gigabyte cuesta mucho más.

H200 pertenece a la arquitectura Hopper, la misma familia que H100. NVIDIA no cambió aquí toda la historia desde cero. Lo que hizo fue mover una pieza que ya empezaba a doler: pasó a 141 GB de memoria HBM3e con 4,8 TB por segundo de ancho de banda. En su propia documentación, la compañía lo compara con H100 como casi el doble de capacidad y 1,4 veces más ancho de banda de memoria. La cifra suena enorme, pero conviene traducirla a una pregunta más terrenal: ¿qué estaba intentando meter la industria dentro de la GPU para necesitar tanto espacio tan pronto?

Lo primero que vive ahí son los pesos del modelo. Un modelo no es una idea abstracta flotando en un API; son valores que tienen que estar disponibles para hacer las operaciones que producen cada token. El tamaño depende del número de parámetros y de la precisión con la que se carguen. Reducir precisión permite encajar más, y muchas veces es una decisión razonable, pero tampoco es gratis ni siempre encaja con el resultado que se busca. En infraestructura rara vez elegimos entre una opción perfecta y una mala. Elegimos qué coste estamos dispuestos a asumir: memoria, latencia, calidad, complejidad o dinero.

Pero si solo estuvieran los pesos, la conversación sería más sencilla. Cuando un modelo de lenguaje responde, va conservando información del contexto que ya procesó para no empezar de cero en cada nueva palabra. Esa memoria de trabajo suele aparecer con el nombre de KV cache. El usuario no la ve. Solo ve que pegó una documentación larga, abrió una conversación de muchas vueltas o lanzó varias solicitudes a la vez. Detrás, cada una de esas decisiones ocupa espacio. Un servicio puede soportar un modelo durante la prueba y romper su promesa cuando el contexto y la concurrencia se parecen por fin al uso real.

Por eso me parece más interesante hablar de H200 desde la inferencia que desde la carrera por entrenar el modelo más grande. Imagina un equipo que construye un asistente técnico capaz de leer logs, manifiestos y fragmentos de documentación antes de contestar. El producto no quiere responder con dos líneas aisladas; quiere sostener suficiente contexto como para razonar sobre un problema. Si la memoria obliga a recortar ese contexto o a aceptar muy pocas sesiones simultáneas, el límite del hardware termina moldeando la experiencia del usuario. No lo hace en una gráfica espectacular. Lo hace de una forma silenciosa: peor respuesta, más cola o una factura que sube porque la única salida fue añadir más GPUs.

HBM3e es importante aquí porque no se trata únicamente de almacenar más. La GPU necesita leer y mover esos datos con una velocidad brutal para que los núcleos de cálculo no pasen el tiempo esperando. La memoria HBM se coloca muy cerca del acelerador y ofrece un ancho de banda que la RAM normal de un servidor no puede sustituir. Es la misma lógica que hemos visto siempre en sistemas, llevada a una escala distinta: no sirve de mucho tener un motor rápido si cada pieza que necesita llega tarde. H200 no elimina ese problema; amplía el margen antes de chocar con él.

Hay otra parte que suele perderse cuando miramos una ficha técnica: H200 no suele existir sola. La encontraremos en servidores con varias GPUs, en plataformas HGX, en equipos H200 NVL o en instancias de nube donde alguien ya decidió por nosotros la CPU, la red y la refrigeración. En ese punto, los 141 GB dejan de ser el final de la explicación. Si el modelo necesita repartir trabajo entre varias GPUs, entra la interconexión. Si varias máquinas deben cooperar, entra la red. Si un job dura horas, entran los fallos, los checkpoints y la observabilidad. La GPU abre la conversación; no la cierra.

Esto también cambia cómo debería estudiar el tema un ingeniero de sistemas. No necesitas comprar una H200 para comenzar a entenderla. Puedes empezar por mirar un modelo que tengas a mano y hacer las preguntas correctas: cuánto ocupan sus pesos en la precisión elegida, qué ocurre al aumentar la longitud de contexto, cuánto crece la memoria al añadir concurrencia y qué métricas ofrece el runtime cuando se queda sin margen. Herramientas de serving como vLLM o TensorRT-LLM entran después, no para decorar la arquitectura, sino porque administran precisamente ese recurso escaso: cómo agrupar peticiones, cómo manejar cache y cómo mantener ocupado el acelerador sin ahogarlo.

También conviene no confundir más memoria con una solución universal. Una H200 puede aliviar cargas donde la capacidad y el ancho de banda eran el cuello de botella, pero no arregla una aplicación mal diseñada, una red insuficiente o un modelo que no tiene sentido económico para el servicio que ofrece. Tampoco vuelve irrelevantes a otros aceleradores. AMD, Google y AWS están construyendo sus propias rutas para este mismo problema, cada una con su ecosistema y sus compromisos. Lo saludable no es aprenderse una marca como si fuera la respuesta; es aprender qué pregunta intenta contestar cada pieza de hardware.

Si vienes de Linux, redes o Kubernetes, esta es la idea que yo me llevaría de H200: en IA, la memoria ya no es una línea más en el inventario del servidor. Es parte de la arquitectura del producto. Define qué modelo cabe, cuánto contexto puede conservar, cuántas personas pueden usarlo a la vez y cuánto cuesta mantener esa experiencia cuando deja de ser una demo. NVIDIA presenta H200 como una GPU para IA generativa y HPC; a mí me interesa por una razón menos comercial: expone con claridad que el rendimiento real empieza por entender dónde viven los datos mientras el modelo está pensando.

Las cifras citadas salen de la página oficial de NVIDIA H200 y de sus fichas técnicas para H200 NVL y H200 para HPC e IA. Son fuentes del fabricante: sirven para fijar capacidades y topologías; la decisión de plataforma siempre exige medir la carga real.