A equipa do llama.cpp publicou a 13 de novembro a versão 1.0.0 do llama.cpp e da biblioteca de tensores que lhe serve de base, a ggml, num texto no blogue da Hugging Face assinado por Daniel Bevenius, Georgi Gerganov e merve. O número conta menos do que a promessa que o acompanha. A partir de agora, dizem os projetos, as alterações que quebrem a API ou a interface binária serão assinaladas com um aumento da versão principal, para que as muitas aplicações construídas sobre as bibliotecas vejam onde estão as fronteiras.
O llama.cpp é uma implementação em C e C++ para executar modelos de linguagem, incluindo multimodais, em equipamento que vai de portáteis de consumo a servidores empresariais, recorrendo à quantização e a backends otimizados para tornar a inferência barata. A equipa afirma que o projeto tem cerca de três anos e meio e que muitas aplicações já dependem dele. A versão 1.0.0 abrange as duas bibliotecas: a libllama, com os cabeçalhos públicos na pasta include do llama.cpp, e a libggml, com os cabeçalhos em ggml/include. No GitHub surgem etiquetas v1.0.0 nos dois repositórios a 13 de novembro, depois de uma longa série de lançamentos do llama.cpp numerados por compilação, como o b12360.
O texto detalha as regras de versionamento, que valem para todos os projetos da ggml-org que usem versionamento semântico. Uma alteração incompatível na API pública em C de uma pasta include aumenta o número principal. Uma funcionalidade retrocompatível, uma atualização de backend, o suporte a um novo modelo ou o acréscimo de uma chamada à API aumentam o número secundário. Uma correção de erro sem efeito na API aumenta o número de correção. Para quem liga a sua aplicação à libllama, esta última distinção é o ganho prático: o trabalho em modelos e backends, onde cai a maior parte das mudanças, já não deve obrigar a reescrever código a cada atualização.
O anúncio trata também da distribuição. A equipa enumera artefactos de pré-lançamento para Linux, macOS, Windows, Android e iOS, imagens Docker para Linux e pacotes através de Debian, Homebrew, conda-forge, MacPorts e Winget, além de um XCFramework para iOS e macOS. Remete quem empacota para uma discussão que explica como incluir os projetos da ggml-org nos respetivos circuitos de lançamento, o que sugere que a equipa quer que mais distribuições acompanhem versões etiquetadas e não compilações contínuas.
Quanto à prática de desenvolvimento, os autores escrevem que continuam a integrar modelos de linguagem no seu próprio fluxo de trabalho, mas que manter uma base de código de qualidade, controlar a arquitetura e compreender os detalhes da implementação continuam a ser prioridades. Dizem investir mais em integração contínua, usando o HF Buckets e o HF Jobs da Hugging Face para escalar a capacidade de testes por trás de cada alteração que chega aos ramos principais. O apoio de hardware da NVIDIA, da AMD, da Qualcomm, da Arm, da IBM e da Intel permite ter executores próprios nas principais plataformas. O texto indica que o llama.cpp suporta mais de 150 variantes de arquitetura e todos os métodos correntes de descodificação especulativa, e que cada backend do ggml pode ser compilado como biblioteca dinâmica e carregado em tempo de execução.
Trata-se do anúncio de uma política de lançamentos feito pelos próprios responsáveis, não de uma avaliação independente. O texto não enumera funcionalidades novas da 1.0.0 nem apresenta números de desempenho. A importância é organizacional: liga as interfaces públicas do projeto a uma regra explícita de compatibilidade, que os projetos dependentes porão à prova quando chegar a próxima versão principal.