Assisted-by en el commit: la evidencia que llama.cpp le exige a la IA

Cuando el código lo escribe una IA, el review humano no basta como red de seguridad. Menos todavía en rutas de bajo nivel: un kernel de multiplicación de matrices o un conversor de pesos no fallan con un stack trace, fallan con NaN, con un resultado ligeramente distinto, o con una lectura fuera de límites que corrompe memoria en silencio. Esta semana, los commits de llama.cpp muestran cómo un proyecto de esa escala está resolviendo ese problema: no confía en que el código de IA esté bien porque compila, exige que venga acompañado de evidencia numérica verificable.

El patrón

En el port del modelo Kimi-K3, la arquitectura combina atención híbrida KDA (lineal) más MLA (completa), MoE latente y una activación “situ” que reemplaza SwiGLU en todas partes, además de una compuerta MLA antes de la proyección de salida. Es exactamente el tipo de cambio donde un error sutil de implementación no rompe la ejecución: solo degrada la calidad del modelo de forma difícil de notar a simple vista. El commit, marcado “Assisted-By: Claude Opus 5 (1M context)”, no se conformó con decir que el código estaba probado. Reportó los números: los logits en la posición final contra la referencia en fp32 dieron un error relativo de 6.7e-05 y una correlación de 1.00000000, tanto en el camino chunked como en el recurrente del delta-net. Los bloques MXFP4 repackeados dequantizan a los pesos originales con 0.0e+00 de error.

El siguiente commit de la misma serie, también asistido por Claude Opus 5, corrigió errores de tipos en el conversor Python. De nuevo, no alcanzó con decir “sin cambio de comportamiento”: el commit repite la medición, esta vez con 8.386e-03 de error relativo y 0.99996630 de correlación en los logits de punta a punta. Y el formato de chat de Kimi-K3, atribuido a “Claude Fable 5”, se verificó de punta a punta contra el modelo completo corriendo en 8x B200, comprobando contenido, reasoning_content, deltas de streaming y tool_calls.

El mismo patrón aparece en bugs, no solo en features nuevas. Un fix en el kernel Vulkan de flash attention corrige un cálculo de cuantización de Q que podía dividir por un número denormalizado y desbordar: la nota del commit dice literalmente que fue Codex quien encontró el problema. Y un fix en el kernel Metal de multiplicación de matrices corrigió un caso donde el tile final de K, cuando no es múltiplo de 32, leía elementos fuera del rango válido del tensor: comportamiento indefinido según la especificación de MSL, que dependiendo del contenido residual de memoria podía corromper el resultado o producir NaN. Ese commit, marcado “Assisted-by: pi:llama.cpp/Qwen3.8-27B”, no se limitó a arreglar el cálculo: agregó casos de test-backend-ops con K no múltiplo de 32 para ejercer específicamente el camino que había fallado.

Por qué importa

Ninguno de estos bugs habría producido un crash. Todos habrían producido resultados plausibles pero incorrectos, el peor tipo de falla en un sistema de inferencia: pasa los tests superficiales, pasa el review visual del diff, y solo se nota cuando alguien compara salidas con cuidado o cuando un usuario reporta que el modelo “se comporta raro” sin poder decir por qué. La única defensa real contra ese tipo de falla es la que aparece en estos commits: una referencia contra la cual medir, una métrica de error explícita, y un test de regresión que reproduce exactamente el caso límite que rompió.

Eso es lo que distingue código “probablemente funciona” de código verificado: no es que el código de IA sea confiable por venir de un modelo grande, es que el flujo de aceptación de estos parches obliga a mostrar el número, no solo a afirmar que “no hay cambio de comportamiento”.

Reglas

Si vas a aceptar código escrito por IA en una ruta numérica o de bajo nivel (kernels, cuantización, conversión de formatos, parsers binarios):

• Exige una referencia independiente contra la cual comparar: otro framework, otra implementación, o el mismo código en fp32 sin optimizar. Sin esa referencia, “el output se ve bien” no es una verificación.
• Pide la métrica, no la afirmación. “Sin cambio de comportamiento” sin un número de error relativo o correlación es una promesa, no una prueba.
• Cuando el bug es de límites o de tipo numérico (denorm, overflow, lectura fuera de rango), el fix no está completo sin un test que reproduzca exactamente ese caso límite. Si el caso que rompió no queda en la suite, va a volver a romper.
• Trata la ausencia de crash como una señal débil en rutas numéricas: el resultado corrupto y silencioso es más peligroso que la excepción, porque no avisa.

Fuentes: https://github.com/ggml-org/llama.cpp/releases/tag/b10448, https://github.com/ggml-org/llama.cpp/releases/tag/b10539, https://github.com/ggml-org/llama.cpp/releases/tag/b10545