Cuantizar un modelo local sin adivinar: cómo elegir 4, 6 u 8 bits según VRAM, contexto y pérdida aceptable

Que los pesos entren en VRAM no significa que el sistema funcione

El error más habitual al elegir un modelo local es comparar el tamaño del archivo cuantizado con la memoria de la GPU y dar la decisión por resuelta. Ese cálculo solo cubre, de forma aproximada, los pesos. Durante la inferencia intervienen además la caché de claves y valores —caché KV—, las activaciones y buffers temporales, el espacio reservado por el runtime, el contexto de cada petición y, en un servicio, las solicitudes simultáneas. Una configuración puede cargar el modelo, responder a una pregunta corta y aun así fallar cuando recibe un documento largo o varias peticiones a la vez.

La consecuencia práctica es importante: «cabe» debe significar que completa la carga máxima prevista con un margen medido, no que inicia una sesión aislada. Si el margen desaparece, el resultado puede ser un error de memoria, una reducción automática del contexto, traslado de parte del trabajo a RAM del sistema o una latencia muy irregular. Cuál de esos comportamientos ocurra depende del runtime y de su configuración; no debe suponerse sin comprobarlo.

La cuantización es una de varias palancas. Reducir los bits de los pesos suele liberar memoria y puede permitir usar un modelo mayor, pero no elimina por sí sola el coste creciente de la caché KV al ampliar el contexto o la concurrencia. También puede modificar la calidad, el rendimiento o las rutas de ejecución disponibles según el formato y el backend. Por eso no existe una equivalencia universal entre «4 bits», «6 bits» y «8 bits».

Esta guía parte de una carga de trabajo concreta: qué longitud de entrada debe aceptarse, cuántos tokens se generan, cuántas solicitudes coexistirán, qué latencia es útil y qué errores serían inaceptables. Si todavía se está eligiendo familia de modelos, conviene revisar primero la guía de modelos locales y, si la duda es entre modelos base distintos, usar la sección de comparación antes de atribuir a la cuantización diferencias que proceden del modelo.

Las partidas de memoria que hay que separar

Una estimación útil empieza por descomponer la memoria en partidas que se puedan observar por separado. La primera son los pesos del modelo. Su tamaño depende del número de parámetros, de la representación cuantizada y de metadatos propios del formato, como escalas, bloques o estructuras auxiliares. Por tanto, dividir simplemente parámetros por ocho, seis o cuatro ofrece una orientación, pero no sustituye al tamaño real informado por el formato y el runtime.

La segunda partida es la caché KV. En un decodificador autorregresivo, el sistema conserva claves y valores de los tokens ya procesados para no recalcularlos en cada token generado. La documentación de Transformers describe tensores de caché con dimensiones de lote, cabezas, longitud de secuencia y dimensión de cabeza. Hay claves y valores, y este almacenamiento se repite por capa. A igual arquitectura, crecer el contexto, el lote o la concurrencia aumenta la memoria necesaria.

La tercera partida reúne activaciones y buffers temporales. Su tamaño depende del backend, de la precisión de cálculo, de kernels, del prefill de entradas largas, de la longitud de generación y de cómo se agrupen solicitudes. No conviene sustituirla por una constante universal. El cuarto componente es la memoria no atribuida directamente al modelo, como contexto de ejecución, bibliotecas, asignadores y fragmentación. El quinto es un margen operativo explícito: memoria que no se asigna deliberadamente para tolerar picos, diferencias entre mediciones y carga real.

En un servidor, lote y concurrencia merecen una precisión adicional. Un lote puede ser el número de secuencias procesadas juntas en un paso, mientras que la concurrencia es el número de solicitudes vivas. Según el planificador, ambas cifras pueden relacionarse pero no son intercambiables. Para estimar la caché debe contarse la suma de tokens vivos de las secuencias que coexisten, no solo la longitud máxima de una solicitud.

Estimar pesos y caché KV antes de descargar o desplegar

La estimación no pretende predecir cada byte: pretende descartar configuraciones inviables y definir qué pruebas merecen ejecutarse. Para los pesos, use el tamaño informado para el artefacto concreto que se piensa cargar, no una cifra genérica para la familia del modelo. Si solo se conoce el número de parámetros, trátese el resultado como un mínimo teórico incompleto. Los formatos de cuantización almacenan información adicional y algunos runtimes convierten o duplican estructuras durante la carga.

Para una arquitectura tipo Llama, una aproximación conceptual de la caché KV por secuencia es: capas multiplicadas por dos, multiplicadas por cabezas de clave-valor, multiplicadas por longitud de secuencia, multiplicadas por dimensión de cabeza y por bytes de cada elemento de caché. El factor dos representa K y V. Para varias secuencias simultáneas, se suman los tokens residentes de cada una. Si el runtime usa una caché estática, puede reservar capacidad hasta un máximo incluso cuando el uso instantáneo sea menor; si usa una caché dinámica, el uso puede crecer con la solicitud. Ambas estrategias requieren medición.

Es crucial emplear el número de cabezas de clave-valor, no siempre el número total de cabezas de atención. En atención multi-query o grouped-query, varias cabezas de consulta comparten proyecciones KV. Esto puede reducir de forma sustancial la caché frente a una arquitectura con una proyección KV por cabeza de atención. La configuración exacta del modelo debe aportar capas, cabezas KV y dimensión de cabeza; no deben deducirse de un nombre comercial.

Los bytes por elemento de la caché también deben verificarse. Cuantizar los pesos no implica automáticamente cuantizar la caché KV. Algunos entornos permiten elegir un tipo de datos de caché cuantizado, otros usan por defecto una precisión distinta, y otros aplican offloading. Estas opciones cambian el presupuesto de memoria y pueden afectar rendimiento o comportamiento numérico. Anote la configuración real del runtime, no solo los bits que aparecen en el nombre del archivo.

Qué cambia al pasar de 8 a 6 o 4 bits

Como regla general, reducir la precisión de los pesos reduce su huella de memoria respecto a una representación de mayor precisión del mismo modelo. Esto puede hacer viable una GPU menor, dejar más presupuesto para contexto o permitir más solicitudes concurrentes. Sin embargo, la reducción observada no tiene por qué seguir una proporción exacta de ocho a seis a cuatro. El empaquetado, las escalas por grupo, el formato de archivo, las conversiones internas y los buffers del backend cambian el resultado.

La calidad tampoco depende únicamente del número de bits. Importan el algoritmo de cuantización, el tamaño de grupo, qué tensores reciben un tratamiento especial, el modelo base y la tarea. Una cuantización de 4 bits de un método puede conservar bien una tarea y otra de 6 bits de otro método puede no hacerlo; el sentido inverso también es posible. Por esa razón, los bits sirven para formular hipótesis de prueba, no para certificar precisión.

La velocidad requiere la misma cautela. Menos memoria puede reducir transferencias y mejorar la viabilidad en un dispositivo limitado, pero un formato puede carecer de kernels eficientes en un backend concreto o requerir conversiones. Aumentar el contexto puede desplazar el cuello de botella hacia la gestión de caché y el prefill. El rendimiento debe medirse con dos métricas separadas: tiempo hasta el primer token para entradas representativas y tasa de generación posterior. Una sola cifra de tokens por segundo oculta diferencias relevantes.

Como punto de partida, pruebe 8 bits cuando la calidad crítica y el presupuesto lo permitan; 6 bits cuando haga falta recuperar una parte significativa de memoria sin saltar directamente a la opción más agresiva; y 4 bits cuando la VRAM sea la restricción dominante o cuando las pruebas demuestren que no hay pérdida inaceptable. Estas son prioridades de ensayo, no recomendaciones universales.

Procedimiento de decisión: de la restricción al candidato viable

Defina primero el contrato operativo. Escriba la longitud máxima de entrada que realmente debe soportarse, una reserva de tokens de salida, el número máximo de solicitudes vivas, el objetivo de latencia y las tareas críticas. Diferencie un máximo excepcional de un objetivo habitual. Si una aplicación procesa documentos largos, medir solo mensajes breves no representa su riesgo de memoria ni su calidad útil.

Después reúna los parámetros de la arquitectura y del runtime. Para el modelo, registre capas, cabezas KV, dimensión de cabeza y el formato de pesos. Para el runtime, registre el tipo de datos de caché, si reserva caché estática o dinámica, si permite offloading, el límite de memoria de GPU y cualquier ajuste de lote o tokens en vuelo. En herramientas de servicio, el presupuesto de caché puede configurarse explícitamente o derivarse de una fracción de la memoria disponible; ambos casos deben constar en el experimento.

Calcule una banda, no una cifra única: pesos observados o estimados, caché KV para la carga objetivo, una reserva para temporales y un margen. Si el total supera la VRAM disponible antes de aplicar el margen, descarte la combinación. Si entra por muy poco, clasifíquela como candidata de riesgo y pruébela bajo carga máxima. Si entra con margen, no la dé por aprobada hasta validar calidad y latencia.

Elija al menos tres candidatos que respondan a hipótesis distintas: el modelo deseado a 8 bits, a 6 bits y a 4 bits; o, cuando un candidato no tenga sentido, un modelo menor con una precisión superior. Mantenga constantes modelo base, revisión, prompt, contexto máximo, límite de salida, semilla cuando sea compatible, parámetros de decodificación, hardware y versión de runtime. Cambiar varias variables a la vez impide atribuir una diferencia a la cuantización.

Prueba mínima para detectar una pérdida que importe

Una prueba útil no necesita ser enorme, pero sí representativa. Construya un conjunto pequeño de casos que incluya el trabajo que motiva el despliegue: extracción estructurada, clasificación, síntesis de documentos, asistencia de código o respuestas con restricciones, según corresponda. Incluya entradas de longitud habitual y algunas cercanas al límite operativo. Las entradas largas son necesarias porque pueden revelar tanto errores de memoria como pérdidas de seguimiento de instrucciones o de recuperación de detalles.

Para cada caso, defina qué se validará antes de ejecutar el modelo. Algunas tareas admiten comparación exacta: un esquema JSON válido, etiquetas permitidas, campos obligatorios, una consulta que debe contener valores concretos o pruebas automatizadas para código. Otras requieren revisión humana con una rúbrica: fidelidad al documento, cobertura, ausencia de invenciones, cumplimiento de formato y utilidad. No confunda fluidez con corrección.

Fije un umbral explícito. Por ejemplo, una configuración puede quedar descartada si incumple más casos críticos que el candidato de referencia, si empeora la validez estructural por encima de un límite decidido por el equipo o si produce errores nuevos en datos sensibles. El umbral pertenece al riesgo de la aplicación; no puede inferirse de los bits. En una tarea de borrador creativo puede aceptarse más variación que en extracción de datos para un proceso posterior.

Repita las pruebas. Con decodificación estocástica, varias ejecuciones ayudan a separar variación de generación y degradación sistemática. Con decodificación determinista, las repeticiones siguen siendo útiles para observar estabilidad de rendimiento y errores de memoria. Informe resultados por tipo de tarea y longitud de entrada, no solo un promedio global. Una cuantización que parece equivalente en el promedio puede concentrar sus fallos en los documentos más largos o en la tarea de mayor impacto.

Tres perfiles operativos y sus prioridades

En un portátil con GPU limitada, la prioridad suele ser evitar una configuración que dependa continuamente de RAM del sistema o de offloading para una experiencia interactiva. Empiece con un contexto realista, una sola solicitud y un modelo o cuantización que deje margen. Si 4 bits es la única forma de cargar el modelo, compare también un modelo menor a 6 u 8 bits. El segundo puede ser más estable y más útil en la tarea concreta, aunque tenga menos parámetros.

En una estación de trabajo con una GPU, hay más margen para elegir entre calidad, contexto y velocidad, pero el límite sigue siendo compartido por pesos, caché y temporales. Es un entorno apropiado para comparar 4, 6 y 8 bits bajo el mismo corpus y para decidir si se reserva VRAM para contextos largos. Si se prevé alternar entre sesiones breves y análisis documental, mida ambos perfiles: el resultado de una conversación corta no dimensiona el segundo.

En un servidor con concurrencia moderada, la unidad de planificación ya no es el archivo de modelo, sino la capacidad total de tokens vivos. El gestor de caché y el planificador de solicitudes son parte de la decisión. Una configuración que funciona para una sola sesión puede agotar memoria al coincidir prefills largos. Defina límites de admisión, longitud máxima, reserva de salida y concurrencia; después pruebe ráfagas y mezclas de solicitudes cortas y largas. Las métricas de cola y percentiles de latencia son más informativas que el mejor resultado aislado.

En cualquiera de los tres perfiles, el offloading es una opción que debe declararse, no una solución invisible. Puede ampliar la capacidad aparente trasladando parte de los datos, pero también puede alterar la latencia y depender del enlace entre CPU y GPU. Decida con mediciones si esa compensación es aceptable para el caso de uso.

Señales para descartar una configuración y checklist de adopción

Descarte una configuración cuando produzca errores de memoria intermitentes, aunque una demostración breve funcione. La intermitencia suele indicar que la memoria disponible depende de la forma de las solicitudes, del pico de prefill, de fragmentación o de otras cargas del proceso. También es motivo de descarte que el runtime reduzca silenciosamente el contexto efectivo, que el sistema solo sea estable con una carga inferior a la prevista o que el margen observado desaparezca en pruebas repetidas.

La degradación de calidad debe analizarse por patrón. Errores concentrados en extracción, cálculos, campos obligatorios, seguimiento de instrucciones o documentos extensos tienen más peso que cambios estilísticos si esas tareas son críticas. Una salida aparentemente razonable pero con valores inventados no debe aprobarse solo por una puntuación media. Revise además la validez del formato cuando la salida alimente software posterior.

Antes de fijar una opción predeterminada, compruebe privacidad y operación. Ejecutar inferencia en el equipo no garantiza por sí mismo que ningún dato salga de él: descargas de modelos, telemetría, registro de prompts, actualización de dependencias y herramientas de observabilidad son aspectos separados. Qué datos se conservan y qué comunicaciones realiza cada componente debe verificarse en la configuración y en el entorno de red elegido.

El resultado final no tiene por qué ser «la mayor cuantización posible». Puede ser 6 bits para un perfil interactivo, 4 bits para un perfil de análisis con gran contexto, u 8 bits para una tarea donde la pérdida detectada no sea aceptable. Mantenga las alternativas junto con su registro de pruebas. Si cambian el runtime, el hardware, el formato de pesos o la carga de trabajo, vuelva a medir: la conclusión anterior deja de ser una garantía.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.