Motores de Inferência para LLMs e Hardware de IA Local (Edição 2026)

Você não escolhe um mecanismo de inferência primeiro. Você escolhe uma estratégia de hardware, um formato de carga de trabalho e um modelo de serviço. O mecanismo vem depois.

Essa é a maneira mais útil de pensar sobre mecanismos de inferência de LLMs.

Nota da série: Esta é a Parte 3 da minha série sobre LLMs Auto-hospedados / IA Local.

• Parte 1: Matemática de Memória GPU para LLMs (Edição 2026).
• Parte 2: Largura de Banda de Memória para Hardware de IA Local (Edição 2026).

Essas duas peças explicam a capacidade de hardware e a matemática da largura de banda.

Esta explica a camada de software que transforma esse hardware em inferência utilizável.

Mecanismos

Essas ferramentas servem a propósitos diferentes / ocupam camadas diferentes

• Portabilidade local
• CUDA de consumo
• Fluxos de trabalho com memória unificada da Apple
• Inferência quantizada
• Serviço de produção
• Orquestração distribuída
• Execução otimizada para datacenter de fornecedores

Um modelo mental útil:

O mecanismo de inferência não é "o modelo". É o guarda de trânsito, gerenciador de memória, despachante de kernels, escalonador, contador de cache, planejador de paralelismo, superfície de API e, às vezes, o framework de implantação.

O melhor mecanismo corresponde à sua hierarquia de memória, interconexão, formato de quantização, metas de latência e throughput, arquitetura do modelo e maturidade operacional.

O guia de decisão de uma página

• Laptop / borda / hardware incomum → llama.cpp
• Fluxos de trabalho focados em Mac → MLX / MLX-LM
• Inferência local com RTX única → ExLlamaV2
• 2-4+ GPUs NVIDIA / CUDA → ExLlamaV3
• Serviço de produção geral → vLLM
• Contexto longo / MoE / roteamento → SGLang
• Máximo desempenho NVIDIA → TensorRT-LLM
• Orquestração de cluster → NVIDIA Dynamo

O resto deste guia explica o porquê.

O que um mecanismo de inferência realmente faz

Um mecanismo de inferência carrega pesos, tokeniza a entrada, executa a passagem direta, amostra tokens, mantém o cache KV e transmite os resultados. Mecanismos sérios também lidam com agrupamento, escalonamento, cache de prefixos, quantização, execução paralela, serviço de API, métricas e execução distribuída.

A carga de trabalho tem duas fases:

Prefill lê o prompt e constrói o cache KV inicial. É intensivo em computação.

Decode gera um token por vez, lendo repetidamente os pesos e o cache KV. É limitado pela largura de banda da memória. A velocidade do decode acompanha mais a largura de banda da memória do que o pico de computação.

Essa distinção explica quase tudo:

• Prompt curto, resposta longa: decode domina → largura de banda da memória e agrupamento importam.
• Prompt longo, resposta curta: prefill domina → kernels de atenção e prefill fragmentado importam.
• Muitos usuários: qualidade do escalonador importa → agrupamento contínuo, paginação de cache, justiça.
• Contexto longo: cache KV domina → atenção paginada, quantização KV, descarregamento.
• MoE: roteamento de especialistas domina → paralelismo de especialistas, interconexão, GEMMs agrupados.
• Multi-nó: interconexão domina → NVLink, RDMA, paralelismo de pipeline, desagregação.

PagedAttention lidou com a fragmentação do cache KV. FlashAttention usou particionamento consciente de E/S para reduzir o tráfego de HBM (High Bandwidth Memory). A decodificação especulativa rascunha tokens baratos e os verifica em paralelo. O tema recorrente: o desempenho da inferência é movimento de memória mais escalonamento.

Os verdadeiros gargalos

1. Largura de banda da memória, não apenas o tamanho da VRAM. VRAM determina o encaixe. Largura de banda determina a velocidade do decode. O M3 Ultra da Apple oferece até 819 GB/s de largura de banda de memória unificada. O H100 SXM da NVIDIA lista 3,35 TB/s de largura de banda de memória GPU. A memória unificada permite que você encaixe modelos que não caberiam na VRAM de consumo. HBM permite que você os sirva mais rápido quando o modelo cabe. Encaixe não é velocidade. Capacidade não é largura de banda.

1. Crescimento do cache KV. O cache KV cresce com o tamanho do lote e o comprimento do contexto. Cargas de trabalho de contexto longo podem ficar sem memória mesmo quando os pesos cabem. PagedAttention particiona o cache KV em blocos, aumentando a utilização e suportando lotes maiores.

1. Interconexão. No momento em que um modelo cruza os limites da GPU (multi-GPUs), você paga o custo de comunicação. O paralelismo de tensor precisa de coletivas all-reduce frequentes. O paralelismo de pipeline se comunica nos limites do estágio. O paralelismo de especialistas precisa de tráfego all-to-all para MoE. A documentação do vLLM observa que, sem NVLink, o paralelismo de pipeline pode superar o paralelismo de tensor.

1. Qualidade do escalonador. Um bom escalonador decide quais solicitações entram no lote, como prefill e decode compartilham o acelerador, se prompts longos bloqueiam decodes curtos e como evitar starvation. Suportar agrupamento não é o mesmo que se comportar como um escalonador pronto para produção.

1. Sobrecarga de tempo de execução. Gráficos CUDA, fusão de kernels, sobrecarga de amostragem, sobrecarga de tokenizador, sobrecarga HTTP, comutação LoRA e decodificação estruturada são importantes. Em alta escala, as sobrecargas irritantes de 2% formam uma união e exigem atenção.

As famílias de mecanismos

Existem quatro grandes famílias:

Tempos de execução locais portáteis: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, ferramentas estilo Ollama. Esses se preocupam em "fazer funcionar aqui".

Tempos de execução Apple/memória unificada: MLX e MLX-LM. Esses se preocupam em "usar bem a grande memória compartilhada e a pilha da Apple".

Mecanismos de quantização CUDA de consumo: ExLlamaV2 e ExLlamaV3. Esses se preocupam em "fazer minha caixa 3090/4090/5090 gritar com pesos de baixo bit".

Mecanismos de serviço de produção: vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. Esses se preocupam com usuários simultâneos, cache KV, agrupamento, paralelismo, observabilidade e custo por token.

Depois, há camadas de orquestração como o Dynamo que ficam acima dos mecanismos e coordenam frotas, prefill/decode desagregado, roteamento e escalonamento automático.

llama.cpp: o rei da portabilidade

llama.cpp é a resposta quando o hardware é estranho, limitado, offline, pesado em CPU, voltado para a borda ou não é um nó de datacenter NVIDIA organizado.

Ele suporta Apple Silicon via ARM NEON, Accelerate e Metal; x86 via AVX/AVX2/AVX512/AMX; RISC-V; quantização de baixo bit; CUDA; AMD via HIP; MUSA; Vulkan; SYCL; e descarregamento híbrido CPU+GPU. É por isso que o llama.cpp domina a faixa "apenas faça funcionar".

O servidor HTTP é mais capaz do que um "executor local de brinquedo". O llama-server fornece rotas compatíveis com OpenAI, compatibilidade com a API Anthropic Messages, reclassificação, agrupamento contínuo, suporte multimodal, restrições de esquema JSON, chamada de função, decodificação especulativa e uma interface web.

A limitação crítica: o llama.cpp não é para serviço de produção multi-nó sério. Seu backend RPC é explicitamente documentado como prova de conceito, frágil e inseguro.

Veredito: Use llama.cpp quando portabilidade, operação offline, GGUF ou descarregamento híbrido importarem mais do que serviço em escala de frota.

NÃO use com Multi-GPUs

MLX e MLX-LM: a arma do Apple Silicon

MLX é o framework de array da Apple para Apple Silicon, e MLX-LM é o pacote LLM construído sobre ele. É uma pilha de ML focada em Mac.

O fato chave de hardware é a memória unificada. O Apple Silicon dá à CPU e à GPU acesso direto ao mesmo pool de memória. Os arrays MLX residem na memória unificada, e você escolhe o dispositivo ao executar a operação, em vez de mover arrays entre espaços de memória separados.

Isso muda a compensação da inferência local. Em um sistema GPU discreto, a pergunta é "cabe na VRAM?" Em um Mac com chip M e grande memória unificada, a pergunta se torna "cabe na memória, e o sistema de memória consegue alimentar a GPU rápido o suficiente?" Modelos grandes quantizados podem caber em máquinas onde o mesmo modelo seria impossível em uma GPU de consumo de 24 GB.

No entanto, também é mais lento.

MLX-LM adiciona integração com Hugging Face Hub, quantização, ajuste fino LoRA e completo, inferência distribuída e um grande ecossistema de modelos da Comunidade MLX. MLX não é mais exclusivo para Mac: oferece pacotes CUDA e apenas CPU para Linux. A comunicação distribuída suporta MPI, Ring over TCP, JACCL para RDMA over Thunderbolt e NCCL para CUDA.

O próprio servidor MLX-LM avisa que não é recomendado para produção porque implementa apenas verificações básicas de segurança.

Veredito: Use MLX para fluxos de trabalho de ML e LLM focados em Mac. Para serviço público de alta concorrência, comece com uma pilha de serviço real.

ExLlamaV2 e V3: CUDA de consumo, sintonizado e rápido

ExLlamaV2 é o mecanismo de quantização CUDA local para pessoas que querem que uma GPU NVIDIA de consumo supere seu peso. Ele suporta atenção paginada, agrupamento dinâmico, cache de prompt, desduplicação de cache KV, geração em lote, streaming e decodificação especulativa. A palavra a lembrar é local. Ele torna modelos quantizados rápidos em GPUs CUDA modernas, especialmente placas de consumo.

Melhores ajustes: uma caixa RTX 3090/4090/5090, assistente de codificação local, chat local, modelos quantizados EXL2 e uso em estação de trabalho prosumer.

ExLlamaV3 estende a filosofia para inferência multi-GPU e MoE local. Ele adiciona o formato de quantização EXL3 baseado em QTIP, paralelismo de tensor e paralelismo de especialistas flexíveis para hardware de consumo, um servidor compatível com OpenAI via TabbyAPI, agrupamento dinâmico contínuo e suporte multimodal.

O V3 é atraente quando você tem 2-4+ GPUs NVIDIA de consumo ou quer MoE local. Espere ressalvas: alguns modelos não suportam paralelismo de tensor ou de especialistas no ExLlamaV3.

Veredito: ExLlamaV2 é o mecanismo CUDA local do entusiasta. ExLlamaV3 é a fronteira para configurações locais multi-GPU (2-4). Espere arestas mais ásperas para melhor capacidade.

vLLM: o servidor de produção open-source padrão

vLLM é o primeiro mecanismo que a maioria das equipes deve avaliar para serviço sério de LLM open-source.

Ele oferece gerenciamento de memória KV baseado em PagedAttention, agrupamento contínuo, prefill fragmentado, cache de prefixo, gráficos CUDA/HIP, quantização extensiva (FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ, AWQ, GGUF), kernels otimizados de atenção e GEMM/MoE, decodificação especulativa, torch.compile e prefill/decode/encode desagregado.

Também é flexível: paralelismo de tensor/pipeline/dados/especialistas/contexto, streaming, saídas estruturadas, chamada de ferramentas, APIs compatíveis com OpenAI e Anthropic Messages, gRPC, multi-LoRA e suporte para NVIDIA, AMD, CPUs x86/ARM/PowerPC, além de plugins para TPUs, Gaudi, Ascend, Apple Silicon e muito mais.

A documentação do vLLM observa que implantações multi-nó normalmente usam Ray, e sem NVLink, o paralelismo de pipeline pode ser melhor que o paralelismo de tensor. A armadilha é assumir que o vLLM elimina a necessidade de pensamento sistêmico. Você ainda precisa ajustar agrupamento, comprimento de contexto, utilização de memória GPU, layout de paralelismo e roteamento. O vLLM fornece um mecanismo muito bom; ainda requer um bom Design de Sistema.

Veredito: Se alguém disser "precisamos servir modelos abertos em produção", o vLLM é o ponto de partida padrão.

SGLang: o primo com cérebro de sistemas do vLLM

SGLang é o que você usa quando a carga de trabalho de serviço é feia: saídas estruturadas, contexto longo, MoE, desagregação e roteamento.

Ele oferece cache de prefixo RadixAttention, desagregação prefill-decode, decodificação especulativa, agrupamento contínuo, atenção paginada, paralelismo de tensor/pipeline/especialistas/dados, saídas estruturadas, prefill fragmentado e agrupamento multi-LoRA. Ele suporta NVIDIA, AMD, Intel Xeon, Google TPUs, Ascend NPUs e muito mais.

O diferencial do SGLang é a arquitetura de serviço. Sua desagregação prefill-decode separa o prefill intensivo em computação do decode intensivo em memória em instâncias especializadas, transferindo o cache KV entre elas. Isso evita que lotes longos de prefill interrompam o decode e aumentem a latência do token.

Veredito: SGLang é para equipes cujo gargalo não é mais "podemos executar o modelo?" mas "podemos executá-lo sob tráfego hostil sem queimar latência, memória e custo?"

TensorRT-LLM: desempenho máximo NVIDIA

TensorRT-LLM é a pilha de máximo desempenho NVIDIA. É otimizado, especializado, poderoso e não finge ser portátil.

Ele fornece APIs Python para construir mecanismos TensorRT com otimizações de ponta, além de tempos de execução Python e C++. Inclui kernels personalizados para atenção, GEMMs e MoE; desagregação prefill-decode, Wide Expert Paralelismo, decodificação especulativa; e uma API Python de alto nível integrada com NVIDIA Dynamo e Triton Inference Server.

GPUs B200 podem carregar pesos FP4 com kernels otimizados. H100 e posteriores suportam quantização FP8 que pode dobrar o desempenho e reduzir o consumo de memória pela metade em comparação com 16 bits com perda mínima de precisão.

Onde ele brilha: frotas classe H100/H200/B200/GB200/GB300, datacenters somente NVIDIA, implantação FP8/FP4, serviço multi-nó e MoE em escala. Onde é estranho: portabilidade AMD, Apple ou Intel; modelos experimentais que mudam rapidamente; pequenas configurações locais; e equipes que precisam de "funciona em tudo".

Veredito: Se você está comprometido com a NVIDIA e se preocupa com desempenho absoluto, o TensorRT-LLM merece estar na avaliação. Você troca portabilidade por desempenho. Especialização sintonizada, mas menos recursos.

O resto do campo

TGI é o servidor de produção do Hugging Face com rastreamento, métricas, paralelismo de tensor e agrupamento contínuo. Use-o quando a integração com HF e a simplicidade importarem.

MLC LLM é o mecanismo de implantação universal com prioridade de compilador e APIs compatíveis com OpenAI em REST, Python, JavaScript, iOS e Android. Melhor para "enviar LLMs para qualquer lugar", especialmente navegador, celular e aplicativos nativos.

ONNX Runtime GenAI implementa o loop generativo completo sobre ONNX Runtime e alimenta Foundry Local, Windows ML e o VS Code AI Toolkit. Ele suporta CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU e GPU AMD. Melhor para implantação de aplicativos e fluxos de trabalho ONNX.

OpenVINO GenAI é a história otimizada para Intel em CPUs Xeon, GPUs Arc, Core Ultra e NPUs. Ele oferece serviço compatível com OpenAI com agrupamento contínuo e atenção paginada. Melhor para hardware Intel.

LMDeploy é um kit de ferramentas focado em CUDA com TurboMind para desempenho e PyTorch para acessibilidade. Mais interessante para usuários CUDA que querem uma alternativa ao vLLM/SGLang/TensorRT-LLM.

NVIDIA Dynamo é uma camada de orquestração distribuída acima de mecanismos como vLLM, SGLang e TensorRT-LLM, suportando desagregação, roteamento inteligente e cache KV em múltiplos níveis. Use-o quando o serviço de mecanismo único não for mais suficiente.

Nota: NÃO USE Ollama.

Receitas de estratégia de hardware

Servidor apenas CPU: llama.cpp primeiro. OpenVINO para Intel Xeon. ONNX Runtime GenAI para implantação de aplicativo/ONNX.

MacBook / Mac Studio: MLX / MLX-LM para fluxos de trabalho nativos do Mac. llama.cpp para portabilidade GGUF.

RTX 3090 / 4090 / 5090 única: ExLlamaV2 para inferência local EXL2. llama.cpp para GGUF ou portabilidade. vLLM se estiver servindo vários usuários.

Caixa RTX de consumo dupla ou quádrupla: ExLlamaV3 para inferência quantizada multi-GPU ou MoE. vLLM se o comportamento de serviço for importante. SGLang se estiver testando roteamento ou padrões de contexto longo.

Nó 8×H100 / H200: Comece com vLLM ou SGLang. Avalie o TensorRT-LLM se for apenas NVIDIA e o desempenho justificar o ajuste. Use Dynamo quando a orquestração multi-nó se tornar necessária.

Infraestrutura classe B200 / GB200 / GB300: Avalie o TensorRT-LLM, SGLang e vLLM. Adicione Dynamo para orquestração em nível de frota, roteamento consciente de KV e escalonamento automático.

AMD MI300 / MI325 / MI350 / MI355: Comece com vLLM ou SGLang em ROCm. Evite assumir que as avaliações da NVIDIA se transferem perfeitamente.

Intel Xeon / Core Ultra / Arc: OpenVINO GenAI ou OpenVINO Model Server. ONNX Runtime GenAI se a incorporação do aplicativo for importante.

Navegador, celular, aplicativo nativo: MLC LLM / WebLLM ou ONNX Runtime GenAI.

Avaliação comparativa: o que medir

Má avaliação: "Eu consegui 180 tok/s."

A boa avaliação inclui:

Modelo: modelo exato, arquitetura, número de parâmetros, parâmetros ativos do MoE.

Pesos: dtype, formato de quantização, tamanho do grupo, calibração.

Mecanismo: versão, commit, backend, sinalizadores.

Hardware: SKU da GPU, capacidade de memória, largura de banda, interconexão, CPU, RAM.

Carga de trabalho: distribuições de comprimento de entrada/saída, concorrência, streaming, prefixos compartilhados, saída estruturada.

Métricas: TTFT, TPOT, latência ponta a ponta, p50/p95/p99, tokens por segundo, solicitações por segundo, uso de memória GPU, taxa de acerto do cache KV, throughput de prefill, throughput de decode, custo por 1M tokens.

Regras de avaliação:

1. Nunca compare mecanismos usando apenas tokens por segundo de usuário único.
2. Teste sua distribuição real de prompt e saída.
3. Teste com concorrência realista.
4. Separe prefill de decode.
5. Acompanhe p95 e p99, não apenas médias.
6. Meça a margem de memória no comprimento de contexto alvo.
7. Teste o reuso de cache se seu aplicativo tiver prefixos repetidos.
8. Avalie a saída estruturada separadamente; a gramática adiciona sobrecarga.
9. Avalie LoRA e multi-LoRA separadamente.
10. Reteste após atualizações de driver, CUDA, ROCm, modelo ou mecanismo.

Erros comuns

Escolher apenas pela capacidade de VRAM. VRAM determina o encaixe. Largura de banda e escalonador determinam a velocidade. Uma máquina de memória unificada grande pode caber modelos enormes, mas um H100 decodifica mais rápido quando o modelo cabe devido à largura de banda HBM muito maior.

Usar paralelismo de tensor em interconexão fraca. Sem NVLink ou NVSwitch, teste o paralelismo de pipeline. A documentação do vLLM destaca isso para configurações tipo L40S.

Ignorar o cache KV. Contexto longo e concorrência podem tornar o cache KV o fator limitante. PagedAttention, cache de prefixo, quantização KV e desagregação não são opcionais em escala.

Tratar mecanismos locais como servidores de produção. O servidor llama.cpp é capaz. O servidor MLX-LM é conveniente. Ollama é agradável, mas NÃO DEVE SER USADO.

No entanto, produção significa segurança, observabilidade, contrapressão, roteamento, escalonamento automático e comportamento de SLA. O próprio MLX-LM avisa que seu servidor não é recomendado para produção.

Assumir que todo formato de quantização é portátil. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, formatos MLX e ONNX não são intercambiáveis. O formato certo é aquele para o qual seu mecanismo tem kernels otimizados.

Ignorar a arquitetura do modelo. Modelos densos, MoE, atenção híbrida, modelos multimodais e variantes de contexto longo estressam diferentes partes do mecanismo. Suporte amplo não significa que toda otimização funciona igualmente.

Confiar em gráficos de avaliação sem formato de carga de trabalho. Um gráfico para Llama 3.1 8B com 1K de entrada / 128 de saída diz pouco sobre um agente de codificação com contexto de 80K rodando Qwen 3.6 27B / Gemma 4 26B-A4B, ou um serviço RAG com 500 usuários simultâneos.

O mapa final opinativo

Usuário de IA local: LM Studio ou Harbor para conveniência. llama.cpp para controle. MLX no Mac. ExLlamaV2/V3 para desempenho CUDA local.

Construindo um agente local: Qualquer um deve funcionar, mas dado o que a maioria usa; llama.cpp para portabilidade. MLX se os usuários estiverem no Apple Silicon. vLLM se estiver simulando serviço de produção localmente.

Servindo uma equipe interna: Comece com vLLM. Use SGLang se saídas estruturadas, contexto longo, multi-LoRA, MoE ou roteamento forem importantes.

Servindo clientes em escala: Avalie vLLM, SGLang e TensorRT-LLM. Se roteamento e desagregação forem importantes, SGLang e Dynamo merecem atenção.

Datacenter NVIDIA: TensorRT-LLM para desempenho máximo. vLLM para flexibilidade. SGLang para serviço complexo. Dynamo para orquestração de frota.

Apple Silicon: MLX para desenvolvimento nativo. llama.cpp para GGUF. Memória unificada é um superpoder de capacidade com compensações de largura de banda, não HBM.

Borda, aplicativo, navegador ou Windows nativo: llama.cpp, MLC LLM, ONNX Runtime GenAI ou OpenVINO, dependendo da pilha.

Princípio final

Mecanismos de inferência têm consequências.

Escolha o mecanismo depois de responder a estas perguntas:

1. Que hardware eu realmente tenho?
2. O modelo cabe na memória rápida, ou apenas na memória do sistema/unificada?
3. O decode ou o prefill é o gargalo?
4. Que comprimento de contexto e concorrência são importantes?
5. Os prompts são compartilhados o suficiente para cache de prefixo?
6. O modelo é denso, MoE, multimodal ou híbrido?
7. Preciso de conveniência local, serviço de produção ou orquestração de frota?
8. Que formato de quantização tem kernels otimizados no meu mecanismo alvo?
9. Minha interconexão é PCIe, NVLink, NVSwitch, Ethernet, RDMA ou Thunderbolt?
10. Estou otimizando latência, throughput, custo, privacidade, portabilidade ou velocidade do desenvolvedor?

O mecanismo segue as respostas.

Até a próxima vez.

-Ahmad