Mapas de Layout Por Tensor GGUF: Compare Receitas, Não Nomes de Arquivos

O que os mapas de layout por tensor GGUF realmente mudam

Mapas de layout por tensor GGUF especificam quais tensores recebem quais tipos de quantização. Um nome de arquivo familiar pode fazer dois artefatos parecerem equivalentes quando suas alocações de tensores não são.

A nota de lançamento de Bartowski de 10 de setembro de 2026 explica as receitas de alocação de seu gerador. Ela não redefine o GGUF nem estabelece um padrão de nomenclatura para outros publicadores. O gerador usa o formato do modelo e um prior de sensibilidade para atribuir precisão, com mapas publicados ao lado dos artefatos compatíveis.

Considere uma migração hipotética, não uma implantação da Optijara: um operador substitui um GGUF mais antigo por um download Q4_K_M mais novo. Um teste rápido passa, mas o sufixo correspondente não estabelece atribuições de tensor, custo de armazenamento ou comportamento de carga de trabalho equivalentes.

Mantenha a família de quantização, a receita de tensor e o artefato baixado separados. Uma comparação com o mesmo nome revela diferenças de migração. Para comparar receitas com custo de armazenamento semelhante, selecione candidatos dentro de um envelope de bytes declarado, mesmo quando seus sufixos forem diferentes. Este artigo usa uma receita MiniCPM5 fixada como exemplo, não como uma recapitulação de lançamento de modelo. A Optijara não realizou quantização nem benchmarks.

Nomes antigos, novos orçamentos de alocação

Leia _S, _M e _L nos termos deste gerador

A publicação descreve S, M e L com regras de tipo base de 90%, 70% e 50%. O gerador fixado torna o denominador preciso: TIER_SHARE é uma parcela mínima dos bytes do corpo resolvido mantida no tipo base.

Essas não são contagens de tensores nem porcentagens do arquivo GGUF completo. Tensores de classe embedding, tensores fixados e dados retidos exigem contabilização separada. O solucionador não tem alvo absoluto de bytes; a taxa de bits é relatada após a resolução. Aqui, orçamento de alocação significa uma restrição de parcela do corpo, não um tamanho de download prometido.

As variantes históricas e as aposentadorias são descritas em O que é distribuído. Elas não são afirmações sobre todos os publicadores GGUF. Manter tipos de tensor IQ fora das receitas K-quant também é uma escolha de compatibilidade de Bartowski, não uma restrição universal do formato.

Leia uma receita Q4_K_M real

O JSON de layout MiniCPM5 fixado registra base_type q4_k, variant shr0.70, rung_share 0.7 e auto_crush false. Seu arquivo tensor-types atribui output.weight a q6_k e token_embd.weight a q4_k. No bloco zero, attn_k e attn_v usam q8_0 enquanto attn_q usa q4_k.

Q4_K_M, portanto, não significa que todo tensor é Q4_K. O manifesto registra separadamente bytes de arquivo previstos e sua comparação de corpo mais embedding quantizável e não fixado. Nenhum dos dois é uma medição do arquivo baixado. Seu generator_key é a69a855b91615d22 e llama_cpp_version é b10883. Eles identificam metadados de receita inspecionados, não seus pesos de origem nem seu runtime de serviço.

O que a evidência da publicação sustenta

KLD é fidelidade de distribuição, não precisão de tarefa

Bartowski relata divergência KL entre probabilidades de tokens quantizadas e BF16 em wikitext-2-raw com contexto 512. Comparações diretas usam 100 blocos, aumentando para 300 quando as diferenças são pequenas. Essas são as configurações experimentais dele, não um orçamento de avaliação universal.

KLD menor indica distribuições de referência mais próximas sob essa configuração. Isso não estabelece precisão de extração, qualidade em contexto longo nem velocidade de inferência. A documentação de perplexidade do llama.cpp explica comparações de logits de referência, dependência de implementação e estimativas de incerteza.

A publicação relata que modelos densos abaixo de aproximadamente três bits empataram em grande parte com o método antigo, enquanto melhorias acima de aproximadamente Q5 se aproximaram do ruído. O prior inicialmente usou dois modelos Qwen pequenos, com correções posteriores derivadas de Granite. Leia isso como limites da evidência do autor, não como garantias de desempenho para arquiteturas inteiras.

Iteração de lançamento não é cobertura universal

O artigo descreve uma falha inicial do canário MiniCPM e correções posteriores no gerador/prior, depois identifica MiniCPM e Gryphe Pantheon como lançamentos que usam o método. Um fallback anterior e um artefato mapeado posterior refletem iteração, não prova de contradição.

O cartão MiniCPM afirma explicitamente que alguns arquivos usam layouts calculados. Os arquivos Q4_K_M fixados acima fornecem um exemplo concreto. O cartão Gryphe Pantheon documenta separadamente layouts e comparações de canário. Nenhum dos dois estabelece cobertura mapeada para toda quantização.

A expectativa de Bartowski de que a sensibilidade se transfira entre formatos correspondentes permanece uma hipótese a ser testada para fine-tunes e arquiteturas incomuns. O artigo não valida essa expectativa de forma independente.

O Mapa de Migração de Receita de Quantização

Fixe a proveniência e compare as atribuições

O Mapa de Migração de Receita de Quantização proposto pela Optijara é um registro de decisão que conecta um artefato substituto à sua receita, comparação e reversão. Ele não é um padrão externo nem um benchmark executado.

Compare atribuições por nome exato de tensor, incluindo tensores retidos em maior precisão. Preserve a ordem dos padrões: o gerador fixado documenta que o primeiro padrão correspondente vence. Um conjunto não ordenado pode perder informações de reconstrução.

O commit 689246ff8d3d9b7f80495a9c883ac6f19a582630 do Hugging Face fixa os arquivos de receita inspecionados. Ele não estabelece a revisão dos pesos de origem upstream. Da mesma forma, um caminho de origem local no manifesto não é uma identidade de origem portátil.

Compare bytes reais antes da qualidade

Declare o envelope de armazenamento antes de escolher substituições. Mantenha constantes os pesos de origem e as entradas de calibração. Selecione candidatos antigos e mapeados próximos, depois registre a incompatibilidade de bytes restante. Nomes de arquivo correspondentes não substituem essa contabilização.

Se a correspondência exata de bytes não estiver disponível, plote o KLD medido contra o tamanho medido para candidatos próximos. Rotule a interpolação como estimativa, nunca como benchmark observado. Mantenha KLD bruto e bits por peso visíveis. A expressão do autor KLD por bit descreve uma curva de comparação sensível ao tamanho; este artigo não estabelece uma pontuação padronizada de KLD dividido por bits.

A documentação de quantização cobre matrizes de importância e substituições de tensor. Confirme o suporte de opções no executável exato usado para criar o artefato. A documentação atual pode diferir de uma build mais antiga.

Mantenha o experimento dentro de uma única rota de serviço. Nossa comparação de rota quantizada Qwen aborda o problema separado de mover entre BF16, GGUF e SGLang. Mudar rotas durante um teste de receita adiciona outra explicação para diferenças observadas.

Execute canários e mantenha uma troca reversível

A política de canário de Bartowski compara receitas mapeadas com suas próprias alterações no llama.cpp em Q4_K_M, Q3_K_M e IQ2_XS, ou o menor alvo. Um mapa é rejeitado quando um candidato mapeado fica acima da curva de comparação KLD versus bits além do ruído. Esses são os alvos e regras de fallback dele, não limites universais de aplicação.

Reproduzir esse experimento e comparar contra um download existente são exercícios diferentes. Nomeie a linha de base. Mantenha constantes a referência BF16, corpus, tokenização, contexto, seleção de blocos e avaliador. Preserve a saída bruta e as informações de incerteza.

Depois teste tarefas representativas e comportamento de runtime contra requisitos pré-declarados. Mantenha o artefato verificado antigo e a configuração de serviço. Uma curva de fidelidade favorável não pode anular um requisito de carga de trabalho reprovado.

Este registro ilustrativo não contém resultados observados. Preencha campos null com identificadores ou medições verificados.

{
  "framework": "Quant Recipe Migration Map",
  "status": "proposed_not_executed",
  "provenance": {"sourceRevision": null, "generatorCommit": null, "priorRevision": null},
  "oldArtifact": {"sha256": null, "bytes": null},
  "candidateArtifact": {"sha256": null, "bytes": null},
  "recipeDiff": null,
  "comparisonSettings": {"reference": null, "corpus": null, "context": null, "runtimeRevision": null},
  "measurements": {"kld": null, "taskQuality": null, "latency": null, "peakMemory": null},
  "rollbackArtifact": null
}

Meça utilidade separadamente do KLD

Mantenha colunas separadas para decisões separadas

Uma planilha de comparação não deve esconder trade-offs dentro de uma única pontuação. Armazenamento, fidelidade de distribuição, aceitação da carga de trabalho, latência e memória respondem a perguntas diferentes. Nossa análise de benchmark Qdrant faz a distinção análoga entre fidelidade de referência e utilidade de aplicação, usando medições diferentes.

Para extração, pontue campos obrigatórios. Para saída estruturada, separe validade de esquema de correção de conteúdo. Inclua casos de contexto mais longo quando necessário: um teste de referência com contexto 512 não pode validá-los. Mantenha tarefas reservadas em vez de selecionar repetidamente contra um único conjunto de avaliação.

Para RAG local, congele as passagens recuperadas e o modelo de prompt enquanto troca o GGUF. Pontue correção da resposta, suporte de citações e abstenção separadamente. Isso mantém mudanças de recuperação fora da comparação do gerador.

Bytes de arquivo não são memória de pico

O tamanho baixado não considera o cache KV da carga de trabalho, o workspace de runtime ou o comportamento do alocador. Meça picos de host e dispositivo sob as configurações pretendidas. Nosso guia de orçamento de dispositivo MiniCPM5 discute essa questão separada de implantação.

Mantenha configurações de serviço fixas para testes de tempo. Registre comportamento de partida fria e aquecido separadamente quando ambos importarem. Nem um artefato menor nem KLD mais baixo provam inferência mais rápida. Se uma atualização de runtime fizer parte do teste, rotule essa variável adicional em vez de atribuir a mudança de tempo apenas à alocação.

Erros comuns e limites restantes

Comparar nomes de arquivo em vez de artefatos

Evite trocas baseadas apenas em nome, interpretações de arquivo inteiro para parcelas do corpo e substituições que apenas parecem próximas para rótulos aposentados. Use atribuições e bytes medidos. Links de branch mutáveis ajudam na descoberta, mas não estabelecem reprodutibilidade: retenha revisões imutáveis do cartão, da receita e do artefato usados em uma decisão.

Não confunda um gerador fixado com pesos de origem fixados, nem armazenamento de tensor previsto com tamanho de download medido. Proveniência ausente limita o que uma comparação pode estabelecer, mesmo quando o teste de aplicação passa.

Tratar o prior como suporte para toda arquitetura

As limitações da publicação identificam explicitamente tabelas n-gram PLE e o MLA gated do Hy4 como lacunas não tratadas. Correções anteriores em modelos densos justificam canários contínuos, não afirmações de cobertura universal. Diferenças pequenas em maior precisão também podem ser difíceis de separar do ruído.

Reserve tempo para regeneração, validação e testes de compatibilidade de runtime. Um corpus de referência estreito pode não capturar regressões de carga de trabalho. Para documentos de avaliação privados, defina regras de acesso, registro e retenção antes dos testes; a execução local por si só não resolve isso.

Empacotamento de quantização não é evidência de novos direitos de licença, superioridade em benchmark sobre Unsloth ou outro publicador, nem economias prometidas. Quando a proveniência ou a avaliação estiver incompleta, retenha o artefato verificado existente em vez de descrever a migração como validada.