llama.cpp 1.0 borró 35 funciones de un golpe: si compilas contra libllama, tu build se rompe hoy; si solo usas apps empaquetadas, tu roadmap deja de romperse para siempre.
Durante tres años y medio el motor de inferencia local más usado del planeta versionó con builds tipo b3050 y cambios de API sin ceremonia. Eso estaba bien para un hack de Gerganov corriendo LLaMA en un MacBook. Estaba de la patada para cualquiera que tuviera que justificar un presupuesto de infraestructura ante finanzas.
La v1.0.0 de llama.cpp 1.0 y ggml 1.0.0 cambia la regla del juego: semver estricto sobre la API pública C. Breaking change = major bump. Punto. Mi postura: esto no es una release técnica, es un activo financiero. Y quien no lo lea así va a seguir pagando tokens de nube por pura inercia.
Qué pasó con llama.cpp 1.0
El 13 de noviembre de 2026, ggml-org publicó llama.cpp v1.0.0 (libllama) y ggml v1.0.0 (libggml), el primer hito 1.0 del proyecto desde su commit inicial en marzo de 2023. El anuncio lo firman Daniel Bevenius, Georgi Gerganov y Merve en el blog de Hugging Face.
La release no es cosmética. Eliminó 35 funciones deprecadas de la API pública C, más llama_set_warmup y la opción defrag_thold con su flag --defrag-thold, todo en el PR 30565. También movió la API NextN de decodificación especulativa de llama-ext.h al header público llama.h y renombró llama_set_embd_state_src a llama_set_ctx_state_src.
La regla declarada: breaking change en los headers de llama.cpp/include/ y ggml/include/ exige major bump; feature retrocompatible, backend nuevo o modelo soportado es minor; bugfix sin impacto en API es patch. Ambas librerías reflejan incompatibilidades de API y ABI con major bumps. Además, la 1.0 suma caché KV en fp8 y endurece los endpoints de audio y speech del server.
Qué significa para tu stack
Significa que el suelo bajo tus pies deja de moverse sin aviso. Y eso, en términos de negocio, vale más que cualquier benchmark de tokens por segundo.
Piensa en lo que era correr self-hosting hasta ayer. Actualizabas llama.cpp para tener el modelo nuevo, se rompía un wrapper, se rompía Ollama, se rompía tu script de evaluación, y el equipo perdía dos días. Ese costo oculto es exactamente lo que hacía indefendible el TCO local frente a una factura de API predecible. Con la API estable, el riesgo de reescritura baja lo suficiente como para modelar 12 o 24 meses sin que finanzas te mire como si estuvieras pidiendo un capricho.
Ojo con la lectura ingenua. Semver no congela nada, solo etiqueta el cambio. El propio equipo admite que la interfaz va a seguir evolucionando, y un major bump puede llegar tan rápido como antes llegaban los builds b####. La diferencia es que ahora tienes fecha, versión y política: puedes planificar la migración en vez de sufrirla un martes a las 11 de la noche.
Y hay un hueco que nadie menciona: la garantía cubre la API C, no el formato GGUF, no los kernels por backend y no el comportamiento del server HTTP. Si tu operación depende de que un modelo cuantizado cargue igual en Metal y en CUDA, sigues sin garantía contractual. Semver te protege del compilador, no de la física del hardware.
Para quien solo usa Ollama o LM Studio, el 1.0 es irrelevante hasta que esos proyectos migren. Y pueden tardar meses. Pero si eres el que empaqueta, el que certifica o el que firma el contrato de infraestructura, esto es la noticia más importante del año en inferencia local. Con más de 150 arquitecturas soportadas y más de 100.000 stars en GitHub, llama.cpp no es un proyecto de nicho: es la capa sobre la que se apoya medio ecosistema.
Qué hacer al respecto
1. Pin exacto, no rango. Fija la versión de libllama y libggml en tu build con hash o tag exacto. Nada de >=1.0. Y trata cada major bump como un proyecto de migración con fecha y dueño, no como un parche de mantenimiento que alguien mete un viernes.
2. Audita hoy tu código contra llama.h. Si usas llama_set_warmup, defrag_thold o --defrag-thold, llama_set_embd_state_src, o incluías llama-ext.h para NextN, el 1.0 te rompe el build ahora. Grep, lista de archivos afectados, ticket asignado. No mañana.
3. Verifica contra qué versión enlazan tus dependencias. Si consumes vía Ollama, LM Studio o llama-cpp-python, no asumas la garantía. Revisa el lockfile o el submodule antes de prometerle estabilidad interna a tu equipo o a un cliente. Prometer semver ajeno es la forma más rápida de quedar mal.
4. Corre el modelo de costos con local como base y cloud como overflow. Con la API congelada ya puedes presupuestar el TCO de hardware propio a 12-24 meses sin el asterisco de «puede que haya que reescribir». Ese asterisco era el que mataba la conversación con finanzas. Ya no está.
5. Aprovecha la ventana gratis. La caché KV en fp8 y el endurecimiento del server de audio y speech son mejoras de costo y de superficie de ataque que activas sin tocar tu integración. Son las que se olvidan porque no dan titular.
Si tu roadmap de IA depende de un proveedor que puede subirte el precio un 80% sin avisar, esta release te da la excusa técnica que te faltaba para mover carga a tu propio hardware. La excusa, no la decisión. Esa la tomas tú.
¿Ya corriste el grep contra llama.h o vas a esperar a que el build explote en producción? Cuéntame en los comentarios qué te rompió el 1.0 y qué versión estás pineando.
Preguntas frecuentes
¿llama.cpp 1.0 rompe mi app si solo uso Ollama o LM Studio?
No directamente. Esos proyectos enlazan su propia versión de libllama y migrarán a su ritmo. Lo que cambia es que ahora puedes verificar contra qué versión compilan y exigir que se mantengan en una línea estable.
¿Qué pasa si mi código usa llama_set_warmup o defrag_thold?
Se eliminan en la 1.0. El build falla. Tienes que quitar la llamada o reemplazarla por el mecanismo equivalente del nuevo flujo de contexto. Es un cambio de una tarde si lo detectas tú, y un incidente si lo detecta el cliente.
¿La API estable cubre el formato GGUF y los backends?
No. La garantía semver aplica a los headers públicos C de llama.cpp y ggml. El formato de modelo, el comportamiento de los kernels por backend y la API del server HTTP quedan fuera de esa promesa.
¿Vale la pena migrar a self-hosting ahora que la API es estable?
Depende de tu volumen y de tu latencia tolerable. Con la API congelada el riesgo de reescritura baja, así que el cálculo se vuelve puramente económico: costo por token propio contra factura de nube más latencia de red. Si tu carga es alta y estable, los números suelen inclinarse hacia local.
Fuentes
- Hugging Face Blog — llama.cpp v1.0.0: A stronger foundation for the local AI ecosystem
- GitHub — ggml-org/llama.cpp Releases (v1.0.0)
- GitHub — ggml-org/ggml Releases (v1.0.0)
- MLQ.ai — llama.cpp reaches version 1.0 and promises a stable API for local AI apps
- Pasquale Pillitteri — llama.cpp 1.0 arrives with a stable API and 35 fewer deprecated functions