llama.cpp v0.2.0 hace promesas distintas en stable y nightly
llama.cpp ahora ofrece versiones semánticas junto a compilaciones nightly. Su primera etiqueta estable comparte código con una etiqueta de compilación, lo que muestra que los nombres de canal describen una política, no la calidad.
llama.cpp lleva años publicando etiquetas con número de compilación casi tan rápido como cambia su código. El 21 de agosto, el proyecto añadió una segunda vía: la versión v0.2.0 inicia una línea coherente de versionado semántico para versiones estables más lentas, mientras que las etiquetas b[NUM] siguen siendo el canal nightly o de desarrollo rápido.
Eso no hace segura cada actualización de inferencia local. Ofrece a los equipos que dependen del proyecto una versión más clara que fijar, y una elección deliberada cuando una GPU, un modelo o una corrección de rendimiento más recientes solo existen en una compilación nightly.
Usa una versión vX.Y.Z cuando la reproducibilidad y la compatibilidad con los consumidores importen más que el cambio más reciente. Usa una compilación b[NUM] cuando tu hardware o carga de trabajo requiera un commit específico y verificado. En ambos casos, fija la etiqueta y el commit exactos, verifica cualquier binario descargado y ejecuta la misma prueba de humo antes de promoverlo.
Stable y nightly son dos políticas de versiones, no grados de calidad
Los nuevos nombres de etiqueta describen el ritmo y la audiencia. El lanzamiento de llama.cpp dice que las etiquetas stable vX.Y.Z llegan más lentamente y se recomiendan para la distribución a consumidores y los usuarios ocasionales. Las etiquetas b[NUM] existentes se crean en la mayoría de los commits o cerca de ellos, exponen antes la funcionalidad actual y pueden ser menos estables.
La política detallada de lanzamientos y versionado del proyecto añade un límite importante de empaquetado. Una etiqueta stable de llama.cpp se crea cuando su copia interna de ggml coincide con una versión publicada de ggml. Eso permite que un distribuidor descendente compile llama.cpp contra un ggml instalado en el sistema, con un punto de compatibilidad definido. Las compilaciones nightly siguen usando la copia interna de desarrollo de llama.cpp, que puede desviarse de la biblioteca publicada por separado.
Esto ya es más que un ejercicio de nombres. Homebrew cambió su fórmula de llama.cpp a la etiqueta v0.2.0 y al commit exacto, compila con el modo de desarrollo desactivado y enlaza con el ggml del sistema empaquetado. La misma fórmula conserva master como compilación head opcional. Por tanto, stable y el desarrollo actual coexisten como elecciones de dependencias distintas.
| Pregunta | Elegir stable vX.Y.Z |
Elegir nightly b[NUM] |
|---|---|---|
| ¿Qué fuerza la actualización? | Una ventana de mantenimiento planificada o una política de versiones compatible | Un modelo, backend, controlador, corrección de seguridad o regresión concreta ausente de stable |
| ¿Cuánto cambio puede absorber el equipo? | Una diferencia de versión revisada con un ritmo más lento | Una diferencia de commit exacta, con posibles cambios posteriores más rápidos |
¿Cómo se consume ggml? |
Una biblioteca del sistema o un paquete descendente se beneficia del punto de compatibilidad de la versión | La compilación lleva la copia interna actual de ggml de llama.cpp |
| ¿Qué evidencia se necesita? | Notas de la versión más pruebas de carga de trabajo y empaquetado | La solicitud de cambios o el commit que motivan el cambio, más la misma barrera de pruebas completa |
| ¿Qué se registra? | Etiqueta semántica, commit completo, resumen del artefacto, flags de compilación, backend y revisión del modelo | Etiqueta de compilación, commit completo, resumen del artefacto, flags de compilación, backend y revisión del modelo |
| ¿Cuál es la reversión? | La versión semántica aceptada anterior y sus artefactos | La última base stable o nightly aceptada, conservada por separado de la candidata |
Una nightly no es automáticamente más rápida, y stable no afirma que hayan desaparecido todas las regresiones. Las etiquetas indican cómo se seleccionó y publicó el código. El rendimiento y la corrección siguen dependiendo del modelo, la cuantización, el backend, el compilador, el controlador, el hardware, la mezcla de prompts, la longitud del contexto y la configuración del servidor.
v0.2.0 y b10566 apuntan al mismo código, pero sirven para trabajos distintos
La primera versión estable deja ver un matiz útil. Las etiquetas v0.2.0 y b10566 resuelven ambas al commit bb4caa7540188872173c44d161602d9271386413. La página stable establece la versión semántica y enlaza con la nightly b10566; la versión b10566 contiene los artefactos precompilados para macOS, Linux, Android, Windows e iOS correspondientes a ese commit.
Esa distinción cambia lo que debería fijarse:
- Una compilación desde código fuente o un paquete descendente debe identificar
v0.2.0y su commit completo. La etiqueta comunica el contrato de la versión stable. - Un equipo que consuma uno de los archivos precompilados del proyecto debe registrar
b10566, el nombre de archivo exacto y su resumen, porque esos binarios viven en la versión asociada a la etiqueta de compilación. - Una nightly posterior no debe describirse como «v0.2.0 más correcciones» sin examinar su rango exacto de commits. A fecha del 24 de agosto en Yakarta, el repositorio ya había publicado b10603 en un commit diferente.
Las notas de la versión también muestran por qué serían engañosas las promesas de rendimiento a nivel de versión. El rango de cambios de v0.2.0 contiene trabajo de backend, servidor, compatibilidad con modelos, memoria, compilación e ingeniería de versiones. Algunos cambios son específicos de Metal, SYCL, OpenCL, Vulkan, CUDA o determinadas arquitecturas de modelos; otros son reversiones. Ninguna cifra de velocidad puede resumir esa mezcla.
Verifica la procedencia antes de probar el rendimiento
La versión binaria b10566 enlaza con una atestación de artefacto de GitHub y publica resúmenes SHA-256 para sus archivos. Una atestación de artefacto es una declaración firmada que conecta un artefacto con su repositorio de origen y su flujo de compilación. La documentación de atestaciones de GitHub deja claro el límite: la procedencia ayuda a establecer dónde y cómo se compiló un artefacto; no demuestra que el código sea seguro o esté libre de regresiones.
Descarga únicamente el archivo de la plataforma exacta desde la página de versiones del proyecto y verifícalo antes de extraerlo. Con una versión actual de GitHub CLI, la forma documentada del comando es:
gh attestation verify ./llama-b10566-bin-ubuntu-x64.tar.gz \
--repo ggml-org/llama.cppLa referencia de GitHub CLI explica la política de verificación y su salida. Un resultado correcto debe almacenarse con el registro del despliegue junto al repositorio esperado, el nombre de archivo del artefacto, el resumen SHA-256, la etiqueta y el commit. Una verificación fallida o ausente es una condición de parada, no una razón para reintentarlo con un mirror no rastreado.
Fijar únicamente master, latest, head o un canal cambiante del gestor de paquetes hace más difícil reconstruir un incidente posterior. Una etiqueta es mejor, mientras que el commit exacto identifica el código fuente independientemente del nombre del canal.
Stable y nightly responden a necesidades de mantenimiento distintas
La inusual pareja v0.2.0 y b10566 hace concreta la distinción: las etiquetas apuntan al mismo commit de origen, pero la versión semántica comunica un contrato de estabilidad mientras que la etiqueta de compilación lleva los artefactos descargables. Una nightly posterior puede contener una corrección necesaria de backend o modelo, pero también se aleja del código exacto que seleccionó la versión stable.
Por eso, «stable frente a nightly» es una decisión de mantenimiento, no una conclusión de benchmark. El modelo, la cuantización, el hardware, el backend, el contexto y la carga de trabajo pueden dominar el rendimiento, mientras que la procedencia solo puede establecer de dónde procede un artefacto, no que sea seguro o esté libre de regresiones.
La señal más útil de la nueva política de versiones de llama.cpp es, por tanto, organizativa: los usuarios descendentes por fin tienen un ancla semántica sin perder acceso a compilaciones que avanzan rápido. Que esa ancla sea adecuada para un despliegue concreto sigue dependiendo de la capacidad o corrección que necesite una carga de trabajo específica.