Introdução rápida ao llama.cpp com CLI e servidor
Execute modelos GGUF com o CLI e o servidor
llama.cpp é um motor de inferência em C/C++ para modelos GGUF: llama-cli para chat interativo, llama-completion para prompts roteirizados e llama-server para uma API HTTP compatível com OpenAI.
Se você ainda está decidindo entre abordagens locais, auto-hospedadas e em nuvem, comece pelo guia pilar Hospedagem de LLM em 2026: Comparação de Infraestrutura Local, Auto-Hospedada e Nuvem.
Por que usar llama.cpp em 2026
llama.cpp é um motor de inferência leve com uma tendência para:
- portabilidade entre CPUs e múltiplos backends de GPU,
- latência previsível em uma única máquina,
- flexibilidade de implantação, de laptops a nós on-prem.
Ele brilha quando você quer privacidade e operação offline, quando precisa de controle determinístico sobre as flags de tempo de execução ou quando deseja incorporar a inferência em um sistema maior sem executar uma pilha pesada em Python.
Também é útil entender llama.cpp mesmo que você escolha posteriormente um runtime de servidor com maior vazão. Por exemplo, se seu objetivo é a vazão máxima de serviço em GPUs, você também pode querer compará-lo com o vLLM usando:
vLLM Quickstart: Servindo LLMs de Alto Desempenho
e você pode fazer benchmarks de escolhas de ferramentas em:
Ollama vs vLLM vs LM Studio: Melhor Jeito de Executar LLMs Localmente em 2026?.
Se especificamente o Ollama for a alternativa que você está ponderando contra llama-server, llama.cpp vs Ollama em 2026 é a comparação dedicada entre os dois, com gatilhos concretos para quando manter o Ollama e quando migrar para o llama.cpp direto.

Instalação do llama.cpp em Windows, macOS e Linux
Os comandos abaixo correspondem ao llama.cpp v0.6.0 (5 de outubro de 2026). Uma entrada de catálogo para o mesmo runtime — inferência GGUF em backends de CPU e acelerador, versionada por commit de build — está na referência do runtime llama.cpp no LLM Systems. Há quatro caminhos práticos de instalação, dependendo se você quer conveniência, portabilidade ou desempenho máximo.
Instalação via gerenciadores de pacotes
Esta é a opção mais rápida de “fazer funcionar”.
# macOS ou Linux
brew install llama.cpp
# Windows
winget install llama.cpp
# macOS (MacPorts)
sudo port install llama.cpp
# macOS ou Linux (Nix)
nix profile install nixpkgs#llama-cpp
# Ubuntu (universe). Este pacote está muito atrás do upstream:
# 8681+dfsg contra o build atual b11433 / v0.6.0, então flags mais novas faltarão.
sudo apt install llama.cpp-tools
Dica: após instalar, verifique se as ferramentas existem:
llama-cli --version
llama-completion --version
llama-server --version
Instalação via binários pré-compilados
Se você deseja uma instalação limpa sem compiladores, use os binários pré-compilados oficiais publicados nos releases do GitHub do llama.cpp. Eles tipicamente cobrem múltiplos alvos de sistema operacional e múltiplos backends (variantes apenas CPU e habilitadas para GPU).
Um fluxo de trabalho comum:
# 1) Baixe o arquivo correto para seu SO e backend
# 2) Extraia-o
# 3) Execute a partir da pasta extraída
./llama-cli --help
./llama-server --help
Executar o container oficial
O projeto publica imagens de servidor no GitHub Container Registry. A imagem de CPU é ghcr.io/ggml-org/llama.cpp:server; a imagem de CUDA é :server-cuda. O container deve ouvir em todas as interfaces, pois o bind padrão ainda é 127.0.0.1:
docker run --gpus all -p 8080:8080 \
-v /path/to/models:/models \
ghcr.io/ggml-org/llama.cpp:server-cuda \
-m models/my-model.gguf -c 4096 --host 0.0.0.0 -ngl all
Compilar do código-fonte para seu hardware exato
Se você se preocupa em extrair o melhor desempenho do seu backend de CPU/GPU, compile a partir do código-fonte com CMake.
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
# Build de CPU
cmake -B build
cmake --build build --config Release
Após o build, os binários tipicamente estão aqui:
ls -la ./build/bin/
Builds de GPU em um único comando
Habilite o backend que corresponda ao seu hardware (exemplos mostrados para CUDA e Vulkan):
# NVIDIA CUDA
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release
# Vulkan
cmake -B build -DGGML_VULKAN=ON
cmake --build build --config Release
Ubuntu 24.04 + GPU NVIDIA: roteiro completo de build
No Ubuntu 24.04 com uma GPU NVIDIA, você precisa do toolkit CUDA e do OpenSSL antes de compilar. Aqui está uma sequência testada:
1. Instale o toolkit CUDA 13.1. Este roteiro fixa o instalador local 13.1.1. Um toolkit mais novo do repositório Ubuntu 24.04 da NVIDIA segue os mesmos passos de pin-file e de deb local com nomes de arquivos atualizados.
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-ubuntu2404.pin
sudo mv cuda-ubuntu2404.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/13.1.1/local_installers/cuda-repo-ubuntu2404-13-1-local_13.1.1-590.48.01-1_amd64.deb
sudo dpkg -i cuda-repo-ubuntu2404-13-1-local_13.1.1-590.48.01-1_amd64.deb
sudo cp /var/cuda-repo-ubuntu2404-13-1-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-1
2. Adicione o CUDA ao seu ambiente (acrescente ao ~/.bashrc):
# cuda toolkit
export PATH=/usr/local/cuda-13.1/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-13.1/lib64:$LD_LIBRARY_PATH
Depois execute source ~/.bashrc ou abra um novo terminal.
3. Instale os cabeçalhos de desenvolvimento do OpenSSL (necessário para um build limpo):
sudo apt update
sudo apt install libssl-dev
4. Compile o llama.cpp (a partir do diretório contendo seu clone do llama.cpp, com CUDA habilitado):
cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-mtmd-cli llama-server llama-gguf-split llama-embedding
cp llama.cpp/build/bin/llama-* llama.cpp
Isso produz llama-cli, llama-mtmd-cli, llama-server, llama-embedding e llama-gguf-split no diretório llama.cpp.
Você também pode compilar múltiplos backends e escolher dispositivos em tempo de execução. Isso é útil se você implantar o mesmo build em máquinas heterogêneas.
Escolha um modelo GGUF e uma quantização
Para executar inferência, você precisa de um arquivo de modelo GGUF (*.gguf). GGUF é um formato de arquivo único que reúne pesos do modelo mais metadados padronizados necessários por motores como llama.cpp.
Duas maneiras de obter um modelo
Opção A: Usar um arquivo GGUF local
Baixe ou copie um GGUF para ./models/:
mkdir -p models
# Coloque seu GGUF em models/my-model.gguf
Depois execute-o por caminho:
llama-cli -m models/my-model.gguf -p "Hello! Explain what llama.cpp is." -n 128 -st
Opção B: Deixar o llama.cpp baixar do Hugging Face
Builds modernos do llama.cpp podem baixar do Hugging Face e manter arquivos em um cache local. Isso muitas vezes é o fluxo de trabalho mais fácil para experimentos rápidos.
# Baixe um modelo do HF e execute um prompt
llama-cli \
--hf-repo ggml-org/tiny-llamas \
--hf-file stories15M-q4_0.gguf \
-p "Once upon a time," \
-n 200 \
-st
Você também pode especificar a quantização no seletor de repositório e deixar a ferramenta selecionar um arquivo correspondente:
llama-cli \
--hf-repo unsloth/phi-4-GGUF:q4_k_m \
-p "Summarize the concept of quantization in one paragraph." \
-n 160 \
-st
Se você precisar de um fluxo de trabalho totalmente offline depois, --offline força o uso do cache e impede o acesso à rede.
Escolha de quantização para inferência local
A quantização é a resposta prática à pergunta “Qual quantização GGUF devo escolher para inferência local” porque ela faz um trade-off direto entre qualidade, tamanho do modelo e velocidade.
Um ponto de partida pragmático:
- comece com uma variante Q4 ou Q5 para máquinas priorizadas em CPU,
- migre para precisão mais alta (ou quantização menos agressiva) quando puder pagar pela RAM ou VRAM,
- quando o modelo “parece burro” para sua tarefa, a correção muitas vezes é um modelo melhor ou uma quantização menos agressiva, não apenas ajustes de amostragem.
Lembre-se também que a janela de contexto importa: tamanhos de contexto maiores aumentam o uso de memória (às vezes dramaticamente), mesmo quando o arquivo GGUF em si cabe.
Quickstart do llama-cli e parâmetros-chave
llama-cli é a maneira mais rápida de validar que seu modelo carrega, que seu backend funciona e que seus prompts se comportam como esperado.
llama-cli tem sido um cliente de chat interativo desde a reescrita de dezembro de 2025. Quando o modelo inclui um template de chat, o modo de conversa está habilitado por padrão e --no-conversation é rejeitado com uma referência para llama-completion. Esse segundo binário é o antigo llama-cli: um prompt de entrada, uma conclusão de saída, adequado para scripts e pipes. A partir do novo cliente, --single-turn (-st) gera uma única resposta e sai.
Uma resposta e depois sair
llama-cli \
-m models/my-model.gguf \
-p "Write a short TCP vs UDP comparison." \
-n 200 \
-st
O mesmo prompt através do binário não interativo:
llama-completion \
-m models/my-model.gguf \
-p "Write a short TCP vs UDP comparison." \
-n 200 \
--no-conversation
Execução de chat interativo
llama-cli \
-m models/my-model.gguf \
--system-prompt "You are a concise systems engineering assistant." \
--ctx-size 4096
--conversation não é mais necessário. Para encerrar a geração quando o modelo imprime uma sequência específica, use um prompt reverso.
Principais flags do llama-cli que importam
Em vez de memorizar 200 flags, foque nas que dominam correção, latência e memória.
Modelo e download
| Objetivo | Flags | Quando usar |
|---|---|---|
| Carregar um arquivo local | -m, --model |
Você já tem *.gguf |
| Baixar do Hugging Face | --hf-repo, --hf-file, --hf-token |
Experimentos rápidos, cache automatizado |
| Forçar cache offline | --offline |
Execuções em ambiente isolado ou reproduzíveis |
Contexto e vazão
| Objetivo | Flags | Nota prática |
|---|---|---|
| Aumentar ou reduzir contexto | -c, --ctx-size |
Contextos maiores custam mais RAM ou VRAM |
| Melhorar processamento de prompt | -b, --batch-size e -ub, --ubatch-size |
Tamanhos de lote afetam velocidade e memória |
| Ajustar paralelismo de CPU | -t, --threads e -tb, --threads-batch |
Combine com seus núcleos de CPU e largura de banda de memória |
Offload de GPU e seleção de hardware
| Objetivo | Flags | Nota prática |
|---|---|---|
| Listar dispositivos disponíveis | --list-devices |
Útil quando múltiplos backends são compilados |
| Escolher dispositivos | --device |
Habilita escolhas híbridas de CPU e GPU |
| Offload de camadas | -ngl, --n-gpu-layers |
Padrão é auto. all força todas as camadas para a GPU |
| Ajustar configurações não definidas à VRAM | --fit (padrão on), --fit-target, --fit-ctx |
Reduz apenas o que você deixou indefinido, até 4096 tokens de contexto, deixando 1024 MiB livres por dispositivo |
| Manter especialistas MoE na RAM | --cpu-moe, --n-cpu-moe N |
Pesos de especialistas ficam na CPU para que um modelo MoE caiba em uma GPU menor |
| Precisão do cache KV | --cache-type-k, --cache-type-v |
Padrão f16; q8_0 ou q4_0 reduz memória KV. A matemática está em KV Cache em GPUs de 16 GB |
| Lógica multi-GPU | --split-mode, --tensor-split, --main-gpu |
Útil para hosts multi-GPU ou VRAM desigual |
Amostragem e qualidade da saída
| Objetivo | Flags | Boas configurações padrão para começar |
|---|---|---|
| Criatividade | --temp |
0,2 a 0,9 dependendo da tarefa |
| Amostragem nuclear | --top-p |
0,9 a 0,98 comum |
| Corte de token | --top-k |
40 é uma linha de base clássica |
| Reduzir repetição | --repeat-penalty e --repeat-last-n |
Especialmente útil para modelos pequenos |
Cargas de trabalho de exemplo com llama-cli
Resumir um arquivo, não apenas um prompt
llama-cli \
-m models/my-model.gguf \
--system-prompt "You summarize technical documents. Output five bullets max." \
--file ./docs/incident-report.txt \
-n 300 \
-st
Tornar resultados mais reproduzíveis
Quando você está depurando prompts, fixe a seed e reduza a aleatoriedade:
llama-cli \
-m models/my-model.gguf \
-p "Extract key risks from this design note." \
-n 200 \
--seed 42 \
--temp 0.2 \
-st
Quickstart do llama-server com API compatível com OpenAI
llama-server é um servidor HTTP embutido que pode expor:
- endpoints compatíveis com OpenAI para chat, conclusões, embeddings e respostas,
- uma interface Web para testes interativos,
- endpoints de monitoramento opcionais para visibilidade em produção.
Iniciar um servidor com um modelo local
llama-server \
-m models/my-model.gguf \
-c 4096
Por padrão, ele ouve em 127.0.0.1:8080.
Para bind externo (por exemplo dentro do Docker ou em uma LAN), especifique host e porta:
llama-server \
-m models/my-model.gguf \
-c 4096 \
--host 0.0.0.0 \
--port 8080
Flags opcionais, mas importantes do servidor
| Objetivo | Flags | Por que é importante |
|---|---|---|
| Concurencia | --parallel |
Controla slots do servidor para requisições paralelas |
| Batch contínuo | --cont-batching, --no-cont-batching |
Ligado por padrão; desligue apenas para comparar latência |
| Restringir acesso | --api-key ou --api-key-file |
Autenticação para requisições de API. Também definível com LLAMA_API_KEY |
| ID do modelo nas respostas da API | --alias |
Sem isso, o ID do modelo é o caminho do GGUF |
| Métricas Prometheus | --metrics |
Desligado por padrão; necessário para expor /metrics |
| Cache de prompt | --cache-prompt, --no-cache-prompt |
Ligado por padrão |
Se você executar em containers, muitas configurações também podem ser controladas através de variáveis de ambiente LLAMA_ARG_*.
Chamadas de API de exemplo
Chat completions com curl
curl http://localhost:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer no-key" \
-d '{
"model": "gpt-3.5-turbo",
"messages": [
{ "role": "system", "content": "You are a helpful assistant." },
{ "role": "user", "content": "Give me a quick llama.cpp checklist." }
],
"temperature": 0.7
}'
Dica para implantações reais: se você definir --api-key, pode enviá-lo via um cabeçalho x-api-key (ou continuar usando cabeçalhos de Authorization dependendo do seu gateway).
Cliente Python OpenAI apontando para llama-server
Com um servidor compatível com OpenAI, muitos clientes podem funcionar apenas mudando base_url — esta também é a forma como agentes de pesquisa como lukeswade/deep-research se comunicam diretamente com o llama-server, sem uma camada de adaptador separada. Sistemas de Pesquisa Profunda Auto-Hospedados: 12 Ferramentas Comparadas cobre esse projeto e outros apontados para endpoints locais compatíveis com OpenAI.
import openai
client = openai.OpenAI(
base_url="http://localhost:8080/v1",
api_key="sk-no-key-required",
)
resp = client.chat.completions.create(
model="gpt-3.5-turbo",
messages=[
{"role": "system", "content": "You are a concise assistant."},
{"role": "user", "content": "Explain threads vs batch size in llama.cpp."},
],
)
print(resp.choices[0].message.content)
Embeddings
Embeddings compatíveis com OpenAI são expostos em /v1/embeddings, mas o modelo deve suportar um modo de pooling de embedding que não seja none.
curl http://localhost:8080/v1/embeddings \
-H "Content-Type: application/json" \
-H "Authorization: Bearer no-key" \
-d '{
"input": ["hello", "world"],
"model": "GPT-4",
"encoding_format": "float"
}'
Se você executar um modelo de embedding dedicado, considere iniciar o servidor em modo apenas embeddings:
llama-server \
-m models/Qwen3-Embedding-0.6B-Q8_0.gguf \
--embeddings \
--host 127.0.0.1 \
--pooling last \
--port 8080
ou se você quiser executar o llama-cpp com modelo de embedding na CPU:
CUDA_VISIBLE_DEVICES="" llama-server \
-m models/Qwen3-Embedding-0.6B-Q8_0.gguf \
--embeddings \
--host 127.0.0.1 \
--pooling last \
--port 8080
tente assim:
CUDA_VISIBLE_DEVICES="" llama-embedding \
-m /path/to/Qwen3-Embedding-0.6B-Q8_0.gguf \
-p "your text here" \
--pooling last \
--verbose-prompt
Servir múltiplos modelos de um único processo
Os exemplos acima vinculam llama-server a um único modelo na inicialização. Se você precisar alternar entre modelos base em requisição — sem reiniciar o processo — é para isso que serve o modo router. Veja
Modo router do llama-server: troca dinâmica de modelos sem reinicialização.
Para um fluxo de descarregamento de todos scriptável que libera VRAM sem reiniciar o router, veja Descarregar Todos os Modelos do Router llama.cpp Sem Reiniciar.
Desempenho, monitoramento e fortalecimento para produção
A pergunta da FAQ “Quais opções de linha de comando do llama.cpp importam mais para velocidade e memória” torna-se muito mais fácil quando você trata a inferência como um sistema:
- Limite de memória é geralmente a primeira restrição (RAM na CPU, VRAM na GPU).
- Tamanho do contexto é um multiplicador de memória importante.
- Offload de camadas para GPU é muitas vezes o caminho mais rápido para mais tokens por segundo.
- Tamanhos de lote e threads podem melhorar a vazão, mas também podem aumentar a pressão de memória.
Para uma visão mais profunda, centrada em engenharia, veja: Desempenho de LLM em 2026: Benchmarks, Gargalos & Otimização.
Se você quer resultados medidos no estilo llama-cli em uma GPU de classe 16 GB—tokens por segundo, VRAM e carga da GPU enquanto varre o contexto (19K / 32K / 64K) através de GGUFs densos e MoE—veja Benchmarks de LLM com VRAM de 16 GB com llama.cpp (velocidade e contexto).
Para o Qwen 3.6, o llama.cpp suporta decodificação especulativa de Multi-Token Prediction integrada. Ative-a com --spec-type draft-mtp; --spec-draft-n-max define quantos tokens a cabeça de rascunho propõe (padrão 3). A v0.6.0 estende esse mesmo caminho MTP para o Qwen4Exp. Para a comparação de métodos, veja Decodificação Especulativa. Para números medidos do Qwen 3.6 em 16 GB, veja Qwen 3.6 MTP vs Padrão em GPU de 16GB.
Monitoramento do llama-server com Prometheus e Grafana
llama-server expõe métricas compatíveis com Prometheus em /metrics apenas quando --metrics está habilitado. Aponte um job de scrape do Prometheus nesse caminho. Dashboards e limiares de alerta para llama.cpp, vLLM e TGI estão em Monitoramento de Inferência de LLM em Produção (2026): Prometheus & Grafana para vLLM, TGI, llama.cpp.
Lista de verificação básica de fortalecimento
Quando seu llama-server está acessível além do localhost:
- use
--api-key(ou--api-key-file) para que as requisições sejam autenticadas, - evite bind em
0.0.0.0a menos que você precise, - considere TLS via as flags SSL do servidor ou termine TLS em um proxy reverso,
- restrinja a concorrencia com
--parallelpara proteger a latência sob carga, - mantenha
--toolse--agentdesligados. Ambos são experimentais e expõem operações de arquivo e shell pela API; habilitar qualquer um também restringe CORS para localhost.
Vitórias rápidas na solução de problemas
O modelo carrega, mas as respostas são estranhas no chat
Endpoints de chat são melhores quando o modelo tem um template de chat suportado. Se as saídas parecerem desestruturadas, tente:
- passar um
--system-promptexplícito (o modo de conversa já é o padrão nollama-cli), - verificar se seu modelo é uma variante ajustada para instruções ou chat,
- testar usando a interface Web do servidor antes de integrá-lo a um aplicativo. A v0.6.0 reconstruiu essa interface com um navegador do Hugging Face Hub, de modo que um modelo pode ser baixado da página, e não apenas da CLI.
Modelos de raciocínio envolvem a resposta em rastros de raciocínio. --reasoning off suprime isso e --reasoning-format deepseek move o rastro para reasoning_content em vez de content.
Você atingiu limite de memória
Reduza o contexto ou escolha uma quantização menor:
- abaixe
--ctx-size, - reduza
--n-gpu-layersse o problema for VRAM, ou defina--cpu-moepara que os pesos de especialistas de um modelo MoE fiquem na RAM, - mude para um modelo menor ou uma quantização mais compressa,
- quantize o cache KV com
--cache-type-k q8_0 --cache-type-v q8_0.
O contexto ou divisão de GPU não é o que você pediu
--fit está habilitado por padrão e reescreve configurações de memória que você deixou indefinidas, visando deixar 1024 MiB livres em cada dispositivo (--fit-target). Ele reduzirá o contexto, mas nunca abaixo de --fit-ctx (4096), e apenas quando você não passou -c. Ele não tocará na colocação de camadas uma vez que você passe qualquer -ngl. --fit off desabilita o mecanismo. Se os logs disserem n_gpu_layers already set by user, seu -ngl explícito é o que foi carregado, e fit não resgatará um erro de falta de memória dele.
Está lento na CPU
Comece com:
--threadsigual aos seus núcleos físicos,- tamanhos de lote moderados,
- validando se você instalou um build que corresponde à sua máquina (recursos de CPU e backend).