La biblioteca de inferencia local llama.cpp ha publicado la v1.0.0, y la biblioteca de tensores que le sirve de base, ggml, también ha pasado a la 1.0. El equipo del proyecto explica en el blog de Hugging Face que esta versión quiere ofrecer una base más estable a los desarrolladores que dependen de ella: de ahora en adelante, siempre que la API pública o la ABI de llama.cpp y ggml sea incompatible, se reflejará en un cambio de versión mayor.
Durante los últimos años, llama.cpp se publicaba casi únicamente mediante números de compilación que empiezan por b: cada vez que el código se integra en la rama principal sale una compilación nueva, y ya se ha superado b12000. Tras la 1.0, esa numeración no se detiene y sigue generándose como versión preliminar; lo que cambia es que ahora hay además una línea de versiones oficiales con compromiso, y quien lo use puede elegir según su necesidad.
Los números de versión ya significan algo
Las reglas que da el blog son claras: MAJOR corresponde a cambios que rompen la interfaz C pública del directorio ./include; MINOR, a nuevas funciones o soporte de modelos compatibles hacia atrás; PATCH solo corrige errores sin tocar la interfaz. Se aplica a todos los proyectos de ggml-org. El equipo escribe que, como cada vez hay más usuarios, a partir de ahora hará más estrictos y visibles esos límites.
Para arrancar limpio, la 1.0 empezó con una limpieza: eliminó una serie de interfaces públicas marcadas como obsoletas desde hace tiempo, renombró algunas funciones y añadió campos nuevos a la estructura de parámetros de contexto; en el lado de ggml, también se quitaron las API obsoletas y el antiguo operador DIAG_MASK. Para los desarrolladores que enlazan llama.cpp como biblioteca en sus propios productos, esta actualización obliga a modificar el código una vez; después, siguiendo las versiones menores, no tendrán que temer que una interfaz desaparezca de golpe en alguna compilación.
Qué añade esta versión
Además de las reglas de versionado, la propia 1.0 trae bastantes novedades:
- La caché KV admite FP8; se añade una caché de expertos MoE en la memoria del host, con proporción de cálculo en CPU configurable;
- Se incorpora soporte para modelos como Kimi-K3.1-Pro, y Kimi-K3.1 puede procesar entradas de imagen;
- llama-server suma la interfaz de síntesis de voz /v1/audio/speech, que funciona con el modelo TTS drama-3;
- En el lado del servidor se han corregido problemas de SSRF, CORS y DNS rebinding; las llamadas a herramientas sin autenticación y el acceso a URL privadas ahora deben activarse de forma explícita, y HF_TOKEN solo se envía a huggingface.co.
El último punto es el más práctico para quien monta sus propios servicios. llama-server suele usarse como interfaz local compatible con OpenAI dentro de la red interna, e incluso expuesta directamente a internet; si las llamadas a herramientas están abiertas por defecto, la superficie de riesgo crece con ellas. Pasar a la activación explícita devuelve la decisión a quien despliega.
La caché de expertos MoE apunta a la forma de modelo actual. La mayoría de los grandes modelos de este año usan arquitectura de mezcla de expertos, con un total de parámetros de varios cientos de miles de millones, de los que solo se activa una pequeña parte en cada paso. Cuando la memoria de vídeo no alcanza para todos los expertos, trasladar los que no se usan por ahora a la memoria del host y repartir el cálculo con la CPU en cierta proporción es un compromiso habitual para ejecutar modelos MoE grandes en tarjetas gráficas de consumo. Ahora esto ha entrado en la rama principal y los usuarios ya no tienen que buscar bifurcaciones de terceros.
Frente al camino de los centros de datos
Los marcos de inferencia se dividen hoy en dos vías. vLLM, SGLang y similares se dirigen a las GPU de centros de datos y compiten en rendimiento por lotes y concurrencia; el objetivo de llama.cpp es que los modelos funcionen en móviles, portátiles y estaciones de trabajo, apoyándose en la cuantización para meter modelos grandes en una memoria limitada y combinando CPU y GPU.
Se nota en la lista de backends: CUDA, Metal, Vulkan, WebGPU, HIP de AMD, SYCL de Intel, Hexagon de Snapdragon y MUSA de Moore Threads figuran todos, y cada backend puede compilarse como biblioteca dinámica y cargarse en ejecución según se necesite. Según el blog, ya admite más de 150 variantes de arquitecturas de modelo. Los marcos de centros de datos persiguen el hardware más reciente; llama.cpp persigue la larga cola de dispositivos, y los públicos de ambos lados apenas se solapan.
El proyecto tiene en GitHub unas 135.000 estrellas y 25.600 forks. El equipo trabaja actualmente en Hugging Face; el blog agradece a HF la capacidad de cómputo para CI y menciona también el apoyo de hardware de NVIDIA, AMD, Qualcomm, Arm, IBM e Intel. Que el compromiso de versiones se mantenga dependerá de si las próximas versiones menores cambian la interfaz a escondidas.
Fuentes: blog de Hugging Face, página de versiones de llama.cpp en GitHub, CocoLoop, README del repositorio de llama.cpp; la página de versiones confirma las nuevas funciones de la 1.0, el alcance de la limpieza de interfaces y la lista de backends.