Capítulo 6 — Poda e Destilação de Conhecimento

Sexto post do passeio capítulo a capítulo pelo LLM Primer VI: Escalando Sistemas de IA. O capítulo que ataca diretamente a contagem de pesos — primeiro zerando aqueles que não importam, depois transferindo o comportamento de um modelo grande para um menor.

Por que este capítulo existe

A quantização encolhe os bytes por peso. A poda encolhe a contagem de pesos que são de fato multiplicados. A destilação de conhecimento transfere o comportamento de um professor grande para um aluno menor que roda mais barato de ponta a ponta. A poda é uma edição na mesma arquitetura que apara custos; a destilação é uma mudança de arquitetura que aceita um custo em tempo de treino em troca de uma economia permanente em tempo de inferência. O Capítulo 6 percorre as duas — a mecânica de cada uma, os modos de falha que os praticantes encontram, e o padrão acelerado por hardware (esparsidade 2:4) que voltou a tornar a poda estruturada economicamente interessante em Hopper e Blackwell.

6.1 Esparsidade 2:4 é o padrão de poda que o hardware recompensa

Poda por magnitude não estruturada — zerar os 50% menores dos pesos e refinar por um breve fine-tune — funciona numericamente, mas não acelera. GPUs executam GEMMs densos; zeros dispersos continuam sendo multiplicados. A poda estruturada remove unidades inteiras que o hardware pode pular: cabeças de atenção, neurônios de MLP, ou (o caso importante) padrões N:M dentro das matrizes de peso. Hopper e Blackwell suportam esparsidade 2:4 nativamente — exatamente dois zeros a cada quatro pesos consecutivos ao longo da dimensão de entrada. O chip armazena cada grupo de quatro pesos como dois valores não-zero mais uma máscara de dois bits, o sparse tensor core pula as multiplicações por zero, e tanto a largura de banda quanto os FLOPs caem por aproximadamente um fator de dois. No throughput medido de decodificação, isso vira uma aceleração de 1,7 a 1,9 vezes. O truque é que 2:4 precisa ser imposto durante a poda: o algoritmo percorre cada matriz em grupos de quatro e força os dois menores a zero, e então ou faz um breve fine-tune ou aplica SparseGPT para compensar. A máscara é metadado; a economia no runtime é automática.

6.2 A destilação transfere a distribuição do professor, não o seu argmax

Um LLM professor treinado produz em cada posição uma distribuição sobre o vocabulário — um softmax de 128 mil dimensões. O argmax é o token que ele emitiria em decodificação greedy. Mas a distribuição codifica a incerteza do professor, sua estrutura de preferência entre quase-sinônimos e sua calibração. Treinar um aluno para casar com essa distribuição transfere tudo isso: a perda é uma divergência KL entre saídas suavizadas do professor e do aluno, com uma temperatura que alarga o sinal de gradiente para a cauda de baixa probabilidade. O aluno que emerge se comporta como uma versão menor e mais rápida do professor, e não como um modelo menor treinado do zero sobre os mesmos dados. Patient Knowledge Distillation estende a receita para camadas intermediárias, casando estados ocultos entre pares mapeados aluno-professor. MiniLLM aborda uma falha mais sutil — o problema de mediar entre modos, em que um aluno com KL forward hedgia entre múltiplas continuações plausíveis do professor e produz uma saída sem graça — trocando para KL reverso, que prefere um casamento nítido com um dos modos do professor a uma cobertura suave de todos eles.

6.3 As três compressões se empilham, em uma ordem específica

Destilar primeiro, podar em segundo, quantizar por último. A destilação é a operação mais cara e mais arquiteturalmente invasiva; faz sentido executá-la uma única vez sobre um modelo denso de alta precisão antes que outras escolhas sejam travadas. Depois, podar o aluno para 2:4 com SparseGPT e um breve fine-tune de recuperação. Por fim, quantizar o aluno esparsificado para FP8 com o llm-compressor. Uma pilha trabalhada: professor 70B BF16 → aluno destilado 13B BF16 → esparsificado em 2:4 → quantizado em FP8. Os bytes de peso por forward pass caem de 140 GB para aproximadamente 6,5 GB — uma redução de 22 vezes — e os caminhos FP8 e 2:4 da Hopper transformam isso em um ganho de throughput de 8 a 10 vezes por GPU. O que a pilha não reduz é o KV cache, que depende da dimensão oculta, da contagem de cabeças e do comprimento de contexto, e não da contagem de pesos. Esse é o tema do Capítulo 8. E a compressão em nível de modelo é por inferência; ela dá folga à GPU, mas a alavanca de runtime que preenche essa folga com usuários concorrentes é o batching.

O que o Capítulo 6 prepara

Os Capítulos 5 e 6 esgotam as compressões do lado do modelo — quantizar os bytes por peso, podar a contagem de pesos, destilar o modelo inteiro para uma versão menor. A GPU agora tem folga em cada forward pass. O Capítulo 7 se volta para a alavanca em nível de sistema que preenche essa folga com trabalho útil: o batching. O batching estático quase funciona e colapsa no problema do que termina primeiro. O batching contínuo, com escalonamento em nível de iteração, é o que os motores de produção rodam e o que transforma a fase de decodificação limitada por largura de banda de um chip ocioso em um chip atendendo muitos usuários ao mesmo tempo.

Próximo — Capítulo 7: Estratégias Avançadas de Batching. Batching estático, dinâmico e contínuo — e a dívida que o batching contínuo cria para o KV cache.