Cartes de disposition par tenseur GGUF: comparez les recettes, pas les noms de fichiers

Ce que les cartes de disposition par tenseur GGUF changent vraiment

Les cartes de disposition par tenseur GGUF indiquent quels tenseurs recoivent quels types de quantification. Un nom de fichier familier peut faire paraitre deux artefacts équivalents alors que leurs allocations de tenseurs ne le sont pas.

La note de publication de Bartowski du 10 septembre 2026 explique les recettes d'allocation de son générateur. Elle ne redéfinit pas GGUF et n'établit pas de norme de nommage pour d'autres éditeurs. Le générateur utilise la forme du modèle et un prior de sensibilite pour attribuer la précision, avec des cartes publiees a côté des artefacts pris en charge.

Considerez une migration hypothétique, pas un déploiement Optijara: un operateur remplace un ancien GGUF par un nouveau téléchargement Q4_K_M. Un test de fumée réussit, mais le suffixe correspondant n'établit pas que les affectations de tenseurs, le coût de stockage ou le comportement de la charge de travail correspondent.

Gardez sépares la famille de quantification, la recette de tenseurs et l'artefact téléchargé. Une comparaison a nom identique revele les différences de migration. Pour comparer des recettes a coût de stockage similaire, sélectionnez des candidats sous une enveloppe d'octets declaree, meme lorsque leurs suffixes different. Cet article utilise une recette MiniCPM5 épinglée comme exemple, pas comme recapitulatif de lancement de modèle. Optijara n'a effectue aucune quantification ni aucun benchmark.

Anciens noms, nouveaux budgets d'allocation

Lisez _S, _M et _L selon les termes de ce générateur

La publication décrit S, M et L avec des regles de type de base a 90%, 70% et 50%. Le générateur épinglé precise le denominateur: TIER_SHARE est une part minimale des octets de corps resolus conserves au type de base.

Il ne s'agit pas de nombres de tenseurs ni de pourcentages du fichier GGUF complet. Les tenseurs de classe embedding, les tenseurs épinglés et les donnees conservees exigent une comptabilité distincte. Le solveur n'a pas de cible absolue en octets; le débit binaire est signale apres resolution. Ici, budget d'allocation signifie une contrainte de part du corps, pas une taille de téléchargement promise.

Les variantes historiques et les retraits sont décrits dans Ce qui est livre. Ce ne sont pas des affirmations concernant chaque éditeur GGUF. Exclure les types de tenseurs IQ des recettes K-quant est aussi un choix de compatibilite de Bartowski, pas une restriction universelle du format.

Lisez une vraie recette Q4_K_M

Le JSON de disposition MiniCPM5 épinglé enregistre base_type q4_k, variant shr0.70, rung_share 0.7 et auto_crush false. Son fichier tensor-types affecte output.weight a q6_k et token_embd.weight a q4_k. Dans le bloc zero, attn_k et attn_v utilisent q8_0 tandis que attn_q utilise q4_k.

Q4_K_M ne signifie donc pas que chaque tenseur est en Q4_K. Le manifeste enregistre séparement les octets de fichier predits et sa comparaison corps plus embedding quantifiable non épinglée. Aucun des deux n'est une mesure du fichier téléchargé. Son generator_key est a69a855b91615d22 et llama_cpp_version est b10883. Ces éléments identifient les metadonnees de recette inspectees, pas vos poids source ni votre runtime de service.

Ce que les preuves de la publication soutiennent

KLD est une fidélité de distribution, pas une exactitude de tache

Bartowski rapporte la divergence KL entre les probabilites de jetons quantifiees et BF16 sur wikitext-2-raw a contexte 512. Les comparaisons tete a tete utilisent 100 segments, puis passent a 300 quand les écarts sont proches. Ce sont ses paramètres experimentaux, pas un budget d'évaluation universel.

Une KLD plus basse indique des distributions de référence plus proches dans cette configuration. Elle n'établit pas l'exactitude d'extraction, la qualité en contexte long ni la vitesse d'inférence. La documentation perplexity de llama.cpp explique les comparaisons avec logits de référence, la dependance a l'implementation et les estimations d'incertitude.

La publication indique que les modèles denses sous environ trois bits etaient surtout a égalité avec l'ancienne methode, tandis que les améliorations au-dessus d'environ Q5 approchaient du bruit. Le prior utilisait initialement deux petits modèles Qwen, avec ensuite des corrections dérivées de Granite. Lisez ces éléments comme des limites des preuves de l'auteur, pas comme des garanties de performance valables pour toutes les architectures.

L'iteration de publication n'est pas une couverture universelle

L'article décrit l'échec initial du canari MiniCPM puis des corrections du générateur et du prior, puis identifie MiniCPM et Gryphe Pantheon comme des publications utilisant la methode. Un repli antérieur et un artefact cartographie ulterieur refletent une iteration, pas la preuve d'une contradiction.

La carte MiniCPM dit explicitement que certains fichiers utilisent des dispositions calculees. Les fichiers Q4_K_M épinglés ci-dessus fournissent un exemple concret. La carte Gryphe Pantheon documente séparement les dispositions et les comparaisons canari. Aucune des deux n'établit une couverture cartographiee pour chaque quantification.

L'attente de Bartowski selon laquelle la sensibilite se transfere entre formes correspondantes reste une hypothese a tester pour les fine-tunes et les architectures inhabituelles. L'article ne valide pas independamment cette attente.

La Quant Recipe Migration Map

Épinglez la provenance et comparez les affectations

La Quant Recipe Migration Map proposee par Optijara est un enregistrement de décision reliant un artefact de remplacement a sa recette, sa comparaison et son retour arriere. Ce n'est pas une norme externe ni un benchmark exécuté.

Comparez les affectations par nom exact de tenseur, y compris les tenseurs conserves a plus haute précision. Conservez l'ordre des motifs: le générateur épinglé documente que le premier motif correspondant l'emporte. Un ensemble non ordonne peut perdre les informations de reconstruction.

Le commit Hugging Face 689246ff8d3d9b7f80495a9c883ac6f19a582630 épingle les fichiers de recette inspectés. Il n'établit pas la revision amont des poids source. De meme, un chemin source local dans le manifeste n'est pas une identité source portable.

Comparez les octets réels avant la qualité

Declarez l'enveloppe de stockage avant de choisir des remplacements. Gardez les poids source et les entrees de calibration constants. Sélectionnez des candidats anciens et cartographies proches, puis consignez l'ecart d'octets restant. La correspondance des noms de fichiers ne remplace pas cette comptabilité.

Si une correspondance exacte en octets n'est pas disponible, tracez la KLD mesurée en fonction de la taille mesurée pour les candidats proches. Étiquetez l'interpolation comme une estimation, jamais comme un benchmark observé. Gardez visibles la KLD brute et les bits par poids. L'expression KLD par bit de l'auteur décrit une courbe de comparaison sensible a la taille; cet article n'établit pas de score standardise KLD divise par les bits.

La documentation de quantification couvre les matrices d'importance et les remplacements de tenseurs. Confirmez la prise en charge des options dans l'executable exact utilise pour construire l'artefact. La documentation actuelle peut différer d'un build plus ancien.

Gardez l'expérience dans une seule voie de service. Notre comparaison de route quantifiee Qwen traite le probleme distinct du passage entre BF16, GGUF et SGLang. Changer de route pendant un test de recette ajoute une autre explication aux différences observées.

Exécutez des canaris et conservez un basculement réversible

La politique canari de Bartowski compare les recettes cartographiees avec ses propres changements llama.cpp a Q4_K_M, Q3_K_M et IQ2_XS, ou avec la plus petite cible. Une carte est rejetee lorsqu'un candidat cartographie se situe au-dessus de la courbe de comparaison KLD-versus-bits au-dela du bruit. Ce sont ses cibles et ses regles de repli, pas des seuils applicatifs universels.

Reproduire cette expérience et comparer avec un téléchargement existant sont deux exercices différents. Nommez la baseline. Gardez constants la référence BF16, le corpus, la tokenisation, le contexte, la sélection des segments et l'évaluateur. Conservez la sortie brute et les informations d'incertitude.

Testez ensuite les taches representatives et le comportement runtime par rapport a des exigences pré-déclarées. Gardez l'ancien artefact verifie et la configuration de service. Une courbe de fidélité favorable ne peut pas l'emporter sur une exigence de charge de travail échouée.

Cet enregistrement illustratif ne contient aucun résultat observé. Remplissez les champs null avec des identifiants ou des mesures verifies.

{
  "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
}

Mesurez l'utilite séparement de la KLD

Gardez des colonnes séparees pour des décisions séparees

Une feuille de comparaison ne doit pas cacher les compromis dans un score unique. Le stockage, la fidélité de distribution, l'acceptation de la charge de travail, la latence et la mémoire répondent a des questions différentes. Notre analyse du benchmark Qdrant fait une distinction analogue entre fidélité de référence et utilite applicative, avec des mesures différentes.

Pour l'extraction, notez les champs requis. Pour la sortie structuree, séparez la validité du schéma de l'exactitude du contenu. Incluez des cas a contexte plus long lorsque nécessaire: un test de référence a contexte 512 ne peut pas les valider. Gardez des taches retenues plutot que de sélectionner de façon repetee contre un seul jeu d'évaluation.

Pour le RAG local, gelez les passages récupérés et le modèle de prompt pendant le remplacement du GGUF. Notez séparement l'exactitude de la reponse, le support des citations et l'abstention. Cela garde les changements de récupération hors de la comparaison du générateur.

Les octets du fichier ne sont pas la mémoire de pointe

La taille téléchargée ne tient pas compte du cache KV de la charge de travail, de l'espace de travail du runtime ni du comportement de l'allocateur. Mesurez les pointes hôte et appareil avec les paramètres prévus. Notre guide de budget appareil MiniCPM5 traite cette question de déploiement distincte.

Gardez les paramètres de service fixes pour les tests de temps. Consignez séparement le comportement au demarrage a froid et apres chauffe lorsque les deux comptent. Ni un artefact plus petit ni une KLD plus basse ne prouvent une inférence plus rapide. Si une mise a niveau du runtime fait partie du test, étiquetez cette variable supplementaire au lieu d'attribuer le changement de temps seulement a l'allocation.

Erreurs courantes et limites restantes

Faire correspondre les noms de fichiers plutot que les artefacts

Evitez les remplacements fondes seulement sur le nom, les interprétations du fichier entier a partir des parts de corps et les remplacements qui semblent les plus proches pour des libellés retirés. Utilisez les affectations et les octets mesures. Les liens de branche mutables aident a la découverte mais n'établissent pas la reproductibilité: conservez des revisions immuables pour la carte, la recette et l'artefact utilises dans une décision.

Ne confondez pas un générateur épinglé avec des poids source épinglés, ni le stockage de tenseurs predit avec la taille de téléchargement mesurée. Une provenance manquante limite ce qu'une comparaison peut établir, meme lorsque le test applicatif réussit.

Traiter le prior comme une prise en charge valable pour toute architecture

Les limites de la publication identifient explicitement les tables n-grammes PLE et le MLA gate de Hy4 comme des lacunes non traitees. Les corrections antérieures sur des modèles denses justifient des canaris continus, pas des affirmations de couverture universelle. Les petites différences de précision plus elevee peuvent aussi etre difficiles a séparer du bruit.

Prévoyez du temps pour la regeneration, la validation et les tests de compatibilite runtime. Un corpus de référence étroit peut manquer des régressions de charge de travail. Pour les documents d'évaluation prives, définissez les regles d'acces, de journalisation et de conservation avant les tests; l'exécution locale seule ne les regle pas.

L'emballage de quantification ne constitue pas une preuve de nouveaux droits de licence, de supériorité de benchmark sur Unsloth ou un autre éditeur, ni d'économies promises. Quand la provenance ou l'évaluation est incomplete, conservez l'artefact verifie existant au lieu de décrire la migration comme validée.