Zubnet AIAprenderWiki › Cuantización
Infraestructura

Cuantización

También conocido como: GGUF, GPTQ, AWQ
Reducir la precisión de un modelo para hacerlo más pequeño y rápido. Un modelo entrenado en punto flotante de 32 bits puede cuantizarse a 8 bits, 4 bits o incluso menos — reduciendo su tamaño de 4-8x con una pérdida de calidad sorprendentemente pequeña. GGUF es el formato popular para inferencia local vía llama.cpp.

Por qué importa

La cuantización es lo que hace posible ejecutar un modelo de 14B parámetros en un solo GPU o incluso en una laptop. Sin ella, los modelos open-weights serían inutilizables para la mayoría de las personas. Las variantes Q4_K_M y Q5_K_M dan en el punto óptimo de tamaño vs. calidad.

En profundidad

Para entender la cuantización, necesitas entender qué está comprimiendo. El “conocimiento” de una red neuronal se almacena como miles de millones de parámetros numéricos (pesos), cada uno un número de punto flotante. Durante el entrenamiento, estos se almacenan típicamente en FP32 (punto flotante de 32 bits) o BF16 (bfloat16, 16 bits). Un modelo de 7 mil millones de parámetros en BF16 ocupa 7B × 2 bytes = 14GB de memoria. La cuantización reduce la precisión de cada peso — representándolo con menos bits. En INT8 (entero de 8 bits), ese mismo modelo se reduce a ~7GB. En INT4 (4 bits), son ~3.5GB. La idea clave es que los pesos de redes neuronales son sorprendentemente redundantes — realmente no necesitas 16 bits de precisión para representarlos de manera útil. La mayoría de los pesos se agrupan alrededor de cero y pueden aproximarse con representaciones mucho más gruesas.

Formatos y métodos

Los principales formatos de cuantización que encontrarás toman diferentes enfoques técnicos. GPTQ (optimizado para GPU, cuantización post-entrenamiento) fue uno de los primeros métodos prácticos — analiza cómo interactúan los pesos durante la inferencia real con datos de calibración y los cuantiza de una manera que minimiza la propagación de error. AWQ (Activation-aware Weight Quantization) mejoró esto enfocándose en el pequeño porcentaje de pesos que más importan para la calidad del modelo y protegiéndolos con mayor precisión. GGUF es el formato usado por llama.cpp y está diseñado para cuantización flexible de precisión mixta en CPUs y GPUs por igual. La convención de nombres en archivos GGUF te dice qué estás obteniendo: Q4_K_M significa cuantización de 4 bits usando el método K-quant a calidad media. Q5_K_M es 5 bits. Q2_K es agresivo de 2 bits (pérdida de calidad notable). Q8_0 es 8 bits (casi sin pérdida).

Calidad vs. compresión

La pérdida de calidad por cuantización es real pero a menudo exagerada. Pasar de BF16 a Q8 (8 bits) es esencialmente gratis — los benchmarks típicamente muestran menos de 0.5% de degradación en evaluaciones estándar. Q5_K_M aún retiene la mayor parte de la capacidad del modelo y a menudo es el punto óptimo para inferencia local. Q4_K_M es donde empiezas a notar diferencias sutiles: el modelo podría ser ligeramente menos preciso con números, ocasionalmente perder el hilo en salidas muy largas, o ser marginalmente peor siguiendo instrucciones complejas. Por debajo de 4 bits, la calidad se degrada más notablemente — las cuantizaciones Q2 y Q3 pueden hacer a un modelo notablemente menos inteligente, especialmente en tareas de razonamiento. La regla general es: cuantiza a Q4_K_M o Q5_K_M para uso cotidiano, y solo ve más bajo si literalmente no puedes caber el modelo en tu VRAM de otra manera.

La bonificación de velocidad

Hay una segunda dimensión de la cuantización que a menudo se pasa por alto: no solo ahorra memoria, hace la inferencia más rápida. Esto es contraintuitivo si piensas en las matemáticas cuantizadas como “aproximadas” y por lo tanto más lentas. Pero para la inferencia de LLM, el cuello de botella durante la generación de tokens es leer los pesos del modelo de la VRAM (ancho de banda de memoria), no computar con ellos. Un modelo Q4 tiene la mitad de datos para leer comparado con Q8, así que los tokens salen aproximadamente al doble de velocidad — asumiendo que tu motor de inferencia soporta adecuadamente cómputo cuantizado. Por eso llama.cpp ejecutando un modelo Q4_K_M en un GPU de escritorio a veces puede igualar los tokens por segundo de una API en la nube: el modelo cuantizado es genuinamente más eficiente por unidad de hardware. El trade-off es siempre el mismo — estás intercambiando algo de calidad por velocidad y accesibilidad — pero para muchas aplicaciones, es un intercambio que vale mucho la pena hacer.

Nacidos cuantizados

El último desarrollo que vale la pena conocer es el quantization-aware training (QAT), donde el modelo se entrena con la cuantización en mente desde el principio en lugar de cuantizarse después del hecho. Meta lanzó versiones QAT de modelos Llama que superan a los equivalentes cuantizados post-entrenamiento al mismo ancho de bits. Este enfoque produce modelos que “nacen” para funcionar a menor precisión en lugar de que se les imponga, y probablemente es hacia donde va el campo a medida que la inferencia local continúa creciendo.

Conceptos relacionados

← Todos los términos
← Ingeniería de prompts RAG →
ESC