Elegir una cuantización por sus resultados, no por sus bits.

Describir la variante más allá de su número de bits

Nombra el método, su implementación, su versión y la revisión exacta del artefacto. Dos variantes en cuatro bits pueden emplear representaciones, grupos, metadatos y kernels distintos. Separa el formato de almacenamiento de los pesos del de las operaciones de cálculo. Anota también los módulos que se conservan en otra precisión y cualquier derivación a la CPU.

En bitsandbytes, unas capas lineales cuantizadas sustituyen a ciertas capas ordinarias; los demás módulos siguen su dtype configurado. Por lo tanto, este comportamiento no describe por sí solo el pico del proceso. Lee la configuración efectiva tras la carga y luego verifica que la variante realice de verdad el tratamiento esperado en lugar de un repliegue de software distinto.

Fuentes técnicas: Hugging Face Transformers 5.17 — capas cuantizadas y otros dtypes

Separar calibración y evaluación

Algunos métodos usan ejemplos para preparar la cuantización. El procedimiento GPTQ documentado en Transformers requiere, en particular, un conjunto de calibración y un tokenizer. Este conjunto participa en la fabricación del artefacto: no constituye una prueba independiente de calidad. Otros métodos siguen otro camino; no supongas que un mismo protocolo de calibración se aplica a todos los formatos.

Reserva los ejemplos de calibración dentro de los datos autorizados para preparar el modelo y luego registra identificadores, procedencia, longitudes y transformación aplicada. Guarda la validación para elegir los ajustes y el test final para la confirmación. Si eliges varios conjuntos de calibración después de comparar sus puntuaciones, esa búsqueda forma parte del desarrollo y debe constar en el balance.

Fuentes técnicas: Hugging Face Transformers 5.17 — calibración de una cuantización GPTQ · Construir particiones según su rol

Calcular una cota de pesos sin venderla como un pico

Tomemos un modelo ficticio de tres mil millones de parámetros, todos almacenados con el mismo número de bits. El volumen bruto se calcula con parámetros × bits / 8. A 16 bits, se obtienen 6 mil millones de bytes; a 8 bits, 3 mil millones; a 4 bits, 1,5 mil millones. Estos números son una aritmética ilustrativa, no los tamaños observados de un artefacto ni las necesidades de un modelo en ejecución.

La diferencia bruta entre 16 y 4 bits es de 4,5 GB, es decir, unos 4,191 GiB. Excluye escalas, metadatos, módulos no cuantizados, caché y temporales. Permite formular una hipótesis de memoria que hay que verificar, sin predecir una división por cuatro del pico. El expediente de memoria explica cómo separar las fases e interpretar los contadores.

Fuentes técnicas: NIST — prefijos binarios y decimales · IteraGPU — estimaciones y picos de memoria

Cambiar los pesos antes de cambiar la caché

Empieza por una referencia cuyo comportamiento conozcas. Después compara las variantes de pesos con la misma caché, las mismas longitudes, el mismo batch o la misma concurrencia. Si también cambias esos parámetros, estás comparando configuraciones completas: anúncialo y no atribuyas toda la diferencia a la cuantización de los pesos.

La caché KV puede cuantificarse a su vez cuando el modelo y el motor lo permiten. Se trata de una elección distinta. La documentación de Transformers señala en particular que una caché cuantificada puede penalizar la latencia en contextos cortos cuando aún queda suficiente memoria. Prueba este segundo cambio en una serie aparte; ahorrar más memoria no garantiza un mejor tiempo de respuesta.

Fuentes técnicas: Hugging Face Transformers 5.17 — caché KV cuantificada y compromiso de latencia

Ejemplo de regla de calidad: una pequeña bajada puede seguir siendo inadmisible

Aquí tienes una ilustración de decisión, sin ejecución del modelo. Un proyecto evalúa 200 documentos y define antes de las pruebas una pérdida máxima de un punto porcentual frente a la referencia. También exige al menos un 90 % de aciertos en 20 documentos críticos incluidos en esos 200. Un documento se acepta únicamente si todos sus campos obligatorios son correctos.

Los valores ficticios de abajo hacen que A sea admisible según estas dos reglas: 94 % en lugar de 95 %, y 18/20 en el grupo crítico. B falla en ambas. Todavía no se puede declarar A ganadora: no se indican ni el pico de memoria ni la duración. Además, los totales no muestran qué documentos han cambiado; examina los errores emparejados para detectar nuevas regresiones importantes.

Fuentes técnicas: Examinar los errores en lugar del total

Ejecutar una comparación cuyas diferencias se expliquen

Prepara primero el contrato de comparación y después los archivos de resultados. El protocolo siguiente debe realizarse sobre tu carga; las cifras anteriores no lo sustituyen. Si una variante no carga o no dispone de los operadores necesarios, conserva ese fallo como información de compatibilidad.

• Fija el corpus, las referencias, el modelo, el tokenizer, el prompt y las reglas de salida; mantén identificables los casos largos y difíciles.
• Registra la calibración, el artefacto exportado y la configuración efectiva. Verifica los dispositivos utilizados y los posibles trasvases CPU/GPU.
• Separa fabricación, carga, calentamiento y procesamiento estabilizado. Utiliza los mismos límites de medición y conserva las repeticiones en bruto.
• Anota el pico por dispositivo y por fase; mantén allocated y reserved por separado. No sumes estos contadores ni restes sus máximos independientes.
• Evalúa el formato, el contenido y los subgrupos acordados, y luego relaciona los errores por identificador.
• Recarga el artefacto elegido en un proceso nuevo y repite un control definido. Un resultado obtenido antes de la exportación no valida automáticamente la recarga.

Fuentes técnicas: Medir correctamente la memoria · Definir las repeticiones y la cronometración

Vincular el compromiso con el coste asumido

Un ahorro de memoria puede ampliar las configuraciones posibles, permitir más concurrencia o simplemente dejar margen. No reduce automáticamente el gasto. Si el periodo, los lotes reservados y los entregables aceptados siguen siendo los mismos, el coste del forfait sigue siendo el mismo, aunque una pasada sea más rápida.

Incluye en el calendario la posible calibración, la cuantificación, la evaluación, los intentos rechazados y la recarga. Compara después los forfaits completos de 3, 7 o 30 días entre las opciones que satisfagan tus criterios. El ratio por corpus útil solo se calcula con corpus realmente terminados y aceptados; las repeticiones de cronometración no crean nuevos entregables.

Si un único alquiler sirve para comparar varias variantes, su importe es un gasto común de campaña. No imputes mentalmente el forfait entero a cada variante y luego sumes esos importes como gastos reales distintos. Para asignar una parte analítica, anuncia una convención; esta no cambia el total asumido.

Fuentes técnicas: IteraGPU — forfait completo y coste de un experimento

Concluir con una configuración y sus límites

La decisión final nombra el artefacto, el entorno, la carga cubierta, el criterio de calidad superado y la restricción mejorada. Si las variantes son parecidas, conserva esa incertidumbre y prioriza una opción que sepas recargar y explicar. El número de bits no es por sí solo un orden de preferencia.

Una conclusión sobre un corpus corto no se extiende automáticamente a contextos largos, a otro idioma o a más solicitudes simultáneas. Una cuantificación adoptada para la inferencia tampoco define los parámetros entrenables de un fine-tuning. Mantén estas cuestiones separadas y confirma la variante elegida sobre el test reservado.

Preguntas prácticas