Antes de instalar qualquer coisa, você precisa de uma forma de pensar. Esta lição instala o framework de Ahmad Osman: hardware de IA local é capacidade × banda × stack de software, e você nunca escolhe um motor de inferência primeiro. É interativa — clique nas abas, percorra o fluxo, leia o mapa. Internalize isto e cada decisão das próximas lições deixa de ser um chute e passa a ser uma dedução.
Esta lição destila esses dois artigos + os fatos fixos do seu Mac. Os números têm fonte (rodapé). Por que importa pra missão: é a lente que diz, antes de qualquer download, se o cérebro local do Alembic vale a pena neste hardware — e por quê.
Objetivos desta lição
Recitar a equação hardware = capacidade × banda × stack e dizer por que é ×, não +.
Diagnosticar, pelo sintoma, se um setup é capacity-bound, bandwidth-bound ou stack-bound.
Pôr a escolha do motor de inferência (MLX, llama.cpp…) no 4º lugar da decisão — nunca no 1º.
Diferenciar "roda" (demo, 1 req) de "serve" (sistema, N reqs com fila + KV).
0
fatores que definem tudo: capacidade · banda · stack
0º
o motor de inferência vem por ÚLTIMO
0 GB
a sua capacidade fixa (M5 Max)
0 GB/s
o topo da sua banda fixa
01 · A fórmula dos três fatores
Todo o resto do curso pende de uma única frase. Hardware de IA local não é "uma GPU boa" — é o produto de três coisas, e cada uma responde a uma pergunta diferente. Não é metáfora: é a equação que diz quanto da ficha técnica você consegue de fato sacar.
Hardware de IA local = capacidade × banda × stack de software. A capacidade diz o que cabe. A banda diz com que força a caixa consegue respirar. O stack de software diz quanto da ficha técnica você consegue de fato sacar.— Ahmad Osman, "GPU Memory Math for LLMs (2026)"
As três peças, e a pergunta de cada uma
Os três fatores se multiplicam numa única saída — o que você de fato saca. Cada bloco abaixo é um conceito que vale entender de verdade, não decorar. Veja-os surgirem e os conectores × ligarem tudo à saída:
capacidade × banda × stack → o que você saca
Por que "×" e não "+": um fator fraco não é compensado pelos outros — ele multiplica para baixo. Se qualquer fator for zero, a saída é zero. Banda enorme com pouca capacidade nem roda o modelo; 512 GB de capacidade com um stack que só saca 30% da banda entrega menos que 128 GB bem servidos. Esta é a lente que separa quem compra ficha técnica de quem compra resultado.
⏱ Pré-pense (3 s)
Você compra uma máquina nova: capacidade 200% da sua atual, banda 200%, mas o stack só saca 25% da banda (drivers ruins). Quantas vezes mais "saída útil" você ganha?
1.0× — mesmo desempenho. Conta: 2 × 2 × 0,25 = 1.0. Triplicou o investimento e não melhorou nada — porque um fator multiplica para baixo. É exatamente o que acontece com um Mac novo onde só roda llama.cpp genérico em vez do motor nativo Metal/MLX.
01b · Sinta o "×" — simulador dos três fatores
A multiplicação fica óbvia quando você mexe nela. Arraste os três sliders: cada um vai de 0 (fator zerado) até 200% da linha-base. O número grande é o produto normalizado; a barra colorida mostra a saída real. Repare: zerar qualquer fator zera tudo, e amplificar dois deles não compensa um terceiro fraco.
capacidade × banda × stack = saída útil (relativa)
O que sentir aqui: o stack é um teto, não um bônus. Capacidade e banda multiplicam livremente, mas o stack só sabe sacar o que tem — e quase nunca chega a 100% na vida real. Esse é o fator sob seu controle no M5 Max: capacidade e banda já estão soldadas, mas qual motor você usa decide se o stack saca 35% ou 85% da banda.
01c · Faça a conta — exemplo resolvido
A fórmula só vira intuição quando você a executa com números reais. Vamos pôr o seu M5 Max na conta e medir o que dois stacks diferentes entregam — mesma capacidade, mesma banda, só o stack muda. Acompanhe cada passo e depois faça o "agora você":
Exemplo resolvido · saída útil do M5 Max com dois motores
1
Fixe o que não muda. Capacidade = 128 GB e banda ≈ 614 GB/s são soldadas no M5 Max. Em termos relativos: capacidade = 1,0 e banda = 1,0 (a linha-base do simulador acima).
2
Estime o stack do motor A (genérico). Um llama.cpp sem kernels Metal nativos saca ~35% da banda. Stack = 0,35.
3
Multiplique (motor A). saída = capacidade × banda × stack = 1,0 × 1,0 × 0,35 = 0,35 → você usa só 35% da máquina que pagou.
4
Troque só o stack: motor B (nativo). MLX/Metal bem afinado saca ~85% da banda. Stack = 0,85, tudo o mais igual.
5
Compare. saída(B) = 1,0 × 1,0 × 0,85 = 0,85. Ganho = 0,85 ÷ 0,35 ≈ 2,4× mais tokens/s — sem trocar uma peça de hardware. Só o fator sob seu controle.
→
Agora você. Um motor mediano saca ~60% (stack = 0,60). Qual a saída relativa, e quantas vezes melhor que o motor A? (Resposta no slider 04c — confira lá.) Dica: é a mesma multiplicação, trocando só o último número.
mesma banda (614 GB/s), 3 stacks · o que cada motor SACA no M5 Max
A lição do exemplo: não há hardware novo nestes 2,4× — só o stack mudou. Por isso o resto do curso é uma caça ao motor que saca mais da banda que você já tem. [uncertain] os 35% / 85% são faixas ilustrativas plausíveis do efeito kernel nativo vs genérico, não uma medição do seu Mac; a Lição 05 mede de verdade.
02 · Qual gargalo você está comprando?
Toda máquina de IA local é dominada por um dos três fatores. Não existe a máquina sem gargalo — existe a máquina cujo gargalo combina com o seu workload. Saber ler o sintoma é saber qual peça apertar. Clique numa aba para ver o sintoma e a correção de cada tipo de limite:
"não cabe" — capacity-bound
"não respira" — bandwidth-bound
"não saca" — stack-bound
A sua leitura, founder
No M5 Max, capacidade (128 GB) e banda (~460–614 GB/s) são fixas — você não troca o hardware. Sobra um fator sob seu controle: o stack. É por isso que o resto do curso é, na prática, uma caça ao stack que saca o máximo da banda que você já tem. O gargalo que você "comprou" foi banda-média; a sua alavanca é não desperdiçá-la.
02c · Fluxograma: que gargalo é este?
As três abas acima viram um algoritmo de três perguntas, na ordem em que a máquina te avisa. Você sempre pergunta na sequência cabe? → respira? → saca? — e para na primeira que falhar. Siga as setas; o diamante é onde a decisão se ramifica:
cabe? → respira? → saca? · pare na primeira que falhar (M5 Max)
Por que a ordem importa: não adianta caçar tokens/s (pergunta 2) se o modelo nem cabe (pergunta 1) — ele nem carrega. E não adianta culpar o motor (pergunta 3) se o gargalo é banda física (pergunta 2). No M5 Max a pergunta 1 quase sempre passa (128 GB é generoso) e a 2 é o limite físico; sobra a 3 — o stack — como a sua alavanca real.
03 · A virada de pergunta
O framework não é só descritivo — ele muda a pergunta que você faz na hora de comprar ou configurar. Sair de "qual é o melhor hardware?" para "qual gargalo eu estou comprando?" é a diferença entre escolher por hype e escolher por engenharia.
Quando você internaliza isto, para de perguntar "Qual hardware é melhor?". Você começa a perguntar "Qual gargalo eu estou comprando?".— Ahmad Osman, "GPU Memory Math for LLMs (2026)"
da pergunta de hype → à pergunta de engenharia
"Qual o melhor?" não tem resposta — depende do que você vai rodar. "Qual gargalo estou comprando?" é decidível: olha o seu workload, lê os sintomas da seção 02 e escolhe conscientemente o trade-off. É a mesma diferença entre comprar por marketing e comprar por especificação.
04 · A ordem de decisão: o motor vem por último
O erro mais comum de quem começa é abrir o fórum e perguntar "uso Ollama, llama.cpp ou MLX?". Errado — não por ser uma má ferramenta, mas por ser a última pergunta. Primeiro você fixa a estratégia de hardware, o formato do workload e o modelo de serviço. O motor é consequência, não ponto de partida.
Você não escolhe um motor de inferência primeiro. Você escolhe uma estratégia de hardware, um formato de workload e um modelo de serviço. O motor vem depois.— Ahmad Osman, "You don't run a model (you run Kernels)"
Clique em cada etapa do fluxo — ela acende e a nota aparece. Repare que a 4ª (o motor) está tracejada: é a última.
hardware → workload → serviço → motor (por último)
Tradução para você: o hardware já está fixo (M5 Max). O formato do workload são dois: um cérebro de coding/agente e visão ocasional. O modelo de serviço você ainda vai escolher (e é aí que mora a próxima distinção, "roda vs serve"). Só depois disso o motor — MLX, llama.cpp, etc. — aparece, e quase se escolhe sozinho.
04b · O "stack" em duas camadas: simples e técnico
"O stack saca X% da banda" pode soar abstrato. Comece pela analogia; só depois desça ao mecanismo. Clique nas abas — a versão Simples primeiro, a Técnica quando quiser o porquê:
analogia do canudo — a banda é o copo, o stack é o canudo
Em uma frase: o copo (banda) é o mesmo nos dois casos — o que muda é a grossura do canudo (o motor). Um canudo fino deixa litros parados no copo; um grosso esvazia depressa. Você não pode trocar o copo (hardware soldado), mas escolhe o canudo.
o mecanismo — kernels lendo a memória unificada
O porquê: gerar 1 token relê todos os pesos da RAM (Lição 03). Kernels nativos fundem operações e leem a memória em sequência coalescida — quase a banda máxima. Kernels genéricos quebram isso em muitas leituras dispersas e em cópias extras, então a GPU fica ociosa esperando bytes: a mesma banda física rende menos. É software deixando hardware na mesa.
04c · Sinta o stack — quanto da banda o motor saca?
Aqui o fator sob seu controle vira um botão. Arraste a eficiência do stack de 30% a 95% e veja, na mesma banda do M5 Max (614 GB/s), a banda efetiva e uma estimativa de tokens/s mudarem — sem tocar no hardware. É a resposta numérica do "agora você" do exemplo 01c:
stack (% da banda) → banda efetiva & tokens/s · M5 Max, modelo ~32 GB
Leitura do botão: tokens/s sobem linearmente com o stack porque a geração é dominada por leitura de memória. Dobrar a eficiência do stack ≈ dobrar a velocidade — e é grátis (só trocar de motor). Esse é o retorno de engenharia mais barato do curso, e por que o motor, embora venha por último na decisão, importa muito.
05 · O M5 Max como ponto fixo no mapa
Cada classe de hardware ocupa um lugar diferente no plano capacidade × banda. Plotar os candidatos deixa óbvio o que a Apple oferece: capacidade alta, banda média. Uma GPU dedicada inverte: banda altíssima, capacidade pequena. Não há vencedor absoluto — há posições, e a sua já está escolhida. O ★ M5 Max pulsa no mapa:
capacidade ↑ × banda → · o seu ponto está fixo (★ M5 Max pulsa)
Valores aproximados, para posicionar — não benchmarks exatos. O recado é a forma do mapa: a Apple troca banda de ponta por capacidade generosa numa só caixa portátil. A RTX 5090 faz o oposto. O Mac Studio 512 GB empurra a capacidade ao extremo, mas não cabe na mochila.
Hardware
Capacidade
Banda (aprox.)
Perfil dominante
M5 Max ★
128 GB unificada
~460–614 GB/s
Capacidade alta · banda média — modelo grande num laptop
RTX 5090
32 GB GDDR7
~1,8 TB/s
Banda altíssima · capacidade pequena — rápido, mas cabe pouco
Mac Studio
512 GB unificada
média-alta
Capacidade extrema — roda quase tudo, não é portátil
DGX Spark
~128 GB
baixa-média
Capacidade ok · banda fraca — gargalo de banda cedo
05c · M5 Max × RTX 5090 × Mac Studio, lado a lado
O mapa mostrou posições; este comparativo mostra o trade-off em três eixos ao mesmo tempo — capacidade, banda e portabilidade — normalizados de 0 a 100% para a leitura ser direta. Nenhuma máquina ganha nos três: cada coluna alta tem uma coluna baixa em troca. É a forma do compromisso que você comprou:
3 máquinas × 3 eixos (0–100% relativo) · ★ = o seu M5 Max
Eixo
★ M5 Max
RTX 5090
Mac Studio 512
O trade-off
Capacidade
128 GB (alta)
32 GB (baixa)
512 GB (máxima)
Studio cabe tudo; 5090 cabe pouco
Banda
~614 GB/s (média)
~1,8 TB/s (topo)
média-alta
5090 gera rápido; Apple troca por capacidade
Portabilidade
laptop (total)
desktop só
desktop só
só o M5 Max vai na mochila
A leitura para você: o M5 Max é o único que não tem nenhuma barra curta demais — capacidade alta, banda média, portabilidade total. Não vence em banda pura (a 5090 vence) nem em capacidade pura (o Studio vence), mas é o único equilíbrio que cabe num laptop. Você não comprou "o melhor"; comprou "o melhor equilíbrio portátil" — e o curso assume exatamente esse ponto. Valores normalizados de aproximações da seção anterior, para leitura comparativa.
06 · "Roda" não é "serve"
A última peça do modelo mental é a mais cara de aprender na prática. Fazer um modelo responder uma vez no terminal é trivial. Fazê-lo servir — aguentar concorrência, latência previsível e custo sob carga — é projeto de sistema. Confundir os dois é a origem de metade das frustrações com IA local.
It runs = demo. It serves = system design. (Roda = demo; serve = projeto de sistema.)— Ahmad Osman, "You don't run a model (you run Kernels)"
Clique no botão para alternar entre os dois estados — veja a demo (1 request) virar sistema (as requisições se acumulam, entram fila + batch + KV cache):
prova que carrega e responde — uma vez
aguenta produção sob carga
A demo cabe numa linha de terminal. O sistema exige fila, batching, gestão de KV cache e um teto de RAM respeitado. Este curso te leva do "roda" ao "serve" — é por isso que a config final (Lição 08) fala em portas, picos de RAM e folga, não só em "qual modelo baixar".
O contrato deste curso
Para você, o hardware é dado: M5 Max, 128 GB, ~460–614 GB/s. Os workloads são dois: um cérebro de coding/agente e visão ocasional. Tudo o que vem a seguir — memória (Lição 02), banda, quantização, MoE, motor, a config final — é derivado desses fatos com o framework desta lição. Você não vai decorar receitas; vai deduzir a sua.
06c · Do "roda" ao "serve" — o caminho do curso
Esta distinção é o destino do curso, então vale ver o caminho como um fluxo. Você começa provando que "roda" (a esquerda) e, se — e só se — precisar de concorrência, passa pela ponte de engenharia (fila, batch, KV) até "serve" (a direita). O diamante é a pergunta que decide se você precisa cruzar a ponte:
Para a sua missão: o cérebro local do Alembic precisa servir (vários agentes/requisições), não só "rodar". Por isso a config final (Lição 08) fala em portas, pico de RAM e folga — ela está do lado direito do fluxo. Mas você sempre prova o "roda" primeiro: é o degrau que valida o motor antes de investir na ponte.
Fixe os conceitos (flashcards)
Clique pra virar. Tente lembrar a resposta antes de virar — recuperação ativa fixa mais que reler. Os quatro pilares desta lição, um por carta:
Fórmula
Por que é capacidade × banda × stack, e não +?
clique pra virar ↻
Resposta
Porque um fator fraco multiplica para baixo: se um é ~0, a saída é ~0. 2 × 2 × 0,25 = 1,0 (nada mudou). Soma perdoaria; produto não.
Diagnóstico
Qual a ordem das 3 perguntas de gargalo?
clique pra virar ↻
Resposta
cabe? (capacity) → respira? (bandwidth) → saca? (stack). Pare na primeira que falhar — nada adianta caçar tokens/s se o modelo nem carrega.
Ordem
Em que lugar entra o motor de inferência?
clique pra virar ↻
Resposta
4º e último: hardware → workload → serviço → motor. Ele decorre dos três acima e quase se escolhe sozinho.
Roda vs Serve
Qual a diferença entre "roda" e "serve"?
clique pra virar ↻
Resposta
Roda = demo (1 req, latência/custo não importam). Serve = sistema (N reqs com fila + batch + KV cache + teto de RAM). Roda prova; serve sustenta.
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. Segundo o framework de Ahmad Osman, qual é a pergunta certa ao avaliar hardware de IA local?
Correto: c — todo setup é dominado por um dos três fatores, e a pergunta certa identifica qual. Por que as outras falham: a olha TFLOPs no papel, mas a geração é dominada por banda de memória, não FLOPs — número de marketing. b não tem resposta: "o melhor" depende do workload (a virada inteira da seção 03). d inverte a ordem — o motor é o 4º passo (seção 04), nunca o 1º.
2. Na ordem de decisão correta, quando entra a escolha do motor de inferência (MLX, llama.cpp…)?
Correto: b — a sequência é hardware → workload → serviço → motor; o motor decorre dos três. Por que as outras falham: a é o erro clássico ("uso Ollama ou MLX?" antes de tudo) — o motor é consequência, não ponto de partida. c ainda é cedo demais: faltam workload e modelo de serviço antes dele. d exagera para o oposto — o motor importa muito (é o stack, ~2,4× no exemplo 01c), só não vem primeiro.
3. No M5 Max, capacidade e banda são fixas. Qual fator você controla, e o que ele muda?
Correto: d — o stack é o único fator sob seu controle, e como a geração é dominada por banda, dobrar a eficiência do stack ≈ dobra a velocidade (slider 04c; ~2,4× no exemplo 01c). Por que as outras falham: a a RAM unificada do Apple Silicon é soldada — não há upgrade. b não existe "modo turbo": a banda é física, fixa em ~460–614 GB/s. c é o erro que a lição inteira desfaz — sobra exatamente um fator vivo (o stack).
💬 Travou em algo? Eu sou seu professor neste curso — pergunte. "Por que banda vira gargalo antes da capacidade no meu Mac?", "Como sei se estou stack-bound?", "O que muda se eu acoplar o M4 Max de 36 GB?". É só dizer.