Ejecutar un modelo de lenguaje en el ordenador de casa dejó de ser una rareza de laboratorio, y buena parte del mérito es de un repositorio escrito en C y C++ que casi nadie instala a mano. llama.cpp llegó el 13 de noviembre de 2026 a la versión 1.0.0, el mismo día que ggml, la librería de tensores que lo sostiene. El anuncio de la versión mayor no promete más velocidad, sino algo menos vistoso y más útil: un número que avise cuando algo deje de funcionar.
Detrás hay una decisión práctica. Las aplicaciones que hablan con esa librería no la copian: la llaman, y esperan que las funciones que usaban ayer sigan respondiendo mañana. El proyecto admite modelos comprimidos, reparte el trabajo entre memoria y tarjetas gráficas y lo ejecuta desde un portátil hasta un servidor con varias tarjetas gráficas, de modo que cada versión nueva aterriza en programas que sus autores no controlan.
Con ese peso encima, un cambio de firma en una función es una factura para terceros. De ahí la 1.0: a partir de ahora, cualquier incompatibilidad en la interfaz pública obligará a subir el número mayor. El anuncio no toca la licencia MIT ni cambia quién manda en el proyecto, y esa ausencia también informa de lo que la versión es y de lo que no es.
Nueve días separan la 0.9.0 de la 1.0.0
La etiqueta anterior, la 0.9.0, se publicó el 4 de noviembre de 2026, nueve días antes. Entre una y otra siguieron cayendo compilaciones con numeración bXXXXX, la serie con la que el proyecto lleva tiempo entregando código recién horneado. La 1.0.0 salió con la b12359 como referencia inmediata.
El cambio de fondo no es una función nueva. Se retiran 35 declaraciones obsoletas de la cabecera principal, la función de calentamiento y el umbral de defragmentación de la caché, y promociona a la cabecera pública la API de decodificación especulativa NextN.
Las notas de la versión 1.0.0 detallan el resto: caché de expertos en memoria del sistema con una cuota de CPU configurable, FP8 para la caché de contexto y tres arquitecturas de texto nuevas. Ninguna de esas piezas justifica por sí sola un salto mayor; lo que lo justifica es el contrato que anuncian al mismo tiempo.
| Cambio en el código |
Nivel |
Qué le pasa a quien compila |
| Retirada de 35 funciones de `llama.h` y del umbral de defragmentación |
Mayor |
El programa deja de compilar hasta que se migre la llamada |
| La API NextN pasa de `llama-ext.h` a `llama.h` |
Menor |
Aparece una cabecera nueva y nada existente se rompe |
| FP8 en la caché de contexto con `-ctk f8_e4m3` |
Menor |
Quien no active la opción no toca una línea |
| Retirada de las operaciones `DIAG_MASK` en ggml |
Mayor |
Los kernels propios que las usaran dejan de compilar |
| Protocolo RPC que rechaza pares incompatibles |
Mayor |
Mezclar versiones deja de pasar desapercibido |
La regla que acompaña a la tabla es explícita: un cambio incompatible en la API C pública de `include/` implica número mayor, una función o un backend nuevos implican número menor, y una corrección sin tocar la API implica parche. La misma vara se aplica a ggml, la librería de tensores del proyecto, que también llegó a 1.0.0 el 13 de noviembre de 2026 con la API obsoleta podada.
El alcance declarado ayuda a medir el riesgo. El proyecto dice cubrir más de 150 variantes de arquitectura y todos los métodos principales de decodificación especulativa, una superficie que crece con cada modelo que aparece. Por esa puerta entran fichas como la de Nanbeige 4.3 33B y su licencia Apache, que solo sirven de algo si el motor reconoce la arquitectura el mismo día de la publicación.
El anuncio insiste en un punto que no es técnico. El equipo quiere seguir integrando modelos en su propio ciclo de desarrollo sin delegar el código en un tercero, y sostiene que mantener la arquitectura bajo control pesa más que publicar rápido. Eso encaja con que la 1.0 haya tardado tres años y medio en llegar.
Lo que compra quien empaqueta IA local
Un número mayor sirve de poco si nadie puede comprobarlo. La parte útil del compromiso está en el reparto: libllama y libggml se exponen mediante cabeceras en `include/`, y los backends se compilan como bibliotecas dinámicas que el programa carga en tiempo de ejecución. Ahí una incompatibilidad de ABI no produce un mensaje elegante, produce un fallo de carga.
Para un empaquetador de distribución, eso convierte la versión de la librería en información operativa y no en una curiosidad del registro de cambios: antes de subir un paquete hay que saber si el salto toca lo que el paquete ya usa.
Las vías de distribución que enumera el anuncio incluyen paquetes para Debian y Homebrew, artefactos para Android e iOS y una imagen Docker, además de conda-forge, MacPorts y Winget. Los binarios previos al lanzamiento cubren Linux y macOS, y también Windows, Android e iOS con el mismo código. Cada vía arrastra su propia política de congelación, parecida a la que ordena cualquier ciclo de publicación de Linux 7.4.
El ecosistema que se apoya en esta librería es amplio y en buena parte invisible. La documentación de Ollama reconoce llama.cpp como su backend, y el repositorio incluye instrucciones para compilar en Android, lo que explica que la base esté también en clientes móviles. La comparativa entre Ollama, llama.cpp, vLLM y TGI ordena qué aporta cada motor, aunque todos comparten la misma dependencia de fondo: alguien decide cuándo cambia la interfaz.
Durante buena parte de su historia, la referencia práctica para quien integraba la librería era el número de compilación. Una etiqueta como b12374 describe un árbol de código concreto y una fecha, mientras que una versión 0.x apenas decía algo sobre lo que había dentro. Ese hueco es justo el que la 1.0 pretende cerrar.
El día que cambia el driver y no la cabecera
La promesa cubre el código, no el entorno. Las notas de la 1.0.0 incluyen un salto de las compilaciones de CUDA a la 13.5, la reactivación de una configuración de multiplicación de matrices en Vulkan solo con el driver propietario de AMD 26.10.1 o superior y una actualización a oneAPI 2026.2 con oneDNN 2026.1. Nada de eso rompe la API y todo eso rompe instalaciones.
Quien compila desde el código fuente solo necesita un compilador. Quien descarga un binario hereda la versión de CUDA, de Metal o del SDK que usó el servidor de integración, y esa cadena es la que falla en un portátil de 2021.
El anuncio sostiene ese frente con infraestructura. El proyecto agradece el hardware de seis fabricantes, entre ellos NVIDIA y AMD, y describe una red de servidores propios de integración para probar cada cambio en todas las plataformas, apoyada en recursos de computación que se alquilan por horas. La lista de fabricantes es también la lista de formas distintas de romper un binario.
Un motor de inferencia que cambia una firma sin avisar traslada el coste a quien lo empaqueta: hay que leer el código de cada versión para saber si el programa sigue compilando. La diferencia con este anuncio no está en la calidad del software, está en que el aviso llega antes de la descarga y no después del fallo. Un binario oficial se compila contra un conjunto fijo de herramientas, así que un driver más antiguo que ese conjunto puede impedir que arranque la biblioteca del backend aunque la cabecera coincida.
Una cifra que se puede auditar
La 1.0 no cambia lo que el proyecto es, cambia lo que promete por escrito. Cualquier salto mayor futuro quedará a la vista en la cabecera pública, y cualquiera podrá comprobar si el número dijo la verdad sobre lo que se rompía. Es un estándar bajo y, a la vez, más exigente que el de buena parte de los proyectos que viven del mismo público.
La prueba llegará con la próxima incompatibilidad anunciada, no con esta. Entonces se verá si el número mayor funcionó como contrato o solo como una etiqueta con más ceros que antes, y si los paquetes de las distribuciones lo leyeron a tiempo.
