Capítulo 6 — Pruning y destilación de conocimiento

Sexta entrega del recorrido capítulo por capítulo de LLM Primer VI: Scaling AI Systems. El capítulo que ataca el número de pesos directamente — primero poniendo a cero los pesos que no importan, y luego transfiriendo el comportamiento de un modelo grande a uno más pequeño.

Por qué existe este capítulo

La cuantización reduce los bytes por peso. El pruning reduce el número de pesos que llegan a multiplicarse. La destilación de conocimiento transfiere el comportamiento de un profesor grande a un estudiante más pequeño que corre más barato de punta a punta. El pruning es una edición de misma arquitectura que rebaja el overhead; la destilación es un cambio de arquitectura que acepta un coste en tiempo de entrenamiento a cambio de un ahorro permanente en tiempo de inferencia. El Capítulo 6 recorre ambas — la mecánica en que cada una se apoya, los modos de fallo que la práctica encuentra, y el patrón acelerado por hardware (sparsity 2:4) que ha vuelto a hacer económicamente interesante el pruning estructurado en Hopper y Blackwell.

6.1 La sparsity 2:4 es el patrón de pruning que el hardware recompensa

El pruning de magnitud no estructurado — pon a cero el 50 por ciento más pequeño de los pesos y haz un fine-tune breve — funciona numéricamente pero no acelera. Las GPUs ejecutan GEMMs densos; los ceros dispersos siguen multiplicándose. El pruning estructurado elimina unidades enteras que el hardware puede saltarse: cabezas de atención, neuronas MLP o (el caso importante) patrones N:M dentro de matrices de pesos. Hopper y Blackwell soportan sparsity 2:4 nativamente — exactamente dos ceros por cada cuatro pesos consecutivos a lo largo de la dimensión de entrada. El chip guarda cada grupo de cuatro pesos como dos valores no cero más una máscara de dos bits, el tensor core sparse se salta las multiplicaciones cero, y tanto el ancho de banda como los FLOPs bajan aproximadamente por un factor de dos. En throughput de decoding medido eso es una aceleración de 1,7–1,9×. El truco es que el patrón 2:4 debe imponerse durante el pruning: el algoritmo recorre cada matriz en grupos de cuatro y fuerza a cero los dos más pequeños, y luego o bien hace un fine-tune breve o bien aplica SparseGPT para compensar. La máscara es metadatos; el ahorro en runtime es automático.

6.2 La destilación transfiere la distribución del profesor, no su argmax

Un LLM profesor entrenado produce en cada posición una distribución sobre el vocabulario — un softmax de 128k dimensiones. El argmax es el token que emitiría en decodificación greedy. Pero la distribución codifica la incertidumbre del profesor, su estructura de preferencias entre casi-sinónimos y su calibración. Entrenar a un estudiante para que iguale esa distribución lo transfiere todo: la pérdida es una divergencia KL entre las salidas suavizadas de profesor y estudiante, con una temperatura que abre la señal de gradiente hasta la cola de baja probabilidad. El estudiante que emerge se comporta como una versión más pequeña y rápida del profesor, y no como un modelo pequeño entrenado desde cero sobre los mismos datos. La Destilación de Conocimiento Paciente (PKD) extiende la receta a capas intermedias, casando estados ocultos entre pares de capas profesor-estudiante mapeadas. MiniLLM aborda un fallo más sutil — el problema del promediado de modos, donde un estudiante forward-KL hedgea entre varias continuaciones plausibles del profesor y produce una salida sosa — cambiando a reverse-KL, que prefiere un match agudo con uno de los modos del profesor antes que una cobertura blanda de todos ellos.

6.3 Las tres compresiones se apilan, en un orden específico

Destila primero, prune después, cuantiza al final. La destilación es la operación más cara y arquitectónicamente más invasiva; tiene sentido hacerla una vez sobre un modelo denso de alta precisión antes de que otras elecciones se fijen. Prune el estudiante a 2:4 con SparseGPT y un breve fine-tune de recuperación. Cuantiza el estudiante ya sparsificado a FP8 con llm-compressor. Un stack trabajado: profesor 70B BF16 → estudiante destilado 13B BF16 → sparsificado 2:4 → cuantizado a FP8. Los bytes de pesos por forward pass caen de 140 GB a aproximadamente 6,5 GB — una reducción de 22× — y los caminos FP8 y 2:4 de Hopper convierten eso en una ganancia de throughput de 8–10× por GPU. Lo que el stack no reduce es la caché KV, que depende de la dimensión oculta, el número de cabezas y la longitud de contexto, no del número de pesos. Ese es el tema del Capítulo 8. Y la compresión a nivel de modelo es por-inferencia; da a la GPU margen, pero es el trabajo de batching y gestión de KV de los Capítulos 7 y 8 el que convierte esa baratura en throughput de usuarios concurrentes.

Lo que prepara el Capítulo 6

Los Capítulos 5 y 6 agotan las compresiones del lado del modelo — cuantiza los bytes por peso, prune el número de pesos, destila el modelo entero hacia abajo. La GPU tiene ahora margen en cada forward pass. El Capítulo 7 pasa a la palanca a nivel de sistema que llena ese margen con trabajo útil: el batching. El batching estático casi funciona y colapsa en el problema del que termina primero. El batching continuo, con scheduling a nivel de iteración, es lo que corren los motores de producción y lo que convierte la fase de decoding limitada por ancho de banda de un chip ocioso en un chip que sirve muchos usuarios concurrentemente.

Próximamente — Capítulo 7: Estrategias de batching avanzadas. Batching estático, dinámico y continuo — y la deuda que el batching continuo crea para la caché KV.