AMD Matrix Cores: modelos bit-exactos para MI100, MI250 y MI300X

Por qué importa que tu GPU "no cumpla" con IEEE 754

Un nuevo paper de arXiv ("Accurate Models of AMD Matrix Cores", publicado el 16 de septiembre de 2026) demuestra con pruebas bit a bit que los multiplicadores matriciales de las GPUs AMD Instinct MI100, MI210/250 y MI300A/300X no se comportan como el estándar IEEE 754 de coma flotante. Para un founder que entrena o sirve modelos, esto explica por qué un mismo cálculo puede dar resultados distintos entre GPUs de la misma marca, y por qué los benchmarks sintéticos a veces no predicen lo que pasa en producción.

El equipo detrás del paper (Khattak, Mikaitis y colaboradores, Universidad de Durham, con financiamiento EPSRC y acceso a recursos de Argonne National Laboratory) construyó modelos en MATLAB que replican el hardware con exactitud de bit, y los validó contra 10 millones de vectores aleatorios por arquitectura. El código está disponible en github.com/north-numerical-computing/MATLAB-tensor-core.

Qué caracterizaron exactamente

Los autores no se limitaron a "contar FLOPS". Diseñaron vectores de prueba dirigidos a ocho propiedades numéricas concretas: ancho del acumulador, modo de redondeo, puntos de normalización, manejo de underflow/overflow intermedios, soporte de subnormales y tratamiento de entradas especiales (infinitos, NaN).

Las pruebas cubren tres generaciones de la arquitectura CDNA de AMD:

• CDNA 1 (MI100): lanzada como base de la línea Instinct para data center.
• CDNA 2 (MI210/250): siguiente paso en inferencia y HPC.
• CDNA 3 (MI300A/300X): la primera generación con soporte para entradas fp8 y la base del competidor directo de NVIDIA H100.

En cada arquitectura probaron todos los formatos de entrada soportados: fp32, fp16, bf16, tf32/tf19, fp8-E4M3 y fp8-E5M2. Los modelos resultantes alcanzaron cero discrepancias contra el hardware en las pruebas aleatorias, con cotas bayesianas sobre la probabilidad de error que el paper detalla por iteración de refinamiento.

Diferencias clave entre CDNA 1, 2 y 3

Uno de los hallazgos más accionables es que AMD cambió el comportamiento numérico entre generaciones, no solo el throughput:

• CDNA 1 (MI100) usa un acumulador de precisión completa, tipo Kulisch, lo que entrega resultados cercanos al redondeo correcto.
• CDNA 2 (MI210/250) abandona la precisión completa y adopta sumas por pares con redondeo RNE; además, no soporta subnormales en salida.
• CDNA 3 (MI300A/300X) introduce una lógica completamente distinta: acumula productos pares e impares por separado (interleaving), aplica dos pasos de redondeo RD antes del RNE final, y es la única de las tres con soporte para fp8.

La consecuencia práctica para un founder es que un kernel numéricamente estable en MI100 puede no serlo en MI300X, aunque ambos sean "AMD Instinct". El paper ofrece los vectores de prueba exactos para detectar estas diferencias antes de desplegar.

AMD Matrix Cores vs NVIDIA Tensor Cores: dos filosofías

La sección 6 del paper compara directamente las decisiones de diseño de AMD y NVIDIA. NVIDIA (Volta, Ampere, Ada, Hopper, Blackwell) usa redondeo RTZ (hacia cero) en la salida, mientras que AMD usa RNE (al más cercano). En fp8 y tf32, NVIDIA emplea acumuladores tempranos y AMD acumuladores tardíos. En fp16/bf16, AMD CDNA 3 ofrece dos bits extra de alineación que acercan su comportamiento al redondeo correcto.

En las aplicaciones demostrativas (multi-word arithmetic y un algoritmo SMD de procesamiento de señales banda-ancha del paper de Redif et al., 2015), los modelos de AMD y NVIDIA divergen. Por ejemplo, en fp8-e5m2 con 6 palabras de baja precisión, el NVIDIA B200 acumula errores visiblemente mayores que el MI300X a medida que crece la dimensión interna. En fp16, las diferencias entre MI300X, MI100 y B200 se mantienen pequeñas pero no nulas, suficiente para degradar algoritmos iterativos que dependen de precisión acumulada.

Por qué un founder debería prestarle atención

Los "Matrix Cores" o "Tensor Cores" son las unidades que ejecutan la mayor parte del trabajo en entrenamiento e inferencia de modelos grandes. Cuando un benchmark reporta "1.305 TFLOPS en BF16" para el MI300X (dato confirmado en la ficha técnica del fabricante recogida por Lenovo Press), esa cifra es un techo teórico; el comportamiento real depende de cómo el hardware redondea, normaliza y acumula esos productos.

Para una startup que evalúa dónde correr su inferencia, este paper trae tres implicancias concretas:

• Reproducibilidad entre GPUs no está garantizada por software. Si cambias de MI300X a H100, o incluso entre MI100 y MI300X, los resultados numéricos pueden divergir aunque uses el mismo framework y el mismo modelo. Esto importa si tu producto depende de outputs deterministas (scoring crediticio, recomendación, simulaciones científicas).
• La elección de precisión (fp8 vs bf16 vs fp16) no es trivial. En el experimento SMD del paper, fp8 resultó "inadecuado" para el caso estudiado por la magnitud de las desviaciones. Elegir el formato más rápido sin medir el error puede romper pipelines aguas abajo.
• El ecosistema ROCm importa más que las specs en crudo. El paper entrega los modelos en MATLAB (con compatibilidad Octave y Python vía Oct2Py), permitiendo simular el comportamiento numérico del hardware sin comprar GPUs. Para founders con presupuesto limitado, esto significa que pueden predecir el error antes de gastar en infraestructura.

Qué puedes hacer hoy con este trabajo

1. Si entrenas o sirves LLMs en AMD Instinct, descarga el toolbox MATLAB del repositorio del paper y reemplaza tus kernels más sensibles por las versiones bit-exactas. Vas a poder reproducir el resultado exacto que daría el hardware real sin ejecutarlo en una GPU.

2. Si estás migrando de NVIDIA a AMD (o al revés), corre los vectores de prueba del paper sobre tu modelo en ambos backends. Las diferencias que el paper documenta (modo de redondeo, manejo de subnormales, acumulación pares/impares) son las que explican buena parte de los "bugs fantasma" que aparecen en porting.

3. Si tu startup consume GPUs en la nube, usa este tipo de modelos para elegir el formato de cuantización que minimice el error en tu caso concreto antes de comprometerte con fp8 o int8. La diferencia entre un modelo que funciona y uno que degrada la métrica de negocio puede estar escondida en estos detalles numéricos que las hojas de especificaciones no documentan.

Fuentes

• Accurate Models of AMD Matrix Cores — arXiv (fuente original)
• Accurate Models of AMD Matrix Cores — HTML completo en arXiv
• ThinkSystem AMD MI300X 192GB 750W 8-GPU Board — Lenovo Press
• AMD MI300X Price 2026 — Cloud Rental vs H100 Cost — GPUCost
• MATLAB Tensor Core (modelos numéricos bit-exactos) — GitHub