Cómo superar la no determinación en la inferencia de LLM

• 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}
}