Multiverse Computing publicou uma receita de distillation esta semana que quebra o gargalo do cluster de duas GPUs: cachear os top-100 logits do teacher uma vez offline, trocar por uma fused chunked KL loss, e executar recuperação de distillation de longo contexto em uma única H200 em vez de um rack. O paper, co-lançado na Hugging Face, visa equipes comprimindo modelos de pesos abertos como Qwen, GLM, ou Kimi — onde o teacher pesa 2.8 trilhões de parâmetros e exige 3 TB de VRAM apenas para carregar.
O driver de custo é direto de articular, porém ruinoso na prática. A distillation online padrão mantém tanto teacher quanto student na memória GPU simultaneamente. A cada passo de treinamento o teacher executa um forward pass completo e produz uma distribuição de probabilidade através de seu vocabulário inteiro. Para gpt-oss-120b com tamanho de vocabulário 201.088, comprimento de sequência 32K, e batch size 4, esse tensor de probabilidade do teacher é aproximadamente 50 GB em bfloat16 antes de um único gradiente computar. Adicione pesos do student, ativações, estados do otimizador, e o pico de memória por passo atinge cerca de 250 GB — bem acima do limite de 141 GB de um H200 ou B200.
O primeiro fix é distillation offline. Execute o teacher uma vez, cachear os top-100 tokens mais prováveis por posição de sequência, armazenar esses logits em disco, então evictar o teacher da memória GPU completamente. O student treina contra o cache indefinidamente. O mesmo cache é reutilizável através de ablations: trocar arquiteturas de student, taxas de aprendizado, ou comprimentos de sequência não mais requer executar um modelo com trilhões de parâmetros.
O segundo fix é a fused chunked KL loss. O paper faz benchmark de três formulações matematicamente equivalentes. Dense KL expande os cached top-100 teacher logits em uma grade de tamanho de vocabulário completo e compara contra a grade de log-probabilidade igualmente densa do student, mantendo dois tensores vocab × sequence completos na memória simultaneamente. Forward-chunked KL mantém o teacher sparse e calcula a loss em um slice de sequência de cada vez, eliminando o tensor teacher denso e alcançando o throughput mais rápido; a responsabilidade é que a grade de logits completa do student se materializa para o backward pass, então memória ainda escala com comprimento de sequência. A fused chunked KL vai além fundindo a projeção de output diretamente no loop de loss. Nunca constrói o tensor de logits completo do student: projeta hidden states para logits para um chunk, dobra o resultado no acumulador de loss em execução, descarta o chunk, e continua. O backward pass recomputa cada chunk on-the-fly em vez de armazená-lo. O trade-off é FLOPs adicionais para recomputação; o ganho é pico VRAM cai de aproximadamente 250 GB para 128 GB.
Essa figura de 128 GB é significativa: se encaixa dentro de um único H200 com espaço para pesos de modelo student, removendo a exigência de tensor parallelism multi-nó. Isso torna long-context healing runs — fine-tuning de um student comprimido para recuperar capacidades em comprimentos de sequência estendidos — prático em infraestrutura single-GPU pela primeira vez.
Para arquitetos avaliando isso, a superfície de integração é estreita. Nenhuma mudança requer modificar arquitetura de modelo. O cache offline é um passo de preprocessing contra qualquer checkpoint de teacher. A fused chunked loss é uma drop-in replacement para o termo KL em qualquer loop de distillation training padrão. Multiverse Computing produziu Hypernova 60B usando esse pipeline; Nvidia's Nemotron 3 Puzzle 75B usou compressão comparável. Ambos os modelos mostram a trajetória de produção: começar com um teacher de frontier, distillar para tamanho deployable, recuperar qualidade através de treinamento multi-ablation barato.
A restrição que permanece é a aproximação top-K. Cachear apenas 100 logits por posição descarta a cauda da distribuição do teacher. Para a maioria dos tokens — distribuições peaked de alta confiança — isso importa pouco. Para posições ambíguas onde o teacher espalha massa de probabilidade através de centenas de candidatos, um cache top-100 é lossy. Equipes comprimindo modelos para domínios estreitos onde tail tokens carregam peso semântico devem validar qualidade de recuperação em seus conjuntos eval específicos antes de se comprometer à produção.