Cómo superar la no determinación en la inferencia de LLM
(thinkingmachines.ai)- En la inferencia de LLM (modelos de lenguaje grandes) aparece un problema de no determinación (nondeterminism): incluso con la misma entrada y las mismas condiciones, los resultados pueden variar
- Hasta ahora, se consideraba que las causas principales de la no determinación eran la concurrencia (concurrency) y la no asociatividad (non-associativity) de las operaciones de punto flotante (floating-point)
- La causa realmente determinante proviene del cambio en el orden de cálculo dentro del kernel (código de operación) según varía el tamaño del batch (batch size)
- Si todas las operaciones dentro del kernel se implementan para que tengan invariancia al batch (batch invariance), es posible garantizar una reproducibilidad (reproducibility) completa
- Con operaciones paralelas de datos, split reduction y estrategias de split de tamaño fijo, es posible construir kernels invariantes al batch para operaciones clave como RMSNorm, matmul y attention
Introducción y panorama del problema
- La reproducibilidad, un elemento central del progreso científico, no se respeta bien en la inferencia de LLM (modelos de lenguaje grandes)
- Incluso si se hace la misma pregunta a ChatGPT varias veces, con frecuencia se generan respuestas distintas
- Esto se debe a que el proceso de sampling en los LLM se basa en una selección probabilística a partir de una distribución de probabilidad
- Sin embargo, incluso si se establece temperature en 0, en la práctica una API de LLM no es necesariamente determinista (es decir, no siempre produce el mismo resultado para la misma entrada)
- El problema de la no determinación también existe al ejecutar bibliotecas open source de inferencia (como vLLM, SGLang, etc.) y en hardware propio
Hipótesis previas y limitaciones
- Hipótesis ampliamente difundida: la no determinación ocurre por concurrencia + no asociatividad del punto flotante
- En GPU, las operaciones de punto flotante cambian sutilmente según el orden de las operaciones y el orden en que terminan los hilos
- Sin embargo, en la práctica, incluso si se repite la multiplicación de matrices de los mismos datos de la misma forma, siempre se obtiene el mismo resultado (bw=bitwise equal)
- Para identificar la causa real, se necesita un análisis más profundo
Análisis profundo de las causas de la no determinación en la inferencia de LLM
La naturaleza de la no asociatividad del punto flotante
- Las operaciones de punto flotante cumplen la relación (a+b)+c ≠ a+(b+c)
- Al operar valores de distinto tamaño (exponent), hay pérdida de precisión y de información, y el resultado cambia según el orden de las operaciones
- Como el orden de las operaciones puede variar, si varias sumas se ejecutan de manera aleatoria se obtienen resultados diversos (confirmado también experimentalmente)
Cambio en el orden de operaciones dentro del kernel y concurrencia
- Normalmente se señala la concurrencia en operaciones como atomic add como la causa principal de la no determinación
- Pero la mayoría de los kernels usados en la inferencia de LLM (especialmente en el forward pass) funcionan incluso sin atomic add
- Con una estrategia de paralelización adecuada y técnicas como split (reduction), se puede asegurar el mismo orden de operaciones
La verdadera causa clave: falta de "invariancia al batch (batch invariance)"
- Cada kernel individual, si la entrada es la misma, siempre devuelve el mismo resultado (run-to-run deterministic)
- Pero como las solicitudes simultáneas de varios usuarios (batch size) cambian de forma no determinista, en la práctica los resultados no son consistentes para cada solicitud
- Según el tamaño del batch, el orden interno en que se dividen o combinan las operaciones cambia, lo que produce no determinación
- En otras palabras, la causa principal era que la carga del servidor y el paralelismo (tamaño del batch) eran no deterministas
Diseño de kernels invariantes al batch y casos clave de operaciones
RMSNorm
- Se aplica una estrategia de paralelización de datos (data-parallel): cada elemento del batch es procesado de forma independiente por un núcleo
- Si el tamaño del batch es grande, se mantiene suficiente paralelismo; es decir, la estrategia paralela permanece constante y se asegura la invariancia al batch
- Cuando el tamaño del batch es muy pequeño, se usan estrategias alternativas como split reduction, aunque en ese caso se sacrifica parte de la invariancia al batch
Multiplicación de matrices (matmul)
- Se usa una estrategia paralela de datos mediante paralelización por tile
- Para optimizar el uso de Tensor Cores, se debe dividir en tiles 2D, y cuando el batch es muy pequeño se requieren estrategias especiales como split-K
- Al usar la estrategia split-K, puede romperse la invariancia al batch
- Aunque se sacrifique algo de rendimiento, es posible asegurar un orden de operaciones constante (reproducible) forzando la misma configuración de kernel
Attention
- En FlashAttention2 y similares, se asegura la invariancia al batch con una estrategia de paralelización en la dirección de query y reducción simultánea de Key/Value
- Si el orden de reduction cambia según el tamaño del batch o la división de secuencias (chunked prefill, prefix caching, etc.), la invariancia se rompe
- En estrategias de split-reduction como split-KV (FlashDecoding), se mantiene el mismo orden de operaciones fijando el tamaño de split (fixed split-size)
- Por el funcionamiento interno, no se deben procesar por separado la caché de key/value y los tokens nuevos; en cambio, hay que mantener un layout coherente de key/value en todas las operaciones
Implementación
- Se presenta un demo de inferencia determinista usando batch-invariant kernels con vLLM y torch.Library
- Los kernels de reemplazo para las operaciones relacionadas pueden revisarse en el repositorio de GitHub (thinking-machines-lab/batch-invariant-ops)
Experimentos y rendimiento
Experimento de medición de la no determinación
- Con el modelo Qwen/Qwen3-235B-A22B-Instruct-2507, se generó 1000 veces el mismo prompt (“Tell me about Richard Feynman”) con temperature 0
- Se produjeron 80 completions distintas (el prompt era idéntico, pero existía no determinación)
- Hasta los primeros 102 tokens el resultado fue igual; la primera bifurcación ocurrió en el token 103 (“Queens, New York” vs “New York City”)
- Al usar kernels invariantes al batch, las 1000 ejecuciones dieron exactamente el mismo resultado, logrando reproducibilidad completa
Evaluación de rendimiento
- Con 1 GPU, ejecutando Qwen-3-8B, se procesaron 1000 solicitudes con secuencias de longitud entre 90 y 110
- vLLM base: 26 segundos
- vLLM deterministic sin optimizar: 55 segundos
- con kernel de attention mejorado: 42 segundos
- Aunque todavía falta optimización, se mantiene un nivel de rendimiento utilizable en la práctica
Valor en On-policy RL
- Hasta ahora, por pequeñas diferencias numéricas entre training e inference, on-policy RL no podía implementarse con exactitud
- Si se logra inferencia determinista, sampling y training pueden hacerse bitwise identical, lo que permite implementar un verdadero on-policy RL
- Se confirmó que métricas clave como KL-divergence y reward coinciden completamente
Conclusión
- En los sistemas de inferencia de LLM es fácil ignorar la no determinación y el error numérico, pero si se identifica y corrige la causa raíz (falta de invariancia al batch), se puede obtener reproducibilidad y determinismo completos
- Este estudio aclara una forma de resolver el problema de la no determinación en la inferencia de LLM y ayuda a los desarrolladores a asegurar reproducibilidad total dentro de sus propios sistemas
Información de cita
- Para citar este estudio, use la siguiente información
He, Horace and Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference",
Thinking Machines Lab: Connectionism, Sep 2025.
o bien
@article{he2025nondeterminism,
author = {Horace He and Thinking Machines Lab},
title = {Defeating Nondeterminism in LLM Inference},
journal = {Thinking Machines Lab: Connectionism},
year = {2025},
note = {https://thinkingmachines.ai/blog/…},
doi = {10.64434/tml.20250910}
}
1 comentarios
Opiniones en Hacker News
Incluso si se resolviera por completo la no determinación "teórica" en pares individuales de entrada-salida totalmente cerrados, seguirían quedando dos problemas reales de no determinación: que la misma entrada produzca resultados distintos según el contexto previo, y que una entrada ligeramente modificada no produzca un resultado correctamente modificado. Mientras esos problemas no se resuelvan, la no determinación en un sistema cerrado no ayuda demasiado, salvo en situaciones donde en realidad bastaría con una tabla de consulta. Es difícil demostrar algo con pruebas unitarias "correctas" o conjuntos de evaluación para entradas no probadas
La situación de "la misma entrada exacta produce resultados distintos según un contexto previo diferente" en realidad no existe. El contexto previo en sí es parte de la entrada. Si para un prompt dado siempre sale el mismo resultado, entonces puede decirse que el contexto está siendo ignorado. Es decir, equivale a empezar siempre con un contexto vacío sin importar el estado de la sesión. Lo que algunas personas quieren es,
¿Por qué sería un problema que el 'contexto previo' produzca un resultado diferente? Si el contexto no afecta el resultado, entonces simplemente se puede descartar. ¿Por qué querrías forzar ese comportamiento? De hecho, si es una herramienta, espero que responda distinto según mi intención o un cambio de modo (por ejemplo, en vim cambia el comportamiento al pasar a modo insert). También quisiera que la inteligencia funcionara así. Ignorar el contexto me parece más cercano a un sesgo de confirmación extremo
Es muy útil para reproducir bugs
Yo estaba de acuerdo hasta la parte de decir que "no ayuda mucho". Supongo que quisiste decir "no resuelve completamente el problema"
Me pregunto por qué hay tanta preocupación por el determinismo en sistemas probabilísticos. Desde la perspectiva del usuario, aunque a la entrada "How do I X?" siempre le diera la misma respuesta determinista, eso sirve de poco si entradas con el mismo significado como "how do i x?", "how do I x", "how do I X??" producen resultados completamente distintos. Lo que realmente hace falta en los LLM es la capacidad de garantizar que entradas semánticamente equivalentes produzcan siempre salidas semánticamente equivalentes. Eso es un concepto totalmente distinto del determinismo del que solemos hablar en algoritmos
No todas las aplicaciones basadas en LLM tienen una interfaz de chat improvisada para usuarios. Si estás ejecutando llamadas a herramientas 10 veces seguidas con fines de evaluación, o probando prompts de manera continua con herramientas como DSPy Optimizer enlace, y tienes control total hasta el nivel de tokens de entrada, reducir la imprevisibilidad importa. En ese entorno, si puedes eliminar la variación a nivel de token y dejar solo la ambigüedad de la propia entrada, puedes mapear el comportamiento del sistema con mucha más confianza a estructuras tipo árbol o grafo
Lo que dices no está mal, pero eso no significa que este nivel de determinismo sea inútil. Si aun metiendo exactamente los mismos tokens de entrada el resultado siempre cambia, se vuelve difícil reproducir y compartir resultados con colegas o probar situaciones donde el LLM genera salidas muy raras y difíciles de predecir (por ejemplo, red teaming)
Estoy trabajando en un proyecto para esconder información con esteganografía dentro de salidas de LLM: innocuous. Solo extraigo y uso algo así como los 10 tokens principales del modelo, y como hago pruebas principalmente con modelos 8B basados en CPU, no me preocupa demasiado que el hardware cambie el orden de los tokens, pero eventualmente pienso crear una condición de resguardo para evitar que una pérdida sutil de precisión cambie la elección
Puede ser muy útil para clientes de plataformas de IA. Puedes ejecutar varias veces el prompt con temperature 0 y verificar si el resultado siempre es el mismo, para confirmar si el proveedor de IA te está cambiando a escondidas el modelo PRO por otro más barato
Para reproducir un "bug" es absolutamente necesario. Si al poner la misma cadena de entrada puedes reproducir exactamente la misma salida errónea o extraña cada vez, depurar se vuelve mucho más fácil. Si el resultado cambia una de cada 100 veces, se vuelve mucho más difícil
(Experiencia trabajando con JAX/XLA) Esto es bastante conocido. Yo también me topé muchas veces con este fenómeno (variabilidad a nivel de batch), y encontré la explicación en los siguientes issues: penzai issue #82, comentario en jax issue
A veces la no determinación viene de detalles de implementación. Por ejemplo, en el código fuente de GPT-2, aunque pongas temperature en 0 desde la GUI, en realidad se usa un valor de "epsilon" distinto de cero, aunque muy pequeño. Eso es razonable porque evita un error de division by zero. La no determinación es "inútil" en muchas aplicaciones. También es un problema viejo en los modelos de temas LDA. En especial en ámbitos legales, financieros o regulatorios, usar métodos no deterministas podría incluso ser ilegal. O podría acarrear obligaciones adicionales no deseadas, como tener que conservar todas las grabaciones de pantalla para poder reconstruir después, paso por paso, lo que ocurrió
Sale el tema de "trabajar con otros en Thinking Machines". Me da nostalgia acordarme de cuando podía ver en persona esa máquina con cubos LED rojos brillando frente al MIT AI Lab. Richard Feynman hizo cosas realmente geniales, y hay un texto relacionado: Feynman and the Connection Machine. En Estados Unidos, la marca “THINKING MACHINES” no fue registrada por Hillis sino por la empresa que fundó, y fue cancelada en 1998–1999. La empresa quebró en 1994 y sus activos pasaron a Sun Microsystems (y luego a Oracle), entre otros. Thinking Machines Lab Inc., fundada por Amira Murati, está tramitando una nueva solicitud de marca para “THINKING MACHINES” en 2025
Da mucho gusto ver recientemente discusiones de investigación tipo blog con tanta calidad. Anthropic está impulsando esta cultura y parece que cada vez se extiende más, lo cual da bastante esperanza. En la época anterior de investigación en RL, OpenAI también era así
El lenguaje natural en sí es ambiguo. Tiene que serlo. Creo que este intento de 'volver cuadrado el círculo y luego explicar por qué debería ser así' está equivocado. Estas discusiones terminarán evolucionando hacia una conversación sobre aceptar mejor la naturaleza del lenguaje y de la aleatoriedad, e interpretar el lenguaje en algo más que subpatrones mínimos de gramática como una matriz de proyección QKV
El nombre de la empresa todavía no me gusta. Me pregunto por qué este tipo de nombres sigue repitiéndose. No sé si es una especie de deseo de que el carácter de una organización legendaria se transfiera también a una startup nueva. No es como si ponerle PARC a tu próxima startup fuera a heredar automáticamente tu innovación en networking, ¿no?
¿Te refieres a la empresa “Thinking Machines” que desapareció en 1994? Yo solo lo supe después de buscarlo, y no me parece tan famosa como para que esa haya sido la intención. Me parece simplemente un nombre cool e intuitivo
Solo con ponerle ese nombre ya te llega marketing gratis, que es justo la razón por la que existe el sistema de marcas
Es realmente interesante. Para quienes no lo sepan, esta es la empresa que inició Mira Murati, ex CTO de OpenAI