Quantização Ciente da Sensibilidade Explicada: Como o OrcaSAQ Decide Quais Pesos Recebem Mais Bits

A quantização ciente da sensibilidade é a prática de gastar seu orçamento de bits onde importa: os tensores que a quantização mais prejudica recebem mais bits, e todo o resto permanece em uma largura base menor. Este artigo explica como o OrcaSAQ — nosso método de precisão mista sem calibração e ciente da arquitetura, lançado com a GLM-5.3-Flash família de quantização orcarouter/GLM-5.3-Flash-MLX — decide quais dos 37.338 tensores em um modelo Mixture-of-Experts de 320 bilhões de parâmetros merecem bits extras, inteiramente sem um conjunto de dados de calibração. A lição transferível para quem estiver quantizando um MoE diferente: especialistas compartilhados e projeções descendentes merecem os bits extras, e você pode encontrá-los usando nada mais do que os próprios metadados de quantização da versão upstream.

A resposta curta

A quantização ciente da sensibilidade é uma precisão mista com uma política: a largura de bits de cada tensor segue o quão sensível ele é ao erro de quantização, em vez de uma única largura para o modelo inteiro. A literatura de pesquisa mede a sensibilidade com Hessianas, informação de Fisher ou divergência entre as saídas das camadas original e quantizada e, então, aloca bits às camadas que mais prejudicam. A OrcaSAQ pertence a uma família menor que dispensa totalmente a medição. Ela codifica a classificação de sensibilidade na própria arquitetura: usa prioris arquitetônicas e de papel do tensor para decidir quais pesos são frágeis e, então, quantiza todo o resto com uma precisão-base alvo.

O que isso lhe proporciona é um pipeline rápido, determinístico e sem calibração. Não há corpus de calibração para montar, nem busca de sensibilidade por camada, nem reajuste por modelo; portanto, a mesma receita se transfere para uma nova arquitetura no dia em que seus pesos são lançados. O que isso sacrifica é a adaptação: um método orientado por calibração, como GPTQ ou AWQ, observa a distribuição real de ativações do seu modelo e dos seus dados e, geralmente, extrai mais qualidade da mesma largura média de bits. A aposta do OrcaSAQ é que, para modelos Mixture-of-Experts, o papel de um tensor diz a maior parte do que uma execução de calibração diria, por uma fração do custo.

Duas maneiras de encontrar os pesos sensíveis

Antes da política, a questão: como você sabe quais tensores a quantização prejudica? As duas respostas são todo o espaço de design.

• Baseado em calibração. Passe um pequeno corpus pelo modelo, meça o erro que cada tensor ou bloco causa e aloque bits para minimizar o erro total de reconstrução. O GPTQ usa uma aproximação baseada na Hessiana para o erro de quantização por camada; o AWQ usa estatísticas de ativação para identificar os pesos salientes a proteger. A vantagem é a adaptação aos seus dados reais; os custos são um corpus curado, passagens diretas e soluções de Hessiana inversa para cada camada, e resultados que mudam quando o conjunto de calibração muda.

• Sem calibração.Decida a classificação de sensibilidade antes de ver quaisquer dados, a partir da arquitetura. Em um MoE, você já conhece os papéis estruturais: o especialista que dispara em cada token, e a projeção que escreve no fluxo residual. Codifique essa classificação como uma política fixa e aplique-a mecanicamente.

OrcaSAQ está firmemente no segundo campo, e este artigo é uma defesa desse campo para quantização MoE — com um relato lúcido do que se abre mão por isso.

A política: quais tensores recebem mais bits

A política de alocação de bits do OrcaSAQ está declarada na ficha do modelo para orcarouter/GLM-5.3-Flash-MLX, e se resume a três regras mais uma exceção. A básica precisão é a versão que você está criando — 6, 4, 3 ou 2 bits — e a política eleva papéis específicos de tensores acima dela:

• Especialista partilhado: base +2 bits. O especialista partilhado é ativado em todos os tokens, pelo que o seu erro de quantização é reproduzido em todas as saídas que o modelo produz. É o tensor de maior alavancagem no modelo e recebe mais bits.

• down_proj: base +1 bit. Em um bloco MLP SwiGLU, a projeção descendente é o gargalo residual — sua saída é adicionada diretamente ao fluxo residual que todas as camadas mais profundas leem. Um erro aqui corrompe diretamente o que tudo a jusante vê.

• gate_proj e up_proj: precisão base. Estes são os caminhos de expansão e de gating; suas saídas são multiplicadas elemento a elemento dentro da ativação. Um erro modesto aí é em parte eliminado pelo gating, então eles toleram a largura base.

• Nunca quantizados, mantidos em BF16: as 34 camadas de atenção linear, o indexador esparso aprendido, as matrizes de hiperconexão, as normas, embed_tokens, lm_head e toda a torre de visão. Esses não eram FP8 na versão upstream e permanecem em precisão total.

Os bits são arredondados para cima até a largura suportada mais próxima do MLX, {2,3,4,5,6,8}. Concretamente, no GLM-5.3-Flash — 320B no total / 18B ativos, 288 roteados mais 1 especialista compartilhado com roteamento top-8, 45 camadas — a versão de 4 bits dá ao especialista compartilhado 6 bits, a cada projeção down 5 bits, e às projeções gate e up 4 bits. A versão de 6 bits arredonda as projeções down para 8 bits. O tamanho do grupo é 64 para as versões de 4 e 6 bits, 32 para as de 2 e 3 bits, e o especialista compartilhado sempre usa 64.

A regra do especialista compartilhado vale a pena? Com base de 2 bits, o especialista compartilhado fica em 4 bits e, com base de 6 bits, fica em 8 — em ambos os casos, os dois bits extras custam memória que os especialistas roteados poderiam ter usado de outra forma, e os próprios números do card do modelo, discutidos abaixo, sugerem que a troca compensa. É o mesmo raciocínio que justifica lançar a build 2bit-lite: o especialista sempre ativo é o único lugar onde um pouco de precisão extra rende o máximo.

A regra de seleção: _scale_inv como um sinal de sensibilidade livre

A política de alocação de bits pressupõe que você já sabe quais tensores são candidatos. É na escolha desse conjunto que o OrcaSAQ é mais inteligente, porque a regra é mecânica e dispensa dados: um tensor é requantizado se, e somente se, a versão FP8 o entregou com um companheiro _scale_inv.

Por que isso funciona: a base upstream GLM-5.3-Flash é FP8 — block-wise e4m3, blocos de 128×128, com um esquema de ativação dinâmico. A quantização FP8 block-wise armazena uma escala por bloco e seu inverso junto ao peso; a presença de _scale_inv no checkpoint é um marcador durável de que o tensor passou pelo caminho de quantização upstream. A versão upstream já informou quais tensores são seguros para quantizar — sem Hessiana, sem corpus de calibração, sem forward passes.

Para o GLM-5.3-Flash, esse conjunto são os lineares de MoE e de MLP denso, mais as quatro projeções de cada bloco deepseek_sparse_attention — q_a_proj, q_b_proj, kv_a_proj_with_mqa e o_proj — ao longo das 11 camadas esparsas nas profundidades 3, 7, 11 … 43, além do bloco MTP, 12 × 4 = 48 tensores. Todo o resto nunca carregou o marcador e permanece em BF16: as 34 camadas linear_attention, o indexador esparso e a torre de visão. A camada MTP — camada 45 — está incluída nos pesos quantizados em vez de ser exportada como um módulo separado.

O ponto que vale a pena roubar é o próprio truque. Um lançamento de modelo que quantiza seus pesos upstream já fez grande parte do trabalho de decidir o que pode ser quantizado; o _scale_inv, o marcador, é essa decisão, serializada no formato de arquivo. OrcaSAQ o lê de volta. É isso que torna o pipeline determinístico e transferível — qualquer modelo que forneça pesos FP8 com metadados de escala pode ser tratado pela mesma regra, sem pipeline de dados algum.

A pegadinha: configuração por módulo, não bits de nível superior.

Se você escreve seu próprio quantizador MLX — e esse é o público desta seção — a coisa mais útil no model card é um aviso: no nível superior, bits e group_size em config.json não são suficientes.

Ao todo, 37.338 tensores são quantizados. A atribuição é registrada em config.json → quantization como por módulo {group_size, bits} sobrescritas chaveadas pelo caminho do módulo MLX — por exemplo model.layers.3.mlp.switch_mlp.down_proj. Como o MLX funde os especialistas roteados de uma camada em um único switch_mlp, 173 entradas cobrem todos os 37.338 tensores.

E o carregador lê essas entradas no momento do carregamento. Se você quantizar o arquivo inteiro na largura base, todo tensor com precisão elevada — o expert compartilhado em base +2, toda projeção descendente em base +1 — resulta com a largura errada, e o modelo carrega com formato incorreto. O mapa por módulo não é uma otimização que se possa ignorar; ele é o caminho de carregamento. Ao escrever seu próprio quantizador, emita as substituições para cada tensor que a política eleva e verifique-as contra o padrão de nível superior antes de publicar.

A apólice se paga?

A evidência é nossa, medida em um único modelo: GLM-5.3-Flash, cada build dequantizado e executado através do mesmo glm5_next forward, de modo que a única variável é a quantização. Os números abaixo vêm do card do modelo e não são benchmarks de fornecedores nem números de terceiros — trate-os como um único ponto de dados, não como uma lei.

• Perplexidade, versus a referência FP8 em 2,7797: 6-bit 2,7864 (+0,24%), 4-bit 2,8620 (+2,96%), 3-bit 3,0566 (+9,96%), 2-bit 4,3622 (+56,9%).

• Concordância de token Top-1 com a referência, na mesma ordem: 97.76%, 96.13%, 92.06%, 86.56%.

{{1}}A leitura é exatamente o que a política prevê.{{/1}} Tudo até 3 bits degrada suavemente — essa é a assinatura de um orçamento de bits gasto nos tensores certos — e 2 bits é um precipício, porque abaixo de certo ponto os aumentos baseados em papéis param de cobrir o dano. {{2}}Em 4 bits, +2.96% de perplexidade para uma compilação aproximadamente 38% menor que a referência FP8 é uma troca genuinamente boa,{{/2}} e é a mesma política, aplicada de forma mais agressiva, que faz a compilação 2bit-lite de 102 GB carregar. {{3}}Profissionais independentes que quantizam a mesma base relatam a mesma ordem{{/3}} — os degraus superiores próximos ao piso de ruído, 4 bits real, porém modesto — {{4}}com números absolutos diferentes de um corpus de avaliação diferente.{{/4}}

O que é transferido para o seu próprio MoE

O raciocínio reutilizável, para um modelo que não é nosso:

• Encontre os especialistas sempre ativos. O que dispara em cada token — geralmente um especialista compartilhado ou sempre roteado — recebe seus bits mais generosos. Seu erro é reproduzido em todos os lugares.

• Encontre os gargalos residuais. A projeção que escreve no fluxo residual (tipicamente a projeção descendente de cada bloco MLP) recebe base +1. O erro ali é visto por todas as camadas mais profundas.

• Mantenha os caminhos de expansão e gating na base. Se uma saída for multiplicada elemento a elemento dentro de uma ativação, o erro de quantização nela é parcialmente absorvido.

• Nunca quantizado upstream significa nunca quantizado por você. Se a versão base carregou esses tensores em precisão total, carregue-os em precisão total.

• Use os metadados de escala da versão upstream como sua regra de seleção.Se o modelo base quantiza seus pesos, os marcadores de escala/escala inversa que ele deixa para trás são um mapa gratuito do que é quantizável — sem necessidade de busca de sensibilidade.

• Registre sobrescritas por módulo. Uma largura de bits global distorcerá cada tensor elevado no carregamento. Escreva o mapa de caminho do módulo.

E se você puder dispor de um conjunto de calibração, use-o para auditar a política — não para substituí-la. Execute uma quantização orientada por calibração com a mesma média de bits e verifique se a ordenação do prior do papel corresponde ao que os dados dizem. Em um modelo denso ou em uma arquitetura totalmente nova, essa auditoria é a diferença entre um padrão defensável e um palpite.

Onde OrcaSAQ é a escolha errada

Esta é a seção que deve manter o método honesto, porque o trade-off sem calibração é real.

• Quando o teto de qualidade supera a velocidade do pipeline, e você tem um conjunto de calibração. Métodos estilo GPTQ ou AWQ se adaptam às estatísticas reais de ativação do seu modelo e dos seus dados e, com a mesma média de bits, geralmente superam uma política fixa baseada em papéis. Se você quantiza um modelo uma única vez e nunca o re-quantiza, as horas extras de calibração são um custo único que compra qualidade mensurável.

• Modelos densos não-MoE. O prior de papéis — especialista compartilhado, gate/up/down — não existe, portanto a política perde a estrutura que a torna confiável. Resta "tudo o que é quantizado a montante permanece quantizado", o que é uma afirmação mais fraca.

• Modelos sem release upstream de FP8. A _scale_inv regra de seleção não tem nada em que se basear. Você precisa decidir o conjunto quantizável de outra forma, e o argumento de transferibilidade mecânica colapsa.

• Arquiteturas totalmente novas.Os priors são exatamente as suposições que podem não se sustentar. Um método orientado por calibração detectaria um tensor frágil que uma política baseada em papéis não percebeu; OrcaSAQ não o fará, porque nunca procura.

• Alvos abaixo de 3 bits. A política não te salva. Com 2 bits, o modelo está em +56,9% de perplexidade, independentemente de para onde os bits extras foram; a versão 2bit-lite existe para caber, não para qualidade.

• Quando você precisa de garantias.Garantias por tensor, orçamentos de treinamento com consciência de quantização (QAT) ou a melhor qualidade possível para um tamanho fixo, sem levar em conta o custo do pipeline, são território de calibração.

O resultado final

A quantização ciente da sensibilidade é a prática; OrcaSAQ é uma receita determinística e sem calibração para isso. As lições duradouras são os aumentos de especialista compartilhado e de projeção descendente, a regra mecânica _scale_inv de seleção, e a configuração por módulo que o carregador realmente lê. Para um MoE de 320 bilhões de parâmetros como o GLM-5.3-Flash, essa receita produz um build MLX de 4 bits com +2,96% de perplexidade — e o orcarouter/GLM-5.3-Flash-MLX repositório oferece a mesma política em 2, 3, 4 e 6 bits, com um build separado 2bit-lite para máquinas de 128 GB. Nosso GLM-5.3-Flash-MLX tutorial aborda qual build executar em qual máquina, passo a passo.

Se a sua prioridade é o último bit de qualidade em um tamanho fixo e você pode montar um corpus de calibração, use as ferramentas orientadas por calibração e deixe-as se adaptarem. Se a sua prioridade é uma quantização reprodutível, rápida e sem dados, que se transfere para a próxima arquitetura — ou você simplesmente não quer construir um pipeline de dados — a política baseada em papéis é uma opção padrão defensável. E se você preferir não quantizar em primeiro lugar, a precisão total GLM-5.3-Flash é servida através do OrcaRouter como z-ai/glm-5.3-flash. A escolha é sobre o quanto de pipeline você está disposto a executar, não sobre se a quantização ciente de sensibilidade vale a pena.

Prefere não quantizar nada? z-ai/glm-5.3-flash é o modelo de precisão total servido no OrcaRouter ao preço do provedor, com 0% de markup.