Mapas de diseño por tensor para GGUF: compara recetas, no nombres de archivo

Qué cambian realmente los mapas de diseño por tensor para GGUF

Los mapas de diseño por tensor para GGUF especifican qué tensores reciben qué tipos de cuantización. Un nombre de archivo familiar puede hacer que dos artefactos parezcan equivalentes cuando sus asignaciones de tensores no lo son.

La nota de lanzamiento de Bartowski del 10 de septiembre de 2026 explica las recetas de asignación de su generador. No redefine GGUF ni establece un estándar de nomenclatura para otros publicadores. El generador usa la forma del modelo y un prior de sensibilidad para asignar precisión, con mapas publicados junto a los artefactos compatibles.

Considera una migración hipotética, no un despliegue de Optijara: un operador reemplaza un GGUF antiguo con una descarga Q4_K_M más reciente. Una prueba básica pasa, pero el sufijo coincidente no establece asignaciones de tensores, costo de almacenamiento ni comportamiento de carga de trabajo coincidentes.

Mantén separados la familia de cuantización, la receta de tensores y el artefacto descargado. Una comparación con el mismo nombre revela diferencias de migración. Para comparar recetas con un costo de almacenamiento similar, selecciona candidatos bajo un límite declarado de bytes, incluso cuando sus sufijos difieran. Este artículo usa una receta MiniCPM5 fijada como ejemplo, no como recapitulación del lanzamiento del modelo. Optijara no realizó cuantización ni benchmarks.

Nombres antiguos, nuevos presupuestos de asignación

Lee _S, _M y _L en los términos de este generador

El lanzamiento describe S, M y L con reglas de tipo base de 90%, 70% y 50%. El generador fijado hace preciso el denominador: TIER_SHARE es una participación mínima de los bytes del cuerpo resuelto mantenida en el tipo base.

No son recuentos de tensores ni porcentajes del archivo GGUF completo. Los tensores de clase embedding, los tensores fijados y los datos retenidos requieren contabilidad separada. El solucionador no tiene un objetivo absoluto de bytes; el bitrate se informa después de resolver. Aquí, presupuesto de asignación significa una restricción de participación del cuerpo, no un tamaño de descarga prometido.

Las variantes históricas y los retiros se describen en What ships. No son afirmaciones sobre todos los publicadores de GGUF. Mantener los tipos de tensor IQ fuera de las recetas K-quant también es una elección de compatibilidad de Bartowski, no una restricción universal del formato.

Lee una receta Q4_K_M real

El JSON de diseño MiniCPM5 fijado registra base_type q4_k, variant shr0.70, rung_share 0.7 y auto_crush false. Su archivo tensor-types asigna output.weight a q6_k y token_embd.weight a q4_k. En el bloque cero, attn_k y attn_v usan q8_0 mientras que attn_q usa q4_k.

Por tanto, Q4_K_M no significa que todos los tensores sean Q4_K. El manifiesto registra por separado los bytes de archivo previstos y su comparación cuantizable, no fijada, de cuerpo más embedding. Ninguna de las dos es una medición del archivo descargado. Su generator_key es a69a855b91615d22 y llama_cpp_version es b10883. Estos identifican metadatos de receta inspeccionados, no tus pesos fuente ni tu runtime de servicio.

Qué respalda la evidencia del lanzamiento

KLD es fidelidad de distribución, no precisión en tareas

Bartowski informa divergencia KL entre probabilidades de token cuantizadas y BF16 en wikitext-2-raw con contexto 512. Las comparaciones directas usan 100 fragmentos, aumentando a 300 cuando las brechas son pequeñas. Estos son sus ajustes experimentales, no un presupuesto de evaluación universal.

Una KLD más baja indica distribuciones de referencia más cercanas bajo esa configuración. No establece precisión de extracción, calidad de contexto largo ni velocidad de inferencia. La documentación de perplexity de llama.cpp explica las comparaciones de logits de referencia, la dependencia de implementación y las estimaciones de incertidumbre.

El lanzamiento informa que los modelos densos por debajo de aproximadamente tres bits empataron mayormente con el método antiguo, mientras que las mejoras por encima de aproximadamente Q5 se acercaron al ruido. El prior usó inicialmente dos modelos Qwen pequeños, con correcciones posteriores derivadas de Granite. Léelas como límites de la evidencia del autor, no como garantías de rendimiento para todas las arquitecturas.

La iteración del lanzamiento no es cobertura universal

El artículo describe un fallo temprano del canario MiniCPM y correcciones posteriores del generador y del prior, luego identifica MiniCPM y Gryphe Pantheon como lanzamientos que usan el método. Un fallback anterior y un artefacto mapeado posterior reflejan iteración, no prueba de contradicción.

La tarjeta MiniCPM dice explícitamente que algunos archivos usan diseños calculados. Los archivos Q4_K_M fijados arriba proporcionan un ejemplo concreto. La tarjeta Gryphe Pantheon documenta por separado diseños y comparaciones canario. Ninguna establece cobertura mapeada para cada cuantización.

La expectativa de Bartowski de que la sensibilidad se transfiera entre formas coincidentes sigue siendo una hipótesis que debe probarse para fine-tunes y arquitecturas inusuales. El artículo no valida esa expectativa de forma independiente.

El Quant Recipe Migration Map

Fija la procedencia y compara las asignaciones

El Quant Recipe Migration Map propuesto por Optijara es un registro de decisión que conecta un artefacto de reemplazo con su receta, comparación y rollback. No es un estándar externo ni un benchmark ejecutado.

Compara asignaciones por nombre exacto de tensor, incluidos los tensores retenidos en mayor precisión. Conserva el orden de patrones: el generador fijado documenta que el primer patrón coincidente gana. Un conjunto sin ordenar puede perder información de reconstrucción.

El commit de Hugging Face 689246ff8d3d9b7f80495a9c883ac6f19a582630 fija los archivos de receta inspeccionados. No establece la revisión de los pesos fuente upstream. Del mismo modo, una ruta fuente local en el manifiesto no es una identidad de fuente portable.

Compara bytes reales antes de calidad

Declara el límite de almacenamiento antes de elegir reemplazos. Mantén constantes los pesos fuente y las entradas de calibración. Selecciona candidatos antiguos y mapeados cercanos, luego registra el desajuste de bytes restante. Coincidir nombres de archivo no sustituye esta contabilidad.

Si la coincidencia exacta de bytes no está disponible, grafica la KLD medida contra el tamaño medido para candidatos cercanos. Etiqueta la interpolación como una estimación, nunca como un benchmark observado. Mantén visibles la KLD bruta y los bits por peso. La frase del autor KLD per bit describe una curva de comparación sensible al tamaño; este artículo no establece una puntuación estandarizada de KLD dividida por bits.

La documentación de cuantización cubre matrices de importancia y overrides de tensores. Confirma el soporte de opciones en el ejecutable exacto usado para construir el artefacto. La documentación actual puede diferir de una compilación antigua.

Mantén el experimento dentro de una sola ruta de servicio. Nuestra comparación de rutas cuantizadas Qwen aborda el problema separado de moverse entre BF16, GGUF y SGLang. Cambiar rutas durante una prueba de receta añade otra explicación para las diferencias observadas.

Ejecuta canarios y conserva un cambio reversible

La política de canarios de Bartowski compara recetas mapeadas con sus propios cambios de llama.cpp en Q4_K_M, Q3_K_M e IQ2_XS, o el objetivo más pequeño. Un mapa se rechaza cuando un candidato mapeado queda por encima de la curva de comparación KLD contra bits más allá del ruido. Estos son sus objetivos y reglas de fallback, no umbrales universales de aplicación.

Reproducir ese experimento y comparar contra una descarga existente son ejercicios distintos. Nombra la línea base. Mantén constantes la referencia BF16, el corpus, la tokenización, el contexto, la selección de fragmentos y el evaluador. Conserva la salida bruta y la información de incertidumbre.

Luego prueba tareas representativas y comportamiento de runtime contra requisitos predeclarados. Conserva el artefacto verificado antiguo y la configuración de servicio. Una curva de fidelidad favorable no puede invalidar un requisito de carga de trabajo fallido.

Este registro ilustrativo no contiene resultados observados. Rellena los campos null con identificadores o mediciones 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
}

Mide la utilidad por separado de la KLD

Mantén columnas separadas para decisiones separadas

Una hoja de comparación no debe ocultar trade-offs dentro de una sola puntuación. Almacenamiento, fidelidad de distribución, aceptación de carga de trabajo, latencia y memoria responden preguntas distintas. Nuestro análisis del benchmark de Qdrant hace la distinción análoga entre fidelidad de referencia y utilidad de aplicación, usando mediciones distintas.

Para extracción, puntúa los campos requeridos. Para salida estructurada, separa la validez del esquema de la corrección del contenido. Incluye casos de contexto más largo cuando sea necesario: una prueba de referencia con contexto 512 no puede validarlos. Mantén tareas retenidas en vez de seleccionar repetidamente contra un solo conjunto de evaluación.

Para RAG local, congela los pasajes recuperados y la plantilla de prompt mientras cambias el GGUF. Puntúa corrección de respuesta, soporte de citas y abstención por separado. Eso mantiene los cambios de recuperación fuera de la comparación del generador.

Los bytes de archivo no son memoria pico

El tamaño descargado no explica la caché KV, el workspace del runtime ni el comportamiento del asignador de la carga de trabajo. Mide picos de host y dispositivo bajo los ajustes previstos. Nuestra guía de presupuesto de dispositivo MiniCPM5 trata esa pregunta de despliegue separada.

Mantén fijos los ajustes de servicio para las pruebas de tiempo. Registra por separado el comportamiento de arranque en frío y con calentamiento cuando ambos importen. Ni un artefacto más pequeño ni una KLD más baja prueban una inferencia más rápida. Si una actualización del runtime forma parte de la prueba, etiqueta esa variable adicional en vez de atribuir el cambio de tiempo solo a la asignación.

Errores comunes y límites restantes

Coincidir nombres de archivo en lugar de artefactos

Evita cambios basados solo en el nombre, interpretaciones de participaciones de cuerpo como si fueran de archivo completo y reemplazos de apariencia cercana para etiquetas retiradas. Usa asignaciones y bytes medidos. Los enlaces de ramas mutables ayudan al descubrimiento, pero no establecen reproducibilidad: conserva revisiones inmutables para la tarjeta, la receta y el artefacto usado en una decisión.

No confundas un generador fijado con pesos fuente fijados, ni almacenamiento tensorial previsto con tamaño de descarga medido. La procedencia faltante limita lo que una comparación puede establecer incluso cuando la prueba de aplicación pasa.

Tratar el prior como soporte para toda la arquitectura

Las limitaciones del lanzamiento identifican explícitamente tablas de n-gramas PLE y la MLA gated de Hy4 como brechas no manejadas. Las correcciones anteriores de modelos densos justifican canarios continuos, no afirmaciones de cobertura universal. Las pequeñas diferencias de mayor precisión también pueden ser difíciles de separar del ruido.

Deja tiempo para regeneración, validación y pruebas de compatibilidad de runtime. Un corpus de referencia estrecho puede omitir regresiones de carga de trabajo. Para documentos de evaluación privados, define reglas de acceso, logging y retención antes de probar; la ejecución local por sí sola no las resuelve.

El empaquetado de cuantización no es evidencia de nuevos derechos de licencia, superioridad de benchmark sobre Unsloth u otro publicador, ni ahorros prometidos. Cuando la procedencia o la evaluación estén incompletas, conserva el artefacto verificado existente en vez de describir la migración como validada.