O modelo é só um grafo de pesos parado no disco. 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 te dá a ordem mental certa (hardware → workload → serviço → engine por último), mostra por que a mesma GPU pode quadruplicar de velocidade só trocando o software, e por que o caminho mais "fácil" — o Ollama — é justamente o que você não deve pegar.
Esta lição destila o guia do Ahmad (a árvore de decisão de engines, o "you run kernels", os ganhos de vazão medidos e o aviso categórico sobre o Ollama) + o MODEL_CARD do DS4 do antirez (o engine C/Metal feito do zero para um modelo). Por que importa pra missão: no Mac, o engine certo é o que faz o cérebro local do Alembic responder rápido — ou travar.
Objetivos desta lição
Decidir o engine na ordem certa: hardware → workload → serviço → engine por último.
Ler o loop de inferência (prompt → tokenize → prefill → decode → detokenize) e separar scheduler de kernel.
Comparar MLX, llama.cpp, vLLM, SGLang, Ollama e DS4 num quadro único — e ler a coluna "no Mac".
Explicar por que migrar de engine entrega 3–4× sem trocar uma única peça de hardware.
0×10⁻¹
≈4,4× mais tok/s só trocando p/ vLLM (2× RTX 3090, TP=2)
~0×10⁻¹
≈3,4× na RTX PRO 6000 ao migrar p/ SGLang
0
tipos de kernel onde o trabalho de fato acontece
⛔ 0
vezes que você deve usar Ollama
⟳ adivinhe antes de revelar
Você troca só o engine de inferência num par de RTX 3090 (a placa, a RAM e o modelo continuam idênticos). Quantas vezes a vazão sobe? Pense num número antes de clicar.
≈ 4,4× — de ~14,5 para ~64 tok/s, migrando para vLLM com tensor-parallel 2. A resposta surpreende justamente porque a maior parte das pessoas chuta < 2×. Não é GPU nova; é kernels novos. Esse é o número que a lição inteira existe para te ensinar a colher. Fonte: Ahmad Osman, "Inference Engines for LLMs (2026)".
01 · A ordem certa: o engine vem por ÚLTIMO
O erro de iniciante é começar pelo engine: "qual é o melhor — vLLM? llama.cpp?". Errado. Não existe "melhor engine" no abstrato — existe o melhor engine para o seu hardware e o seu workload. A decisão correta desce numa ordem fixa, e o engine é a última peça a cair: o hardware que você tem restringe os engines possíveis; o workload (chat? RAG? agente?) restringe ainda mais; o tipo de serviço (local single-user vs. produção multi-usuário) afina; só então o engine certo já está praticamente escolhido.
Clique em cada etapa abaixo — de cima para baixo — e veja como as opções vão estreitando até sobrar o motor:
DO HARDWARE AO MOTOR · o engine é a ÚLTIMA decisão (clique cada degrau)
Repare: quando você chega na etapa 4, quase não há o que decidir — o hardware + workload + serviço já apontaram o engine. Para este curso (Mac, em 1º lugar), a árvore decide MLX antes mesmo da pergunta 2.
Use MLX para fluxos de ML e LLM com Mac em primeiro lugar.— Ahmad Osman, "Inference Engines for LLMs (2026)"
A regra em uma frase
Hardware você compra; workload você define; serviço você expõe; engine você escolhe por último — e, na maioria das vezes, ele já se escolheu sozinho. Começar pelo engine é como escolher o pneu antes de saber se o carro é de rua ou de Fórmula 1.
02 · Você não roda um modelo. Você roda kernels.
É a virada mental desta lição, e ela explica por que o engine importa tanto. O "modelo" é um grafo — uma descrição declarativa de operações (pesos + topologia). Quem executa esse grafo é o engine: ele agenda (scheduler), otimiza (funde operações, gerencia memória) 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?".
A PILHA DE EXECUÇÃO · o trabalho real está na camada de kernels
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. É exatamente por isso que dá para ganhar 3–4× sem trocar uma única peça física — a prova vem na próxima seção.
A prova: o mesmo hardware, só trocando o software
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 (colorido):
TROCOU O ENGINE, MESMO HARDWARE · tokens/s (escala real)
TP=2 = tensor-parallelism em 2 GPUs. Nenhuma placa foi adicionada — só o engine mudou. O "modelo lento" era, na verdade, kernels mal explorados.
02b · O loop de inferência — do prompt ao token
Você já sabe onde o trabalho mora (kernels) e quem o agenda (engine). Falta ver o que o engine realmente executa a cada vez que você manda um prompt. É sempre o mesmo loop, idêntico em MLX, llama.cpp ou vLLM — o que muda entre eles é só quão rápido cada caixa roda. Entender este loop é entender por que existem duas "velocidades" diferentes num LLM (a primeira palavra demora; o resto jorra) e onde cada engine ganha ou perde.
Analogia simples primeiro: pense num tradutor simultâneo. Ele ouve a frase inteira de uma vez (entende o contexto — isso é o prefill) e só então começa a falar uma palavra de cada vez, cada palavra dependendo da anterior (isso é o decode). Ler tudo de uma vez é rápido e paralelo; falar palavra a palavra é sequencial e mais lento. Um LLM faz exatamente isso.
Siga o fluxograma de cima a baixo. Repare no losango de decisão e na seta que volta: o decode é um laço — um token por volta, realimentando o anterior — até sair o token de parada (EOS):
O LOOP DE INFERÊNCIA · prompt → tokenize → prefill → [decode ↻] → detokenize
A leitura que muda tudo: são dois regimes distintos. O prefill é uma passada só — lê o prompt inteiro em paralelo, satura a compute da GPU (FLOPs) e produz a primeira palavra. O decode é um laço — para cada token novo ele relê todos os pesos da RAM, então satura a banda de memória (assunto da Lição 03). Por isso a primeira palavra "pensa" e o resto "jorra": é o losango voltando, token após token. Cada engine otimiza esses dois regimes de formas diferentes — é aí que nasce o 4,4× da seção 02.
Onde o tempo vai — conte você mesmo
Vamos quantificar. Suponha uma resposta de 1 prompt longo + 200 tokens gerados. O prefill processa o prompt todo numa passada; o decode roda 200 vezes. Acompanhe a conta (números ilustrativos para enxergar o formato — não uma medição):
Worked example · por que a 1ª palavra demora e o resto voa
1
Prefill do prompt (digamos 2.000 tokens) numa passada paralela ≈ 0,25 s. Esse é o seu time-to-first-token (TTFT): o tempo até a primeira palavra aparecer.
2
Decode: cada token novo relê os pesos da RAM. A ~50 tok/s, isso é 1 ÷ 50 = 0,02 s por token. Esse é o seu inter-token latency.
3
Para 200 tokens: 200 × 0,02 s = 4,0 s de decode. Some o prefill: 0,25 + 4,0 ≈ 4,25 s no total.
4
A lição: o decode domina o relógio (4,0 de 4,25 s). Acelerar o engine = acelerar o decode, e decode é gargalo de banda de memória, não de compute. Agora você: se a banda dobrar e o decode for a 100 tok/s, quanto cai o total? (200 × 0,01 = 2,0 s de decode → ≈ 2,25 s — quase metade.)
Prefill × decode, lado a lado
As duas fases puxam recursos opostos. Ver isso explica de uma vez por que "tokens/s" tem dois números e por que cada engine se vende por um deles:
PREFILL × DECODE · dois regimes, dois gargalos (mesmo modelo)
Por que isto pertence à lição de engines
Cada engine é, no fundo, um conjunto de truques para esses dois regimes: o vLLM ataca o decode multi-usuário com continuous batching + PagedAttention; o SGLang ataca o prefill repetido com cache de prefixo (RadixAttention); o MLX ataca os dois com kernels Metal sobre memória unificada. "Trocar de engine" = trocar a tática de prefill/decode. É literalmente a engenharia por trás do 4,4×.
03 · Os engines, lado a lado
Agora os candidatos, um por um. Clique em cada aba: o que ele faz bem, sobre qual backend roda, quando escolher — e o que isso significa num Mac. Note o padrão: para Apple Silicon, só uma aba acende de verdade.
MLX / MLX-LM — o framework de ML da Apple para Apple Silicon.
• Forças: Metal nativo, memória unificada (CPU+GPU compartilham a mesma RAM, sem cópia), o caminho de menor atrito num Mac.
• Backend: Metal.
• Quando usar: qualquer fluxo "Mac em 1º lugar". A árvore da seção 01 escolhe MLX antes de qualquer outra pergunta.
• Num Mac: ★ é a escolha. É o mesmo mlx_vlm.server que você viu rodando nas lições de visão. Ressalva: o servidor do MLX-LM "não é recomendado para produção" — ótimo para local/dev, ponha um gateway na frente se for expor.
llama.cpp — o canivete suíço portátil da inferência local.
• Forças: roda em quase qualquer coisa (CPU, GPU, mista), formato GGUF, ecossistema gigante, ótimo para borda e hardware estranho.
• Backend: multi — CPU, Metal, CUDA, Vulkan…
• Quando usar: laptop/borda, hardware exótico, ou quando você quer um binário único sem dependências pesadas.
• Num Mac: funciona (tem backend Metal) e é excelente para experimentar GGUFs — mas para puro desempenho de LLM no Apple Silicon, o MLX costura mais fino. llama.cpp brilha quando a portabilidade é o objetivo.
vLLM — o padrão de mercado para servir em produção.
• Forças: throughput altíssimo, continuous batching, PagedAttention; foi o engine que levou 2× RTX 3090 de 14,5 a 64 tok/s (seção 02).
• Backend: CUDA (foco NVIDIA; suporte a outros aceleradores evolui).
• Quando usar: endpoint multi-usuário, muitas requisições concorrentes, produção geral.
• Num Mac: não é o caminho — é pensado para GPUs de datacenter NVIDIA. No M5 Max, a resposta é MLX.
Ollama — agradável… e desaconselhado.
• Forças: UX deliciosa — ollama run e pronto; é por isso que tanta gente começa por ele.
• Backend: embrulha o llama.cpp por baixo, mas esconde o engine e os kernels de você.
• Quando usar:segundo o guia, nunca para um setup sério — veja a seção 05. A conveniência cobra o preço de te tirar o controle da exata camada que esta lição ensina.
• Num Mac: prefira o MLX direto. Você quer ver e ajustar os kernels, não escondê-los atrás de um wrapper.
DS4 / DwarfStar — o engine sob medida do antirez para um modelo.
• Forças: kernels em C + Metal escritos do zero, afinados especificamente para o DeepSeek-V4-Flash em 2 bits; nada de overhead de um engine genérico.
• Backend: Metal (Apple Silicon), implementação from-scratch.
• Quando usar: quando o workload é fixo e crítico e vale extrair o máximo daqueles kernels específicos — o "engine segue o workload" levado ao extremo.
• Num Mac: ★ é exatamente o caso deste curso. Para o cérebro (DeepSeek), DS4; para a visão (Qwen3-VL), MLX. Dois workloads, dois engines — assunto da Lição 07 e da Lição 08.
It's not a joke — it calls tools reliably even at 2-bit.— antirez, DS4 MODEL_CARD (sobre o DeepSeek-V4-Flash rodando no engine DS4)
Guia de bolso — todos os cenários
As abas em forma de tabela, para consulta rápida (inclui os engines NVIDIA que você não usará no Mac, para fechar o mapa):
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 tudo, CPU/GPU mista, GGUF.
Uma RTX (single-GPU)
ExLlamaV2
Alta eficiência numa placa só.
2–4+ GPUs NVIDIA
ExLlamaV3
Multi-GPU caseiro.
Produção geral
vLLM
Throughput, continuous batching, 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.
Workload fixo e crítico (1 modelo)
DS4 / bespoke
Kernels feitos sob medida; o extremo do "engine segue o workload".
Conveniência a qualquer custo
⛔ Ollama
Não usar. Esconde o engine e os kernels.
03b · A tabela comparativa — os 4 que você vai cogitar
A tabela acima cobre todos os cenários; esta aqui é a comparação direta dos quatro engines que de fato disputam a sua atenção no dia a dia — os dois que rodam no seu Mac (MLX, llama.cpp), o padrão de produção (vLLM) e o atalho que você vai recusar (Ollama). Compare coluna a coluna: backend, formato/quant, Metal? e o melhor caso de uso. A coluna "Metal?" é o filtro do Mac — onde dá ✓ é onde você pode rodar.
Engine
Backend
Formato / quant
Metal (Mac)?
Melhor caso de uso
MLX / MLX-LM
Metal
mlx (4/8-bit, fp16)
✓ nativo ★
Tudo "Mac em 1º"; LLM e visão no Apple Silicon
llama.cpp
CPU · Metal · CUDA · Vulkan
GGUF (Q2…Q8, K-quants)
✓ sim
Borda, portabilidade, hardware exótico, GGUFs
vLLM
CUDA
fp16/fp8, GPTQ, AWQ
✗ não
Produção multi-usuário em GPU NVIDIA
⛔ Ollama
llama.cpp (oculto)
GGUF (embrulhado)
~ via wrapper
Nenhum sério — esconde engine+kernels
Como ler a tabela: só as duas primeiras linhas têm um ✓ limpo em "Metal" — são os engines que falam com o seu Mac. O vLLM é CUDA-only (lindo em datacenter, inerte no M5 Max). O Ollama "roda" no Mac, mas só porque embrulha o llama.cpp e te esconde justo a camada — engine + kernels — que esta lição inteira ensina a controlar. Entre MLX e llama.cpp num Mac, o desempate é desempenho (MLX costura mais fino) vs portabilidade (llama.cpp roda em qualquer lugar).
A mesma comparação, agora como um mapa visual de duas perguntas — "fala Metal?" e "te dá controle dos kernels?". Só um quadrante é o lugar certo para um setup Mac sério:
MLX vs llama.cpp vs vLLM vs Ollama · "fala Metal?" × "te dá controle?"
03c · Anatomia de um kernel — o que o engine de fato chama
"Você roda kernels" soa abstrato até você ver um. Pegue o kernel mais quente de todos no decode: a multiplicação de matrizes (MatMul / GEMM) — é onde a esmagadora maioria dos FLOPs de um LLM é gasta. Um "engine melhor" quase sempre significa, na prática, um kernel de MatMul melhor para o seu hardware. Vamos abri-lo.
Simples primeiro: um modelo "pensar" = multiplicar a representação do token atual por uma pilha gigante de tabelas de pesos, camada após camada. Cada multiplicação dessas é um MatMul. Faça-o rápido (lendo a memória de forma esperta, fundindo etapas) e o modelo todo fica rápido. É só isso — repetido bilhões de vezes por token.
UM KERNEL DE PERTO · MatMul (GEMM) — o trabalho mais quente do decode
Conecte com o DS4
Agora a frase do antirez faz sentido literal: o DS4 escreve esses kernels do zero, em C + Metal, afinados para um único modelo (DeepSeek-V4-Flash a 2-bit). Sem o overhead de um engine genérico que precisa servir mil arquiteturas, os kernels de MatMul/attention ficam exatamente sob medida — é o "engine segue o workload" levado ao osso. Detalhe completo na Lição 07.
Os três truques, em dois níveis — Simples ⇄ Técnico
Cada engine compete por como faz esses kernels. Abaixo, os três truques centrais — leia a versão Simples primeiro (a intuição) e troque para Técnico quando quiser o nome real e quem usa. Cada um traz um micro-diagrama:
REUSAR O QUE JÁ FOI LIDO
NUNCA DEIXAR A GPU OCIOSA
Em uma frase: bons engines (1) reaproveitam texto repetido em vez de reprocessá-lo e (2) mantêm a GPU sempre cheia de trabalho. Os dois truques atacam justo as duas fases do loop (prefill e decode) que você viu na seção 02b.
Truque
Nome técnico
Ataca a fase
Quem se destaca
Reusar prefixo idêntico
RadixAttention / prefix cache
prefill
SGLang
Encaixar pedidos sem ociosidade
continuous batching
decode (multi-user)
vLLM
Paginar o KV cache
PagedAttention
decode (memória)
vLLM
Kernels Metal sobre RAM unificada
fused Metal kernels
prefill + decode
MLX
Kernels C/Metal de 1 modelo
bespoke from-scratch
prefill + decode
DS4
O fio condutor: nenhum desses truques é "mágica de modelo" — são kernels e agendamento. É literalmente a camada da seção 02 (kernels) somada à camada da seção 02b (as fases prefill/decode). Trocar de engine = adotar outro conjunto desses truques. No Mac, os que importam são os do MLX e do DS4 — os demais vivem no mundo CUDA.
04 · O mapa dos backends — quem fala com qual GPU
Por baixo de todo engine há um backend: a camada que fala a língua da GPU. São basicamente três mundos. Metal é a API gráfica/compute da Apple — é por onde MLX, DS4 e o llama.cpp-Metal acessam o Apple Silicon. CUDA é o mundo NVIDIA — vLLM, SGLang, ExLlama, TensorRT-LLM vivem lá. E há os portáteis (CPU/Vulkan), terreno do llama.cpp. Um engine só roda onde seu backend existe: é por isso que vLLM não é caminho no Mac e DS4 não roda numa RTX.
Clique num engine e veja o backend acender (e o que ele significa no seu Mac):
ENGINE → BACKEND → GPU · clique um engine
A leitura que importa: dos engines, só MLX, DS4 e o llama.cpp têm caminho até o Apple Silicon (via Metal/portátil). Todo o resto fala CUDA — lindo em datacenter NVIDIA, inerte no seu Mac. É o mapa concreto por trás da regra "Mac → MLX".
04b · O teto do decode — por que o engine só pode ir até onde a banda deixa
Aqui a lição de engines encosta na de banda (a Lição 03) e fica honesta sobre um limite. Você viu que o decode relê todos os pesos da RAM a cada token. Logo existe um teto físico de velocidade: por melhor que seja o engine, ele não inventa banda de memória. A conta de guardanapo é direta:
tokens/s de decode (teto) ≈ banda de memória (GB/s) ÷ tamanho dos pesos lidos por token (GB).— regra de teto de banda; cf. Lição 03 (banda = velocidade)
⟳ adivinhe antes de revelar
O DeepSeek q2 lê ~81 GB de pesos por token. O M5 Max tem ~546 GB/s de banda. Pelo teto de banda, qual é o máximo teórico de tokens/s no decode — antes de qualquer overhead? Chute.
≈ 6,7 tok/s — porque 546 ÷ 81 ≈ 6,7. Surpreende porque parece pouco para uma máquina tão cara — mas é o preço de um modelo de 284 B em 81 GB. Um engine excelente te leva perto desse teto; um ruim te deixa muito abaixo. Trocar de engine compra a distância até o teto; só trocar de hardware (mais banda) ou de modelo (pesos menores) move o teto em si. ~546 GB/s e 81 GB: ordens de grandeza para Apple Silicon high-end + o GGUF q2 do DS4. Valor exato de banda do M5 Max: [uncertain] — trate como estimativa.
Mexa a banda e o tamanho dos pesos. O número de tok/s do teto recalcula e a barra cresce em escala real — verde = confortável (≥10 tok/s), vermelho = arrastado (<5 tok/s). Veja como pesos menores (mais quant) ou mais banda é o que move o teto — o engine só te aproxima dele:
Escala: 0–60 tok/s. O engine te leva até esta barra; ele não a estende. Para subir o teto: mais banda (hardware) ou pesos menores (mais quant — Lição 04).
Visualmente: o teto é uma parede fixa (a banda). O engine é o quanto você chega perto dela. Veja a diferença entre um engine ruim e um bom no mesmo teto:
ENGINE RUIM × ENGINE BOM · mesmo teto de banda, distâncias diferentes
O papel honesto do engine
O 4,4× da seção 02 foi colher a distância até o teto num hardware que tinha banda sobrando. Num Mac com um modelo enorme, o teto é baixo — então o engine certo (kernels Metal afinados) importa ainda mais para não desperdiçar a pouca banda que há. É exatamente por isso que o curso usa DS4 (kernels sob medida) para o cérebro: extrair cada token/s possível do teto apertado de 81 GB/token.
05 · Por que NÃO o Ollama
Aqui está o ponto não-negociável do guia. O Ollama é a porta de entrada mais simpática da IA local — e justamente por isso vale ser explícito sobre por que não usá-lo num setup que você quer controlar. A objeção não é gosto pessoal; é arquitetura.
DO NOT USE Ollama. Ollama is pleasant yet should not be used.— Ahmad Osman, "Inference Engines for LLMs (2026)"
⛔ POR QUE NÃO OLLAMA · a conveniência cobra um preço
⛔ Aviso direto
O guia é categórico: "DO NOT USE Ollama. Ollama is pleasant yet should not be used." A conveniência abstrai exatamente a camada — engine + kernels — que decide a sua velocidade. No Mac, vá de MLX direto; na borda, llama.cpp; em produção, vLLM ou SGLang. Você não está perdendo facilidade — está ganhando o controle que faz o 4,4× da seção 02 existir.
Fechando: neste curso, dois workloads, dois engines
A doutrina "o engine vem por último, seguindo o workload" é exatamente o que a config deste curso faz — e leva ao extremo. Não há "o melhor engine"; há o engine certo para cada trabalho. O fluxograma abaixo é a lição inteira em uma figura: uma única pergunta de decisão (é um Mac?) e o ramo do workload que separa os dois motores deste curso:
SÍNTESE · a lição em um fluxograma (o caminho deste curso em destaque)
Visão (Qwen3-VL) → MLX. Mac em 1º lugar, então a árvore decide MLX antes de qualquer outra pergunta. É o mesmo mlx_vlm.server das lições de visão.
O cérebro (DeepSeek) → DS4. Em vez de um engine genérico, kernels Metal sob medida para um modelo. Workload fixo e crítico justifica um engine dedicado.
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 vira o orçamento de memória concreto do seu M5 Max.
Fixe os conceitos (flashcards)
Clique pra virar. Tente lembrar a resposta antes de virar — recuperação ativa fixa mais que reler. Quatro ideias-âncora desta lição:
Ordem
Em que ordem se decide o engine?
clique pra virar ↻
Resposta
hardware → workload → serviço → engine por ÚLTIMO. As 3 primeiras já quase escolhem o motor. No Mac, a árvore decide MLX antes da pergunta 2.
Kernels
"Trocar de engine" muda o quê, de fato?
clique pra virar ↻
Resposta
Os kernels (MatMul, attention, fused…). Mesmo modelo + mesmo hardware + kernels melhores = mais tok/s. Foi assim que 2× RTX 3090 foram de 14,5 a 64 (~4,4×).
Loop
Prefill × decode — qual é o gargalo de cada um?
clique pra virar ↻
Resposta
Prefill = 1 passada paralela, limitada por compute (TTFT). Decode = laço de 1 token/volta, limitado por banda de memória (velocidade que você sente).
Ollama
Por que NÃO usar Ollama num setup sério?
clique pra virar ↻
Resposta
Ele embrulha o llama.cpp e esconde engine + kernels — justo a camada que decide sua velocidade. No Mac: MLX direto; borda: llama.cpp; produção: vLLM/SGLang.
Revisão cumulativa — recupere de memória
Antes de clicar: tente responder de cabeça. Recuperar da memória (não reler) é o que fixa de verdade. As quatro opções têm o mesmo tamanho de propósito — sem pista pela forma.
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. a está errado: nenhuma placa mudou — é o ponto inteiro da medição. c: não houve requantização; o modelo é o mesmo. d: nada de 3ª GPU. Na RTX PRO 6000, migrar para SGLang levou de 32 a 110 tok/s (~3,4×).
2. Você roda num Mac e quer o caminho recomendado. E quanto ao Ollama?
Correto: c. A árvore decide MLX para Mac antes de qualquer outra pergunta. a inverte o guia: Ollama é desaconselhado de forma categórica ("pleasant yet should not be used"). b: TensorRT-LLM é CUDA/NVIDIA-only — não roda no Mac. d: vLLM é para GPUs NVIDIA de produção, não para Apple Silicon.
3. Por que a 1ª palavra "pensa" e o resto da resposta "jorra"?
Correto: a. A primeira palavra espera o prefill (uma passada sobre todo o prompt = time-to-first-token); depois o decode emite token a token. b: não há "ficar mais esperto" durante a geração. c: inferência local não usa internet — o atraso é o prefill, não rede. d: é o mesmo modelo do começo ao fim; não há troca de modelo entre palavras.
4. No Mac, o decode de um modelo enorme está lento. O que de fato MOVE o teto de tok/s?
Correto: d. O teto do decode ≈ banda ÷ pesos-por-token. a erra a sutileza: o engine te leva até o teto, mas não o estende. b: contexto maior gasta mais KV e tende a piorar, não acelerar. c: Ollama não tem "turbo" e ainda esconde os kernels. Mover o teto exige banda maior ou pesos menores.
💬 Travou em algo? Eu sou seu professor neste curso — pergunte. "Por que a memória unificada ajuda o MLX?", "O que é tensor-parallel na prática?", "DS4 ou MLX para o DeepSeek — por que não os dois no mesmo modelo?". É só dizer.