Cómo entender la GPU

• La GPU cumple un papel central en el machine learning moderno, con una arquitectura que combina numerosos Streaming Multiprocessors (SMs) especializados en multiplicación de matrices de alta velocidad junto con HBM (memoria de alto ancho de banda)
• El SM de una GPU se divide en Tensor Cores (multiplicación de matrices) y CUDA Cores (operaciones vectoriales), lo que permite cómputo paralelo a gran escala y programación flexible
• La GPU y la TPU difieren en su estructura interna y en la configuración de red; la GPU tiene mayor versatilidad y escalabilidad, pero alcanzar el rendimiento óptimo requiere más consideraciones
• Dentro de un nodo (Node), es posible la comunicación ultrarrápida entre GPUs mediante NVLink y NVSwitch, y entre nodos se conectan mediante redes como InfiniBand para responder al entrenamiento distribuido a gran escala
• Las operaciones colectivas (Collectives) en GPU (por ejemplo, AllReduce, AllGather, etc.) varían mucho en rendimiento según la estructura del hardware y las capas de red, y en la práctica tienden a quedar por debajo del ancho de banda teórico

---

¿Qué es una GPU?

• Las GPUs modernas para ML (por ejemplo, H100, B200) están compuestas por decenas o cientos de Streaming Multiprocessors (SMs) especializados en multiplicación de matrices, combinados con memoria HBM rápida
• Cada SM incluye Tensor Cores (multiplicación de matrices), Warp Scheduler (operaciones vectoriales) y SMEM (caché on-chip)
• A diferencia de la TPU, la GPU permite un procesamiento paralelo más flexible y masivo mediante más de 100 SMs

Estructura detallada del SM

• El SM se divide en 4 subparticiones, y cada subpartición cuenta con su propio Tensor Core, CUDA Core (operaciones vectoriales), Warp Scheduler, archivo de registros, etc.
• El CUDA Core se encarga de operaciones aritméticas vectoriales (SIMD/SIMT), mientras que el Tensor Core está especializado en multiplicación de matrices
• Los FLOPs del Tensor Core son abrumadoramente mayores, y con operaciones de menor precisión la velocidad de procesamiento aumenta aún más
• Las GPUs más recientes (por ejemplo, B200) agregan una gran TMEM para soportar entradas de gran tamaño para Tensor Core

Flexibilidad del CUDA Core

• El CUDA Core de la GPU usa el modelo SIMT (Single Instruction Multiple Threads), ejecutando una instrucción en paralelo sobre múltiples hilos
• Cada hilo tiene su propio puntero de instrucciones (program counter), lo que aporta flexibilidad para bifurcaciones condicionales y similares, aunque muchas divergencias de instrucciones dentro de un warp degradan el rendimiento
• Cada CUDA Core tiene libertad de estado individual y acceso a memoria (la TPU solo puede procesar memoria contigua)

Scheduling/paralelismo

• El SM planifica y ejecuta simultáneamente múltiples warps (hasta 64), y cada warp scheduler ejecuta un programa a la vez
• Gracias a esta estructura, la GPU logra un alto nivel de concurrencia manteniendo bastante flexibilidad

Estructura de memoria de la GPU

• En la GPU, la HBM es la memoria más grande, y además existe una jerarquía de memoria con L2/L1 (SMEM)/TMEM/registros, entre otras

Resumen de especificaciones de GPUs modernas

• La cantidad de SMs (Streaming Multiprocessors), reloj, memoria, FLOPs y ancho de banda (BW) varían según el modelo
• La capacidad de memoria (HBM), el ancho de banda y los FLOPs (coma flotante/enteros/baja precisión) aumentan con cada generación
• En la tabla (omitida), las características principales incluyen: Blackwell (B200) con HBM de 192GB, HBM BW de 8.0TB/s, FP8 FLOPs de 4.5e15, etc.
• En cada generación se observan avances claros de hardware, como mayor capacidad de registros y caché on-chip (SMEM), además de la incorporación de TMEM

Comparación GPU/TPU

• La GPU es de propósito general y está modularizada en muchos SMs pequeños (unidades paralelas), con abundante control de hardware, lo que dificulta su comprensión y optimización
• La TPU se compone de unos pocos Tensor Cores grandes y muchas ALUs vectoriales (VPU), y al usar un esquema de control de un solo hilo puede simplificar el hardware y reducir costos
• Por esto, en la TPU la optimización del compilador es obligatoria, mientras que en la GPU pueden ejecutarse múltiples kernels de forma independiente, lo que mejora la facilidad de uso
• En términos de rendimiento/precio, una GPU H200 reciente ofrece aproximadamente el doble de FLOPs/s que una TPU v5p, 1.5 veces más HBM y un precio unas 2.5 veces mayor
• La TPU tiene más VMEM (caché on-chip) y es más rápida, lo que puede dar grandes ventajas en inferencia de modelos LLM, entre otros casos

Puntos clave del Q&A de hardware GPU

• El H100 tiene un total de 16,896 CUDA cores fp32 (132 SM x 4 x 32), y el B200 tiene 18,944
• El rendimiento vectorial de FLOPs alcanza como máximo unos 33.5TFLOPs/s en H100, unas 30 veces menos que los FLOPs de multiplicación de matrices del Tensor Core (990TFLOPs/s)
• La capacidad combinada de L1/SMEM y registros del H100 es de 66MB, mientras que la VMEM de TPU es de 120MB
• La relación entre bandwidth (ancho de banda) y FLOPs (intensidad de cómputo teórica) es de alrededor de 280-300 tanto en H100/B200 como en TPU

Redes de GPU (estructura de comunicación)

Estructura de nodos/clúster

• Un nodo de GPU normalmente agrupa 8 GPUs, conectadas directamente con ancho de banda completo mediante NVLink (ultrarrápido) y NVSwitch (switch)
• Entre nodos puede escalar horizontalmente usando InfiniBand (Ethernet, etc.)
• Las GPUs más recientes (Blackwell) tienen una estructura escalable hasta 72 nodos

Características por capa de red

• Dentro del nodo (área NVLink): egress por GPU de 450GB/s (H100), 900GB/s (B200), y hasta 1.6TB/s por NVSwitch
• Nivel superior al nodo (InfiniBand Leaf/Spine): estructura de Leaf Switch (8) a Spine Switch (16), manteniendo teóricamente 400GB/s de ancho de banda completo entre GPU y GPU
• En arquitecturas grandes como SuperPod, hay 1024 GPUs (128 nodos), y en GB200 (nodo de 72 GPUs) el ancho de banda aumenta 9 veces (3600GB/s)

Puntos clave del rendimiento de red

• En teoría, la estructura de red (Full Fat Tree) está diseñada para ofrecer el máximo ancho de banda incluso entre nodo y nodo
• Debido a limitaciones de puertos de hardware y otros factores, al escalar a 1024~4096 GPUs se usa una estructura jerárquica con más Spine/Core Switches
• El cambio de ancho de banda dentro del nodo (450GB/s) a ancho de banda entre nodos (400GB/s) produce diferencias de rendimiento en las operaciones colectivas

Estructura de operaciones colectivas (Collectives)

• Se admiten operaciones colectivas de alto nivel como AllGather, AllReduce (suma), AllToAll (distribución)
• Dentro del nodo, la conexión directa por NVLink permite un rendimiento óptimo (B/W teórico), mientras que entre nodo y nodo pasa por InfiniBand
• Se utilizan las bibliotecas NCCL y NVSHMEM de NVIDIA

Análisis de rendimiento de operaciones colectivas

• AllGather/ReduceScatter: implementación en anillo (Ring) usando B/W (450GB/s en H100), aunque con mensajes pequeños también puede usarse un esquema de árbol (Tree)
• AllToAll: cada GPU envía directamente a la GPU destino; como se divide desde el B/W entre N, dentro del nodo en teoría es 2 veces más rápido
• En mediciones reales, AllReduce alcanza alrededor de 370GB/s, sin llegar al máximo del hardware
• Frente a la TPU, solo con volúmenes grandes (decenas de MB a GB) se aproxima al peak bandwidth del hardware

Resumen general e insights

• La GPU destaca por su versatilidad y escalabilidad, pero según la estructura de hardware/red la dificultad de optimización y observabilidad del rendimiento es mayor que en la TPU
• El networking (Intra-Node/NVLink/InfiniBand/Leaf/Spine, etc.) es clave para el rendimiento del entrenamiento a gran escala, y hay que prestar atención a la diferencia entre ancho de banda real y teórico
• Comprender las operaciones colectivas y la estructura de red es un elemento esencial para el entrenamiento/serving de modelos distribuidos de escala masiva
• Se requiere un proceso basado en benchmarks reales y en la comprensión detallada del hardware para identificar cuellos de botella de rendimiento y condiciones óptimas

[GN⁺]

Comentarios de Hacker News

• Sentí que este artículo y varios otros documentos son algo poco claros, sobre todo porque al explicar las GPU suelen usar la terminología de forma ambigua; por ejemplo, en la primera imagen se describe el Warp Scheduler como una unidad vectorial SIMD similar al VPU de una TPU y se dice que tiene 32 CUDA Core, pero no se explica con claridad qué es exactamente un CUDA core, así que no se transmite bien el objeto central de la explicación. Por este tipo de errores compuestos, para principiantes o lectores que quieren formar el concepto sigue siendo difícil de entender, mientras que para quienes ya entienden más o menos el tema es algo que ya saben. Incluso si era un borrador, al publicarlo hay que tratar cada término con precisión quirúrgica y no confundir ni mezclar términos. También es un consejo para usar las analogías con cuidado. Y creo que términos como MXU (unidad de operación matricial) deberían poder encontrarse fácilmente mediante una explicación adicional o un hipervínculo. Hoy en día incluso se le puede encargar ese papel a la IA, lo cual es un poco triste.

  • Respondo directamente como autor. En general estoy de acuerdo con la observación. Cuanto más intento asegurar precisión en la explicación, más me preocupa el equilibrio con la “verdad moral”. Por ejemplo, podría escribir “una unidad similar al VPU de una TPU compuesta por 32 ALU, es decir, unidades vectoriales SIMD (single instruction, multiple data) que NVIDIA llama CUDA Core”, pero entonces la oración se alarga y aun así podrían faltar definiciones de términos como unidad vectorial. Intento usar muchas notas al pie, pero tampoco es realista esperar que el lector haga clic en cada una, y las notas laterales son difíciles de implementar en HTML. Términos como MXU ya estaban definidos en un capítulo anterior, pero creo que es demasiado asumir que el lector va a leer todos los capítulos. Warp Scheduler también es un término ambiguo en sí mismo, porque en la práctica puede referirse a varios roles a la vez —scheduler, unidad de despacho y SIMD ALU—, pero eso ocurre porque NVIDIA no le da un nombre separado a la unidad compuesta. Voy a intentar mejorarlo más en adelante. Es una sucesión de compromisos nada fáciles.

  • Los LLM son una herramienta bastante buena para resolver estas dificultades de conexión entre términos. Cuando buscas un término y van apareciendo otros desconocidos en cadena, te orientan bien sobre por dónde empezar a estudiar.

  • Casi todo está en la documentación de arquitectura del sistema TPU de Google.

  • Lo pregunto en serio: me da curiosidad cuál sería un nivel adecuado de conocimientos previos sobre arquitectura de computadoras. El concepto de SIMD en sí ya tiene más de 50 años. Al inicio de ese material se asume como base entender los LLM y la arquitectura Transformer, pero se da a entender que no hace falta comprender cómo funciona una computadora; aun así, yo pensaría que al menos habría que conocer el funcionamiento básico de una CPU.

  • Este contenido es un capítulo de un libro escrito para personas que trabajan en machine learning.

• Siento que es muy difícil justificar el tiempo invertido si no es algo open source o una tecnología interoperable entre varios proveedores. Me parece que saber aprovechar bien los chips de Nvidia es como ser consultor de SAP ABAP en otros tiempos. Claro, en este campo se gana mucho dinero, pero históricamente ese tipo de especialización no siempre ha sido tan beneficiosa.

  • Yo pensaba lo mismo y por eso en la universidad, hace 10 años, me salté a propósito un curso de CUDA.

  • CUDA tiene dos partes: la arquitectura de hardware y el stack de software para usarla. El stack de software es cerrado, así que si no planeas hacer optimización directa a bajo nivel no hace falta prestarle tanta atención. Pero la estructura del hardware sí vale totalmente la pena aprenderla. Básicamente todas las GPU funcionan de forma parecida —la filosofía base de la arquitectura CUDA sigue siendo la misma desde 2007—, y esa arquitectura influye mucho en los lenguajes de shaders y en la manera de abstraer las GPU. Si entiendes características detalladas como el scheduling de threads, los warps y la estructura de memoria privada/compartida, puedes adaptar mejor los algoritmos al modelo de ejecución del hardware y aprovechar un rendimiento de cómputo enorme.

  • Quiero enfatizar que los principios del cómputo paralelo y la forma en que funcionan a nivel de hardware y de drivers tienen bastante generalidad. Parte de esto sí está especializado a una plataforma concreta, pero mucho se puede aplicar de forma amplia. Si uno se obsesiona solo con lo genérico, también puede salir perdiendo. Además, el hecho de que algo sea open source y que sea general o específico son cuestiones separadas, así que vale la pena explorarlo con más amplitud.

  • La transición no es tan difícil. Si ya habías escrito código con OpenMP o MPI, empezar con CUDA en sí era fácil. Aprender cómo optimizar rendimiento en CUDA también acelera el código paralelo en CPU, así que en esencia es una evolución de los modelos de cómputo existentes.

  • Yo también aprendí a programar de niño con IBM PC/MS-DOS, y aunque ninguno de los dos era open source, me sigue sirviendo mucho hasta hoy.

• Creo que el cálculo en la parte “Quiz 2: GPU nodes” no es preciso. En la práctica, cada GPU o switch tiene un número limitado de puertos, así que esos 450GB/s teóricos no están realmente garantizados; por eso los principales clouds o sistemas de referencia ofrecen 3.2TB/s. Si 3.6TB/s fuera posible, habría un cuello de botella en cargas distribuidas en anillo. Por cierto, ando buscando trabajo.

  • Yo también me puse a pensar en esta parte después de mucho tiempo, y la razón por la que los proveedores cloud anuncian solo 3.2Tbps es por el límite de conexión de red IB (InfiniBand) del nodo. En un DGX, cada H100 tiene un NIC Connect-X 7 que ofrece hasta 400Gbps. 8 GPU x 400Gbps = 3.2Tbps. La redacción de Quiz 2 es confusa, pero creo que se refiere a la conexión entre GPU dentro del nodo, no a la red entre nodos.

• Toda esta serie fue realmente muy buena. Explica los límites teóricos de las cargas de trabajo modernas de IA y vuelve accesibles principios técnicos como la arquitectura y el paralelismo. Está centrada en TPU, pero en general se puede aplicar a otras áreas, así que resulta muy útil.

• El orden sería optimizar al máximo el código numéricamente intensivo en un lenguaje con tipado fuerte, y solo si aun así hace falta más velocidad, evaluar la opción de GPU. En mi experiencia, con GPU se obtiene más o menos una mejora de 8x. Si puedes bajar una respuesta web de 4 segundos a 0.5 segundos, el cambio es enorme. Pero en la práctica a veces es más fácil mostrar latencia con websockets y un spinner, o usar caché en segundo plano. Y también hay que considerar que correr GPU en la nube es caro.

• Me parece interesante que nvshmem esté tan de moda en ML. En cambio, MPI con la misma funcionalidad no resultó tan satisfactorio en el mundo anterior de las simulaciones científicas. Como referencia, yo trabajaba sobre todo con tareas difíciles, como cálculos de fuerzas de largo alcance distribuidos entre varios nodos.

• Me pregunto por qué Nvidia no desarrolló su propia TPU.

  • No lo necesita. Ya tiene una posición dominante en el mercado del hardware y del modelo de programación, y una TPU es incluso más difícil de programar.

  • En la práctica, como explica este artículo, el 90% del rendimiento de una GPU de Nvidia proviene de las unidades de operación matricial, así que su estructura ya es casi equivalente a una TPU. Se sacrifica un poco de rendimiento, pero se consigue un ecosistema de compiladores mucho más flexible.

• Me sorprende que Nvidia todavía no haya ofrecido oficialmente recursos de este nivel. Al final, terceros terminan haciendo ingeniería inversa del hardware y organizándolo hasta convertirlo en diagramas conceptuales realmente utilizables. Me da curiosidad cuál es la motivación real de Nvidia. Si solo pensaran en marketing, diría que les ha salido bien, pero a mí me deja dudas sobre su cultura de ingeniería.

  • Desde la perspectiva de un ingeniero de renderizado en tiempo real, siempre ha sido así. NV oculta casi toda la información para evitar que los competidores capten los cambios entre generaciones. Los otros vendors tampoco son muy distintos. En videojuegos sí dan información arquitectónica más detallada bajo NDA, pero fuera de eso, salvo Intel, no he visto casos de divulgación completa.

  • Nvidia sí tiene de hecho una cantidad realmente excelente de documentación oficial en comparación con otras empresas.

  • Me da curiosidad por qué te dio esa impresión. En realidad, parece que la mayor parte de lo que hay en este artículo está tomado casi tal cual de documentación oficial de Nvidia. Por ejemplo, el diagrama del H100 en realidad fue copiado del whitepaper del H100 sin citar la fuente. La información de cómputo y ancho de banda también ya está toda tratada en los whitepapers oficiales y en los capítulos 5, 6 y 7 de la guía de CUDA C++. Tiene valor que alguien externo lo resuma de forma más breve y agregue interpretación, pero sin los materiales oficiales de Nvidia un artículo así ni siquiera habría sido posible, así que tanta sospecha o insinuación sin base me parece exagerada.

  • Nvidia publica documentación de un nivel apenas normal, lo que hace que solo bibliotecas cerradas como cuBLAS o cuDNN sean realmente rápidas, y con eso se refuerza la dependencia del proveedor. Gracias a eso también se vuelve más difícil que otros fabricantes logren alcanzarla por ingeniería inversa.

  • Por varios indicios, parece que Nvidia tiende a dar materiales personalizados solo a quienes firman NDA y a los VIP, mientras que descuida adrede la publicación de manuales oficiales para el público general. Probablemente lo hace porque comercialmente le conviene. Incluso si levanta barreras hasta en la documentación oficial del API y eso dificulta el acceso a desarrolladores comunes, está enfocada en vender todo el ecosistema —IA, la propia GPU, software y documentación para VIP—, así que simplemente presta menos atención al desarrollador general.

• Cuando vemos diagramas de arquitectura, hay que tener muy presente que no reflejan perfectamente el hardware real. Nvidia no garantiza que los bloques o componentes de esos diagramas existan de verdad tal como aparecen; los ofrece solo como modelos mentales de referencia para pensar en la estructura de la GPU y del SM. Por ejemplo, oficialmente no se puede saber cuántas unidades funcionales hay realmente dentro de un SM, si un tensor core es hardware independiente o el resultado de combinar varias unidades, ni tampoco cómo funciona el detalle por debajo del warp.

  • Es una opinión interesante. Pero me pregunto si el hecho de que en la práctica el SM quede bloqueado durante operaciones de tensor no podría interpretarse como que la misma FPU está procesando también las operaciones de tensor.

• Es un recurso realmente fantástico, me sirvió para sacar buen contenido de ahí.