Cuantización consciente de la sensibilidad explicada: cómo OrcaSAQ decide qué pesos obtienen más bits

La cuantización consciente de la sensibilidad es la práctica de gastar tu presupuesto de bits donde importa: los tensores a los que la cuantización más perjudica reciben más bits, y todo lo demás se mantiene en un ancho base más bajo. Este artículo explica cómo OrcaSAQ — nuestro método de precisión mixta sin calibración y consciente de la arquitectura, publicado con la GLM-5.3-Flashfamilia de cuantización orcarouter/GLM-5.3-Flash-MLX — decide cuáles de los 37 338 tensores de un modelo Mixture-of-Experts de 320 mil millones de parámetros merecen bits adicionales, sin ningún conjunto de datos de calibración. La lección transferible para cualquiera que cuantifique un MoE diferente: los expertos compartidos y las proyecciones descendentes se ganan los bits adicionales, y puedes encontrarlos usando nada más que los metadatos de cuantización de la propia versión original.

La respuesta corta

La cuantización consciente de la sensibilidad es precisión mixta con una política: el ancho de bits de cada tensor sigue su grado de sensibilidad al error de cuantización, en lugar de un único ancho para todo el modelo. La literatura de investigación mide la sensibilidad con hessianos, información de Fisher o divergencia entre las salidas de las capas originales y cuantizadas, y luego asigna bits a las capas que más perjudican. OrcaSAQ pertenece a una familia más pequeña que omite por completo la medición. Codifica la clasificación de sensibilidad en la propia arquitectura: utiliza conocimientos previos arquitectónicos y de rol de tensor para decidir qué pesos son frágiles y luego cuantiza todo lo demás con una precisión base objetivo.

Lo que eso te aporta es un proceso rápido, determinista y sin calibración. No hay que armar un corpus de calibración, ni buscar sensibilidad por capa, ni reajustar cada modelo, por lo que la misma receta se transfiere a una nueva arquitectura el mismo día en que se publican sus pesos. Lo que sacrifica es la adaptación: un método basado en calibración como GPTQ o AWQ observa la distribución real de activaciones de tu modelo y tus datos, y normalmente extrae más calidad del mismo ancho de bits promedio. La apuesta de OrcaSAQ es que, para los modelos de mezcla de expertos, el rol de un tensor te dice casi todo lo que diría una ejecución de calibración, a una fracción del costo.

Dos formas de encontrar los pesos sensibles

Antes de la política, la pregunta: ¿cómo sabes a qué tensores perjudica la cuantización? Las dos respuestas son todo el espacio de diseño.

• Impulsado por calibración. Ejecute un corpus pequeño a través del modelo, mida el error que causa cada tensor o bloque y asigne bits para minimizar el error total de reconstrucción. GPTQ utiliza una aproximación basada en la Hessiana del error de cuantización por capa; AWQ utiliza estadísticas de activación para identificar los pesos sobresalientes que proteger. La fortaleza es la adaptación a sus datos reales; los costos son un corpus curado, pasadas hacia adelante y soluciones de Hessiana inversa para cada capa, y resultados que varían cuando el conjunto de calibración cambia.

• Sin calibración.Decide la clasificación de sensibilidad antes de ver cualquier dato, a partir de la arquitectura. En un MoE, ya conoces los roles estructurales: el experto que se activa con cada token, y la proyección que escribe en el flujo residual. Codifica esa clasificación como una política fija y aplícala mecánicamente.

OrcaSAQ está firmemente en el segundo bando, y este artículo es una defensa de ese bando para la cuantización MoE — con una descripción lúcida de lo que se sacrifica a cambio.

La política: qué tensores obtienen más bits

La política de asignación de bits de OrcaSAQ se indica en la tarjeta del modelo para orcarouter/GLM-5.3-Flash-MLX, y se reduce a tres reglas más una excepción. La base de precisión es la compilación que estás haciendo — 6, 4, 3 o 2 bits — y la política eleva roles de tensor específicos por encima de ella:

• Experto compartido: base +2 bits. El experto compartido se activa en cada token, por lo que su error de cuantización se reproduce en cada salida que produce el modelo. Es el tensor de mayor impacto del modelo y recibe la mayor cantidad de bits.

• down_proj: base +1 bit. En un bloque MLP SwiGLU, la proyección descendente es el cuello de botella residual — su salida se añade directamente al flujo residual que leen todas las capas más profundas. Un error aquí corrompe directamente lo que todo lo posterior ve.

• gate_proj y up_proj: precisión base. Estas son las rutas de expansión y de compuerta; sus salidas se multiplican elemento a elemento dentro de la activación. Un error modesto allí se atenúa en parte por la compuerta, por lo que toleran el ancho base.

• Sin cuantizar, mantenidos en BF16: las 34 capas de atención lineal, el indexador disperso aprendido, los arreglos de hiperconexión, las normas, embed_tokens, lm_head, y toda la torre de visión. Estos no eran FP8 en la versión upstream, y se mantienen con precisión completa.

Los bits se redondean hacia arriba al ancho compatible con MLX más cercano, {2,3,4,5,6,8}. Concretamente, en GLM-5.3-Flash — 320B en total / 18B activos, 288 enrutados más 1 experto compartido con enrutamiento top-8, 45 capas — la versión de 4 bits le da al experto compartido 6 bits, a cada proyección descendente 5 bits, y a las proyecciones de puerta y ascendentes 4 bits. La versión de 6 bits redondea las proyecciones descendentes al alza a 8 bits. El tamaño del grupo es 64 para las versiones de 4 y 6 bits, 32 para las de 2 y 3 bits, y el experto compartido siempre usa 64.

¿Vale la pena la regla del experto compartido? Con una base de 2 bits, el experto compartido se sitúa en 4 bits y, con una base de 6 bits, en 8; en ambos casos, los dos bits extra cuestan memoria que los expertos enrutados podrían haber utilizado de otro modo, y las propias cifras de la ficha del modelo, que se comentan más adelante, sugieren que la compensación merece la pena. Es el mismo razonamiento que hace que valga la pena distribuir la versión 2bit-lite: el experto siempre activo es el lugar donde un poco de precisión adicional rinde más.

La regla de selección: _scale_inv como una señal de sensibilidad libre

La política de asignación de bits asume que ya sabes qué tensores son candidatos. Elegir ese conjunto es donde OrcaSAQ es más ingenioso, porque la regla es mecánica y no necesita datos: un tensor se recuantiza si y solo si la versión FP8 lo incluyó con un acompañante _scale_inv.

Por qué funciona: la base upstream GLM-5.3-Flash es FP8 — por bloques e4m3, con bloques de 128×128 y un esquema de activación dinámica. La cuantización FP8 por bloques almacena una escala por bloque y su inversa junto al peso; la presencia de _scale_inv en el checkpoint es un marcador persistente de que el tensor pasó por la ruta de cuantización upstream. El lanzamiento upstream ya te ha dicho qué tensores son seguros de cuantizar: sin Hessiano, sin corpus de calibración, sin pasadas hacia adelante.

Para GLM-5.3-Flash, ese conjunto son los lineales de MoE y de MLP denso, más las cuatro proyecciones de cada deepseek_sparse_attention bloque — q_a_proj, q_b_proj, kv_a_proj_with_mqa y o_proj — en las 11 capas dispersas en las profundidades 3, 7, 11 … 43, más el bloque MTP, 12 × 4 = 48 tensores. Todo lo demás nunca llevó el marcador y permanece en BF16: las 34 capas linear_attention, el indexador disperso y la torre de visión. La capa MTP — capa 45 — está incluida en los pesos cuantizados en lugar de exportarse como un módulo separado.

El punto que vale la pena robar es el truco en sí. Una versión de modelo que cuantiza sus pesos en una etapa anterior ya ha hecho gran parte del trabajo de decidir qué se puede cuantizar; el _scale_inv es esa decisión, serializada en el formato de archivo. OrcaSAQ la vuelve a leer. Eso es lo que hace que el pipeline sea determinista y transferible — cualquier modelo que incluya pesos FP8 con metadatos de escala puede manejarse con la misma regla, sin necesidad de ningún pipeline de datos.

La trampa: configuración por módulo, no bits de nivel superior.

Si escribes tu propio cuantizador MLX — y esa es la audiencia de esta sección — lo más útil en la ficha del modelo es una advertencia: a nivel superior, bits y group_size en config.json no son suficientes.

En total, se cuantifican 37,338 tensores. La asignación se registra en config.json → quantization como por módulo {group_size, bits} overrides claveados por la ruta del módulo MLX — por ejemplo model.layers.3.mlp.switch_mlp.down_proj. Debido a que MLX fusiona los expertos enrutados de una capa en un único switch_mlp, 173 entradas cubren los 37,338 tensores.

Y el cargador lee esas entradas en el momento de la carga. Si cuantizas todo el archivo con el ancho base, todo tensor de precisión elevada — el experto compartido en base +2, cada proyección descendente en base +1 — sale con el ancho incorrecto, y el modelo se carga con una forma incorrecta. El mapa por módulo no es una optimización que puedas omitir; es la ruta de carga. Cuando escribas tu propio cuantizador, emite las anulaciones para cada tensor que la política eleve, y verifícalas contra el valor predeterminado de nivel superior antes de publicar.

¿La póliza se paga por sí sola?

La evidencia es nuestra, medida en un modelo: GLM-5.3-Flash, en el que cada compilación se descuantizó y se ejecutó a través del mismo glm5_next forward, de modo que la única variable es la cuantización. Los números a continuación provienen de la ficha del modelo y no son benchmarks del proveedor ni cifras de terceros — considéralos como un único dato, no como una ley.

• Perplejidad, en comparación con la referencia FP8 en 2.7797: 6 bits 2.7864 (+0.24%), 4 bits 2.8620 (+2.96%), 3 bits 3.0566 (+9.96%), 2 bits 4.3622 (+56.9%).

• Acuerdo de token Top-1 con la referencia, mismo orden: 97,76 %, 96,13 %, 92,06 %, 86,56 %.

La lectura es exactamente lo que predice la política. Todo hasta 3 bits se degrada suavemente — esa es la firma de un presupuesto de bits gastado en los tensores correctos — y 2 bits es un precipicio, porque por debajo de cierto punto los aumentos basados en roles dejan de cubrir el daño. A 4 bits, +2.96% de perplejidad para una versión aproximadamente un 38% más pequeña que la referencia FP8 es una compensación genuinamente buena, y es la misma política, aplicada de forma más agresiva, la que hace que la versión 2bit-lite de 102 GB siquiera pueda cargarse. Profesionales independientes que cuantizan la misma base reportan el mismo orden — los peldaños superiores cerca del piso de ruido, el de 4 bits, real pero modesto — con números absolutos diferentes provenientes de un corpus de evaluación distinto.

Qué se transfiere a tu propio MoE

El razonamiento reutilizable, para un modelo que no es nuestro:

• Encuentra los expertos siempre activos. Lo que se activa en cada token — normalmente un experto compartido o siempre enrutado — recibe tus bits más generosos. Su error se repite en todas partes.

• Encuentra los cuellos de botella residuales. La proyección que escribe en el flujo residual (típicamente la proyección descendente de cada bloque MLP) recibe una base de +1. El error allí es visto por todas las capas más profundas.

• Deja las rutas de expansión y de compuerta en su base. Si una salida se multiplica elemento a elemento dentro de una activación, el error de cuantización en ella se absorbe parcialmente.

• Un upstream nunca cuantizado significa que nunca ha sido cuantizado por ti. Si la versión base contenía esos tensores en precisión completa, manténlos en precisión completa.

• Usa los metadatos de escala de la versión upstream como regla de selección. Si el modelo base cuantiza sus pesos, los marcadores de escala/escala inversa que deja atrás son un mapa gratuito de lo que es cuantizable — no se requiere búsqueda de sensibilidad.

• Registre las sobrescrituras por módulo. Un ancho de bits global deformará cada tensor elevado al cargar. Escriba el mapa de rutas de módulos.

Y si puedes tener un conjunto de calibración, úsalo para auditar la política — no para reemplazarla. Realiza una cuantización basada en calibración con los mismos bits promedio y verifica si el orden del prior de roles coincide con lo que dicen los datos. En un modelo denso o en una arquitectura completamente nueva, esa auditoría es la diferencia entre un valor predeterminado defendible y una suposición.

Dónde OrcaSAQ es la elección equivocada

Esta es la sección que debería mantener honesto el método, porque el trade-off de prescindir de la calibración es real.

• Cuando el techo de calidad supera a la velocidad del pipeline, y tienes un conjunto de calibración. Los métodos de estilo GPTQ o AWQ se adaptan a las estadísticas de activación reales de tu modelo y de tus datos, y a igual promedio de bits suelen superar a una política fija basada en roles. Si cuantizas un modelo una vez y nunca lo vuelves a cuantizar, las horas adicionales de calibración son un costo único que se traduce en calidad medible.

• Modelos densos no-MoE. El prior de rol — experto compartido, gate/up/down — no existe, por lo que la política pierde la estructura que la hace confiable. Te quedas con "todo lo cuantizado aguas arriba permanece cuantizado", que es una afirmación más débil.

• Modelos sin release upstream de FP8. La _scale_inv regla de selección no tiene nada en qué basarse. Debes decidir el conjunto cuantificable de alguna otra manera, y el argumento de transferibilidad mecánica se derrumba.

• Arquitecturas completamente nuevas. Los priores son exactamente los supuestos que podrían no cumplirse. Un método basado en calibración detectaría un tensor frágil que una política basada en roles pasó por alto; OrcaSAQ no lo hará, porque nunca mira.

• Objetivos por debajo de 3 bits. La política no te salva. Con 2 bits, el modelo tiene una perplejidad de +56,9% sin importar a dónde fueron los bits extra; la versión 2bit-lite existe para que quepa, no por calidad.

• Cuando necesitas garantías. Las garantías por tensor, los presupuestos de entrenamiento consciente de la cuantización (QAT) o la mejor calidad posible para un tamaño fijo sin importar el costo del pipeline son territorio de calibración.

El resultado final

La cuantización consciente de la sensibilidad es la práctica; OrcaSAQ es una receta determinista y sin calibración para ello. Las lecciones duraderas son los aumentos de experto compartido y de proyección descendente, la mecánica _scale_inv regla de selección, y la configuración por módulo que el cargador realmente lee. Para un MoE de 320 mil millones de parámetros como GLM-5.3-Flash, esa receta produce una compilación MLX de 4 bits con +2.96% de perplejidad — y el orcarouter/GLM-5.3-Flash-MLX el repositorio publica la misma política a 2, 3, 4 y 6 bits, con una compilación separada 2bit-lite para máquinas de 128 GB. Nuestro GLM-5.3-Flash-MLX tutorial cubre qué compilación ejecutar en cada máquina, paso a paso.

Si tu prioridad es el último gramo de calidad a un tamaño fijo y puedes armar un corpus de calibración, usa las herramientas basadas en calibración y deja que se adapten. Si tu prioridad es una cuantización reproducible, rápida y sin datos, que se transfiera a la próxima arquitectura — o simplemente no quieres construir un pipeline de datos en absoluto — la política basada en roles es una opción predeterminada defendible. Y si prefieres no cuantizar en primer lugar, el modelo de precisión completa GLM-5.3-Flash se sirve a través de OrcaRouter como z-ai/glm-5.3-flash. La elección se trata de cuánto pipeline estás dispuesto a ejecutar, no de si la cuantización consciente de la sensibilidad vale la pena.

¿Prefiere no cuantizar nada en absoluto? z-ai/glm-5.3-flash es el modelo de precisión completa servido en OrcaRouter al precio del proveedor, con 0% de margen.