Qué ahorra la cuantización a cuatro bits y qué cambia

El mismo nombre de modelo puede aparecer en una descarga de más de quince GiB y en otra de menos de cinco. «Cuatro bits» explica el cambio de representación de los pesos, pero deja abiertas las preguntas de despliegue: ¿qué ocurre con el coste de la GPU, la calidad, la velocidad y la cantidad de peticiones que admite el servicio?

Cuantizar los pesos puede hacer viable la ejecución local y dejar memoria para más peticiones activas. Sin embargo, cambia la representación numérica y su beneficio depende del método de conversión y de la ruta de ejecución. Conviene separar número de parámetros, precisión de los pesos y memoria total del servicio. La guía de modelos de lenguaje conecta archivos concretos con programas compatibles y supuestos de memoria.

Qué cambia al pasar los pesos a cuatro bits

Los pesos son valores numéricos aprendidos. Los checkpoints habituales pueden almacenarlos en BF16 o FP16, con dieciséis bits por valor. La cuantización transforma un conjunto amplio de valores posibles en una representación menor. Cuatro bits permiten dieciséis códigos; escalas y, en ocasiones, otros metadatos determinan qué representa cada código dentro de un grupo de pesos. La guía de cuantización de Transformers explica esa distinción entre código y valor reconstruido.

Se parece a medir piezas con un instrumento menos preciso: dos medidas próximas pueden volverse indistinguibles. La diferencia importa cuando cambia el producto terminado. Los métodos de cuantización intentan distribuir el error de aproximación para reducir su efecto sobre el comportamiento útil del modelo; no todos consisten en redondear uniformemente cada peso.

La cuantización habitual conserva las capas y el número de parámetros. Un modelo de 8B sigue teniendo ocho mil millones de parámetros. La poda y la destilación son otras intervenciones. Expandir un peso cuantizado a un contenedor de dieciséis bits tampoco recupera la información perdida; para comparar con el original hace falta el checkpoint original.

Almacenamiento de cuatro bits no describe todo el cálculo

Pesos, activaciones intermedias y caché KV tienen precisiones distintas. W4A16 describe pesos de cuatro bits y activaciones de dieciséis para las operaciones afectadas; la acumulación depende del kernel. Un archivo llamado Q4 puede seguir usando KV en FP16. La configuración de bitsandbytes distingue explícitamente almacenamiento y tipo de cálculo.

La especificación GGUF y la guía de cuantización de llama.cpp describen contenedor y configuraciones. GPTQ y AWQ explican métodos diferentes para reducir errores. QLoRA introduce NF4 en su proceso de adaptación, mientras que la explicación de NVIDIA sobre FP4 distingue NVFP4 de MXFP4. No son nombres intercambiables de un único tipo de archivo.

El primer ahorro está en los pesos almacenados

Una conversión pura de dieciséis a cuatro bits reduciría los pesos a una cuarta parte. Los archivos reales contienen escalas, metadatos y tensores con otras precisiones; además, el tamaño incluido en el nombre del modelo está redondeado. Para planificar almacenamiento y descargas, es más preciso usar los archivos publicados.

En Qwen3-8B, la fila BF16 suma los archivos de pesos de la revisión fijada del repositorio original. Las demás filas proceden del repositorio oficial GGUF, también fijado. Un GiB son 2³⁰ bytes; las reducciones se refieren a archivos BF16, no a VRAM medida.

El paquete BF16 ocupa aquí aproximadamente 3,26 veces lo que ocupa Q4_K_M. Disminuyen el volumen descargado y el almacenamiento de los pesos comprimidos. El tiempo de carga también depende de conversiones y preparación del motor. Un cambio especialmente útil aparece cuando el modelo entero pasa a caber en una GPU y desaparece la necesidad de transferir pesos desde RAM repetidamente o de repartirlos entre tarjetas.

La memoria total baja en otra proporción

Los pesos son una sola asignación. Caché KV, espacio de trabajo, búferes y gestión de peticiones siguen consumiendo memoria. Cuantizar pesos no cuantiza automáticamente el estado del contexto.

La configuración de Qwen3-8B tiene 36 capas, 8 cabezas KV y dimensión 128 por cabeza. Con valores KV de dos bytes y 32.768 tokens retenidos, la caché sin sobrecarga de una petición es:

2 × 36 × 8 × 128 × 2 × 32.768 bytes = 4,5 GiB

En este ejemplo de planificación, aproximamos los pesos residentes mediante el tamaño del archivo y reservamos hipotéticamente 2 GiB para el motor. Cada petición activa conserva los 32.768 tokens; no hay prefijos compartidos ni cuantización KV.

El total de una petición disminuye aproximadamente un 49 %, frente al 69 % de reducción de los archivos. Cuatro peticiones largas superan el presupuesto de una tarjeta nominal de 24 GB incluso con pesos Q4. Ajustar contexto, peticiones activas, réplicas o precisión KV actúa sobre partes distintas del problema. La documentación de KV cuantizada de vLLM explica esa optimización separada; el artículo sobre 24 y 48 GB desarrolla las consecuencias para el hardware.

Son cálculos de memoria. No miden usuarios simultáneos ni acreditan latencia aceptable, y el espacio de trabajo real del motor puede diferir de la reserva supuesta.

¿Cuatro bits significa más velocidad?

Los pesos menores pueden reducir el tráfico de memoria, algo valioso cuando la generación está limitada por ancho de banda. Un kernel adecuado debe consumir esa representación eficientemente. Desempaquetar, reescalar o reorganizar pesos puede comerse parte de la ventaja; algunas rutas integran la reconstrucción en el propio cálculo. Marlin es un ejemplo de diseño de kernels para aprovechar pesos de cuatro bits. Sus resultados corresponden al kernel y trabajo estudiados, no automáticamente a toda una aplicación.

Leer la entrada, o prefill, difiere de generar tokens sucesivos, o decode. Entradas largas y lotes mayores cambian la reutilización de pesos y la cantidad de cálculo. Contextos largos también incrementan tráfico KV. Una mejora en la generación para un usuario no implica la misma mejora en tiempo hasta el primer token ni en capacidad total del servicio.

Registremos longitudes de entrada y salida, peticiones activas y configuración del motor. Comparemos por separado latencia inicial, velocidad de continuación y peticiones completadas correctamente. W4A16 puede leer pesos comprimidos y calcular con mayor precisión; usar instrucciones nativas de baja precisión es otra ruta. La matriz de hardware de vLLM muestra por qué hay que concretar modelo, formato numérico, kernel y versión del motor.

La calidad cambia según la tarea

No existe un porcentaje universal de pérdida por usar cuatro bits. Influyen arquitectura, tamaño, método, tensores afectados y tarea. Evaluating Quantized Large Language Models estudia pesos, activaciones y KV en varias familias y encuentra sensibilidades diferentes. No fija una pérdida para cada modelo o conversión posterior.

Dos variantes pueden sonar igual de fluidas y diferir al conservar un identificador, interpretar una excepción contractual o construir un argumento de herramienta. Conviene puntuar la tarea: valores de campos en extracción, respaldo documental en RAG, pruebas ejecutadas en código y elección correcta de herramienta y argumentos en agentes. Un JSON válido acredita sintaxis, no valores correctos. Tampoco una redacción distinta es por sí sola una pérdida de calidad, especialmente con generación aleatoria.

La evaluación debe usar el idioma del servicio. Resultados ingleses o una media multilingüe no explican cómo ese checkpoint cuantizado maneja nombres, formatos numéricos o vocabulario especializado de una comunidad hispanohablante. Mantener casos difíciles junto a los habituales permite detectar errores poco frecuentes pero costosos.

¿Modelo mayor en cuatro bits o menor con más precisión?

La cuantización permite introducir un modelo mayor en el mismo presupuesto de memoria. Tiene valor cuando el menor carece de una capacidad necesaria y el mayor cuantizado la conserva. Pero más parámetros pueden seguir exigiendo más trabajo por token: comprimirlos no elimina esa diferencia de cálculo.

Comparemos dos configuraciones ejecutables con la misma tarea y hardware, en vez de comparar solo archivos. Si un especialista o un modelo pequeño alcanza la calidad requerida, la memoria libre puede servir para más peticiones u otros componentes. Si hace falta razonamiento más potente, conviene estudiar un modelo mayor cuantizado. La guía de tamaño de modelo explica cómo preparar esa comparación sin suponer una clasificación universal por tamaño.

Cuantización entrenada y conversión de archivos

ParetoQ publica 53,3 en HellaSwag para MobileLLM-350M BF16 y 53,5 para su variante de 4 bits; la perplejidad Wiki baja de 10,5 a 10,3. Son variantes entrenadas y ajustadas con ParetoQ. El resultado no demuestra que convertir cualquier modelo a GGUF de 4 bits mejore su calidad. Además de arquitectura y bits, hay que identificar el entrenamiento y el método de cuantización. El estudio tampoco garantiza memoria o velocidad en un motor de escritorio.

PTQ, QAT y QLoRA resuelven problemas distintos

La cuantización posterior al entrenamiento, PTQ, convierte un modelo ya entrenado. Puede utilizar una colección pequeña de calibración para elegir una aproximación numérica mejor; GPTQ y AWQ son ejemplos. Calibrar no equivale a enseñar al modelo el conocimiento de una organización. Si existe un archivo publicado adecuado, quien lo despliega no necesita repetir la conversión.

El entrenamiento consciente de cuantización, QAT, introduce el efecto de la precisión reducida durante entrenamiento o ajuste para que los parámetros se adapten. La explicación de QAT de PyTorch presenta implementación y evaluación. Simular el error de cuantización no significa que todas las operaciones y estados del optimizador sean de cuatro bits.

QLoRA conserva congelados los pesos base cuantizados y entrena un conjunto limitado de adaptadores. Busca abaratar la adaptación, no entrenar todos los parámetros con aritmética de cuatro bits. Antes hay que decidir si el error restante necesita entrenamiento o si se resuelve con recuperación y mejores entradas; la comparación de RAG y ajuste distingue esos casos.

Elegir la variante que quite la restricción real

Es útil empezar por un archivo fiable con checkpoint base, cuantización, publicador, licencia y ruta de ejecución identificables. Tokenizador y plantilla de conversación deben corresponder al modelo. Para convertir de nuevo conviene partir de un original adecuado: encadenar conversiones con pérdida puede arrastrar errores anteriores.

El catálogo identifica archivos y la tabla de programas sus rutas de ejecución. En una comparación controlada de calidad conviene mantener entradas y ajustes de generación; al comparar sistemas finales se puede optimizar cada ruta si se explican las diferencias.

El ahorro económico aparece cuando se usan menos recursos para trabajo aceptado o se termina más trabajo aceptado con los mismos recursos. También cuentan conversión, mantenimiento de variantes, ingeniería y respuestas fallidas. El archivo menor aporta valor cuando la memoria liberada o el tráfico reducido se convierten en una mejora utilizable, conservando la calidad exigida.