Prefill vs decode: duas máquinas diferentes

01 · Conceito

Conceito

Sirva o Qwen3.8-27B e observe os tempos: um prompt de 8.192 tokens é absorvido no tempo de ler esta oração, e então a resposta escorre token a token. Mesmos pesos, mesma GPU — e ainda assim as duas fases rodam a velocidades separadas por ordens de magnitude. Elas são, na prática, duas máquinas diferentes. O prefill processa o prompt e cria estado; o decode consome esse estado um token por vez.

Durante o prefill, todas as posições do prompt atravessam a rede juntas. As camadas lineares multiplicam pesos por matrizes de ativação com uma dimensão de tokens na casa dos milhares; as 16 camadas de attention computam interações entre posições do prompt e escrevem keys e values, enquanto as 48 camadas de Gated DeltaNet condensam o prompt em seus estados recorrentes. Aceleradores adoram esse formato — paralelismo através de tokens, heads e entradas do batch — e prompts longos podem chegar perto do teto aritmético do hardware. A saída do prefill são os logits do primeiro token mais o estado populado, e é por isso que o comprimento do prompt e a eficiência dos kernels dominam o time to first token.

O decode apresenta o formato oposto: uma posição nova por sequência ativa por passo, através de todas as camadas.

Aqui está o desvio que a maioria toma quando o decode parece lento: supor que a GPU ficou sem aritmética e correr atrás de mais FLOPs. Rode as contas em vez disso. Para uma matriz de pesos com $P$ parâmetros em bf16 (2 bytes cada), processar $n$ tokens custa cerca de $2nP$ operações contra pelo menos $2P$ bytes de tráfego de pesos, então a intensidade aritmética é

O prefill com $n = 8{,}192$ posições de prompt realiza aproximadamente 8.192 operações úteis para cada byte de peso que busca. O decode em batch 1 tem $n = 1$: cerca de uma operação por byte. E os bytes são substanciais — os pesos em bf16 do Qwen3.8-27B somam cerca de 54 GB, essencialmente todos precisando fluir da memória a cada passo de decode. Uma operação por byte está muito abaixo do que qualquer acelerador moderno precisa para manter suas unidades aritméticas ocupadas, então o passo é limitado por banda de memória, não por compute. Acrescentar FLOPs não mudaria nada; o modelo roofline (Williams et al.) torna isso preciso, e a lição 9.1 usa o checkpoint de 54 GB como heurística de taxa de ordem de grandeza e explica por que um roofline exato exige bytes ativos medidos. A correção, e não o palpite ingênuo, explica por que os remédios do decode são todos sobre bytes: pesos quantizados, batching para reaproveitar cada leitura de peso entre sequências, speculative decoding para verificar vários tokens por leitura.

O segundo fluxo de tráfego do decode é o estado, e aqui o layout híbrido do Qwen3.8-27B muda o quadro clássico. Num modelo uniforme de attention, toda camada lê um histórico de KV que cresce com o contexto, então o decode fica progressivamente mais caro por token. Neste modelo só as 16 camadas de full attention fazem isso, lendo um cache que cresce aos 64 KiB por token derivados na lição 7.2 — ilustrativamente, a 100.000 tokens em cache essas camadas transmitem cerca de 6 GiB de K/V por passo. As 48 camadas de DeltaNet, em vez disso, leem e atualizam estados matriciais de tamanho fixo somando 144 MiB na referência em float32, os mesmos no token dez e no token 200.000. Três quartos da profundidade contribuem com tráfego constante de decode, então o custo cresce com o contexto muito mais devagar do que a contagem de camadas sozinha sugeriria — esse achatamento é exatamente o que a arquitetura comprou.

O batching remodela os dois regimes. Sequências independentes decodificadas juntas compartilham cada leitura de peso, multiplicando o trabalho útil por byte; é por isso que o $n$ na fórmula de intensidade é, na verdade, tokens em voo, não apenas o comprimento do prompt. Mas batches não são de graça: esperar para formar um eleva a latência de fila, sequências terminam em momentos diferentes, e o continuous batching (lição 7.8) troca um retângulo estático por um conjunto móvel de passos de token que o scheduler precisa manter justo.

As fases também interferem uma na outra. Um prefill grande monopoliza compute e banda exatamente quando requisições em decode precisam de sua cadência estável; o chunked prefill intercala pedaços de prompt entre passos de decode, e algumas implantações desagregam as fases em workers separados, pagando custos de transferência de KV para evitar a contenção.

As métricas devem respeitar essa divisão: registre queue time, duração do prefill e vazão de prompt separadamente do tempo de passo do decode e da vazão de saída, em percentis por comprimento de prompt e concorrência. Médias agregadas escondem alegremente um scheduler que alimenta jobs em lote enquanto deixa usuários interativos passando fome.

O modelo mental durável: um processador paralelo de prompt entrega estado a um motor de tokens sensível à latência que sobretudo move memória. Tudo no resto desta track — attention ciente de IO, caches paginados, quantização, speculative decoding — é um ataque a um dos dois lados dessa fronteira.