llama.cpp vs vLLM vs Exllama

#Um motor de inferência: o que realmente difere entre eles

Um motor de inferência transforma tokens de entrada em tokens de saída. Os aplicativos que você instala (Ollama, LM Studio, Jan) incorporam um; os servidores de produção (vLLM, SGLang) são motores de inferência. Três diferenças afetam seu uso: os formatos de modelos aceitos, o hardware que pode ser utilizado e a forma de gerenciar várias requisições ao mesmo tempo.

#O formato do modelo determina qual mecanismo pode ser usado

Antes de comparar velocidades, verifique o formato em que o modelo que você deseja está publicado. Um arquivo GGUF é carregado no llama.cpp e, portanto, no Ollama, no LM Studio e no Jan. Pesos do Hugging Face em FP16, FP8 ou quantizados em AWQ ou GPTQ são carregados no vLLM ou no SGLang. Um modelo convertido para MLX é carregado com MLX LM no Mac, e um modelo EXL3, com ExLlamaV3. Mudar de motor geralmente significa baixar novamente o modelo em outro formato.

#llama.cpp: o padrão portátil

O llama.cpp é uma implementação em C/C++ sem dependências, cujo objetivo declarado é a inferência com o mínimo de configuração em uma ampla variedade de hardware. O Apple Silicon recebe prioridade (NEON, Accelerate, Metal), as CPUs x86 são compatíveis com AVX, AVX2, AVX512 e AMX, e há suporte a GPUs NVIDIA (CUDA), AMD (HIP), Vulkan e SYCL. Ele oferece quantizações de 1,5 a 8 bits e inferência híbrida entre CPU e GPU, o que permite executar um modelo maior do que a VRAM disponível.

Ideia errada a corrigir: o llama.cpp não se limita a uma requisição de cada vez. Seu servidor anuncia geração paralela multiusuário e batching contínuo, ativado por padrão, com slots configurados pelo parâmetro --parallel. Ele atende, portanto, adequadamente uma pequena equipe; o que ele não busca igualar são as funcionalidades de produção em grande escala do vLLM.

Pontos fortes

Portabilidade (Mac, Linux, Windows, Android), formatos GGUF amplamente disponíveis, execução híbrida em CPU e GPU, poucas dependências.

Limites

Sem recursos de implantação distribuída comparáveis aos do vLLM; é preciso conhecer as configurações (contexto, slots, camadas na GPU).

Ecossistema

Base de apoio do Ollama e do LM Studio, também citada pelo Jan.

Para compilação com CUDA, Metal ou Vulkan, consulte os guias de compilação; o guia completo sobre llama.cpp detalha o uso.

#vLLM: o servidor para muitos usuários

vLLM é uma biblioteca de inferência e disponibilização de modelos criada no Sky Computing Lab da Universidade da Califórnia em Berkeley. Ela se baseia no PagedAttention, que gerencia por páginas a memória das chaves e dos valores da atenção, e no batching contínuo, complementados pelo pré-preenchimento em blocos e pelo cache de prefixos. Ela anuncia suporte aos formatos FP8, INT4, GPTQ, AWQ e GGUF, uma API compatível com a API da OpenAI e suporte a GPUs NVIDIA, AMD e Intel, além de CPUs x86, ARM e PowerPC.

Duas ideias equivocadas a corrigir. Primeiro, o vLLM não é mais exclusivo da NVIDIA e também tem suporte a CPUs: seu repositório indica suporte a várias GPUs e CPUs. Segundo, ele já oferece suporte a GGUF: sua documentação descreve esse suporte como muito experimental e pouco otimizado, utilizável principalmente para reduzir o uso de memória. Para o uso diário de GGUF, o llama.cpp continua sendo o caminho habitual.

Pontos fortes

Taxa de processamento sob carga, memória do cache gerenciada por páginas, API compatível com OpenAI, paralelismo (de tensores, de pipeline e de especialistas), diversos formatos.

Limites

Mais trabalhoso de instalar e configurar do que o llama.cpp; pensado para servidores com GPU; GGUF não é seu ponto forte.

Ecossistema

Escolha padrão quando várias pessoas ou aplicações consultam o mesmo modelo ao mesmo tempo.

O guia sobre o vLLM explica o que é o motor; o guia sobre sua implantação em produção detalha as configurações e o monitoramento.

#ExLlama: V2 arquivada, V3 em desenvolvimento

O repositório de ExLlamaV2 possui uma nota indicando que o projeto está arquivado por enquanto e que o desenvolvimento continua em ExLlamaV3. Muitos comparativos, incluindo a versão antiga desta página, ainda apresentam a V2 como a opção mais avançada. O repositório de ExLlamaV3 anuncia o formato de quantização EXL3, inferência paralela por tensores e por especialistas, offload para a CPU em modelos com especialistas, batching contínuo, decodificação especulativa e uma API compatível com OpenAI via TabbyAPI, seu servidor recomendado.

ExLlamaV3 é voltado para GPUs de consumo, não para servidores de produção nem Macs. Se você tem uma placa NVIDIA e quer o melhor equilíbrio entre qualidade e tamanho, vale a pena testar a quantização EXL3; verifique primeiro se o seu modelo consta na lista de arquiteturas do repositório.

#SGLang, MLX LM e os outros

SGLang

Framework para servir modelos, descrito como voltado para baixa latência e alto throughput, desde uma GPU até grandes clusters. Anuncia RadixAttention para o cache de prefixos, batching contínuo, PagedAttention e decodificação especulativa. Concorre com o vLLM em servidores; o guia dedicado o apresenta em detalhes.

MLX LM

Pacote Python para gerar texto e fazer ajuste fino de modelos no Apple Silicon com MLX. Não funciona fora do Mac. O guia MLX versus llama.cpp compara os dois no Mac.

TensorRT-LLM

Motor da NVIDIA, com alto desempenho em suas placas, mas com mais exigências de configuração; considerar apenas para um conjunto de placas NVIDIA em produção.

#O que dizem as medições publicadas

As taxas de geração dependem do hardware, do modelo, da quantização, do comprimento das requisições e da versão do motor, e evoluem todos os meses. Este guia, portanto, não apresenta nenhuma medição própria e recomenda que você desconfie de tabelas de tokens por segundo sem protocolo. Uma fonte de terceiros, no entanto, publica um protocolo completo: Red Hat, em agosto de 2025.

Ler com ressalvas: o artigo está ligado aos produtos Red Hat AI e, portanto, vem de uma empresa do setor; os testes são feitos com Ollama, não diretamente com llama.cpp, e usam configurações padrão; eles foram realizados há várias versões. A conclusão sólida é qualitativa: com muitas solicitações simultâneas, um mecanismo de serviço com batching agressivo supera uma aplicação projetada para um único usuário. Para uso individual, a diferença na taxa de processamento não é o que prejudica você.

#Memória: o que cada motor reserva

A memória de um modelo é composta pelos pesos, pelo cache de contexto (KV) e por uma margem. É possível calcular o tamanho dos pesos: um modelo com 8 bilhões de parâmetros ocupa cerca de 16 GB em FP16 (8 bilhões vezes 2 bytes) e cerca de 5 GB em Q4, valor de referência do site. O cache de contexto aumenta com o comprimento da conversa e o número de requisições simultâneas.

Ponto principal: o vLLM reserva a memória desde o início, o que o torna eficiente para atender a requisições, mas pouco adequado para uma placa compartilhada com outros aplicativos. Reduza o valor do parâmetro gpu_memory_utilization se a placa também for usada para outras tarefas.

#Qual motor para qual uso

Os motores podem coexistir: Ollama para o chat diário, vLLM iniciado sob demanda para processar um lote de extrações. Não há razão para manter apenas um se os usos forem diferentes. Apenas reserve espaço em disco para o mesmo modelo armazenado em dois formatos, por exemplo, um arquivo GGUF para o chat e pesos Hugging Face para o servidor.

• Ollama contra llama.cpp
• vLLM: o guia completo
• SGLang como servidor LLM local
• MLX contra llama.cpp no Mac
• llama.cpp: o guia completo
• Ollama, LM Studio, Jan ou GPT4All

• Fonte: repositório de llama.cpp
• Fonte: repositório do vLLM
• Fonte: repositório do ExLlamaV2
• Fonte: Red Hat, Ollama contra vLLM