🤖 machine learning

Demystifying Numerical Instability in LLM Inference: Achieving Reproducible Inference for Mission-Critical Tasks with HEAL

Este artículo presenta HEAL, un marco híbrido de mitigación de errores que logra la reproducibilidad de la inferencia de LLM de misión crítica a través de GPUs heterogéneas mediante la combinación de cuantización INT16 para tensores KV con compensación de error algebraica en Tensor Cores de 16 bits, eliminando así la divergencia catastrófica de salida sin los costos prohibitivos de rendimiento y memoria de un pipeline global de FP32.

Autores originales: Zhenting Zhu, Lucas Thai, Shan Yu, Yicheng Liu, Yifan Qiao, Chenxi Wang, Harry Xu, Junyi Shu

Publicado 2026-06-23

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Zhenting Zhu, Lucas Thai, Shan Yu, Yicheng Liu, Yifan Qiao, Chenxi Wang, Harry Xu, Junyi Shu

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

El Gran Problema: La "Mano Temblorosa" de la IA

Imagine que usted es un juez en un tribunal de alto riesgo (como un diagnóstico médico o un fallo legal). Necesita que un testigo (la IA) le dé exactamente el mismo testimonio cada vez que le haga la misma pregunta, independientemente de qué micrófono o estudio de grabación utilice.

En el mundo de los Modelos de Lenguaje Extensos (LLM), esto es actualmente una pesadilla. Incluso si le hace a la IA exactamente la misma pregunta dos veces, usando exactamente la misma configuración, la respuesta puede cambiar ligeramente.

Escenario: Usted pregunta: "¿Cuál es el código para esta enfermedad?".
Ejecución 1: La IA dice "Código A".
Ejecución 2: La IA dice "Código B".

En un chat casual, esto no importa. Pero en finanzas, medicina o derecho, una sola letra errónea puede ser un desastre. El artículo llama a esto no reproducibilidad.

La Investigación: ¿Por qué está temblando la IA?

Los investigadores (de UCLA, Berkeley, etc.) querían saber: ¿Por qué la IA cambia de opinión?

Sospechaban que la IA estaba haciendo matemáticas de una forma "difusa". Para encontrar al culpable, miraron bajo el capó de los chips de computadora (GPUs) que ejecutan estos modelos.

El Malentendido:
La mayoría de la gente pensaba que la IA estaba haciendo todas sus matemáticas con baja precisión (como usar una regla que solo tiene marcas grandes y toscas) porque eso es más rápido. Pensaban que la "difusidad" provenía de las matemáticas en sí.

El Verdadero Culpable (El "Límite del Kernel"):
Los investigadores descubrieron que las matemáticas dentro del chip son en realidad muy precisas (como usar una regla medida con láser). El problema ocurre en los límites —las puertas entre diferentes partes del cálculo.

La Analogía: La Cadena de Cubetas
Imagine un equipo de trabajadores pasando cubetas de agua (datos) en una línea para apagar un incendio.

Dentro de las manos: Los trabajadores sostienen las cubetas perfectamente estables (las matemáticas dentro del chip son precisas).
El traspaso: Cuando un trabajador pasa la cubeta al siguiente, tiene que verter el contenido en un recipiente ligeramente diferente.
El derrame: Cada vez que vierten, se derrama una pequeña gota de agua.
El resultado: Si la línea es corta, una gota no importa. Pero en un LLM, la línea tiene millas de largo (miles de capas). Esas pequeñas gotas se acumulan. Para cuando el agua llega al final, la cubeta está vacía o tiene la cantidad incorrecta, lo que hace que la IA elija la respuesta equivocada.

Este "derrame" ocurre porque la computadora guarda el agua en un contenedor más pequeño (menor precisión) para ahorrar espacio, perdiendo un poco de detalle cada vez que mueve los datos.

Las Soluciones Antiguas: El Enfoque de "Fuerza Bruta"

Antes de este artículo, había dos formas de solucionar esto, y ambas eran terribles:

El Método de "Orden Estricto": Obligar a los trabajadores a pasar las cubetas en un orden específico y rígido para que nadie se confunda.
- Desventaja: Es increíblemente lento y solo funciona en tipos específicos de hardware. Si cambia a una marca diferente de GPU, se rompe.
El Método de la "Cubeta Grande": Dejar de usar contenedores pequeños por completo. Usar cubetas gigantes, pesadas y ultra precisas (FP32) para toda la línea.
- Desventaja: Son tan pesadas que los trabajadores se mueven en cámara lenta. La IA se vuelve 13 veces más lenta, lo que la hace inútil para aplicaciones en tiempo real.

La Nueva Solución: HEAL (Alivio de Errores Híbrido)

Los autores proponen un punto medio inteligente llamado HEAL. En lugar de hacer toda la línea pesada o rígida, ellos arreglan los puntos específicos donde el agua se derrama.

1. El Truco del "Empaquetado Inteligente" (Para la Atención)

El Problema: Las cubetas de "Clave" (Key) y "Valor" (Value) (datos usados para la atención) suelen estar mayormente vacías o tienen números simples. Usar una cubeta gigante para ellos es un desperdulo.
La Solución: HEAL utiliza una "cinta de embalaje" especial (cuantización INT16). Comprime los datos en un paquete más pequeño y ajustado que encaja perfectamente.
La Magia: Aunque el paquete es pequeño, los trabajadores lo desempaquetan en dos cubetas más pequeñas (Dual-FP16) para hacer las matemáticas. Esto mantiene el nivel del agua alto (preciso) sin necesidad de las cubetas gigantes y pesadas que ralentizan todo.

2. El Truco de la "Compensación de Errores" (Para las Matemáticas)

El Problema: Al realizar matemáticas pesadas (GEMM), las cubetas estándar pierden un poco de precisión.
La Solución: HEAL divide las matemáticas en dos pasos.
- Paso A: Hacer la matemática principal con la cubeta estándar.
- Paso B: Hacer una matemática rápida de "limpieza" con una cubeta diminuta para atrapar las pequeñas gotas que se derramaron en el Paso A.
- Resultado: Obtiene la precisión de la cubeta gigante, pero solo usa las cubetas rápidas y ligeras para el trabajo pesado.

Los Resultados: Rápido, Preciso y Confiable

Los investigadores probaron este nuevo método en un nuevo benchmark que crearon llamado MCR-Bench (Benchmark de Reproducibilidad para Misiones Críticas), que incluye preguntas difíciles de medicina, derecho y finanzas.

Reproducibilidad: HEAL logró el mismo nivel de "consistencia perfecta" que el método lento y pesado de la "Cubeta Grande".
Velocidad: Fue 7.1 veces más rápido que el método pesado.
Memoria: No requirió memoria adicional, a diferencia del método pesado que duplicaba las necesidades de memoria.

La Conclusión

El artículo demuestra que no necesitamos ralentizar todo el proceso de la IA para hacerla confiable. Solo necesitamos parchar los "agujeros" específicos donde se pierden los datos durante los traspasos.

En pocas palabras:
En lugar de reemplazar todo el motor de un coche de carreras por un motor de tractor lento y pesado para asegurar que no se detenga, los autores encontraron la manera de apretar los tornillos del motor existente. El coche (la IA) ahora corre tan confiablemente como el tractor, pero sigue siendo lo suficientemente rápido como para ganar la carrera.

Resumen Técnico: Desmitificando la Inestabilidad Numérica en la Inferencia de LLM con HEAL

Declaración del Problema

A medida que los Modelos de Lenguaje de Gran Escala (LLMs) se despliegan en dominios de misión crítica como las finanzas, la medicina y el derecho, la reproducibilidad de los resultados se ha convertido en un requisito estricto del sistema. Aunque los profesionales suelen emplear la decodificación codiciosa (greedy decoding) para eliminar la estocasticidad algorítmica, los despliegues empíricos utilizando precisiones de 16 bits (por ejemplo, BF16) aún exhiben una divergencia de salida catastrófica a través de hardware heterogéneo (por ejemplo, diferentes generaciones de GPUs de NVIDIA o aceleradores de AMD).

Las estrategias de mitigación existentes enfrentan un dilema inaceptable:

Determinismo Estricto a Nivel de Bit: Imponer órdenes de reducción de punto flotante deterministas o utilizar kernels especializados restringe el despliegue a rutas de ejecución estrechas, deshabilita las características del hardware moderno y sacrifica el rendimiento (throughput).
Pipelines Globales de Alta Precisión: Realizar todos los cálculos en FP32 elimina el ruido por truncamiento, pero incurre en penalizaciones de sistema prohibitivas. Servir enteramente en FP32 puede aumentar el Tiempo por Token de Salida (TPOT) hasta en 13.1× y duplica la huella de memoria del caché de Clave-Valor (KV), lo que resulta económicamente impráctico para el servicio a gran escala.

El desafío central es lograr una reproducibilidad robusta y lista para el despliegue sin sacrificar la eficiencia de los aceleradores de hardware de 16 bits.

Metodología: HEAL (Alivio de Errores Híbrido)

Los autores proponen HEAL, una intervención dirigida que aproxima la reproducibilidad de nivel FP32 mientras se adhiere a las restricciones del hardware. La metodología se fundamenta en una investigación sistemática de las causas raíz de la no-reproducibilidad, pasando de un fallo macroscópico a sus orígenes microscópicos.

1. Análisis de la Causa Raíz

A través de la profilación a nivel de SASS y la descomposición de errores, el artículo identifica que la no-reproducibilidad no es impulsada por la aritmética interna de los kernels (que opera predominantemente en FP32 mediante Tensor Cores), sino por los errores de truncamiento introducidos durante el reescalado (downcasting) en los límites de los kernels.

Origen Microscópico: La inestabilidad surge del truncamiento obligatorio de registros de alta precisión a formatos de almacenamiento de menor precisión en los límites de los kernels (por ejemplo, al escribir resultados de acumuladores FP32 de vuelta a la memoria BF16).
Acumulación: Estas pérdidas microscópicas de precisión fraccionaria se acumulan exponencialmente a través de las capas de la red. Una vez que el error acumulado traspasa un umbral específico, desplaza las log-probabilidades finales lo suficiente como para alterar la selección del token top-1, causando un "cambio de resultado" (result flipping).
Perspectiva Clave: La reproducibilidad robusta no requiere una paridad matemática estricta con una verdad de referencia (ground truth) en FP32; solo requiere acotar el ruido numérico por debajo del umbral que dispara el cambio de resultado.

2. La Solución HEAL

HEAL aborda los dos cuellos de botella primarios de un pipeline global de FP32 (Memoria para Atención, Cómputo para GEMM) mediante dos mecanismos dirigidos:

A. Mitigación del Truncamiento de Atención mediante Cuantización INT16

Problema: El escalado ascendente (upcasting) de los cachés de Clave-Valor (KV) a FP32 duplica el uso de memoria, creando un cuello de botella de memoria.
Solución: HEAL reconoce que los formatos de punto flotante estándar subutilizan su ancho de bits para los tensores Q, K y V. Aplica una cuantización INT16 para almacenar estos tensores.
Mecanismo: Durante la ejecución, el tensor INT16 se desempaqueta algebraicamente en dos tensores FP16 ( $X_{hi}$ y $X_{lo}$ ). El tensor inferior se desplaza por un factor de $2^{10}$ , permitiendo que el par $(X_{hi} + X_{lo}/2^{10})$ emule 20 bits de precisión fraccionaria continua.
Beneficio: Esto preserva la huella de memoria estricta de 16 bits del caché KV mientras reduce significativamente el error de truncamiento, previniendo efectivamente la divergencia sin expandir el uso de memoria.

B. Mitigación del Truncamiento de GEMM mediante Compensación de Error Algebraica

Problema: El escalado ascendente de las entradas de GEMM a FP32 obliga al hardware a omitir los Tensor Cores de 16 bits de alto rendimiento, causando una severa regresión de rendimiento.
Solución: HEAL sintetiza multiplicaciones de matrices de alta precisión utilizando una estrategia de compensación de error algebraica ejecutada enteramente en Tensor Cores de 16 bits.
Mecanismo: Las activaciones de entrada se descomponen en un valor primario de 16 bits y un término de error residual. El sistema realiza dos multiplicaciones de matrices paralelas utilizando entradas estándar de 16 bits y suma los resultados. Esto captura el error de truncamiento manteniendo el rendimiento del hardware nativo de 16 bits.
Manejo de Desbordamiento (Overflow): Para abordar el estrecho rango dinámico de FP16, HEAL aplica un reescalado dirigido a canales atípicos (outliers) poco frecuentes (que constituyen <1% de los canales fijos) para evitar desbordamientos catastróficos sin añadir una sobrecarga significativa.

Contribuciones Clave

Diagnóstico de la Inestabilidad: El artículo demuestra que la no-reproducibilidad intrínseca es impulsada fundamentalmente por errores de truncamiento en los límites más que por la no-asociatividad aritmética interna. Establece que la reproducibilidad robusta requiere acotar este ruido por debajo de un umbral específico de cambio de resultado.
Marco de Trabajo HEAL: Introduce una solución de dos vertientes que evita las penalizaciones de hardware salvaguardando la Atención mediante cuantización INT16 y sintetizando GEMM de alta precisión mediante compensación de error algebraica.
MCR-Bench: Introduce el Benchmark de Reproducibilidad para Misiones Críticas, un nuevo conjunto de evaluación dirigido a la reproducibilidad en dominios de alto riesgo (médico, legal, financiero) donde la consistencia del resultado es primordial.
Compromiso Eficiencia-Reproducibilidad: Demuestra que HEAL logra una reproducibilidad de nivel FP32 para tareas descendentes (downstream) en diversos tipos de hardware, reduando la sobrecarga de rendimiento en hasta 7.1× en comparación con los pipelines completos de FP32.

Resultados

Evaluado a través de cinco modelos (Qwen3-8B/14B/32B, Llama-3.1-8B, DeepSeek-R1-Distill-Qwen-14B) y tres tipos de hardware (NVIDIA A100, H100, AMD MI300X):

Reproducibilidad: HEAL-Full (el pipeline híbrido completo) logra una tasa de cambio de respuesta (answer flip rate) y un MSE de la Capa Oculta Final casi idénticos a la línea base de FP32 (por ejemplo, 0.0% de tasa de cambio para Llama-8B y DeepSeek-14B, comparado con 11.7% y 12.8% para el BF16 nativo).
Sobrecarga de Rendimiento:
- Línea Base FP32: Aumenta el TPOT de 4.2× a 13.1×.
- HEAL-Full: Incurre en solo una sobrecarga de TPOT del 40%–109% respecto a la línea base de BF16 nativo.
- Memoria: HEAL mantiene la huella de memoria de 16 bits para el caché KV, evitando la expansión de memoria de 2× requerida por el escalado ascendente completo a FP32.
Agnosticismo de Hardware: El error numérico acumulado permanece constante a través de diferentes tipos de hardware bajo configuraciones de precisión fija, confirmando que HEAL neutraliza eficazmente la divergencia específica del hardware.

Significancia

El artículo sostiene que la suposición de que se requiere un costo de "todo o nada" de los pipelines de alta precisión completa para una reproducibilidad robusta es incorrecta. Al identificar que la no-reproducibilidad es una sensibilidad localizada a características atípicas específicas (truncamiento de límites) en lugar de un problema de ruido generalizado, HEAL restaura el comportamiento determinista a través de hardware heterogéneo. Crucialmente, el método logra esta estabilidad actualizando menos del 1% del cómputo total (vía compensación algebraica) y optimizando los formatos de almacenamiento, ofreciendo un camino práctico para desplegar LLMs en entornos de misión crítica donde se requieren salidas numéricas exactas sin la carga económica de la inferencia completa en FP32.