Key Takeaways
- vLLM: melhor para produção de alta carga — processa 1.000+ tok/s com otimizações PagedAttention e batching contínuo.
- llama.cpp (via Ollama): melhor para hardware de consumo — leve, suporta CPU+GPU, configuração simples.
- Text-Generation-WebUI: melhor para pesquisa e fine-tuning — suporte nativo a LoRA, interface visual para experimentos.
- Regra geral: use Ollama (llama.cpp) para desenvolvimento e projetos individuais; vLLM para APIs multi-usuário em produção.
O llama.cpp é o motor de inferência mais leve e alimenta o Ollama, o vLLM é o mais rápido para APIs de produção de alto rendimento, e o Text-Generation-WebUI é o mais rico em recursos para pesquisa e experimentação -- escolha de acordo com sua necessidade de portabilidade, throughput ou flexibilidade.
Essas três ferramentas rodam modelos de IA localmente, mas para tarefas diferentes. O llama.cpp é o motor leve que alimenta o Ollama por baixo dos panos -- ótimo para uso pessoal. O vLLM foi feito para atender muitos usuários ao mesmo tempo o mais rápido possível, por isso as empresas o usam em produção. O Text-Generation-WebUI é a ferramenta para quem gosta de mexer, com mais opções para pesquisa e ajuste fino.
O que é um motor de inferência?
Um motor de inferência é o componente de software que carrega um arquivo de modelo pré-treinado e executa as operações matemáticas necessárias para gerar texto. Ele é diferente de uma interface de chat (como Open WebUI) ou de uma camada de API (como a API REST do Ollama).
Uma implantação típica de LLM local tem três camadas:
1. Arquivo do modelo (por exemplo, llama-3.1-8b.gguf) — os pesos da rede neural.
2. Motor de inferência (por exemplo, llama.cpp, vLLM) — carrega o modelo e gera tokens.
3. Interface ou API (por exemplo, API REST, chat web, extensão do VS Code) — permite interagir com o motor.
O próprio Ollama é essencialmente um wrapper em torno do llama.cpp com uma API compatível com a OpenAI. O vLLM é um motor de inferência sem interface própria. O Text-Generation-WebUI é um motor de inferência com interface web integrada.
Comparação de recursos: llama.cpp vs vLLM vs Text-Generation-WebUI
| Recurso | llama.cpp | vLLM | Text-Gen-WebUI |
|---|---|---|---|
| Tipo | Biblioteca C++ (leve) | Framework Python (produção) | Aplicativo Python (experimentação) |
| Suporte a GPU | NVIDIA, AMD, Apple Metal | NVIDIA (melhor), AMD ROCm, Intel, CPU | NVIDIA, AMD, CPU |
| Inferência em CPU | Excelente | Fraca | Boa |
| Throughput (tokens/seg) | Médio (1-100) | Muito alto (100-1000+) | Médio (1-100) |
| Suporte a batching | Limitado | Completo (lotes de 100+) | Limitado |
| Interface web integrada | Não | Não | Sim |
| Fine-tuning LoRA | Não diretamente | Limitado | Integrado |
| Formatos de quantização | GGUF (GGML legado) | Precisão total, 8-bit, 4-bit | GGUF, safetensors, fp16 |
| Dificuldade de instalação | Via Ollama (fácil) | pip install (média) | Clone do GitHub (média) |
| Preço | Gratuito | Gratuito | Gratuito |
Entendendo o llama.cpp: a base
O llama.cpp é uma implementação em C++ de inferência de LLMs, escrita originalmente para rodar o modelo Llama da Meta em hardware de consumo sem aceleração por GPU. Ele continua sendo o motor de inferência mais leve e portátil.
Por que o llama.cpp domina o uso de consumo:
- Sobrecarga mínima de memória — roda com 8 GB de RAM apenas com CPU.
- Suporta múltiplos backends de GPU (NVIDIA, AMD, Apple Metal, Intel).
- Formato GGUF: um formato de modelo quantizado que comprime modelos de 70B para 20-40 GB.
- Alimenta o Ollama internamente — você está usando llama.cpp sempre que roda o Ollama.
O llama.cpp não é um aplicativo completo; é uma biblioteca. Você interage com ele por meio do Ollama (a forma mais comum) ou de outras ferramentas que o integram. Para usá-lo diretamente em ajustes avançados, é preciso compilá-lo e usar as ferramentas de linha de comando ou os bindings em Python.
Entendendo o vLLM: o padrão de produção
O vLLM é um framework Python projetado para inferência de alto throughput em clusters de GPU. Ele é otimizado para servir modelos via API, com suporte a batching, inferência distribuída e agendamento avançado.
Por que o vLLM domina a produção:
- PagedAttention: o vLLM usa um layout de memória inovador que eleva a utilização da GPU de ~20% para ~70%, aumentando muito o throughput.
- Processamento em lote: consegue processar 50-100 prompts simultaneamente, atendendo mais usuários por GPU.
- Inferência distribuída: divide automaticamente um modelo de 70B entre várias GPUs.
- Amplo suporte a modelos: funciona com qualquer modelo do HuggingFace (Llama, Qwen, Mistral, Phi etc.).
O vLLM segue como o motor de produção mais implantado, embora o SGLang (também baseado em PagedAttention) venha ganhando adoção nas maiores escalas por sua saída estruturada e serviço multi-modelo mais rápidos. A compensação é o alcance real do hardware: o vLLM também funciona em AMD ROCm, Intel e CPU (e de forma experimental em Apple Silicon), mas a NVIDIA continua sendo de longe o caminho mais bem otimizado, e seu desempenho em CPU fica bem atrás do llama.cpp.
# Instalar o vLLM
pip install vllm
# Rodar um modelo via API
vllm serve meta-llama/Llama-3.2-3B-Instruct \
--host 0.0.0.0 --port 8000 \
--gpu-memory-utilization 0.9
# Agora acessível em http://localhost:8000/v1/completionsEntendendo o Text-Generation-WebUI: a ferramenta do pesquisador
O Text-Generation-WebUI (também chamado de oobabooga) é um aplicativo Python completo com interface web para experimentar com modelos. Ele combina inferência com ferramentas integradas de fine-tuning, treinamento LoRA, geração de embeddings e teste avançado de prompts.
Nota sobre o nome: o projeto foi renomeado para TextGen em 2026 e o repositório passou para `github.com/oobabooga/textgen`. A URL antiga continua redirecionando e os scripts de inicialização não mudaram, então instalações e guias existentes seguem funcionando. A comunidade ainda o chama majoritariamente de text-generation-webui ou oobabooga.
As versões 4.x o ampliaram muito além de uma ferramenta apenas de pesquisa: suporte a modelos de visão, tool-calling, uma API compatível com a Anthropic além da compatível com a OpenAI, um aplicativo desktop Electron nativo (4.7.3, maio de 2026), paralelismo de tensores no llama.cpp e decodificação especulativa MTP com leitura de tokens/seg em tempo real (4.9, maio de 2026).
Por que pesquisadores usam o Text-Generation-WebUI:
- Fine-tuning LoRA integrado: treine adaptadores LoRA sobre modelos base sem scripts de treinamento externos.
- Múltiplos motores de inferência: alterne entre llama.cpp, GPTQ, exllama e outros backends.
- Personagens e roleplay: sistema integrado para criar e testar personas.
- Exposição de API: disponibiliza uma interface FastAPI para uso programático.
- Ecossistema de extensões: extensões da comunidade para fluxos personalizados.
O Text-Generation-WebUI é mais uma ferramenta de pesquisa e experimentação do que um servidor de produção. A instalação é mais trabalhosa (exige clone do GitHub e gestão de dependências Python), mas, uma vez rodando, é extremamente poderosa para desenvolvimento.
Qual a velocidade de cada motor? Comparação de throughput
O throughput (tokens por segundo) depende do tamanho do modelo, do hardware e da otimização do motor. Veja benchmarks reais em hardware de consumo:
| Cenário | llama.cpp | vLLM | Text-Gen-WebUI |
|---|---|---|---|
| Llama 3.2 3B em RTX 4090 (GPU) | 150 tokens/seg | 300 tokens/seg (com batching) | 150 tokens/seg |
| Llama 3.2 3B em CPU de 8 núcleos | 5 tokens/seg | 0,5 tokens/seg (inviável) | 4 tokens/seg |
| Llama 4 Scout em 2× RTX 4090 | 20 tokens/seg (GPU única) | 100 tokens/seg (distribuído) | 20 tokens/seg |
| Phi-3 3.8B em MacBook Pro M4 | 30 tokens/seg | Experimental (llama.cpp bem mais rápido) | 25 tokens/seg |
Qual motor usar em produção?
O vLLM é o padrão de produção (ao lado do SGLang nas maiores implantações). A maioria das empresas que roda APIs de LLM local em produção usa vLLM pela otimização de throughput e pelo suporte a batching. Uma única instância de vLLM atende 50+ usuários simultâneos em uma GPU, contra 1-2 do llama.cpp.
Ainda assim, a escolha depende da sua restrição:
- Atender 100+ requisições/dia com GPU limitada: use vLLM (melhor throughput).
- Atender apenas com CPU ou Apple Silicon: use llama.cpp via Ollama (melhor suporte a CPU).
- Usar modelos Llama especificamente: llama.cpp ou vLLM funcionam; o vLLM é mais rápido.
- Usar formatos diversos (GPTQ, GGUF, safetensors): o Text-Generation-WebUI suporta todos; o vLLM exige precisão total ou formatos de quantização específicos.
Quando escolher cada motor?
Use este quadro de decisão:
- llama.cpp (via Ollama): você é usuário final, não desenvolvedor, ou vai implantar em CPU/Apple Silicon. Melhor facilidade de uso geral.
- vLLM: você serve uma API com 50+ usuários simultâneos, tem GPUs NVIDIA e precisa do máximo throughput. Padrão de produção.
- Text-Generation-WebUI: você faz fine-tuning, testa adaptadores LoRA ou experimenta configurações avançadas de inferência. Melhor para pesquisa.
Erros comuns com motores de inferência
- Achar que é preciso escolher entre Ollama e esses motores. O Ollama usa llama.cpp internamente. Você não escolhe entre Ollama e vLLM; o vLLM é um *backend* alternativo, não um app de chat.
- Supor que o vLLM é mais rápido em CPU. O vLLM tem desempenho fraco em CPU; o llama.cpp é cerca de 10× mais rápido nesse cenário. Verifique sua GPU antes de optar pelo vLLM.
- Rodar o vLLM em GPU de notebook. O vLLM é otimizado para GPUs de datacenter. Em GPUs de consumo, a sobrecarga do agendador de batching pode até piorar o desempenho de requisição única. Prefira llama.cpp em notebooks.
- Confundir throughput com latência percebida. O vLLM agrupa 100 requisições, mas cada uma ainda leva tempo para gerar seus tokens. Throughput alto não significa latência baixa.
- Instalar dependências erradas do Text-Generation-WebUI. As instruções do GitHub pressupõem Git, Python 3.10+ e pip instalados. No Windows isso costuma falhar silenciosamente. Sempre confira a versão do Python antes do clone.
Perguntas frequentes
Qual motor de inferência devo usar para produção?
vLLM para produção de alta carga (50+ usuários simultâneos) — oferece PagedAttention, batching contínuo e throughput de 1.000+ tok/s. Para uso individual ou equipes pequenas, o Ollama (llama.cpp) é suficiente e muito mais simples de configurar.
O Text-Generation-WebUI ainda é relevante em 2026?
Sim, especialmente para fine-tuning com LoRA e experimentação com quantizações. Para chat simples ou API, o Ollama é mais prático. Para pesquisadores que precisam de flexibilidade total de configuração, o Text-Generation-WebUI ainda é a melhor escolha.
O vLLM funciona em Mac?
Suporte limitado. O vLLM é otimizado para CUDA (NVIDIA) e tem suporte experimental para Apple Silicon via MPS. Para Mac, use Ollama (llama.cpp com Metal) ou MLX — ambos têm suporte nativo e melhor desempenho.
Qual motor usa menos VRAM?
llama.cpp (Ollama) tem a menor sobrecarga de VRAM — carrega apenas o modelo quantizado sem buffers adicionais significativos. O vLLM usa mais memória para seus buffers de PagedAttention, mas isso se traduz em maior throughput.
Posso executar vLLM e Ollama na mesma máquina?
Sim, se a VRAM for suficiente. Execute-os em portas diferentes (vLLM padrão: 8000, Ollama padrão: 11434). Configuração típica: Ollama gerencia solicitações de chat rápidas de usuário único, vLLM gerencia solicitações de API em lotes. Ambos não podem carregar o mesmo modelo simultaneamente sem duplicar a VRAM.