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 LLM.

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 matemática da capacidade e largura de banda do hardware.

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 para consumidor
• Fluxos de trabalho com memória unificada da Apple
• Inferência quantizada
• Serviço de produção
• Orquestração distribuída
• Execução em datacenter otimizada pelo fornecedor

Um modelo mental útil:

O mecanismo de inferência não é "o modelo". Ele é o guarda de trânsito, o gerenciador de memória, o despachante de kernels, o escalonador, o contador de cache, o planejador de paralelismo, a 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 taxa de transferência, arquitetura do modelo e maturidade operacional.

O guia de decisão em uma página

• Laptop / dispositivo de borda / hardware incomum → llama.cpp
• Fluxos de trabalho focados em Mac → MLX / MLX-LM
• Inferência local com uma única RTX → ExLlamaV2
• 2-4+ GPUs NVIDIA / CUDA → ExLlamaV3
• Serviço de produção geral → vLLM
• Contexto longo / MoE / roteamento → SGLang
• Desempenho máximo 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 batelamento, escalonamento, cache de prefixo, quantização, execução paralela, serviço de API, métricas e execução distribuída.

A carga de trabalho tem duas fases:

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

A decodificação gera um token por vez, lendo repetidamente os pesos e o cache KV. É limitada pela largura de banda da memória. A velocidade de decodificação 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: a decodificação domina → largura de banda de memória e batelamento importam.
• Prompt longo, resposta curta: o preenchimento domina → kernels de atenção e preenchimento fragmentado importam.
• Muitos usuários: a qualidade do escalonador importa → batelamento contínuo, paginação de cache, justiça.
• Contexto longo: o cache KV domina → atenção paginada, quantização KV, descarregamento.
• MoE: o roteamento de especialistas domina → paralelismo de especialistas, interconexão, GEMMs agrupados.
• Multinó: a interconexão domina → NVLink, RDMA, paralelismo de pipeline, desagregação.

O PagedAttention lidou com a fragmentação do cache KV. O FlashAttention usou blocos conscientes de E/S para reduzir o tráfego de HBM (Memória de Alta Largura de Banda). 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 gargalos reais

1. Largura de banda da memória, não apenas o tamanho da VRAM. A VRAM determina o encaixe. A largura de banda determina a velocidade de decodificação. 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 consumidor. A 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. O 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 (várias GPUs), você paga o custo de comunicação. O paralelismo de tensor precisa de coletivos 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 o preenchimento e a decodificação compartilham o acelerador, se prompts longos bloqueiam decodificações curtas e como evitar inanição. Suportar batelamento não é o mesmo que se comportar como um escalonador pronto para produção.

1. Sobrecarga em tempo de execução. Gráficos CUDA, fusão de kernels, sobrecarga de amostragem, sobrecarga de tokenizador, sobrecarga HTTP, alternância de LoRA e decodificação estruturada são importantes. Em grande 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. Eles se preocupam com "fazer funcionar aqui".

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

Mecanismos de quantização CUDA para consumidor: ExLlamaV2 e ExLlamaV3. Eles se preocupam em "fazer meu sistema com 3090/4090/5090 gritar com pesos de baixo比特".

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

Depois, existem camadas de orquestração como Dynamo que ficam acima dos mecanismos e coordenam frotas, preenchimento/decodificação desagregados, 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 arrumado.

Ele suporta Apple Silicon via ARM NEON, Accelerate e Metal; x86 via AVX/AVX2/AVX512/AMX; RISC-V; quantização de baixo比特; CUDA; AMD via HIP; MUSA; Vulkan; SYCL; e descarregamento híbrido CPU+GPU. É por isso que llama.cpp domina o campo do "só fazer 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, reranqueamento, batelamento 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 multinó 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 forem mais importantes do que serviço em escala de frota.

NÃO use com Múltiplas 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 do hardware é a memória unificada. O Apple Silicon dá à CPU e à GPU acesso direto ao mesmo pool de memória. Os arrays MLX vivem 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 troca da inferência local. Em um sistema GPU discreto, a pergunta é "cabe na VRAM?" Em um Mac da série M com 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 quantizados grandes podem caber em máquinas onde o mesmo modelo seria impossível em uma GPU de consumidor de 24 GB.

No entanto, também é mais lento.

MLX-LM adiciona integração com o 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 para consumidor, ajustado e rápido

ExLlamaV2 é o mecanismo de quantização CUDA local para pessoas que querem que uma GPU NVIDIA de consumidor tenha um desempenho acima do seu peso. Ele suporta atenção paginada, batelamento dinâmico, cache de prompt, deduplicaçã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 consumidor.

Melhores usos: sistema com uma 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 local MoE. Ele adiciona o formato de quantização EXL3 baseado em QTIP, inferência flexível de paralelismo de tensor e paralelismo de especialistas para hardware de consumidor, um servidor compatível com OpenAI via TabbyAPI, batelamento dinâmico contínuo e suporte multimodal.

O V3 é atraente quando você tem 2-4+ GPUs NVIDIA de consumidor 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 uma capacidade melhor.

vLLM: o servidor de produção de código aberto padrão

vLLM é o primeiro mecanismo que a maioria das equipes deve avaliar para serviço sério de LLM de código aberto.

Ele oferece gerenciamento de memória KV baseado em PagedAttention, batelamento contínuo, preenchimento 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 preenchimento/decodificação/codificação desagregados.

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 multinó normalmente usam Ray e, sem NVLink, o paralelismo de pipeline pode superar o paralelismo de tensor. A armadilha é presumir que o vLLM elimina a necessidade de pensamento sistêmico. Você ainda precisa ajustar batelamento, 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 mentalidade de sistemas do vLLM

SGLang é o que você procura 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 preenchimento-decodificação, decodificação especulativa, batelamento contínuo, atenção paginada, paralelismo de tensor/pipeline/especialistas/dados, saídas estruturadas, preenchimento fragmentado e batelamento 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 preenchimento-decodificação separa o preenchimento intensivo em computação da decodificação intensiva em memória em instâncias especializadas, transferindo o cache KV entre elas. Isso evita que lotes de preenchimento longos interrompam a decodificação e aumentem a latência do token.

Veredito: SGLang é para equipes cujo gargalo não é mais "conseguimos executar o modelo?" mas "conseguimos 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 desempenho máximo da 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 preenchimento-decodificação, Paralelismo Amplo de Especialistas, 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 multinó e MoE em escala. Onde é estranho: portabilidade AMD, Apple ou Intel; modelos experimentais que mudam rapidamente; configurações locais pequenas; e equipes que precisam de "funciona em tudo".

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

O resto do campo

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

MLC LLM é o mecanismo de implantação universal focado em compilador com APIs compatíveis com OpenAI em REST, Python, JavaScript, iOS e Android. Melhor para "enviar LLMs para todos os lugares", especialmente navegador, dispositivos móveis e aplicativos nativos.

ONNX Runtime GenAI implementa o loop generativo completo sobre o ONNX Runtime e alimenta o Foundry Local, Windows ML e o AI Toolkit do VS Code. 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 pela Intel para CPUs Xeon, GPUs Arc, Core Ultra e NPUs. Oferece serviço compatível com OpenAI com batelamento 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 vários 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 com 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.

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

Sistema com duas ou quatro RTX de consumidor: 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 somente NVIDIA e o desempenho justificar o ajuste. Use o Dynamo quando a orquestração multinó se tornar necessária.

Infraestrutura classe B200 / GB200 / GB300: Avalie o TensorRT-LLM, SGLang e vLLM. Adicione o 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 no ROCm. Evite presumir que os benchmarks 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, dispositivo móvel, aplicativo nativo: MLC LLM / WebLLM ou ONNX Runtime GenAI.

Benchmarking: o que medir

Benchmark ruim: "Consegui 180 tok/s."

Benchmark bom inclui:

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

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

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

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 de ponta a ponta, p50/p95/p99, tokens por segundo, solicitações por segundo, uso de memória GPU, taxa de acerto do cache KV, taxa de transferência de preenchimento, taxa de transferência de decodificação, custo por 1M de tokens.

Regras de Benchmarking:

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 o preenchimento da decodificação.
5. Acompanhe p95 e p99, não apenas as 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. A VRAM determina o encaixe. A largura de banda e o escalonador determinam a velocidade. Uma máquina com grande memória unificada 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 como 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.

Presumir 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 tabelas de benchmark sem o formato da carga de trabalho. Uma tabela 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 em 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 local CUDA.

Construindo um agente local: Qualquer um deve funcionar, mas dado o que a maioria das pessoas 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. A memória unificada é um superpoder de capacidade com compensações de largura de banda, não HBM.

Borda, aplicativo, navegador ou nativo Windows: 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. A decodificação ou o preenchimento é o gargalo?
4. Que comprimento de contexto e concorrência são importantes?
5. Os prompts são compartilhados o suficiente para o 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, taxa de transferência, custo, privacidade, portabilidade ou velocidade do desenvolvedor?

O mecanismo segue as respostas.

Até a próxima.

-Ahmad