A biblioteca de inferência local llama.cpp lançou a v1.0.0, e a biblioteca de tensores que lhe serve de base, a ggml, também foi promovida à 1.0. A equipe do projeto publicou um texto no blog da Hugging Face dizendo que esta versão pretende oferecer uma base mais estável a quem depende dela: daqui em diante, sempre que a API pública ou a ABI do llama.cpp e da ggml se tornar incompatível, isso será refletido na mudança da versão maior.
Nos últimos anos, o llama.cpp foi publicado quase só por números de build iniciados em b: cada código incorporado ao ramo principal gera um novo build, e a contagem já passa de b12000. Depois da 1.0, essa numeração de builds não acabou; continua sendo gerada como pré-lançamento. A mudança é que agora existe também uma linha de versões oficiais com compromisso, e quem usa pode escolher conforme a necessidade.
Os números de versão passam a ter significado
As regras apresentadas no blog são diretas: MAJOR corresponde a mudanças que quebram a interface C pública no diretório ./include; MINOR traz novos recursos ou suporte a novos modelos com retrocompatibilidade; PATCH apenas corrige bugs, sem mexer na interface. Valem para todos os projetos sob a organização ggml-org. A equipe escreve que, como cada vez mais gente usa o projeto, passará a tornar esses limites visíveis de forma mais rigorosa.
Para começar do zero com limpeza, a 1.0 fez antes uma faxina: removeu uma série de interfaces públicas há muito marcadas como obsoletas, renomeou algumas funções e acrescentou novos campos à estrutura de parâmetros de contexto; no lado da ggml, também foram eliminadas APIs obsoletas e o antigo operador DIAG_MASK. Para quem vincula o llama.cpp como biblioteca em seus próprios produtos, esta atualização exige mexer no código uma vez; depois disso, ao acompanhar as versões menores, não é preciso temer que uma interface desapareça de repente em algum build.
O que esta versão traz
Além das regras de versionamento, a própria 1.0 traz várias novidades:
- O cache KV passa a suportar FP8; foi adicionado um cache de especialistas MoE na memória do host, com proporção de cálculo na CPU configurável;
- Foi incluído suporte a modelos como o Kimi-K3.1-Pro, e o Kimi-K3.1 consegue processar entrada de imagens;
- O llama-server ganhou a interface de síntese de voz /v1/audio/speech, que funciona com o modelo de TTS drama-3;
- No lado do servidor, foram corrigidos problemas de SSRF, CORS e DNS rebinding; chamadas de ferramentas sem autenticação e acesso a URLs privadas agora precisam ser ativados explicitamente, e o HF_TOKEN só é enviado para huggingface.co.
O último item é o mais prático para quem hospeda o próprio serviço. O llama-server costuma ser usado como interface local compatível com a OpenAI, instalada na rede interna ou até exposta diretamente à internet; se a chamada de ferramentas vier liberada por padrão, a superfície de risco cresce junto. Exigir ativação explícita devolve a escolha a quem faz a implantação.
O cache de especialistas MoE, por sua vez, mira o formato de modelo atual. A maioria dos grandes modelos deste ano usa arquitetura de mistura de especialistas, com total de parâmetros na casa das centenas de bilhões, mas só uma pequena parte é ativada a cada passo. Quando a memória de vídeo não comporta todos os especialistas, mover para a memória do host os que não estão em uso e entregar à CPU uma parte do cálculo é um meio-termo comum para rodar grandes modelos MoE em placas de vídeo de consumo. Agora isso entrou no ramo principal, e o usuário não precisa mais procurar forks de terceiros.
Em comparação com o lado dos data centers
Os frameworks de inferência hoje seguem dois caminhos. vLLM, SGLang e similares são voltados a GPUs de data center e competem em vazão em lote e concorrência; o objetivo do llama.cpp é fazer os modelos rodarem em celulares, notebooks e estações de trabalho, usando quantização para caber modelos grandes em memória limitada e combinando CPU e GPU.
Isso fica claro na lista de backends: CUDA, Metal, Vulkan, WebGPU, HIP da AMD, SYCL da Intel, Hexagon da Snapdragon e MUSA da Moore Threads estão todos lá, e cada backend pode ser compilado como biblioteca dinâmica e carregado sob demanda em tempo de execução. Segundo o blog, já há suporte a mais de 150 variantes de arquitetura de modelo. Os frameworks de data center perseguem o hardware mais novo; o llama.cpp persegue a cauda longa de dispositivos, e os públicos dos dois lados se sobrepõem pouco.
O projeto tem cerca de 135 mil estrelas e 25,6 mil forks no GitHub. A equipe hoje está na Hugging Face; o blog agradece à HF pelo poder de computação de CI e também lista o apoio de hardware de NVIDIA, AMD, Qualcomm, Arm, IBM e Intel. Se o compromisso de versionamento será cumprido dependerá de as próximas versões menores alterarem ou não a interface às escondidas.
Fontes: blog da Hugging Face, página de lançamentos do llama.cpp no GitHub, CocoLoop, README do repositório llama.cpp; a página de lançamentos confirma os novos recursos da 1.0, o alcance da limpeza de interfaces e a lista de backends.