llama.cpp vs Ollama em 2026: Qual runtime você deve usar?

Ollama e llama.cpp são frequentemente comparados como se fossem motores de inferência rivais. A escolha real está entre um serviço de modelos gerenciado e um toolkit que você opera diretamente.

O Ollama envolve uma versão fixa e com patches do llama.cpp dentro de um agendador, um repositório de modelos e uma API, de modo que o modelo nomeado se torna a unidade que você opera. O llama.cpp direto inverte isso: o processo llama-server e suas flags são a unidade, e cada escolha sobre contexto, cache KV e posicionamento na GPU é feita por você e pode ser vista em um comando.

Este guia compara os dois da maneira como a decisão realmente acontece: instalação e comandos diários, gestão e ciclo de vida dos modelos, controle de runtime, APIs, desempenho, modos de falha e segurança. Termina com gatilhos concretos para manter o Ollama, migrar para o llama-server e um caminho de migração de baixo risco entre eles. Se você ainda está decidindo entre abordagens locais, self-hosted e em nuvem em um nível mais alto, comece pela Visão geral de hospedagem de LLM; para a paisagem mais ampla de ferramentas locais além deste par, a comparação de hospedagem local de LLM cobre vLLM, LM Studio, LocalAI e mais.

llama.cpp vs Ollama: a resposta curta

Se você só precisa de um backend confiável para o Open WebUI, um assistente de codificação ou alguns scripts locais, o Ollama geralmente é a escolha menos distrativa. Se você continua perguntando o que o Ollama selecionou, alocou, alterou ou ocultou, provavelmente chegou ao ponto em que o llama-server é o sistema mais limpo.

O que a comparação realmente significa em 2026

O llama.cpp é um projeto de inferência em C e C++ com backends de CPU e GPU, ferramentas para modelos GGUF, programas de linha de comando e um servidor HTTP. Seu programa de servindo direto suporta Chat Completions compatível com OpenAI, Responses, embeddings, requisições multimodais, function calling, saída estruturada, lote contínuo (continuous batching), decodificação especulativa, endpoints de monitoramento e uma interface web embutida.

O Ollama é um serviço de nível superior. Ele mantém um repositório local de modelos, dá nomes estáveis aos modelos, baixa e importa artefatos, aplica templates e padrões, seleciona um backend disponível, agenda processos de modelos e descarrega modelos ociosos. Sua API nativa também relata tempos de execução e informações de carregamento que são convenientes para aplicativos locais.

A afirmação frequentemente repetida de que “Ollama é apenas um wrapper em volta do llama.cpp” é direcionalmente útil, mas tecnicamente incompleta. O Ollama fixa o código-fonte do llama.cpp, aplica patches de compatibilidade e inicia um servidor através de seu próprio agendador, mas também tem comportamento de produto que o llama.cpp não define; na silício Apple, o Ollama pode usar seu motor MLX. O caminho da requisição torna a diferença concreta:

Isso leva ao modelo mental mais útil:

• Com o Ollama, o modelo nomeado é a unidade que você opera.
• Com o llama.cpp direto, o processo do servidor e suas flags são a unidade que você opera.

Instalação e a superfície de comandos diários

O Ollama otimiza os primeiros cinco minutos. Após a instalação, buscar e iniciar um modelo é intencionalmente conciso:

ollama run qwen3:8b

O nome do modelo representa mais do que seus pesos. O Ollama pode associar um template, parâmetros, prompt de sistema, licença, adaptador e versão mínima de runtime a esse nome. ollama list, ollama show, ollama ps e ollama stop fornecem uma superfície de gestão coerente.

O llama.cpp direto começa mais próximo do metal. Você pode baixar um binário de release, construir uma versão específica de backend, usar um container ou usar o novo caminho de download do Hugging Face, como o llama.cpp quickstart detalha. Um servidor local GGUF pode iniciar assim:

llama-server \
  --model /srv/models/qwen3-8b-q4_k_m.gguf \
  --alias qwen3-8b \
  --host 127.0.0.1 \
  --port 8080 \
  --ctx-size 32768 \
  --n-gpu-layers all \
  --flash-attn on

A documentação atual do llama.cpp também mostra o comando unificado llama serve em seu quickstart. Os nomes dos executáveis empacotados podem variar por distribuição, então verifique a release ou o pacote que você instalou, em vez de copiar um arquivo de serviço cegamente.

O comando mais longo não é automaticamente uma desvantagem. É um registro executável do runtime que você pretendia criar. Coloque-o em uma unidade systemd, arquivo Compose ou script de shell, e a configuração se torna revisável, em vez de estar espalhada por um manifest de modelo, variáveis de ambiente, opções de API e padrões do agendador.

O trade-off prático de instalação

O Ollama é mais fácil de instalar consistentemente em máquinas de desenvolvimento. Também é mais fácil de explicar a alguém que deve usar um modelo, mas não precisa entender offload de tensor, templates de chat ou memória KV.

O llama.cpp é mais fácil de tornar exato. Você escolhe o build, backend, versão, arquivo e flags, o que é valioso quando um novo kernel de GPU corrige sua carga de trabalho ou um commit recente a quebra. Essa liberdade também significa que você é responsável por atualizações, supervisão de serviço e testes de regressão.

Gestão de modelos: nomes de biblioteca ou arquivos comuns

O Ollama trata modelos de maneira semelhante a imagens de container. Um nome familiar aponta para um manifest e blobs endereçados por conteúdo, e ollama pull resolve as camadas necessárias. Isso é excelente para configuração de estação de trabalho repetível e para aplicativos que devem se referir a qwen3:8b em vez de um longo caminho de sistema de arquivos.

Um Modelfile torna a customização reproduzível:

FROM ./qwen3-8b-q4_k_m.gguf
PARAMETER num_ctx 32768
PARAMETER temperature 0.7
PARAMETER top_p 0.9
SYSTEM Você é um assistente técnico preciso.

ollama create qwen3-8b-local -f Modelfile
ollama run qwen3-8b-local

O Ollama pode importar um GGUF local, então escolher o Ollama não o restringe à biblioteca pública do Ollama. A etapa de importação, no entanto, entrega o artefato ao repositório de modelos do Ollama. Se você também reter o GGUF original para o llama.cpp ou LM Studio, considere a cópia gerenciada adicional, a menos que sua camada de armazenamento faça deduplicação.

O llama.cpp pode simplesmente apontar para o GGUF que você já tem. Ele também pode baixar uma quantização selecionada do Hugging Face:

llama-server -hf ggml-org/Qwen3-8B-GGUF:Q4_K_M

Esta abordagem orientada a arquivo funciona especialmente bem para testar novas quantizações. Baixe um arquivo, mude um caminho e inicie; não há etapa de criação e nenhuma pergunta sobre a qual blob o nome do modelo resolve.

Templates são parte do modelo, mesmo quando parecem configuração

Os pesos não definem todo o comportamento do chat. O template de chat controla como as mensagens de sistema, usuário, assistente, pensamento e ferramenta se tornam tokens. Sequências de parada e comportamento do parser podem alterar o resultado novamente.

A biblioteca curada do Ollama reduz esse risco porque seus modelos nomeados carregam metadados testados, e as releases atuais (o Ollama passou de 0.30 para 0.33.3 entre junho e setembro de 2026) respeitam cada vez mais diretamente os parâmetros padrão definidos no GGUF, em vez de exigir que você os repita em um Modelfile. Um GGUF importado manualmente ainda pode precisar de um TEMPLATE, parser ou renderer correto, enquanto o llama.cpp normalmente lê o template de chat GGUF embutido e permite que você o sobrescreva. Nenhum dos runtimes pode reparar metadados de modelo incorretos ou ausentes por mágica.

Se o mesmo modelo quantizado parecer visivelmente pior após uma mudança de runtime, não conclua que um dos motores danificou os pesos. Primeiro compare o template, limite de contexto, valores de amostragem, modo de pensamento, parser de ferramentas e revisão do runtime, uma variável de cada vez, antes de tocar no modelo em si.

Ciclo de vida de modelos e troca

O agendador do Ollama é um de seus motivos mais fortes para existir. Por padrão, um modelo ocioso permanece carregado por cinco minutos; um valor keep_alive no nível da requisição pode mantê-lo residente indefinidamente, mudar a duração ou descarregá-lo imediatamente. ollama ps mostra modelos carregados, posicionamento no processador, alocação de contexto e expiração.

# Mantenha um modelo carregado.
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": -1
}'

# Descarregue imediatamente.
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": 0
}'

Um processo tradicional llama-server --model ... carrega um modelo e o mantém até o processo sair. Esse comportamento é maravilhosamente previsível para um serviço dedicado: não há carga fria surpreendente após um tempo ocioso e nenhum agendador decidindo que outro modelo merece a memória.

O llama.cpp agora também tem modo router. Iniciar o llama-server sem um modelo pode expor modelos em cache, um diretório GGUF ou presets INI e carregar instâncias dinamicamente de acordo com o nome do modelo solicitado. Ele fecha o antigo lacuna de ciclo de vida apenas parcialmente: apenas um modelo é residente por trabalhador de cada vez, uma troca é um descarregamento e recarregamento completo em vez de instantâneo, e não há política de evicção ou pool quente — cada requisição alternada entre dois modelos paga um recarregamento completo. Isso reduz a lacuna em relação a nunca ter modo router, mas não torna os dois produtos idênticos; o Ollama ainda fornece a experiência de registro, pool quente e administração mais suave. Para o roteiro completo de configuração, limitações atuais e uma comparação honesta com o Ollama e o llama-swap, veja o guia do modo router do llama-server. Se você precisa de um endpoint através de llama.cpp, vLLM, SGLang e outros motores, o llama-swap é uma abstração mais apropriada do que pedir a qualquer runtime que se torne um proxy universal de modelos.

Controle de runtime: onde o llama.cpp justifica o trabalho extra

A vantagem decisiva do llama.cpp não é que ele seja sempre mais rápido. É que você pode expressar o plano de memória e execução diretamente, inspecioná-lo e mudar uma variável de cada vez.

Precisão de contexto e cache KV

Para o llama.cpp direto, o tamanho do contexto e os tipos de cache K/V podem ser definidos por processo de servidor:

llama-server \
  --model model.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --parallel 2 \
  --flash-attn on

K e V podem usar tipos diferentes, e o llama.cpp expõe controles adicionais para alocação unificada de KV, limites de contexto por slot, reutilização de cache de prompt e persistência de cache. Essas flags não são decorativas em uma GPU de 16 GB ou 32 GB — elas determinam se requisições de contexto longo cabem e quantos slots podem permanecer úteis, e o cálculo de orçamento de VRAM subjacente é o mesmo, independentemente de qual runtime o imponha; veja KV Cache em GPUs de 16 GB para a fórmula e tabelas de tipos de cache por motor.

O Ollama expõe o caso comum importante com OLLAMA_CONTEXT_LENGTH, a opção num_ctx e OLLAMA_KV_CACHE_TYPE. Seu tipo de cache KV, no entanto, é uma configuração de nível de servidor, e não uma escolha por modelo nomeado. O Ollama também escala a memória com a paralelismo configurado e o comprimento do contexto, o que pode fazer uma mudança inofensiva de concorrentia consumir muito mais VRAM.

Esse comportamento pertence principalmente ao guia de requisições paralelas do Ollama. Para esta comparação, a decisão é mais simples: use Ollama quando uma política global de cache for aceitável; use serviços separados do llama.cpp quando diferentes modelos precisarem de diferentes precisões de cache, contexto ou geometria de slots.

Seleção de GPU e posicionamento multi-GPU

O Ollama visa escolher um posicionamento sensato. Ele relata se um modelo está totalmente na GPU, totalmente na CPU ou dividido, e seu agendador considera a memória disponível ao carregar modelos. Para uma estação de trabalho normal de GPU única, o posicionamento automático é frequentemente exatamente o que você quer.

O llama.cpp expõe o plano. Você pode selecionar dispositivos, especificar camadas de GPU, escolher modos de divisão de tensor por camadas, linhas ou experimentais, definir proporções de tensor, selecionar a GPU principal e manter deliberadamente pesos de especialistas MoE na CPU. Isso é substancialmente melhor para máquinas multi-GPU assimétricas e para espremer um modelo oversized em um orçamento de memória conhecido.

Se suas notas operacionais contêm frases como “coloque o cache KV nestes dispositivos” ou “mantenha apenas os especialistas na RAM do sistema”, o llama.cpp direto é a ferramenta natural. Se o requisito for apenas “use a GPU se couber”, o Ollama economiza tempo sem abrir mão de muito.

Novos recursos e cadência de backends

O llama.cpp direto é onde novos modelos, tipos de quantização, kernels de GPU e opções experimentais de servidor do llama.cpp aparecem primeiro. Isso é valioso durante uma semana de lançamento de modelo, quando o suporte pode depender de um número de build específico em vez do último pacote estável.

O Ollama fixa deliberadamente uma revisão upstream e aplica patches de compatibilidade. Isso pode atrasar um recurso upstream, mas também pode proteger os usuários de instabilidade e integrá-lo com o agendador do Ollama, templates e empacotamento multiplataforma. Acesso mais rápido não é a mesma coisa que maior confiabilidade.

O Ollama 0.30 reduziu substancialmente uma lacuna mais antiga expandindo a compatibilidade GGUF, melhorando o desempenho da NVIDIA e habilitando Vulkan por padrão para suporte mais amplo a AMD e Intel. A cadência de releases do Ollama desde então tem permanecido rápida — 0.33.3 foi lançado no início de setembro de 2026, aproximadamente três meses depois, adicionando relatório de tokens de prompt em cache e outra atualização de backend do llama.cpp — então trate qualquer afirmação específica de versão neste artigo, ou em qualquer outro lugar, como algo a re-verificar com ollama --version em vez de um fato permanente. Qualquer comparação que diga que o Ollama não pode executar um GGUF local arbitrário, ou que o Vulkan sempre requer uma opção experimental, agora está desatualizada.

APIs, ferramentas, visão e saída estruturada

Ambos os runtimes são servidores de API locais credíveis em 2026. Ambos podem lidar com requisições de chat comuns estilo OpenAI, ferramentas, modelos com capacidade de visão, embeddings, streaming e saída estruturada, quando o modelo e o template os suportam.

A diferença está na superfície circundante:

Não trate “compatível com OpenAI” como uma certificação binária. O Ollama diz que suporta partes da API OpenAI, enquanto o llama.cpp evita explicitamente fazer uma promessa forte de compatibilidade. Antes de mudar de runtime, teste quadros de streaming, argumentos de tool-call, campos de raciocínio, contadores de uso, corpos de erro e qualquer endpoint que seu cliente realmente consuma.

O Ollama geralmente vence quando a integração do aplicativo é o trabalho. Seus SDKs e integrações documentadas tornam o caminho feliz curto. O llama.cpp vence quando o próprio servidor é o objeto de engenharia: sua visão de slot, tempos de token, métricas, schemas, templates, adaptadores e endpoints de baixo nível são incomumente úteis durante o diagnóstico.

Desempenho: meça a implantação, não a marca

É tentador perguntar se o llama.cpp ou o Ollama é mais rápido. Em um caminho GGUF, o Ollama pode estar executando um llama.cpp fixo e com patches por baixo, então uma resposta universal de nível de marca não é útil. Os resultados mudam com a revisão do build, backend, flash attention, alocação de contexto, slots paralelos, tamanhos de lote, tipo de cache, residência do modelo e se algumas camadas caíram para a CPU.

Uma comparação justa começa com o mesmo GGUF e testa duas perguntas diferentes:

1. Início frio: inclua o tempo de carregamento do modelo e a latência da primeira resposta.
2. Serviço quente: pré-carregue o modelo, então meça o processamento do prompt e a geração separadamente.

Use uma requisição e um slot primeiro. Combine o tamanho do contexto, tipo de cache K/V, temperatura, top-p, seed, saída máxima e template de chat; confirme o offload completo da GPU a partir de logs ou saída de status. Só então aumente a concorrentia, porque Ollama e llama.cpp alocam e agendam trabalho paralelo de maneira diferente.

Para o Ollama, a resposta final da API nativa inclui durações de carregamento, avaliação do prompt e geração, e as releases atuais também relatam diretamente tokens de prompt em cache naquela resposta — útil para confirmar se a reutilização de prefixo realmente aconteceu antes de você atribuir uma vitória de velocidade ao runtime. Para o llama.cpp, habilite o relatório de desempenho ou métricas Prometheus e inspecione a configuração de inicialização. Uma vitória de cinco por cento de throughput é sem sentido se uma execução usou silenciosamente um contexto mais curto, um tipo de cache diferente ou um template diferente.

Minha expectativa para o mesmo GGUF suportado em uma GPU é geralmente quase paridade, não uma vitória garantida do llama.cpp. O llama.cpp direto pode vencer após ajuste deliberado ou adotando uma otimização mais nova; o Ollama pode ser igualmente rápido quando seu motor selecionado e padrões se alinham com a carga de trabalho. Meça após a configuração, não antes.

Modos de falha que expõem a diferença real

O modelo usa CPU inesperadamente

Com o Ollama, execute ollama ps e inspecione PROCESSOR, CONTEXT e o tamanho carregado. Um contexto maior, outro modelo residente ou um caminho de GPU não suportado podem explicar a divisão. Verifique os logs do serviço em vez de assumir que a GPU foi ignorada.

Com o llama.cpp, comece com llama-server --list-devices, então leia o log de inicialização para posicionamento de tensor e tamanhos de buffer. Se você definiu um número exato de camadas, dispositivo ou divisão, o próprio comando é evidência de sua intenção; isso é muito mais fácil de reproduzir em um relatório de bug.

Um contexto mais longo causa um erro de memória insuficiente

O Ollama escolhe comprimentos de contexto padrão de acordo com a VRAM disponível, e a documentação atual recomenda pelo menos 64K para cargas de trabalho de agentes e codificação. Essa recomendação não é uma promessa de que seu modelo, paralelismo e cache caberão. Reduza num_ctx, reduza o paralelismo, escolha cache KV q8_0 onde apropriado ou use uma quantização de pesos menor. Confirme o quadro real de memória com nvidia-smi antes e depois de uma requisição longa para saber se o modelo, o cache ou ambos são a restrição.

Com o llama.cpp, reduza --ctx-size, mude --cache-type-k e --cache-type-v, diminua --parallel ou ajuste o offload. Como cada escolha é explícita, é mais fácil construir perfis separados de contexto longo e alta concorrentia, em vez de forçar um compromisso em cada modelo.

A API conecta, mas as respostas estão mal formadas

Isso é frequentemente um problema de template ou parser, especialmente com novos modelos de raciocínio e tool-calling. Verifique se o GGUF contém o template de chat esperado e se o runtime reconhece a arquitetura. Compare uma requisição de chat simples antes de depurar o framework de agente sobreposto acima.

No Ollama, inspecione ollama show --modelfile <name> e as capacidades relatadas. No llama.cpp, inspecione as mensagens de template de inicialização, use --jinja e teste /v1/chat/completions diretamente. Fixe a versão do runtime que funciona antes de mudar outra variável.

As requisições ficam lentas após trocar modelos

O Ollama pode precisar descarregar um modelo e carregar outro, então separe o tempo de fila do tempo de geração. Pré-carregue o modelo importante com uma requisição vazia e defina um valor keep_alive intencional, em vez de depender do padrão de cinco minutos.

Um processo dedicado do llama.cpp evita troca surpreendente porque seu modelo permanece residente. Se você adotar o modo router, o carregamento de modelos se torna dinâmico novamente — e cada troca entre dois modelos diferentes é um descarregamento e recarregamento completo sem pool quente — então monitore o estado de carga e a latência de início frio, assim como faria com o Ollama.

Segurança não é um diferencial, a menos que você a configure

Ambos os servidores se vinculam ao localhost por padrão, o que é o comportamento correto para uma estação de trabalho. Mudar o host para 0.0.0.0 transforma um serviço de inferência local privado em um serviço de rede, e nenhum dos produtos deve ser exposto à Internet pública apenas porque uma regra de firewall permitiu.

O llama.cpp pode impor chaves de API e terminar TLS, embora um proxy reverso ainda seja útil para política, limites de taxa e logs. A API local do Ollama não requer uma chave de API; coloque-o atrás de um proxy autenticado ou fronteira de rede privada se clientes remotos precisarem de acesso. Se você precisar de acesso remoto ao Ollama, o guia do Ollama atrás de um proxy reverso cobre a configuração Caddy e Nginx com verificações de streaming e timeout. Modelos com capacidade de ferramentas aumentam a consequência de expor o aplicativo circundante, mesmo quando o servidor de inferência em si não executa as ferramentas.

Quando manter o Ollama

Mantenha o Ollama quando sua automação remove mais trabalho do que oculta. Ele é especialmente forte para estações de trabalho de desenvolvimento compartilhadas, aplicativos de desktop locais, demonstrações, ferramentas de codificação e pequenos serviços que alternam entre vários modelos populares.

O Ollama também é o padrão melhor quando você quer que colegas repitam uma configuração nomeada sem aprender as flags do llama.cpp. Um Modelfile, tag de modelo e dois comandos são um contrato operacional útil. A folha de dicas do Ollama cobre esse fluxo de trabalho diário em mais detalhes.

Não migre apenas porque o llama.cpp direto parece mais técnico. Se seu modelo cabe, a API se comporta corretamente, a latência está estável e você não precisa de um controle ausente, substituir o Ollama cria manutenção sem criar capacidade.

Uma ressalva digna de acompanhamento ao longo do tempo: a direção de produto do próprio Ollama começou a derivar para infraestrutura centralizada. Ollama Turbo é um serviço de aceleração em nuvem com porta de login, sobreposto a uma ferramenta que era originalmente local-first e privacy-first, e não é a única mudança recente que troca controle local por uma camada de conveniência hospedada. Se a razão pela qual você escolheu o Ollama no início foi evitar o envio de prompts para servidores de outra pessoa, esse raciocínio merece uma re-verificação periódica em vez de uma decisão única — veja [Enshittification do Ollama: Os Primeiros Sinais](https://www.glukhov.org/pt/llm-hosting/ollama/ollama-enshittification/ “Visão geral dos primeiros sinais de enshittification do Ollama: monetização em nuvem Turbo, telemetria, comportamento de auto-início e regressões de desempenho.”}) para as mudanças específicas e o que observar. O llama.cpp direto não tem um upsell hospedado equivalente para onde derivar, o que em si é um ponto de dados quando você está pesando controle de longo prazo contra conveniência de curto prazo.

Quando migrar para o llama-server

Migre para o llama-server direto quando uma ou mais destas declarações forem verdadeiras:

• Você precisa de um novo recurso do llama.cpp ou correção de modelo antes que chegue ao Ollama.
• Você deve fixar um commit exato do llama.cpp e um build de backend.
• Modelos diferentes precisam de diferentes tipos de cache K e V ou layouts de slot.
• Você precisa de posicionamento multi-GPU deliberado em vez de seleção automática.
• Você está testando decodificação especulativa, MTP, escalas de LoRA, cache de prompt ou amostradores incomuns.
• Métricas nativas, estado de slot ou internos do servidor são necessários para diagnóstico.
• Você quer que os arquivos GGUF originais permaneçam o catálogo de modelos autoritativo.
• Um modelo deve permanecer residente pela vida de um processo supervisionado.

O gatilho de migração mais limpo é a inspeção repetida. Se cada incidente começa com a descoberta do que o Ollama escolheu antes de você poder diagnosticar o modelo, torne essas escolhas explícitas em uma definição de serviço do llama.cpp.

Uma migração de baixo risco do Ollama para o llama.cpp

Não comece reproduzindo cada recurso do Ollama. Migre um modelo e um cliente, preserve o endpoint atual até que a comparação esteja completa e mantenha o mesmo GGUF, se possível.

1. Registre ollama --version, ollama show <model>, ollama show --modelfile <model> e ollama ps.
2. Localize ou baixe o GGUF equivalente e qualquer projetor multimodal.
3. Inicie um llama-server com um alias explícito, contexto, offload de GPU, tipos de cache e número de slots.
4. Envie uma requisição de chat simples, uma requisição de saída estruturada e uma chamada de ferramenta diretamente para cada API.
5. Teste o cliente real, incluindo streaming e tratamento de erros.
6. Compare a latência de carga fria, a velocidade de prompt quente, a velocidade de geração, a VRAM e o formato da resposta.
7. Só então substitua a URL do serviço ou adicione um proxy na frente de ambos os backends.

Para um teste simples estilo OpenAI:

curl http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3-8b",
    "messages": [
      {"role": "user", "content": "Retorne exatamente: runtime-ok"}
    ],
    "temperature": 0,
    "max_tokens": 16
  }'

Então verifique o próprio serviço:

# llama.cpp
llama-server --version
llama-server --list-devices
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/v1/models

# Ollama
ollama --version
ollama ps
curl http://127.0.0.1:11434/api/ps
curl http://127.0.0.1:11434/v1/models

Se o aplicativo depende da forma de resposta da API nativa do Ollama /api/chat, mudar a URL base não é suficiente. Migre primeiro o cliente para uma rota compatível com OpenAI ou adicione um adaptador. O guia de migração do Ollama para vLLM discute o mesmo princípio de contrato primeiro para um salto de runtime maior.

Veredicto final

O Ollama é o melhor aparelho de modelo local. Ele fornece um catálogo de modelos, receitas reproduzíveis, posicionamento automático sensato, APIs convenientes e gestão de ciclo de vida sem exigir que cada usuário se torne um operador de inferência.

O llama.cpp é o melhor instrumento de precisão. O llama-server expõe suficiente do plano de execução para tornar VRAM restrito, contexto longo, hardware incomum, suporte a novos modelos e experimentos controlados compreensíveis em vez de misteriosos.

Para a maioria das pessoas, a sequência certa não é Ollama ou llama.cpp para sempre. Comece com o Ollama, aprenda quais restrições realmente importam e mova a carga de trabalho afetada para o llama.cpp direto quando você puder nomear o controle de que precisa. Essa é uma razão muito mais forte do que perseguir um benchmark medido sob os padrões de outra pessoa.

Referências

• Projeto llama.cpp e backends suportados
• Recursos, flags, endpoints e modo router do llama-server
• FAQ do Ollama: contexto, keep-alive, concorrentia e cache KV
• Referência de Modelfile do Ollama
• Importação de modelos GGUF e Safetensors para o Ollama
• Compatibilidade da API OpenAI do Ollama
• Mudanças de GGUF, NVIDIA e Vulkan no Ollama 0.30
• Como o Ollama fixa e aplica patches no llama.cpp
• Suporte a hardware do Ollama
• Padrões de comprimento de contexto do Ollama
• Releases do Ollama (GitHub)