Todos se obcecam com a contagem de parâmetros. Modelo maior, respostas melhores — até que os tokens rastejem a três por segundo e o ventilador no seu GPU pareça um soprador de folhas. Metade do ganho de velocidade que as pessoas perseguem ao mudar de um modelo 7B para 70B viria de simplesmente ajustar o runtime que você já tem.
LLM inference local em 2026 é uma pilha de decisões: esquema de quantização, dtype de cache KV, tamanho de lote, cache de prompt, decodificação especulativa, estratégia de offload. Testamos oito aplicativos de desktop para otimizar LLM inference local, dos runtimes de baixo nível que expõem cada botão até ferramentas empacotadas que escolhem padrões sensatos para você. Escolha aquele que corresponde ao quão fundo você quer ir.
O que procurar em um aplicativo de otimização de LLM inference local
Nem todo runtime otimiza a mesma coisa. Antes de escolher, saiba qual destes você realmente precisa:
- Suporte à quantização. O runtime deve ler formatos GGUF, EXL2, AWQ ou MLC e permitir que você escolha a largura de bits por modelo. 4-bit é o padrão moderno; algumas cargas de trabalho funcionam bem em 3-bit.
- Controles de cache KV. Dtype de cache (fp16 vs q8_0 vs q4_0) e tamanho do cache ambos alteram o uso de VRAM substancialmente. O runtime deve permitir que você os configure.
- Reutilização de cache de prompt. Para chat e RAG, reutilizar o cache KV da mensagem anterior é a diferença entre respostas instantâneas e um prefill completo.
- Decodificação especulativa. Emparelhar um modelo de rascunho pequeno com um modelo alvo grande pode dobrar a taxa de transferência no mesmo hardware para cargas de trabalho de chat.
- Multi-GPU e offload. Offload camada por camada para CPU RAM, divisão de tensores entre GPUs e alocação ciente de NUMA importam uma vez que os modelos ficam grandes.
- Batching e manipulação de requisições concorrentes. Se você servir mais de um cliente, a taxa de transferência no tamanho de lote 8 ou 16 importa mais do que latência no lote 1.
Comparação rápida
| Aplicativo | Melhor para | Plataformas | Plano gratuito | Recurso em destaque |
|---|---|---|---|---|
| llama.cpp | Quantização profunda + controle de cache KV | Windows, macOS, Linux | Totalmente grátis, open source | Ecossistema GGUF, offload por camada |
| Ollama | Runtime sem configuração com padrões sensatos | Windows, macOS, Linux | Grátis | Troca de modelos em uma linha |
| LM Studio | GUI para ajuste sem terminal | Windows, macOS, Linux | Grátis | Configurações de runtime visuais para GGUF |
| vLLM | Serving em lote com PagedAttention | Linux, Windows via WSL | Grátis, open source | Batching contínuo para muitos clientes |
| MLC LLM | Inference compilado em GPU | Windows, macOS, Linux | Grátis, open source | Kernels compilados TVM, Metal + Vulkan |
| KoboldCpp | Ajuste de roleplay e escrita criativa | Windows, macOS, Linux | Grátis, open source | UI de ajuste de cache KV por prompt |
| ExLlamaV2 | Fast EXL2 inference em Nvidia | Windows, Linux | Grátis, open source | EXL2 quant + decodificação especulativa |
| TabbyAPI | Servidor ExLlamaV2 compatível com OpenAI | Windows, Linux | Grátis, open source | Funciona atrás de qualquer cliente OpenAI |
Os aplicativos
1. llama.cpp — Melhor para quantização profunda e controle de cache KV
llama.cpp é o runtime no qual a maioria do ecossistema é construída. Ele lê quantizações GGUF de 8 bits a 2 bits, faz offload camada por camada para CPU quando o modelo não cabe em VRAM, e expõe configurações de dtype de cache para que você possa trocar qualidade por espaço.
A superfície de ajuste é onde a velocidade mora. Definir corretamente --n-gpu-layers para sua GPU, corresponder dtype de cache com a quantização, ativar --flash-attn e usar arquivos de cache de prompt podem dobrar a taxa de transferência no mesmo hardware.
Onde falha: A CLI é densa e a lista de flags muda rapidamente. O primeiro ajuste leva uma tarde lendo documentação.
Preço:
- Grátis, open source.
Plataformas: Windows, macOS, Linux — CPU, CUDA, Metal, Vulkan, ROCm.
Download: llama.cpp no GitHub
Resumo: O runtime para usar quando a velocidade importa mais que a conveniência.
2. Ollama — Melhor para runtime sem configuração com padrões sensatos
Ollama envolve llama.cpp e escolhe padrões que levam a maioria das pessoas a uma taxa de transferência aceitável sem tocar em flags. Puxe um modelo, execute-o, pronto. O formato Modelfile permite que você defina prompts de sistema, parâmetros de amostragem e comprimento de contexto por modelo.
Para uma estação de trabalho que executa alguns modelos em rotação, este é o caminho mais rápido de “instalado” para “usável”. Ajustes avançados acontecem através de parâmetros Modelfile em vez de flags de linha de comando.
Onde falha: A abstração esconde alguns dos alavancas que extraem os últimos 30% de taxa de transferência. Usuários avançados geralmente terminam com Ollama para uso casual e llama.cpp para trabalho pesado.
Preço:
- Grátis.
Plataformas: Windows, macOS, Linux.
Download: Ollama para desktop
Resumo: A escolha padrão para alguém novo em LLMs locais que quer velocidade sem manual.
3. LM Studio — Melhor para ajuste sem terminal
LM Studio expõe os botões de otimização de llama.cpp através de uma GUI real. Seleção de quant, n_gpu_layers, comprimento de contexto, dtype de cache e tamanho de lote obtêm sliders e dropdowns em vez de flags.
Isso o torna a melhor opção para pessoas que entendem o que os botões fazem mas não querem memorizar sintaxe CLI. O chat integrado e servidor API funcionam como um banco de testes enquanto você ajusta.
Onde falha: Apenas GUI significa scripting limitado. Para servidores headless, volte para llama.cpp ou Ollama.
Preço:
- Grátis para uso pessoal e hobby.
- Pago: Planos de equipe para implantações comerciais.
Plataformas: Windows, macOS, Linux.
Download: LM Studio para desktop
Resumo: A GUI de ajuste que finalmente torna llama.cpp acessível.
4. vLLM — Melhor para serving em lote com PagedAttention
vLLM brilha quando você serve múltiplas requisições concorrentes. PagedAttention gerencia o cache KV como um alocador de memória, empacotando muitas sequências ativas no mesmo VRAM sem fragmentação. Batching contínuo significa que novas requisições se intercalam entre gerações de tokens em vez de esperar a atual terminar.
Para um home lab que executa um endpoint compatível com OpenAI para vários aplicativos ao mesmo tempo, a curva de taxa de transferência de vLLM no lote 8 esmaga runtimes de requisição única.
Onde falha: Nvidia-first, menos maduro em AMD e Metal. O trade-off é que você provavelmente quer uma GPU real para isso mesmo assim.
Preço:
- Grátis, open source.
Plataformas: Linux nativamente, Windows via WSL.
Download: vLLM no GitHub
Resumo: O runtime para qualquer um servindo mais de um cliente da mesma máquina.
5. MLC LLM — Melhor para inference compilado em GPU
MLC LLM faz uma aposta diferente: compilar os kernels do modelo com TVM para o hardware alvo exato. Isso lhe dá suporte forte para Metal, Vulkan e WebGPU, o que importa se seu desktop é um Mac Studio ou uma máquina AMD onde runtimes CUDA-first lutam.
O resultado é prefill e decode rápidos em hardware onde llama.cpp é bom mas não é rápido. A compilação adiciona um passo único por modelo por alvo.
Onde falha: O zoo de modelos é menor que GGUF, e o fluxo de trabalho é mais pesado para usuários de primeira vez.
Preço:
- Grátis, open source.
Plataformas: Windows, macOS, Linux, mais WebGPU em navegadores.
Download: MLC LLM no GitHub
Resumo: A melhor escolha se sua GPU principal não é uma placa Nvidia.
6. KoboldCpp — Melhor para ajuste de roleplay e escrita criativa
KoboldCpp é llama.cpp embaixo com uma UI destinada a escrita longa e roleplay. Essa carga de trabalho depende muito de cache KV — contexto longo, releituras repetidas da mesma história até agora — então KoboldCpp expõe controles de reutilização de cache e context-shift de forma proeminente.
As ferramentas de cenário, informações mundiais e recursos de memória o tornam uma escolha forte fora de seu público-alvo também. Qualquer um que execute prompts de contexto longo se beneficia do ajuste de cache.
Onde falha: UI funcional em vez de polida. Modo servidor está bem mas a experiência principal é o chat integrado.
Preço:
- Grátis, open source.
Plataformas: Windows, macOS, Linux.
Download: Versões de KoboldCpp no GitHub
Resumo: O front-end mais ajustado para trabalho de contexto longo.
7. ExLlamaV2 — Melhor para fast EXL2 inference em Nvidia
ExLlamaV2 é um mecanismo de inference CUDA-first que lê o formato de quantização EXL2. Na mesma GPU Nvidia, geralmente supera llama.cpp em tokens por segundo para o mesmo orçamento de qualidade de bit efetivo. Decodificação especulativa com um modelo de rascunho pequeno lhe dá outro impulso.
Para uma estação de trabalho com 3090, 4090 ou 5090 como único acelerador, aqui é onde a velocidade mora. Combine com TabbyAPI para obter um endpoint compatível com OpenAI.
Onde falha: Apenas Nvidia. Sem Metal, sem histórico ROCm.
Preço:
- Grátis, open source.
Plataformas: Windows, Linux com GPU Nvidia.
Download: ExLlamaV2 no GitHub
Resumo: O runtime para extrair a maioria dos tokens por segundo de uma GPU Nvidia.
8. TabbyAPI — Melhor para servidor ExLlamaV2 compatível com OpenAI
TabbyAPI envolve ExLlamaV2 em uma API REST compatível com OpenAI, então qualquer coisa que já fale com OpenAI — Cursor, Continue, Aider, LibreChat — pode usá-lo com uma mudança de URL base. Streaming, function calling e decodificação especulativa todos funcionam através da mesma superfície de API.
Para alguém cuja stack já assume um endpoint OpenAI, TabbyAPI é o caminho mais curto de “modelo local em disco” para “tudo fala com ele.”
Onde falha: Configuração é arquivos TOML, não uma UI. Depurar a primeira configuração requer paciência.
Preço:
- Grátis, open source.
Plataformas: Windows, Linux com GPU Nvidia.
Download: TabbyAPI no GitHub
Resumo: A ponte que permite suas ferramentas existentes usar ExLlamaV2 sem mudar mais nada.
Como escolher o correto
Escolha llama.cpp quando você quer controle máximo e está disposto a aprender os flags. Tudo nessa lista ou o usa ou é medido contra ele.
Escolha Ollama quando você quer velocidade sem arquivo de configuração. Isso lhe leva 80% do caminho em um comando.
Escolha LM Studio quando os flags de llama.cpp parecem chinês e você quer a mesma superfície de ajuste com sliders.
Escolha vLLM quando a carga de trabalho é muitas requisições concorrentes. Batching ganha em escala.
Escolha MLC LLM quando a GPU principal é Apple Silicon ou AMD. Runtimes CUDA-first têm baixo desempenho nesse hardware.
Escolha KoboldCpp quando os prompts são longos e a história importa. Manipulação de contexto é todo seu jogo.
Escolha ExLlamaV2 (com TabbyAPI) quando a máquina é Nvidia e cada milissegundo conta.
Fique na nuvem apenas se os modelos que você precisa não têm pesos locais, ou o volume de requisições é grande o suficiente para que um A100 aluguel seja mais barato que a eletricidade para executar um localmente.
FAQ
Quantização realmente torna LLMs locais mais rápido?
Sim, e muito mais do que a maioria das pessoas espera. Mudar de fp16 para Q5_K_M no mesmo modelo tipicamente corta o uso de VRAM pela metade e melhora tokens por segundo em cargas de trabalho vinculadas a GPU, com perda de qualidade pequena o suficiente para que a maioria dos usuários não consiga detectá-la em testes cegos.
O que é decodificação especulativa?
Decodificação especulativa executa um pequeno modelo “rascunho” para adivinhar vários tokens à frente, depois os verifica em um único passe de modelo grande. Quando o rascunho está certo, você obtém múltiplos tokens por chamada de modelo grande. Em cargas de trabalho de chat, pode quase dobrar a taxa de transferência.
O que é PagedAttention e por que importa para LLMs locais?
PagedAttention é a técnica de gerenciamento de cache KV de vLLM. Em vez de alocar slots de cache de tamanho fixo por requisição, trata a memória de cache como páginas que podem ser alocadas dinamicamente. Em um servidor ocupado, isso significa que muitas mais requisições concorrentes cabem no mesmo VRAM.
Qual runtime LLM local é mais rápido em Apple Silicon?
Os kernels Metal compilados de MLC LLM são geralmente a opção de usuário único mais rápida em Macs. O backend Metal de llama.cpp está perto e é mais fácil de executar — escolha MLC se o extra de 10 a 20% importa, llama.cpp caso contrário.
Posso executar um LLM local sem uma GPU discreta?
Sim. llama.cpp e Ollama executam ambos em CPU com qualquer modelo GGUF. As velocidades em laptops modernos variam de alguns tokens por segundo em modelos 7B até um rastreamento lento em 70B — usável para chat, doloroso para gerações longas.