A intuição diz "mais FLOPs = mais rápido". Para gerar tokens, isso está errado: o que manda é a largura de banda da memória — quão rápido os pesos ativos são lidos da RAM a cada token. No fim desta lição você vai estimar, de cabeça, quantos tokens por segundo um modelo dá num dado hardware — e entender por que o seu M5 Max é perfeitamente utilizável apesar de não ser o chip mais rápido do mercado.
Esta lição destila esse artigo + medições reais no M5 Max (DeepSeek-V4-Flash q2: ~33,9 tok/s de geração). Todos os números têm fonte (rodapé). Por que importa pra missão: banda é o que decide se o cérebro local do Alembic responde "vivo" ou arrasta "como cimento molhado" a 3 tok/s.
Objetivos desta lição
Explicar, com analogia, por que decode é limitada pela banda — não pelos FLOPs.
Estimar de cabeça tok/s ≈ banda ÷ bytes-ativos-por-token em qualquer hardware.
Distinguir prefill (compute-bound, paralelo) de decode (bandwidth-bound, sequencial).
Apontar os cinco caminhos para acelerar — e qual deles seu M5 Max já está usando.
0 GB/s
banda do M5 Max (pico)
0 B
params ativos/token (de 284 B)
0 tok/s
geração DeepSeek q2 (medido)
$0
por token · offline
01 · Decode segue a banda, não os FLOPs
Gerar texto tem duas fases bem diferentes. Na decode — a fase em que o modelo cospe um token de cada vez — para produzir cada token a GPU precisa ler da memória todos os pesos ativos. Não importa quão rápido ela calcula: ela passa a maior parte do tempo esperando os pesos chegarem. Por isso a velocidade de geração acompanha a banda de memória (GB/s), não os FLOPs de pico.
Decode speed tracks memory bandwidth more than peak compute. Bandwidth decides whether the box feels alive or like it's decoding through wet cement at 3 tokens per second.— Ahmad Osman, "Memory Bandwidth for Local AI Hardware (2026)"
A intuição: um teto físico, não um detalhe
Pense num cano. A cada token, todos os bytes dos pesos ativos têm que passar por ele — uma vez. Quão grosso é o cano? É a banda. Se você precisa empurrar 26 GB de pesos por token e o cano move 614 GB/s, no melhor caso você faz 614 ÷ 26 ≈ 23 tokens por segundo. FLOPs sobrando não alargam o cano. É um limite de roofline: na decode, você bate no teto da memória muito antes de bater no teto do cálculo.
O CANO DA DECODE · cada token relê os pesos ativos da RAM
A regra de ouro do decode
Numa geração dominada pela decode (prompt curto, resposta longa), tok/s ≈ banda de memória ÷ bytes dos pesos lidos por token. Dobre a banda e você quase dobra os tok/s; dobre os FLOPs sem mexer na banda e quase nada muda. É por isso que a Apple, com banda alta e unificada, joga nessa liga apesar de ter menos compute bruto que uma RTX.
Analogia visual: dois canos, mesmo balde
Pegue dois canos despejando água no mesmo balde de 26 GB (os pesos ativos). O cano fino (256 GB/s, mini-PC) demora ~100 ms por balde; o cano grosso (614 GB/s, M5 Max) demora ~42 ms. O FLOPs é o tamanho da torneira — mas a torneira já passou os bytes lá em cima, o gargalo é o cano. Esta é a diferença entre "vivo" e "cimento molhado":
DOIS CANOS · MESMO BALDE DE 26 GB · O GROSSO ENCHE 2,4× MAIS RÁPIDO
Preveja antes de continuar
Você tem dois Macs com FLOPs IDÊNTICOS. O A tem 800 GB/s de banda. O B tem 400 GB/s. Rodando o mesmo DS4-q2, quantas vezes mais rápida deve ser a decode no Mac A em relação ao Mac B?
≈ 2× mais rápida — porque a decode é bandwidth-bound: tok/s escala quase linearmente com a banda quando os FLOPs já estão sobrando. Se a sua intuição foi "depende dos FLOPs", o cano da decode te derrubou. (Bônus: prefill, ao contrário, mal mudaria — ele é compute-bound; ver seção 03.)
02 · Calcule você mesmo: banda → tok/s
A teoria vira intuição quando você mexe nela. Arraste a banda (de 100 a 1000 GB/s) e veja os tokens por segundo recalcularem ao vivo, com a barra crescendo em escala real. O cálculo é o teto de decode: tok/s ≈ banda ÷ bytes-ativos-por-token, usando os 13 B de params ativos do DeepSeek-V4-Flash a ~2 bytes/param efetivos (a parte crítica fica em 8 bits — ver Lição 04).
Escala: 0–60 tok/s. Abaixo de ~5 tok/s a barra fica vermelha — é o "cimento molhado"; acima disso, verde = utilizável. Repare: a 13 B ativos, mesmo 256 GB/s (um mini-PC) já sai do vermelho; a banda do M5 Max (≈614) entrega ~23 tok/s teóricos — e a medição real fica em 25–34 tok/s, batendo o teto.
Por que a medição (34) supera a conta (23)? A conta acima usa 2 bytes/param como piso conservador; na prática a maior parte dos experts do DS4 está em ~2 bits (¼ de byte), então os bytes lidos por token são bem menores que o pior caso — e os tok/s sobem. A fórmula te dá o teto pessimista; a engenharia da quantização (Lição 04) empurra o real pra cima.
03 · Prefill vs decode: dois gargalos diferentes
Nem toda fase da geração é limitada pela banda. Prefill é quando o modelo lê o seu prompt — e ele processa todos os tokens do prompt em paralelo, num grande produto de matrizes. Aí o gargalo vira o cálculo (os kernels de atenção), não a banda: é compute-bound. Já a decode gera um token por vez, em sequência, relendo os pesos a cada passo: é bandwidth-bound. Por isso "prompt longo, resposta curta" e "prompt curto, resposta longa" têm perfis de velocidade opostos.
PREFILL (paralelo · compute-bound) vs DECODE (sequencial · bandwidth-bound) — setas em movimento = fluxo
PREFILL (compute-bound): • Lê o prompt inteiro em paralelo. • Saturado pelos kernels de atenção (FLOPs). • Um Mac com muita banda mas menos compute fica para trás aqui — prompts gigantes demoram a "engolir". • Otimização típica: chunked prefill.
DECODE (bandwidth-bound): • Gera token a token, em sequência. • Relê os pesos ativos a cada passo → limitado pela banda. • É onde o M5 Max brilha: banda alta unificada. • Otimização típica: menos params ativos (MoE) e menos bytes/peso (quant).
04 · Onde o seu Mac cai (barras à escala)
Agora o mapa concreto. As barras abaixo são proporcionais à banda de memória real (GB/s) de cada plataforma e crescem ao entrar na tela. O M5 Max — a sua máquina — pulsa em destaque. Repare em duas coisas: (1) a Apple não vence a NVIDIA em banda bruta; (2) mas está numa classe mais que suficiente para um MoE de poucos ativos, e entrega isso num único equipamento silencioso, sem sharding.
LARGURA DE BANDA DE MEMÓRIA · GB/s (barras animadas à escala)
Por que 284 B "cabe" rápido: MoE de poucos ativos
Falta uma peça para fechar o enigma: como um modelo de 284 B roda decente num laptop? Porque ele é um Mixture-of-Experts: dos 284 B de parâmetros, só cerca de 13 B acendem por token (os blocos que pulsam abaixo). A banda só precisa alimentar a fração acesa, não o modelo inteiro. Poucos-ativos × banda alta = utilizável.
284 B TOTAIS · ~13 B ATIVOS/TOKEN (≈4,6% acende, pulsando) — cada bloco é um expert
Hardware
Banda
Classe
DS4 q2 (decode)
RTX 5090 / PRO 6000
1792 GB/s
1.8 TB/s
muito rápido
Mac Studio M3 Ultra
819 GB/s
800
rápido
MacBook Pro M5 Max
460–614 GB/s
450–650
~33,9 tok/s · vivo
DGX Spark / Strix Halo
256–273 GB/s
250–300
utilizável
05 · "Por que banda, e não FLOPs?" — o lado a lado
Para cravar a intuição, compare as duas métricas na mesma decode. FLOPs medem o quão rápido a máquina calcula; banda mede o quão rápido ela move pesos. Numa RTX 5090, há FLOPs de sobra — mas o gargalo continua sendo mover bytes. Clique entre as visões: a mesma geração, dois pontos de vista.
Visão correta — banda: na decode, cada token relê os pesos ativos da RAM. Tempo por token ≈ bytes ÷ banda. Logo, tok/s ≈ banda ÷ bytes-por-token. Reduzir bytes (quantizar, MoE de poucos ativos) ou aumentar banda é o que acelera. ★ É a única conta que prevê os tok/s reais que você sente.
Visão enganosa — FLOPs: "minha GPU faz X TFLOPs, então deve gerar rápido". Falso na decode: a GPU passa o tempo esperando os pesos, com as unidades de cálculo ociosas. Por isso uma RTX 5090 (1792 GB/s) gera mais rápido que uma placa com FLOPs parecidos mas banda menor — e por isso o M5 Max, com banda decente, não fica para trás como os FLOPs sozinhos sugeririam.
Comparativo direto: mesmos FLOPs, banda diferente
O experimento mental que cala a intuição dos FLOPs: duas máquinas com poder de cálculo idêntico, só a banda muda. Se FLOPs mandassem, a decode seria igual nas duas. Não é — a barra de tok/s segue a banda, não o cálculo:
MÁQUINA A vs MÁQUINA B · FLOPs IDÊNTICOS · só a banda difere → só a decode difere
Vivo ou "cimento molhado": a faixa que você quer
Junte tudo: banda alta + poucos params ativos colocam você na faixa "vivo"; banda baixa (ou um modelo denso e grande) te jogam no "cimento molhado" a ~3 tok/s. O marcador abaixo desliza até onde o M5 Max realmente caiu nesta sessão: ~34 tok/s.
tok/s SOBE COM A BANDA · o marcador desliza até a faixa do M5 Max ao entrar na tela
O que isso significa pra você: a 460–614 GB/s, o M5 Max está na classe certa para um MoE de poucos ativos. Por isso a config mede 25–34 tok/s (≈33,9 na sessão de referência) num modelo de 284 B — "vivo", não "cimento molhado". E custa $0/token, offline. A Lição 08 mostra a configuração exata que atinge esse número.
Comparativo: 3 precisões, mesma banda — bytes/token mandam
Já que tok/s ≈ banda ÷ bytes-por-token, mudar os bytes por peso (a precisão) muda a velocidade sem tocar no hardware. Para os mesmos 13 B ativos do DS4 na mesma banda de 614 GB/s, veja o que cada precisão lê por token e o teto de decode que isso gera. Este é o segundo motivo (junto do MoE) pelo qual o DS4 quantiza fundo — menos bytes lidos = mais tok/s:
Precisão dos ativos
Bytes/param
Lidos/token (13 B)
tok/s ≈ 614 ÷ bytes
Sensação
FP16 (referência)
2,0 B
26 GB
≈ 24 tok/s
vivo
Q8 (piso conservador)
1,0 B
13 GB
≈ 47 tok/s
rápido
~2 bits (experts do DS4)
0,25 B
3,25 GB
≈ 189 tok/s (teto)
folga enorme
Leia com cuidado — esse 189 é um teto, não a medição. Na prática o DS4 mistura precisões (experts em ~2 bits, atenção/roteamento em Q8 — a receita assimétrica da Lição 02), então os bytes médios por token caem entre os 13 GB do Q8 e os 3,25 GB do 2-bit. Por isso o medido fica em 25–34 tok/s: o teto pessimista (2 B → 24) sobe com a quantização, mas atenção/KV/overhead seguram o pico bem abaixo do teto otimista. A fórmula te dá as balizas; a engenharia decide onde, entre elas, você cai. [uncertain] os bytes médios exatos por token do GGUF do antirez não foram medidos aqui — só as balizas.
A MESMA TABELA, VISUAL · bytes lidos/token ↓ → tok/s ↑ (banda fixa 614 GB/s)
06 · Decisão: otimizar prefill ou decode? (fluxograma)
Saber que prefill é compute-bound e decode é bandwidth-bound só vale se vira decisão. Use este fluxograma: descreva a sua carga (prompt vs resposta) e ele aponta o gargalo real e o que mexer. Siga as setas — o losango é a pergunta que decide o caminho.
FLUXOGRAMA · "ESTÁ LENTO — MEXO EM QUÊ?" (a decisão para a config do M5 Max)
No seu M5 Max, na prática: chat e agentes são resposta longa → quase sempre você cai no ramo DECODE. Logo as alavancas que importam são quantização (Lição 04) e MoE de poucos ativos — exatamente o que o DS4 entrega.
Quando o prefill morde: se você joga um PDF de 50 páginas de uma vez (prompt gigante), o "tempo até o primeiro token" estica — isso é o ramo PREFILL. Aí banda não resolve; é compute. Por isso prompts enormes "demoram a engolir" mesmo num Mac de banda alta.
07 · Cinco caminhos para acelerar (a receita)
A fórmula tok/s ≈ banda ÷ bytes-por-token tem só duas alavancas: aumentar a banda (numerador) ou reduzir os bytes lidos por token (denominador). Tudo o que acelera decode é uma dessas duas. Este fluxo organiza os cinco caminhos práticos — e marca qual deles o seu M5 Max já usa:
RECEITA · DUAS ALAVANCAS → CINCO CAMINHOS (os ✓ são o que a config do M5 Max já faz)
1+2 · Banda & unificada (hardware): caminho que você já tem. Memória unificada significa que CPU e GPU compartilham a mesma RAM sem cópias — não há PCIe estrangulando o tráfego, e os 614 GB/s alimentam a GPU direto.
3+4 · Quant & MoE (modelo): os dois caminhos do DS4. Quantizar corta bytes/peso; MoE corta quantos pesos acendem. Juntos derrubam o denominador da fórmula — é o grosso do ganho que você sente.
5 · Speculative decoding (engine): um modelo pequeno "adivinha" vários tokens e o grande os verifica em lote. Não muda a banda nem os pesos, mas amortiza leituras — assunto da Lição 05.
Por que "unificada" importa: comparativo de arquitetura
O caminho 2 (memória unificada) é fácil de subestimar. Numa GPU discreta (PC + placa), os pesos vivem na VRAM da placa e qualquer dado que venha da CPU cruza o PCIe — um cano estreito. No Apple Silicon, CPU e GPU compartilham a mesma RAM: zero cópia, a banda inteira alimenta a GPU. Lado a lado:
MEMÓRIA DISCRETA (PCIe no meio) vs UNIFICADA (sem cópia) — por que o M5 Max usa toda a banda
08 · Outra alavanca interativa: menos ativos = mais tok/s
A primeira calculadora (seção 02) mexeu na banda. Esta mexe na outra alavanca: os parâmetros ativos por token. Mantendo a banda fixa em 614 GB/s e a precisão em 2 bytes/param, arraste os B ativos e veja os tok/s recalcularem — e o anel de experts acender mais ou menos. É a intuição do MoE: menos acende, mais rápido fica.
Preveja antes de arrastar
Um modelo denso de 70 B (todos os 70 B acendem por token) na mesma banda de 614 GB/s a 2 B/param. Ele fica na faixa "vivo" (≥5 tok/s) ou no "cimento molhado"?
≈ 4,4 tok/s → "cimento molhado". 614 ÷ (70 × 2) ≈ 4,4. É abaixo do piso de 5 tok/s — por isso ninguém roda um denso de 70 B em FP16 num laptop. O DS4 escapa porque só ~13 B acendem (MoE): 614 ÷ (13 × 2) ≈ 24 tok/s. Se você chutou "vivo", subestimou o custo de ler 70 B inteiros por token. Arraste o slider até 70 para ver a barra entrar no vermelho.
09 · O bilhete de uma decode (a linha do tempo)
Para fechar a intuição, olhe dentro de um único passo de decode. A maior parte do relógio não é cálculo — é a GPU esperando os bytes dos pesos chegarem pela memória. Esta linha do tempo mostra, em proporção, onde o tempo de um token realmente vai:
UM PASSO DE DECODE · ~42 ms no M5 Max · a leitura domina, o cálculo é um respingo
10 · Faça as contas (passo a passo → agora você)
Você já viu a fórmula girar nas calculadoras. Agora faça o cálculo na mão, devagar, com o caso de referência — depois um exercício é seu. Recuperar o procedimento (não só ver o resultado) é o que fixa.
Exemplo resolvido · tok/s do DS4 no M5 Max (teto de decode, piso conservador)
1
Pegue os params ativos. O DS4 é MoE: dos 284 B totais, ~13 B acendem por token. É só essa fração que a banda precisa alimentar a cada passo.
2
Converta params → bytes/token. No piso conservador de 2 bytes/param (FP16): 13 B × 2 B = 26 GB lidos por token.
3
Divida a banda pelos bytes.tok/s ≈ banda ÷ bytes/token = 614 GB/s ÷ 26 GB ≈ 23,6 tok/s. Esse é o teto pessimista.
4
Compare com o medido. A medição real é 25–34 tok/s (≈33,9). Acima do teto pessimista? Sim — porque os experts em ~2 bits leem bem menos que 26 GB (ver seção 05). O piso de 2 B é só a baliza inferior.
→
Agora você: um mini-PC com 256 GB/s rodando o mesmo DS4 (13 B ativos, 2 B/param). Quantos tok/s no teto pessimista? Faça antes de revelar.
256 ÷ (13 × 2) = 256 ÷ 26 ≈ 9,8 tok/s. Ainda "vivo" (acima de 5) — mas ~2,4× mais lento que o M5 Max, exatamente a razão das bandas (614÷256 ≈ 2,4). É o "cano fino vs cano grosso" da seção 01 em números. Dica: note que o procedimento é sempre o mesmo — só trocam os três números.
Fixe os conceitos (flashcards)
Clique pra virar. Tente lembrar a resposta antes de virar — recuperação ativa fixa mais que reler.
Fórmula
Qual a conta do teto de decode?
clique pra virar ↻
Resposta
tok/s ≈ banda (GB/s) ÷ bytes-ativos-por-token. Ex.: 614 ÷ (13 B × 2 B) ≈ 24 tok/s.
Fases
Prefill vs decode: quem é o gargalo?
clique pra virar ↻
Resposta
Prefill = compute-bound (FLOPs, prompt em paralelo). Decode = bandwidth-bound (relê pesos por token).
MoE
Por que 284 B roda como modelo pequeno?
clique pra virar ↻
Resposta
Só ~13 B acendem por token (4,6%). A banda alimenta só a fração acesa → velocidade de um modelo de 13 B.
Alavancas
As duas únicas formas de subir tok/s?
clique pra virar ↻
Resposta
↑ banda (numerador) ou ↓ bytes/token (quantizar + MoE de poucos ativos). Tudo o mais é variação disso.
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 tamanho parecido de propósito — sem pista pela forma.
1. Numa geração "prompt curto → resposta longa", qual recurso domina a velocidade?
Correto: b — decode é bandwidth-bound: cada token relê os pesos ativos da RAM. a falha porque os FLOPs ficam ociosos esperando os bytes chegarem (eles mandam no prefill, não na decode). c está errado: os pesos já estão na RAM, não no SSD — disco só conta no carregamento inicial. d confunde agendamento com o gargalo físico de mover bytes.
2. Por que o M5 Max (460–614 GB/s) roda um modelo de 284 B a 25–34 tok/s?
Correto: c — few-active MoE: ~13 B de 284 B por token, então a banda só alimenta 4,6% do modelo. a é falso (284 B é enorme — só "cabe rápido" pelo MoE). b repete o erro do SSD: pesos vivem na RAM. d inventa uma descompressão em tempo real que não existe; o que existe é menos pesos acesos, não os 284 B inteiros.
3. Você dobra a banda de memória e não mexe nos FLOPs. O que acontece com a decode?
Correto: a — como tok/s ≈ banda ÷ bytes/token, dobrar o numerador quase dobra os tok/s. b é a armadilha dos FLOPs (eles já sobram na decode). c inventa um efeito de throttling que não é a regra. d está invertido: é o prefill que mal mudaria (compute-bound); a decode é justamente quem ganha com mais banda.
💬 Travou em algo? Eu sou seu professor neste curso — pergunte. "Por que prefill é compute-bound e decode bandwidth-bound?", "Como meço a banda real do meu Mac?", "Se eu somar o M4 Max de 36 GB via Thunderbolt, a banda agregada ajuda?". É só dizer.