Hoy vamos a mirar a algunas de las técnicas que se usan para reducir los tamaños de los grandes modelos de lenguaje (LLMs). Esto es importante porque, a medida que la Inteligencia Artificial (IA) avanza, queremos hacerlos disponibles en dispositivos móbiles (teléfonos, tabletas, automóbiles, etc). Además, algunos de estos modelos se ofrecen como código abierto, y, por razones de privacidad, queremos tenerlos instalados localmente en servidores empresariales, hospitales, y aún en computadores caseros. Y para eso se requieren LLMs de tamaños moderadamente pequeños, que puedan ejecutarse en hardware con especificaciones limitadas, pero sin que pierdan la precisión y efectividad de los LLMs originales.
Enlace al artículo científico reciente, para aquellos interesados en profundizar sobre el tema: "A Survey of Low-bit Large Language Models: Basics, Systems, and Algorithms", por Ruihao Gong y colegas. Publicado el 12 de Noviembre del 2025.
El resumen, la transcripción, y la traducción fueron hechas usando herramientas de software de Inteligencia Artificial.
El resume se presenta en la forma de un diálogo entre dos personajes sintéticos que llamaremos Alicia y Beto.
Resumen
Beto
Bienvenidos a un nuevo análisis profundo. Hoy abordamos uno de los desafíos más prácticos en IA hoy en día: la accesibilidad. Quiero decir, ¿cómo llevas estos modelos de lenguaje enormes (LLMs), los que necesitan granjas enteras de servidores, y los comprimes, los reduces para que puedan ejecutarse de forma eficiente en, bueno, casi cualquier cosa: un servidor normal, quizá incluso tu teléfono?
Alicia
Es un enorme problema de ingeniería, y la respuesta en la práctica es un campo llamado "cuantización en bajos bits" ("low-bit quantization"). En esencia, es un tipo muy especializado de compresión de datos. Básicamente reducimos el ancho de bits de todos los números dentro del modelo: los pesos, las activaciones, y al hacerlo reduces la huella de memoria y bajas la demanda computacional. No se trata solo de ahorrar espacio; se trata de hacer que esto sea realmente desplegable.
Beto
Bien. Nuestra misión hoy, para quienes nos escuchan, es desempacar la ciencia aquí. Vamos más allá de simplemente hacer los archivos más pequeños. Miramos los "trade-offs" (compromisos, compensaciones) complejos. Es una batalla constante, ¿no?, entre encoger el modelo y conservar su precisión original. Vale, vamos a desglosarlo. Empezando por lo básico: los formatos de datos. Cuando hablamos de quitar bits, ¿cuáles son las principales categorías con las que lidiamos ahora?
Alicia
Podemos empezar con los formatos de "punto flotante" ("floating point"), lo que llamamos FP-{algo}. FP16, es decir 16 bits, ya es bastante estándar, pero para estos modelos enormes la decisión real es cómo usas esos 16 bits. Eso lleva a este clásico compromiso: siempre es precisión versus rango.
Beto
Ahí está el debate FP16 versus BF16 ("Brain Floating Point"). ¿Cuál es el compromiso? ¿Qué crea realmente esa asignación de bits en el mundo real?
Alicia
Todo depende de tus prioridades. El estándar más antiguo, FP16, pone más de sus bits en la mantisa.
Beto
Esa es la parte que maneja los puntos decimales, ¿no? Para la precisión.
Alicia
Exacto: la precisión fraccionaria. Tiene intervalos de datos muy finos. Es muy preciso.
Beto
La resolución final, podrías decirlo así.
Alicia
Perfecta manera de decirlo.
Pero luego tienes BF16 o bfloat16. Fue diseñado para imitar el rango del formato de 32 bits, FP32. Lo consigue asignando más bits al exponente. Esto significa que BF16 puede representar números absolutamente enormes, que es algo que ves todo el tiempo en el entrenamiento de LLM. La trampa: sacrificas bits de mantisa, así que los puntos de datos quedan más dispersos —rango enorme, pero menos precisión dentro de ese rango.
Beto
Con BF16 tienes menos probabilidad de errores por números que se vuelven demasiado grandes o pequeños, incluso si pierdes un poco de esa finura en la precisión. Suena como un compromiso que hay que hacer para un modelo con miles de millones de parámetros.
Alicia
Lo es.
Más allá del punto flotante, llegas a la "cuantización entera". Cosas como INT4 o INT8. Ahí es donde mapeas los valores de punto flotante a enteros discretos. En el extremo más extremo tienes "números binarizados": solo -1 y 1 o 0 y 1, lo cual es una compresión increíble, pero por lo general demasiado agresivo para la precisión que necesita un LM.
Beto
Y aquí es donde se vuelve personalizado, ¿no? La gente se dio cuenta de que los formatos estándar no encajaban perfectamente, lo que llevó a cosas como "normal float" y "student float".
Alicia
Exacto. "Normal Float", o NF, está diseñado principalmente para cuantizar los pesos. Surgió de la observación de que los parámetros de los LLM tienden a seguir una distribución normal estándar, una campana. Así que normal float optimiza sus puntos de cuantización para capturar tanta información como sea posible de esa forma específica.
Beto
Y "student float" es una mejora sobre eso. ¿Por qué?
Alicia
"Student Float", o SF, se basa en una intuición un poco más profunda: los parámetros de estos modelos enormes no siguen una campana perfecta. A menudo tienen colas más largas y gordas. Una "Distribución-t de Student" modela eso mejor. Al adaptar los puntos de cuantización a esa distribución específica, SF obtiene un ajuste más limpio. Menos error. Es una solución a medida para un problema a medida.
Beto
De acuerdo, una vez que has elegido un formato — digamos INT4 — ¿cómo decides qué partes del modelo se comprimen de esa manera? Ahí entra la idea de granularidad.
Alicia
Sí, granularidad. Simplemente dicta qué tamaño de bloque comparte un único factor de escala. Y esta elección es una negociación directa entre complejidad computacional y la cantidad de error que puedes tolerar.
Beto
¿Cómo es el espectro?
Alicia
El extremo más grueso es "por tensor": un único factor de escala para todo el tensor. Es rápido, pero puede perjudicar mucho el rendimiento si los valores dentro de ese tensor varían mucho, algo que en un LLM ocurre con frecuencia. Para reducir ese error te vas a opciones más finas: por canal, que usa un factor de escala por canal de salida.
-
NOTA: "Tensor" es una matriz de datos numéricos multi-dimensional. Se usa para almacenar los pesos y sesgos, que son los valores resultantes al entrenar una red neuronal.
Beto
Y adivino que para la parte generativa, las activaciones, tienes que ser aún más cuidadoso.
Alicia
Exacto. Para activaciones de LLM a menudo usamos "por token": cada palabra o sub-palabra tiene su propio factor de escala.
Pero el punto óptimo ahora mismo, lo que equilibra los compromisos, probablemente sea la cuantización "por grupos". Agrupas, quizá 32 o 64 canales juntos, y das un factor de escala a ese pequeño grupo. Es mucho más preciso que por tensor sin todo el costo general de "por token".
Beto
Hablemos de estrategia: dinámica versus estática. Se trata de cuándo se calcula ese factor de escala.
Alicia
Correcto. En la "cuantización dinámica", los pesos se comprimen y almacenan de antemano. Pero los factores de escala de las activaciones se calculan en tiempo real, sobre la marcha, basándose en los datos de entrada que fluyen. Esto es genial para minimizar el error, pero ese cálculo añade sobrecarga durante la inferencia.
Beto
Y la estática es lo opuesto.
Alicia
Con la "cuantización estática" usas un conjunto de datos de calibración por adelantado para fijar todos los factores de escala tanto de pesos como de activaciones. Una versión muy popular de esto es la "cuantización solo de pesos" ("weight-only quantization"). La verás en algoritmos como AWQ o GPTQ. Aquí solo se cuantizan los pesos; las activaciones se dejan en su formato de alta precisión.
Beto
¿Por qué es eso tan popular? Quiero decir, solo comprimes la mitad de la ecuación.
Alicia
Porque todo gira en torno a la latencia en producción. Durante la inferencia, ese peso comprimido se des-cuantiza, vuelve a punto flotante justo antes del cálculo matricial. Y el ahorro de memoria que obtienes al encoger esos enormes tensores de pesos —que conforman como el 99 % del tamaño del modelo — compensa con creces el pequeño coste de ese paso de des-cuantización.
Beto
Y eso nos lleva a lo que creo que es la parte más contraintuitiva de todo esto. Uno supondría que menos bits, datos más pequeños, matemáticas más rápidas. Pero no siempre es más rápido, ¿verdad? Aquí es donde se pone realmente interesante. La aceleración real suele venir por la memoria, no solo por el cómputo.
Alicia
Ese es la visión central. El cuello de botella más grande no es la operación matemática final; es mover los datos. Llevar esos miles de millones de parámetros a la GPU en primer lugar es el atasco.
Beto
¿Puedes guiarnos por ese cuello de botella? Quizá con un ejemplo, como una GPU Nvidia A100?
Alicia
Claro. Piénsalo como un sistema de autopistas con distintos límites de velocidad. Mover los pesos desde la memoria principal del host, que está fuera del chip y es muy lenta, quizá 25 gigabytes por segundo, hacia la memoria global del dispositivo en la GPU, eso es lo más lento. Una vez que los datos están en el chip, moverlos a la memoria compartida, que es mucho más rápida, quizá 1.500 gigabytes por segundo, y luego a los registros ultrarrápidos es astronómicamente rápido.
Beto
Así que quedamos atascados justo al principio, trayendo los datos del host al dispositivo.
Alicia
Exacto. Y la cuantización ayuda porque tienes los pesos pre-cuantizados y empaquetados en un formato pequeño por adelantado. Eso reduce masivamente la cantidad de datos que tienes que forzar por ese primer conducto lento. Así que con la "cuantización solo de pesos" ahorras mucho tiempo en esa transferencia de datos y eso paga más que el pequeño tiempo que pasas des-cuantizando al otro lado.
Beto
Eso explica la aceleración de solo pesos.
Pero si cuantizas tanto pesos como activaciones, ahí es donde obtienes la verdadera ganancia computacional.
Alicia
Sí. Porque cuando ambos están en formato de bajo bit, las propias operaciones matemáticas se vuelven más rápidas. Puedes usar kernels especializados de bajo bit para multiplicación de matrices. Son instrucciones de hardware dedicadas, como para operaciones en INT4 o INT8. Pero —y esto es un gran pero— la aceleración solo sucede si tu hardware específico soporta esas instrucciones.
Beto
Antes de seguir, tenemos que mencionar la "caché de claves y valores", el "KV cache", otro enorme problema de memoria para los LLM.
Alicia
Oh, absolutamente crucial. Cuando generas secuencias largas de texto, la memoria usada por esa caché KV puede volverse más grande que el propio modelo. La cuantización del KV cache es vital. Comprimir esa caché te deja generar salidas mucho, mucho más largas sin quedarte sin memoria GPU.
Beto
Vale, vayamos a la frontera real aquí: combinar cuantización con "Ajuste Fino Eficiente en Parámetros" ("Parameter-Efficient Fine-Tuning", PEFT).
Alicia
Aquí es donde ocurre la magia de QLoRA. Primero, LoRA (Low-Rank Adaptation) es una forma de ajustar finamente: congelas el gigantesco modelo preentrenado y solo entrenas unas matrices pequeñas adicionales A y B.
Beto
Así que no tocas los 70 mil millones de parámetros; solo entrenas esas pequeñas tablas laterales.
Alicia
Exacto. Y QLoRA toma eso y le añade otra capa. Cuantiza los enormes pesos del modelo base congelado usando algo como "Normal Float", y entrena esas ya diminutas matrices LoRA en mayor precisión. Esta estrategia es brillante. Te permite ajustar un modelo de 65 mil millones de parámetros en una sola GPU de 48 GB. Eso es acceso increíble.
Beto
Bien, ahora pivotemos al mayor escollo en todo esto, especialmente para la cuantización post-entrenamiento: el problema de los "outliers" (valores atípicos). Son esos pocos valores desmesuradamente grandes que arruinan todo el esquema de compresión. Y la solución se llama "transformación equivalente".
Alicia
Correcto. La idea es: si no puedes cuantizar los datos tal y como están, los transformas matemáticamente primero. Cambias la distribución de los pesos o las activaciones sin alterar la salida final del modelo. Y puedes dividir estas maniobras ingeniosas en tres tipos principales.
Beto
Empecemos por la primera: "transformación por desplazamiento". ¿Qué corrige eso?
Alicia
El "shifting" (desplazamiento), que ves en métodos como OS+ u OmniQuant, va de arreglar valores atípicos asimétricos en los datos de activación. Imagina que tus datos están mayormente agrupados, pero tienes unos pocos puntos muy alejados en un lado. Eso agranda mucho el rango total. El desplazamiento básicamente recentra los datos para hacerlos más simétricos. Al hacer eso reduces el rango que necesitas cuantizar, lo que minimiza el error.
Beto
Y esto no añade trabajo extra en tiempo de ejecución.
Alicia
No, porque ese factor de desplazamiento se puede fusionar matemáticamente en otros parámetros existentes, como la capa de normalización, todo se hace offline.
Beto
Siguiente: "transformación por escalado". Esto suena, como dijiste antes, a pasar la dificultad.
Alicia
Es una buena forma de verlo. Técnicas como SmoothQuant reconocen que las activaciones son inherentemente más difíciles de cuantizar que los pesos: son más volátiles. Así que el escalado es una estrategia de migración. Traslada la dificultad de cuantización de las activaciones problemáticas hacia los pesos, que son más robustos y pueden manejarla mejor.
Beto
SmoothQuant encuentra una fuerza de migración para gestionar esa transferencia.
Alicia
Exacto. Usa un parámetro alpha para hallar el punto óptimo, el balance perfecto. Suaviza las magnitudes y hace que todo el sistema sea más fácil de comprimir.
Beto
Y por último, la "transformación por rotación". Esta parece la más abstracta. ¿Por qué demonios rotarías los datos?
Alicia
Es una bonita intuición de álgebra lineal. La cuantización funciona mejor cuando tus pesos son, por falta de mejor palabra, incoherentes. Así que métodos como QuIP y SpinQuant literalmente realizan una rotación matemática sobre los pesos.
Beto
Es como barajar una baraja para asegurarte de que quede aleatoria antes de repartir.
Alicia
Bueno, más bien se parece a asegurarse de que todas las cajas estén alineadas y orientadas de la misma manera antes de intentar apilarlas eficientemente. La rotación hace que los pesos no estén todos alineados de formas extrañas, lo que nivela sus magnitudes. Y los métodos más avanzados, como SpinQuant, de hecho aprenden la matriz de rotación óptima para obtener el rendimiento más estable.
Beto
Esto ha sido una inmersión realmente profunda. ¿Cuál es la conclusión para nosotros? Parece que hacer estos LLMs accesibles es un acto de equilibrio intrincado. Cada elección, desde la asignación de bits de BF16 hasta la granularidad que eliges o un algoritmo de suavizado complejo, es un compromiso calculado. Estás tratando de maximizar la eficiencia y la accesibilidad perdiendo la menor precisión posible.
Alicia
Y si miras el panorama general, la tendencia está clara: va hacia el co-diseño hardware-cuantización. Estamos viendo modelos y algunas arquitecturas de expertos diseñadas desde cero con la cuantización en mente. Eso nos empuja hacia formatos extremos de bajo bit. Deberías estar pendiente de nuevos estándares de hardware que soporten cosas como FP4, no solo para inferencia, sino quizá algún día incluso para entrenamiento.
Beto
Lo que deja una pregunta importante para que pienses después de esto: si podemos desplegar estos modelos increíblemente complejos en casi cualquier dispositivo, ¿qué nuevas aplicaciones están ahí esperando, retenidas solo por esa última barrera de memoria? Porque el progreso continuo en esto es lo que hará que la utilidad generalizada de la IA sea una realidad.
Entradas
