Conditional Program comprime la memoria n-gram de DeepSeek de 203 a 51 GB con 2 bits

Las tablas de memoria n-gram dan al modelo de lenguaje capacidad adicional casi sin aumentar el cómputo: por cada token solo se leen unas pocas filas. Pero el precio es el volumen. Para responder a cualquier entrada posible, la tabla entera tiene que estar disponible. Un nuevo trabajo publicado en Hugging Face Daily Papers propone el formato Conditional Program (CP), que almacena las filas con dos bits por código y reconstruye únicamente las que solicita la entrada. En la tabla de DeepSeek, el tamaño baja de 203 a 51 GB, y la divergencia KL de salida resulta un 41–63% menor que con el redondeo ingenuo a 2 bits.

Cómo funciona CP

La idea es no cuantizar la tabla como un tensor monolítico, sino describir cada fila con un registro compacto. Cada fila tiene un código corto y una escala local. El programa que convierte el código de nuevo en vector es el mismo para todas las filas: se guarda una sola vez para toda la tabla y apenas cuesta nada por fila.

Los autores lo implementan con tres componentes. El primero es una retícula gaussiana (trellis), es decir, un codebook estructurado en el que el código elige un camino por la retícula en lugar de una entrada de una lista explícita. El segundo es la restauración de la norma: tras la decodificación, la longitud del vector vuelve a su valor original, de modo que la cuantización no desplace la escala de las activaciones. El tercero son las entradas de fila decodificables de forma independiente. Es un requisito clave para la memoria condicional: para leer una fila no hace falta descomprimir los bloques vecinos.

Ese último punto es justo lo que distingue este problema de la compresión habitual de pesos. En ese caso, la decodificación se hace por lotes y capa a capa. Aquí el acceso es aleatorio y poco frecuente, y el formato debe soportar acceso arbitrario.

Qué muestran las mediciones

Los autores analizaron tres familias entrenadas de memoria n-gram. La conclusión es doble. La estadística de las coordenadas individuales se aproxima a una gaussiana, por lo que la retícula gaussiana resulta adecuada. Al mismo tiempo, entre las filas persisten relaciones aprendidas que no se pueden tratar como ruido. Aun así, con el mismo presupuesto de almacenamiento, la retícula común superó tanto a los codebooks ajustados a los datos como a las variantes con corrección de bajo rango (low-rank residual) que probaron los autores.

Cifras clave del resumen:

• código: 2 bits por elemento más una escala local por fila;
• KL de salida un 41–63% menor respecto al round-to-nearest de 2 bits;
• tabla de DeepSeek: 203 GB → 51 GB, es decir, unas 4 veces menos;
• formato: programa de reconstrucción común y entradas de fila independientes;
• validación en tres familias de n-gram memory entrenadas.

Conviene detenerse en la mejora de cuatro veces. Si la tabla original se almacena en 16 bits, 2 bits netos darían una compresión de ocho veces. El resumen no explica de dónde viene la diferencia. La sobrecarga de las escalas y de los registros de fila puede ser parte de la explicación, pero hay que comprobarlo en el texto completo del artículo.

En la práctica: a dónde va la memoria liberada

El principal efecto práctico lo formula el propio trabajo: cuando la tabla reside en la GPU, los gigabytes liberados pueden destinarse a cargas mayores. Eso significa más contexto, más peticiones simultáneas y lotes (batch) más grandes. La memoria de la tarjeta gráfica casi siempre se topa con el KV-cache, y los 150 GB que se ahorran en la tabla se convierten directamente en margen para él.

Para los equipos que despliegan modelos con memoria condicional hay otra ventaja. Es más fácil mantener una tabla de 51 GB entera en el acelerador que una de 203 GB, y así no hace falta sacarla a la memoria del host, con la latencia que supone en cada acceso. Esto elimina uno de los principales argumentos en contra de la memoria n-gram en producción.

También hay que ser prudentes. La métrica de calidad del resumen es la KL de la distribución de salida, no un conjunto de benchmarks por tareas. Antes de incorporar CP a un stack de inferencia, hay que ver cómo se comporta la tabla de 2 bits en tareas reales y cuánto cuesta decodificar una fila en la GPU bajo carga alta. Pero la dirección está clara: la memoria condicional ya tiene una forma de pagar por su capacidad no en terabytes, sino en decenas de gigabytes.