Una receta en lugar de los pesos de un LLM: el intento de convertir 16 GB de matrices en fórmulas

Un modelo de 8000 millones de parámetros en fp16 pesa unos 16 GB: ocho mil millones de números de dos bytes cada uno. La versión de 70 000 millones ya llega a los 140 GB. La cuantización a 4 bits reduce un modelo de 8B a entre 4 y 5 GB, pero siguen siendo las mismas matrices, solo que con menos precisión. Habr AI ha publicado un análisis de una idea más radical: almacenar no los pesos en sí, sino una pequeña receta con la que se pueden calcular.

El anuncio del artículo menciona varias familias de estos métodos. Los detalles de implementación y los benchmarks solo figuran en el artículo completo del autor, así que a continuación se describen los enfoques en sí y sus limitaciones conocidas.

Una red que dibuja otra red

La variante más conocida son las hiperredes. La idea se describió en el trabajo HyperNetworks, de 2016: una red pequeña recibe como entrada, por ejemplo, el número de capa y un vector entrenable, y devuelve como salida los pesos de la red grande. Solo hace falta almacenar el generador y un conjunto de vectores cortos.

El enfoque tiene un coste evidente. El generador produce pesos de una familia estrecha, y si la tarea real requiere matrices «incómodas», la precisión cae. El entrenamiento también se complica: el gradiente atraviesa dos niveles de redes en lugar de uno.

Fórmulas y fractales

La segunda rama son las descripciones analíticas. Si los pesos de una capa se ajustan bien a una función suave, basta con guardar sus coeficientes y calcular los valores a partir de las coordenadas de cada elemento de la matriz. Así funcionan las representaciones neuronales implícitas, por ejemplo SIREN para imágenes y NeRF para escenas.

La idea fractal viene de la compresión de imágenes de finales de los años 80. Los bloques de datos se describen como copias transformadas de otros bloques, y en lugar de un array se guarda un conjunto de reglas de autosemejanza. En el caso de los pesos, esto es posible mientras haya una estructura repetitiva. Los LLM entrenados distan mucho de mostrarla siempre.

Los métodos con generadores de números pseudoaleatorios siguen una lógica parecida. En el trabajo SeedLM, de 2024, un bloque de pesos se aproxima con una combinación de una secuencia generada a partir de una semilla corta (seed) y unos pocos coeficientes. Se guarda la semilla y el resto se recalcula al cargar el modelo.

Qué precio hay que pagar

En este campo, la compacidad casi nunca sale gratis. Los compromisos generales son estos:

• Memoria frente a cómputo. Los pesos no se leen de la memoria, sino que se generan, y eso añade operaciones en cada capa.
• Precisión. Toda aproximación introduce un error, y los errores se acumulan a lo largo de la profundidad del modelo.
• Entrenamiento. O bien el modelo se entrena directamente en la parametrización comprimida, o bien se comprime después del entrenamiento; en este segundo caso, la calidad depende de las propiedades de los pesos concretos.
• Hardware. Las GPU están optimizadas para multiplicar matrices densas. Una generación de pesos no estándar sobre la marcha puede anular la ganancia en memoria.

El autor del artículo compara el camino de los LLM con el de Doom, el original, que se ha ejecutado en calculadoras, impresoras y otros aparatos electrónicos domésticos. Por ahora, el LLM no corre en cada hervidor: incluso un modelo muy comprimido choca con el ancho de banda de la memoria, y no únicamente con su capacidad.

Conclusión práctica

Para los ingenieros que despliegan modelos en dispositivos, la compresión mediante recetas sigue siendo una línea de investigación. En producción siguen funcionando la cuantización, los adaptadores LoRA y la destilación. Conviene seguir de cerca las hiperredes y los métodos basados en semillas si el problema es el tamaño de la distribución: en aplicaciones móviles, inferencia en el navegador y sistemas embebidos, incluso un ahorro de dos veces en almacenamiento decide si el modelo puede ejecutarse o no. Antes de adoptar cualquiera de estos métodos, hay que comprobar tres cosas: la pérdida de calidad en las tareas propias, la latencia en el hardware de destino y la complejidad del reentrenamiento.