NVIDIA publicó el primer capítulo de una serie sobre co-diseño de modelos de inteligencia artificial: el arte de diseñar la arquitectura de un modelo pensando desde el inicio en el hardware que lo va a ejecutar. La idea de fondo es simple: los modelos que se alinean con la GPU no solo corren más rápido, también escalan mejor, cuestan menos y llegan a una adopción más amplia.

Tres puntos clave

  • El diseño de transformadores conscientes del hardware, para inferencia de alto rendimiento y baja latencia, requiere capas lineales de dimensiones casi cuadradas, alineadas a los tamaños de tile de la GPU (múltiplos de 128, idealmente 256 o 512) y con una relación de más ancho que profundo, para maximizar la intensidad aritmética y el uso de la GPU.
  • La cuantización NVFP4, soportada por las herramientas de NVIDIA (TensorRT Model Optimizer y LLM Compressor), entrega alto rendimiento con mínima pérdida de precisión en las capas lineales, y permite aprovechar por completo las GPU Blackwell tanto en cargas limitadas por cómputo como por memoria.
  • El paralelismo de expertos y las estrategias híbridas, como el paralelismo de pipeline y Helix Parallelism en TensorRT-LLM, permiten escalar grandes modelos Mixture-of-Experts a través de sistemas multinodo Blackwell con NVLink.

¿Qué equilibra el rendimiento de un modelo?

El rendimiento de la IA se reduce a tres dimensiones:

  • Precisión: qué tan bien razona el modelo y produce sus salidas.
  • Throughput: cuántos tokens por segundo puede generar un centro de datos.
  • Interactividad: qué tan reactivo se siente el modelo para el usuario, algo dominado por la latencia.

Toda implementación debe equilibrar las tres. Una precisión alta se desperdicia si las respuestas son lentas, y un throughput bruto significa poco si la experiencia de cada usuario se siente pesada. Manteniendo la precisión fija, el problema se convierte en una frontera de Pareto de dos dimensiones: mejorar una suele costar la otra. La meta es empujar toda la frontera hacia afuera.

Figura 1. Frontera de Pareto entre throughput del sistema e interactividad
Figura 1. Frontera de Pareto entre throughput del sistema e interactividad

Cada cuadrante del panorama de despliegue necesita optimizaciones distintas. El servicio orientado a throughput con contexto largo pasa la mayor parte del tiempo en la atención, mientras que el orientado a latencia agrega paralelismo de modelo para acortar la atención y las capas feed-forward, a costa de comunicación y sobrecostos fijos.

Figura 2. Desglose de latencia según el régimen de carga y los objetivos de servicio
Figura 2. Desglose de latencia según el régimen de carga y los objetivos de servicio

Aquí aplica la ley de Amdahl: optimizar una parte ayuda solo en la medida del tiempo que ocupa. Si la atención representa el 77% del tiempo de ejecución, ajustar las capas feed-forward entrega ganancias marginales; el camino de la atención es donde el esfuerzo rinde.

El papel de la intensidad aritmética

En cualquier hardware, el rendimiento alcanzable está acotado por el modelo roofline. Dónde cae una carga depende de su intensidad aritmética, definida como la cantidad de operaciones de cómputo por byte de memoria movido. Las cargas de baja intensidad quedan limitadas por el ancho de banda de memoria; las de alta intensidad, por el techo de cómputo del dispositivo en FLOPS.

Figura 3. El modelo roofline: bajo el punto de quiebre la carga está limitada por memoria; sobre él, por el cómputo
Figura 3. El modelo roofline: bajo el punto de quiebre la carga está limitada por memoria; sobre él, por el cómputo

La forma del modelo importa tanto como el tamaño del batch. Como ejemplo concreto, una capa FFN-2 con un valor deliberadamente pequeño de dimensión de proyección (512) frente a una dimensión oculta de 8192, usando entradas de 4 bits y salidas de 8 bits en una GB300, se mantiene limitada por memoria incluso con muchos tokens: el movimiento de datos domina el costo.

Figura 4. Throughput de GEMM en NVFP4 sobre GB300 al variar la dimensión de reducción
Figura 4. Throughput de GEMM en NVFP4 sobre GB300 al variar la dimensión de reducción

Guía 1: para un modelo de parámetros fijos, favorezca matrices de pesos casi cuadradas y evite que la dimensión de proyección o de reducción sea demasiado pequeña.

¿Por qué las dimensiones deben ser múltiplos de 128?

El tamaño por sí solo no basta. Para alcanzar una alta utilización de los Tensor Cores, las dimensiones de un GEMM deben mapearse limpiamente sobre la geometría de tiling. Las GPU ejecutan un GEMM dividiendo la matriz de salida en tiles, cada uno calculado por un streaming multiprocessor (SM). En las GPU recientes, dos SM vecinos pueden unirse en un solo tile con clusterMMA, y un grupo completo de SM puede trabajar como un cluster mediante un Cooperative Grid Array (CGA).

Cuando una dimensión no es múltiplo del tile efectivo, los tiles del borde quedan solo parcialmente llenos pero igual ejecutan el cómputo de un tile completo: la parte no usada no hace trabajo útil y desperdicia ciclos.

Figura 5. Efecto de cuantización de tiles sobre el throughput entregado en GB300
Figura 5. Efecto de cuantización de tiles sobre el throughput entregado en GB300

Guía 2: haga que las dimensiones del modelo sean al menos múltiplos de 128 para alinearse con los tamaños de tile de la GPU y el ancho de las líneas de caché, y prefiera 256 o 512 para coincidir con los tiles cooperativos más grandes que forman clusterMMA y CGA.

Más ancho que profundo

Para un presupuesto de parámetros fijo, los modelos más anchos ofrecen mayor intensidad aritmética y menor latencia que los más profundos, gracias a un mayor reuso de pesos y a un camino crítico secuencial más corto. Eso vuelve a los modelos anchos ventajosos tanto para objetivos orientados a throughput como a latencia.