llama.cpp: conhecendo, instalando e rodando IA local no Linux

Mascote do LinuxPro rodando um modelo local num notebook modesto, com a lhama do llama.cpp e blocos de quantização

Existe um projeto de que quase todo mundo depende sem saber. Quando você roda um modelo local com Ollama, com LM Studio, com Jan ou com aquele app de IA no celular, é bem provável que, lá embaixo, quem está fazendo a conta seja o llama.cpp — um motor de inferência escrito em C++ puro, sem Python, sem CUDA obrigatório, sem dependência nenhuma.

Este post é o guia direto: de onde ele veio, como instalar, como rodar o primeiro modelo e como colocá-lo para servir uma API.

De onde veio o llama.cpp

A história começa com uma biblioteca, não com o LLaMA. Em setembro de 2022, o búlgaro Georgi Gerganov começou a escrever a GGML — uma biblioteca de álgebra tensorial em C, feita para rodar rápido em CPU comum.

Em março de 2023 os pesos do LLaMA, da Meta, vazaram. Poucos dias depois, em 10 de março de 2023, Gerganov publicou o llama.cpp: o modelo da Meta rodando num MacBook, sem GPU, sem Python, sem nada. Foi um daqueles momentos em que a régua do que é possível se move de lugar — até ali, “rodar um LLM” significava alugar GPU de datacenter.

O que veio depois:

  • Junho de 2023 — Gerganov funda a ggml.ai em Sofia, na Bulgária, com investimento pré-semente de Nat Friedman (ex-CEO do GitHub) e Daniel Gross, via AI Grant.
  • 21 de agosto de 2023 — nasce o formato GGUF, que substitui o GGML antigo e vira o padrão de facto de modelo quantizado.
  • 20 de fevereiro de 2026 — a Hugging Face anuncia que Gerganov e o time da GGML entraram para a organização, como funcionários em tempo integral, mantendo autonomia e liderança técnica sobre o projeto.
  • Julho de 2026 — reformulação grande: o llama-cli deixa de rodar a inferência no próprio processo e vira um cliente fino que sobe o llama-server por baixo e conversa com ele.

Hoje o projeto vive em ggml-org/llama.cpp, licença MIT, com mais de 127 mil estrelas — e ganhou site próprio, o llama.app.

GGUF: o formato que faz a coisa toda funcionar

O llama.cpp roda modelos no formato GGUF, e entender isso poupa muita confusão.

Um GGUF é um arquivo único que empacota tudo o que o modelo precisa: os pesos, o tokenizador e os metadados. Não há diretório com uma dúzia de arquivos, não há config.json separado, não há surpresa de “faltou o tokenizador”. Você baixa um arquivo e ele roda.

E ele carrega os pesos quantizados — comprimidos de 16 bits para 8, 5, 4 ou menos por parâmetro. É essa compressão que faz um modelo de 8 bilhões de parâmetros caber em 5 GB em vez de 16, e é por isso que ele roda no seu notebook.

llama.cpp, Ollama ou vLLM?

A confusão mais comum é achar que são concorrentes. Não são exatamente:

llama.cpp Ollama vLLM
O que é O motor Uma camada de conveniência Motor de servidor
Escrito em C++ Go Python
Hardware CPU, qualquer GPU, Raspberry Pi CPU e GPU GPU dedicada
Formato GGUF GGUF, via registro próprio Pesos do Hugging Face
Controle Total, nos mínimos detalhes Padrões prontos Foco em vazão
Vazão sob carga Modesta Modesta É o objetivo do projeto

Em resumo: o Ollama é mais fácil e usa boa parte desta base; o vLLM serve muita gente ao mesmo tempo numa GPU grande; o llama.cpp é para quem quer controle, quer rodar em hardware modesto ou exótico, ou quer entender o que está acontecendo de verdade.

Instalando

O caminho recomendado hoje é o instalador oficial, que detecta a plataforma e baixa o binário certo:

curl -LsSf https://llama.app/install.sh | sh

llama cli --version

Se preferir compilar — que é o que você vai querer para tirar proveito da GPU NVIDIA:

sudo apt update
sudo apt install -y build-essential cmake git libcurl4-openssl-dev

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

# CPU apenas
cmake -B build
cmake --build build --config Release -j$(nproc)

# com CUDA (precisa do CUDA Toolkit instalado)
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j$(nproc)

Existem back-ends para praticamente tudo: -DGGML_CUDA=ON para NVIDIA, -DGGML_HIP=ON para AMD com ROCm, -DGGML_VULKAN=ON para qualquer GPU com Vulkan, -DGGML_METAL=ON no Apple Silicon. O mesmo código, os mesmos modelos, kernels ajustados à mão para cada um.

Primeiros passos: conversando no terminal

O llama cli baixa o modelo do Hugging Face e já abre o chat. Não é preciso baixar nada antes:

llama cli -hf unsloth/gemma-4-E4B-it-GGUF:Q4_K_M

A sintaxe é usuario/repositorio-GGUF:QUANTIZACAO. O modelo cai no cache padrão do Hugging Face, que é compartilhado com outras ferramentas — ou seja, não duplica se você já usa outra coisa.

# listar o que já está no cache
llama cli -cl

# usar um arquivo .gguf que você já tem em disco
llama cli -m ./meu-modelo.gguf

# uma pergunta só, sem entrar no chat — útil para script
llama cli -m ./meu-modelo.gguf -p "explique o comando tar czf" --no-cnv

No fim de cada resposta ele mostra a velocidade em tokens por segundo, separando o processamento do prompt da geração. É a métrica que você quer olhar ao comparar modelo, quantização e ajuste.

llama serve: API compatível com a OpenAI e interface web

Aqui o projeto vai além do que muita gente imagina. Um comando sobe um servidor com interface de chat no navegador e uma API compatível com a OpenAI:

llama serve -hf ggml-org/gemma-4-e4b-it-GGUF:Q4_0

Abra http://localhost:8080 e a interface já está lá — sem instalar front-end nenhum. E qualquer aplicação que fale com a API da OpenAI aponta para cá trocando só a URL:

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [{"role": "user", "content": "Escreva uma unit systemd para /opt/job.sh"}]
  }'
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8080/v1", api_key="nao-importa")

r = client.chat.completions.create(
    model="local",
    messages=[{"role": "user", "content": "Explique inodes em duas frases."}],
)
print(r.choices[0].message.content)

Escolhendo a quantização certa

É a decisão que mais afeta o resultado, e a nomenclatura assusta à toa. A regra prática:

Sufixo Bits/peso Quando usar
Q8_0 ~8 Quase idêntico ao original; use se sobra memória
Q6_K ~6,5 Perda desprezível; ótimo se couber
Q5_K_M ~5,5 Excelente equilíbrio
Q4_K_M ~4,8 O padrão sensato. Comece por aqui
Q4_0 ~4,5 Mais rápido, um pouco pior que o K_M
Q3_K_M ~3,9 Só se a memória for muito apertada
Q2_K ~3 A qualidade cai visivelmente; evite

A conta rápida de memória: multiplique os bilhões de parâmetros por 0,6 GB para ter o tamanho aproximado em Q4, e some folga para o contexto. Um modelo de 8B em Q4_K_M ocupa uns 5 GB.

E o conselho que economiza tempo: um modelo maior mal quantizado costuma render mais que um modelo pequeno bem quantizado. Entre um 14B em Q4 e um 7B em Q8 ocupando a mesma memória, o 14B geralmente ganha.

Os parâmetros que importam

llama serve -m ./modelo.gguf \
  -ngl 99 \
  -c 8192 \
  --host 0.0.0.0 --port 8080 \
  -t 8
  • -ngl (n-gpu-layers) — o mais importante de todos. Quantas camadas do modelo vão para a GPU. Use -ngl 99 para mandar tudo o que couber. Se o modelo não cabe inteiro, o llama.cpp divide entre GPU e CPU sozinho — e é exatamente isso que o vLLM não faz com graça.
  • -c — tamanho do contexto. Quanto maior, mais memória. É o primeiro parâmetro a reduzir quando falta VRAM.
  • -t — número de threads de CPU. O padrão costuma servir; ajuste se estiver rodando só em CPU.
  • --host 0.0.0.0 — expõe na rede. Atenção: o servidor não tem autenticação por padrão. Use --api-key e um proxy reverso na frente se for expor.

Para descobrir o melhor ajuste da sua máquina, o projeto traz um medidor pronto:

llama-bench -m ./modelo.gguf -ngl 0,20,99

Rodando como serviço

Em servidor, crie /etc/systemd/system/llama.service:

[Unit]
Description=llama.cpp server
After=network-online.target
Wants=network-online.target

[Service]
Type=exec
User=llama
Group=llama
WorkingDirectory=/opt/llama
Environment="LLAMA_CACHE=/opt/llama/models"
ExecStart=/usr/local/bin/llama serve -m /opt/llama/models/modelo.gguf \
  -ngl 99 -c 8192 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=5
TimeoutStartSec=300

[Install]
WantedBy=multi-user.target
sudo useradd -r -s /usr/sbin/nologin -d /opt/llama llama
sudo mkdir -p /opt/llama/models && sudo chown -R llama:llama /opt/llama
sudo systemctl daemon-reload
sudo systemctl enable --now llama
journalctl -u llama -f

O TimeoutStartSec alto é proposital: carregar um modelo grande do disco leva tempo, e o padrão de 90 segundos mataria o serviço no meio.

Quantizando um modelo você mesmo

Se o modelo que você quer não tem GGUF pronto, dá para converter:

cd llama.cpp
pip install -r requirements.txt

# baixe os pesos originais do Hugging Face e converta para GGUF em 16 bits
python convert_hf_to_gguf.py /caminho/do/modelo --outfile modelo-f16.gguf

# depois quantize
./build/bin/llama-quantize modelo-f16.gguf modelo-Q4_K_M.gguf Q4_K_M

Na prática, quase nunca é preciso: a comunidade publica GGUF de tudo o que importa no Hugging Face poucas horas depois do lançamento.

Linha do tempo

  • Setembro de 2022 — Georgi Gerganov começa a GGML, biblioteca de tensores em C.
  • 10 de março de 2023 — sai o llama.cpp, dias depois do vazamento dos pesos do LLaMA. LLM rodando em notebook, sem GPU.
  • Junho de 2023 — nasce a ggml.ai, em Sofia, com aporte de Nat Friedman e Daniel Gross.
  • 21 de agosto de 2023 — o formato GGUF substitui o GGML e vira padrão de facto.
  • 20 de fevereiro de 2026 — Gerganov e o time da GGML entram para a Hugging Face, mantendo a liderança técnica do projeto.
  • Julho de 2026 — o llama-cli vira cliente fino do llama-server; chega a CLI unificada llama cli / llama serve e o site llama.app.
  • 2 de setembro de 2026 — a NVIDIA anuncia a compra da Hugging Face por US$ 12,93 bilhões, com fechamento previsto para o primeiro semestre de 2027, sujeito a aprovação regulatória.

O que fica — e a ironia do fim

O llama.cpp é a prova de que uma decisão de engenharia bem tomada vale mais que orçamento. Um desenvolvedor, C++ puro, sem dependência, apostando que dava para rodar modelo grande em hardware pequeno — e a indústria inteira acabou construindo em cima disso.

E aí está a ironia que vale registrar: o projeto que nasceu para rodar IA sem depender de GPU cara terminou, por três saltos, dentro da NVIDIA — via Hugging Face, se a compra for aprovada. Jensen Huang disse que a plataforma segue aberta e que não será preciso hardware NVIDIA para usá-la. A licença do llama.cpp é MIT, o código está publicado e um fork é sempre possível. Ainda assim, é o tipo de movimento que vale acompanhar de perto.

Para continuar: Ollama se você quer o caminho fácil, vLLM se precisa servir muita gente, llama-model para gerenciar seus GGUF, e o servidor de IA recondicionado se a ideia é montar a máquina.

Links oficiais: llama.app · documentação · modelos recomendados · github.com/ggml-org/llama.cpp