O modelo é só um grafo de pesos. Quem decide se ele roda a 14 ou a 64 tokens/s no MESMO hardware é o engine de inferência — o agendador, o otimizador e os kernels que executam as contas. Esta lição mostra como escolher o engine pelo seu workload, por que a mesma GPU pode quadruplicar de velocidade só trocando o software, e por que, no fundo, você não roda um modelo: você roda kernels.
~4,4×
ganho em 2× RTX 3090 ao migrar para vLLM (TP=2)
~3,4×
ganho na RTX PRO 6000 ao migrar para SGLang
7
tipos de kernel onde o trabalho de fato acontece
⛔ 0
vezes que você deve usar Ollama
01 · Escolha o engine pelo workload
Não existe "melhor engine" no abstrato — existe o melhor engine para o seu hardware e o seu workload. O guia abaixo é uma árvore de decisão: responda à primeira pergunta que se aplica e siga o galho. Mac em primeiro lugar? MLX. Hardware estranho ou de borda? llama.cpp. Uma RTX só? ExLlamaV2. E assim por diante até produção e cluster.
A árvore é exaustiva mas raramente você desce até o fim: a primeira condição verdadeira já decide. Para um Mac (este curso), a resposta é MLX antes de qualquer outra pergunta.
Use MLX para fluxos de ML e LLM com Mac em primeiro lugar.— Ahmad Osman, "Inference Engines for LLMs (2026)"
02 · Você não roda um modelo. Você roda kernels.
É a virada mental desta lição. O "modelo" é um grafo — uma descrição de operações. Quem executa esse grafo é o engine de inferência: ele agenda (scheduler), otimiza e executa. Mas o trabalho de verdade — onde os ciclos de GPU são gastos — acontece nos kernels: as rotinas de baixo nível que computam cada operação. Kernels ruins fazem você pensar "esse modelo é lento". Kernels bons fazem você pensar "espera, como isso está rodando local?".
Por que isso importa na prática: o mesmo modelo, o mesmo hardware, dois engines diferentes = dois conjuntos de kernels diferentes = velocidades diferentes. Trocar de engine é trocar os kernels — é por isso que a próxima seção mostra ganhos de 3–4× sem trocar uma única peça física.
03 · O mesmo hardware, só trocando o software
A prova de que o engine é quem manda: pegue a GPU exatamente como está e troque só o engine. A vazão (tokens/s) dispara. Duas medições reais do guia do Ahmad — barras à escala, antes (cinza) e depois (laranja):
TP=2 = tensor-parallelism em 2 GPUs. Nenhuma placa foi adicionada — só o engine mudou. O "modelo lento" era, na verdade, kernels mal explorados.
04 · O mapa do território (e o que NÃO usar)
Agrupando os engines por alvo, fica claro que cada um nasceu para um cenário. E há um ponto não-negociável no guia do Ahmad: o Ollama, por mais agradável que seja, fica de fora.
⛔ Aviso direto — não use Ollama
O guia é categórico: "DO NOT USE Ollama. Ollama is pleasant yet should not be used." (Não use Ollama. O Ollama é agradável, mas não deve ser usado.) A conveniência cobra um preço: ele abstrai o engine e os kernels, justamente a camada que esta lição te ensina a controlar. Prefira MLX no Mac, llama.cpp na borda, ou vLLM/SGLang em produção.
Cuidado em produção, mesmo com MLX: o próprio servidor do MLX-LM "não é recomendado para produção (apenas verificações básicas de segurança)". Ótimo para desenvolvimento e uso local; para um endpoint exposto, ponha um gateway na frente ou use um engine de produção.
05 · Decode vs. prefill: qual kernel domina
Uma inferência tem duas fases, e cada uma estressa kernels diferentes. Saber qual fase domina o seu caso de uso diz qual alavanca otimizar — e até qual engine escolher.
Regra de bolso: chat/agente que gera respostas longas vive no decode → priorize banda (e, no Mac, a memória unificada rápida). Resumir/RAG com prompts gigantes vive no prefill → priorize attention e chunked prefill (forte no SGLang).
O decode acompanha a banda de memória; o prefill acompanha os kernels de attention + chunked prefill. É o mesmo princípio da Lição 03 (banda) e da Lição 06 (KV-cache) visto pela lente do engine.
06 · O guia de decisão completo
A árvore da seção 01 em forma de tabela, para consulta rápida:
Seu cenário
Engine
Por quê
Mac em 1º lugar (ML/LLM)
MLX / MLX-LM
Metal nativo + memória unificada; o caminho deste curso.
Laptop / borda / hardware estranho
llama.cpp
Roda em quase qualquer coisa, CPU/GPU mista.
Uma RTX (single-GPU)
ExLlamaV2
Alta eficiência numa placa só.
2–4+ GPUs NVIDIA
ExLlamaV3
Multi-GPU caseiro.
Produção geral
vLLM
Throughput, batching contínuo, padrão de mercado.
Contexto longo / MoE / routing
SGLang
RadixAttention, cache de prefixo, chunked prefill.
NVIDIA, desempenho máximo
TensorRT-LLM
Compilado para a GPU; NVIDIA-only.
Orquestrar um cluster
NVIDIA Dynamo
Orquestração multi-nó.
Conveniência a qualquer custo
⛔ Ollama
Não usar. Esconde o engine e os kernels.
07 · Neste curso: o engine segue o workload (ao extremo)
A doutrina "escolha o engine pelo workload" é exatamente o que esta config faz — e leva ao limite. Dois workloads, duas escolhas:
Visão (Qwen3-VL) + modelos rápidos → MLX. Mac em primeiro lugar, então a árvore decide MLX antes de qualquer outra pergunta. É o mesmo mlx_vlm.server que você viu rodando nas lições anteriores.
O cérebro (DeepSeek) → DS4. Em vez de um engine genérico, kernels Metal feitos sob medida para um modelo. É o "engine segue o workload" no extremo: quando o workload é fixo e crítico, vale um engine dedicado que extrai o máximo daqueles kernels específicos.
A ponte para a Lição 08
É por isso que a config final usa MLX para a visão e DS4 para o cérebro: dois engines, porque há dois workloads. Você não escolheu "o melhor engine" — escolheu o engine certo para cada trabalho. Guarde isso; na Lição 08 ele vira o orçamento de memória concreto do seu M5 Max.
1. No MESMO par de RTX 3090, a vazão subiu de ~14,5 para ~64 tok/s. O que mudou?
Correto: b. Mesmo hardware, engine diferente = kernels diferentes = ~4,4× mais tok/s. Na RTX PRO 6000, migrar para SGLang levou de 32 a 110 tok/s (~3,4×). O engine é quem manda.
2. Você roda num Mac e quer o caminho recomendado. E o Ollama?
Correto: c. A árvore decide MLX para Mac antes de qualquer outra pergunta. O Ollama é desaconselhado de forma categórica; o TensorRT-LLM é NVIDIA-only e não roda no Mac.