llama.cpp 1.0.0: o que muda com o versionamento semântico da API

A ggml-org lançou o libllama v1.0.0 (llama.cpp) e o libggml v1.0.0 (ggml) em post no blog da Hugging Face publicado em 13/11/2026. Com isso, incompatibilidades de API e ABI nos dois projetos passam a gerar uma nova versão major.

O recado é para quem embute llama.cpp ou ggml em aplicativos, bibliotecas próprias e pipelines de build. A partir de agora, o número da versão diz se a atualização é tranquila ou se pede revisão do seu código.

Por que o llama.cpp chegou à versão 1.0.0 agora

O motivo declarado no anúncio é a quantidade de gente que depende do projeto. Segundo o post oficial, são cerca de 3,5 anos desde a criação, e muitas aplicações já usam as interfaces da biblioteca.

Cada nova integração aumenta o número de desenvolvedores presos à mesma API. Por isso o time decidiu assumir um compromisso público de estabilidade e tornar visíveis os pontos em que uma versão quebra compatibilidade.

O post é assinado por Daniel Bevenius, Georgi Gerganov e merve, pela organização ggml-org.

Vale lembrar o contexto: a ggml.ai entrou na Hugging Face em anúncio de fevereiro de 2026, como registrou o Simon Willison. O time do llama.cpp hoje está na Hugging Face, o que explica o lançamento ter saído no blog dela.

Como interpretar as próximas versões do llama.cpp e do ggml

A regra é o versionamento semântico clássico, e o anúncio diz que ela vale para todos os projetos da ggml-org que usam semver. Na prática, cada parte do número MAJOR.MINOR.PATCH passa a ter um significado fixo:

• MAJOR: mudança incompatível na API C pública que fica em ./include. Se esse número subir, revise o código que chama a biblioteca antes de atualizar.
• MINOR: recurso retrocompatível, atualização de backend, suporte a modelo novo ou adição de API. Em tese, entra sem quebrar o que já funciona.
• PATCH: correção de bug sem mudança de API.

E a ABI, que entra no compromisso do anúncio? É a compatibilidade no nível binário, ou seja, se um app já compilado continua funcionando quando você troca a biblioteca dinâmica por uma versão nova. O post afirma que incompatibilidades de API e de ABI serão refletidas em bump de major.

Tome cuidado com o recorte da garantia. Ela cobre a API C pública nos headers: llama.cpp/include/ para o libllama e ggml/include/ para o libggml. O anúncio não detalha se a mesma regra vale para as ferramentas de linha de comando ou para o servidor, então não trate essas partes como cobertas.

O post também não traz política de suporte para versões major antigas nem cronograma de releases.

Onde obter o llama.cpp 1.0.0: canais de distribuição

O anúncio lista oito canais de distribuição, cada um com as plataformas atendidas:

Os nomes de pacote e os comandos de instalação de cada canal não estão no anúncio. Antes de mexer no seu pipeline, confira na documentação de cada canal qual pacote corresponde ao libllama e ao libggml.

CI, backends e modelos suportados na v1.0.0

O compromisso com estabilidade vem acompanhado de mais testes. A infraestrutura de CI usa HF Buckets e HF Jobs, da Hugging Face, para escalar a capacidade de testar cada mudança que entra na branch master.

Além disso, o projeto mantém runners self-hosted com apoio de hardware da NVIDIA, AMD, Qualcomm, Arm, IBM e Intel. Para quem distribui um app em máquinas variadas, isso significa que as mudanças passam por testes em plataformas de vários fabricantes.

Outro ponto que pesa para quem embute a biblioteca: cada backend do ggml pode ser compilado como biblioteca dinâmica e, opcionalmente, carregado em tempo de execução. Você não precisa amarrar um único backend no binário final do app.

Do lado dos modelos, o llama.cpp suporta mais de 150 variantes de arquitetura, além dos principais métodos de speculative decoding. Pela regra nova, suporte a modelo entra como versão minor, então ganhar arquitetura nova não deveria exigir mudança no seu código.

Próximo passo para quem depende do llama.cpp

Comece descobrindo qual versão do libllama e do libggml o seu projeto usa hoje, seja por submódulo, pacote ou binário vendorizado. Se a dependência acompanha a branch master sem fixar versão, este é um bom momento para mudar isso.

Depois, fixe a dependência considerando a nova regra. Aceitar minor e patch automaticamente e travar o major é o uso típico de semver, e o anúncio dá a base para isso.

Quando aparecer uma versão major nova, leia as notas de release antes de atualizar e revise as chamadas aos headers em include. Os detalhes da política estão no anúncio oficial.

Veja mais exemplos práticos no canal Hora de Codar. Se quiser aprofundar o contexto, veja Lançou o Sonnet 5! Nova versão do modelo da Anthropic supreende?.