Humanizer 12B avec 8, 16 ou 32 Go : quel fichier GGUF télécharger

Une décision que la plupart des gens affrontent avec un modèle local

Imaginez un portable avec 16 Go de mémoire et l’envie d’essayer un réécrivain local. Vous ouvrez la page du modèle et trouvez non pas un téléchargement mais six, de 3,9 Go à 23,8 Go, aux noms comme Q6_K et IQ2_XS-QAT. C’est une hypothèse, mais c’est la situation de presque tout le monde la première fois qu’on rencontre un modèle quantifié. La fiche d’humanizer aide mieux que la plupart, car elle donne à chaque fichier une taille, une mémoire de pointe mesurée, un score de fidélité et un nombre d’erreurs factuelles, et dit clairement à qui chaque fichier s’adresse. Cet article lit ce tableau et explique ce que signifient ses colonnes. Pour le modèle lui-même, et jusqu’où croire ses affirmations vedettes, voyez ce que disent vraiment les chiffres d’humanizer.

Le tableau

L’accord top-1 indique la fréquence à laquelle le token suivant le plus probable du fichier correspond à celui du modèle bf16 complet, en moyenne sur l’anglais et le chinois. « Signalées » est le nombre de réécritures anglaises, sur 420, dans lesquelles un juge LLM strict a trouvé un problème factuel. La mémoire de pointe est la mesure des auteurs avec llama-server sur Metal sur un M5 Max, avec les réglages de l’application, pendant une réécriture. Tous les chiffres sont ceux de l’auteur.

Pourquoi les petits fichiers ne sont pas de simples copies compressées

La fiche fait une distinction qui explique pourquoi le milieu et le bas du tableau se comportent mieux qu’on ne l’attendrait. Elle dit que la plupart des fichiers GGUF viennent d’une seule passe de llama-quantize qui arrondit chaque poids au type visé. Les fichiers 2 bits, Q3 et Q4_K_M vont plus loin. Pour les fichiers 2 bits et Q3, l’auteur a mesuré combien chaque tenseur de poids nuit au modèle quand on le comprime, et a donné plus de bits aux tenseurs sensibles et moins aux robustes. Les trois ont ensuite été entraînés couche par couche pour reproduire le modèle complet, ce qui est de l’entraînement conscient de la quantification, et distillés à partir du modèle bf16 complet sur des données de réécriture en anglais et en chinois. Q6_K et Q8_0 sont des builds standard, car à ces tailles, dit la fiche, il ne reste presque rien à récupérer.

L’effet, d’après la fiche, est mesurable. Pour le fichier 2 bits, un build standard de même taille choisit le même token suivant que bf16 dans 70 % des cas ; les étapes supplémentaires portent ce chiffre à 81 %, puis 85, puis 87. Les détails, y compris la divergence KL et les vérifications de faits par fichier, sont dans un document sur la quantification que la fiche référence ; nous ne les avons pas vérifiés.

Le résultat reste un fichier GGUF ordinaire que tout llama.cpp récent peut exécuter, ce qui compte si vous ne voulez pas dépendre de l’application de l’auteur. La fiche note aussi que les fichiers ont leur propre dépôt, de sorte que les commandes de téléchargement existantes continuent de fonctionner.

Que choisir pour votre mémoire

Les recommandations de la fiche sont précises et concordent avec le tableau. Avec 32 Go ou plus, choisissez Q8_0, que la fiche qualifie de recommandé et de meilleure qualité. Avec 16 Go, choisissez Q6_K, qui n’a, dit la fiche, aucune perte mesurable. Autour de 14 Go, ou quand le disque est juste, Q4_K_M, avec une légère perte et un entraînement conscient de la quantification. Avec 12 Go, Q3-QAT, qui a une petite perte et quelques erreurs factuelles de plus en anglais. À 8 Go, le plus petit fichier, IQ2_XS-QAT. L’application fait l’appariement pour vous : au premier lancement, elle propose l’une de cinq tailles selon votre mémoire, jusqu’aux machines de 8 Go, la télécharge une fois, puis fonctionne hors ligne.

Deux mises en garde accompagnent la liste. D’abord, la colonne mémoire est une mesure sur Mac qui laisse de la place au système ; la fiche dit que l’application garde environ 4 Go libres. Sur une machine Windows ou Linux avec un GPU dédié, c’est la mémoire vidéo qui compte, et la seule réponse fiable est de tester. Ensuite, deux lignes sont des estimations et non des mesures : la mémoire de pointe de Q6_K et de bf16. L’estimation d’environ 11 Go pour Q6_K est le chiffre sur lequel vous vous appuyez si vous choisissez l’option 16 Go.

Lire les colonnes de qualité sans se tromper

Les nombres de réécritures signalées ne descendent pas en ligne droite, et la fiche dit pourquoi. bf16 en a 52 et Q8_0 en a 44, ce que la fiche décrit comme équivalent au bruit près. Q8_0, Q6_K et Q4_K_M sont dans le bruit de bf16 ; Q3 et 2 bits commettent quelques erreurs de plus. Le résumé honnête est que les trois plus gros fichiers sont difficiles à distinguer sur les faits, et que les deux plus petits sacrifient quelque chose que le compte rend visible, de 64 à 70 sur 420.

La colonne du détecteur réserve une surprise dont la fiche parle avec soin. Sur une mesure distincte, les mêmes 60 brouillons anglais passés dans Originality.ai à son réglage le plus strict, Q8_0 en avait 7 signalés sur 60, Q3-QAT en avait 4, le fichier 2 bits en avait 0 et bf16 en avait 4. Le plus petit fichier a obtenu le meilleur score, ce que la fiche signale comme le score de détecteur le plus bas, accompagné de quelques erreurs factuelles de plus. C’est un rappel que scores de détecteur et fidélité factuelle peuvent tirer en sens inverse, et que la fiche dit elle-même que les détecteurs changent et qu’il s’agit d’une mesure à une date. Si votre travail comporte des nombres et des noms, c’est la colonne des faits qu’il faut peser.

La taille du fichier n’est pas non plus toute la facture mémoire. La colonne de mémoire de pointe est plus élevée que la taille du fichier sur chaque ligne, car l’exécution a besoin de place pour le contexte et les tampons en plus des poids. La fiche recommande un contexte de 8192 tokens, couvrant ensemble l’instruction, le brouillon et la réécriture, et dit de découper les longs documents aux sauts de paragraphe. Une bonne habitude avec tout modèle local est de considérer la taille du fichier comme un plancher, pas un budget, et de garder de la marge.

D’autres moyens de le faire tourner plus vite

La fiche documente plusieurs voies en dehors de l’application. llama.cpp est la voie recommandée, avec une commande de téléchargement, une commande de serveur et un court client Python. Pour la puce Apple, il existe une voie MLX qui convertit les poids en 8 bits en local. Pour Ollama, la fiche avertit qu’Ollama ignore le gabarit de conversation stocké dans le fichier et appliquerait le sien, ce qui casse ce modèle ; elle fournit donc un Modelfile avec le bon gabarit. Pour un flux en ligne de commande avec de longs documents, un outil compagnon réécrit la prose morceau par morceau, conserve titres, code, tableaux et liens, et signale tout morceau où un nombre a disparu.

Un projet communautaire mérite d’être cité, avec la réserve de la fiche elle-même que nous ne l’avons pas mesuré. Un contributeur a entraîné un modèle de brouillon à décodage spéculatif pour humanizer, annonçant environ 1,5 fois la vitesse sur un M5 Pro avec MLX, 34,5 tokens par seconde contre 22,8, et une sortie identique token pour token à celle d’humanizer seul dans son test. Il fonctionne avec le modèle principal et demande la configuration MLX décrite dans sa propre fiche.

Notre avis

Prenez le plus gros fichier que votre machine contient avec de la marge. D’après les mesures de l’auteur, passer de Q8_0 à Q6_K coûte 12 réécritures signalées de plus sur 420, passer à Q4_K_M en coûte 14, et passer à 2 bits en coûte 26. Pour un travail avec nombres et noms, c’est cet écart qu’il faut peser, pas la taille du fichier. Si vous êtes quelque part au milieu, la recommandation Q6_K pour 16 Go ressemble au bon compromis de ce tableau : proche de bf16 en fidélité et en vérification des faits, pour moins de la moitié de sa taille.

Pour continuer la lecture

Tous les articles, du plus récent au plus ancien, sont sur l’index du blog Front.

• Humanizer 12B : les affirmations passées au crible: Ce que les sources étayent des affirmations sur le modèle local Humanizer 12B.
• Ling 3.1 Flash : ce que demande son exécution: Le matériel nécessaire pour exécuter Ling 3.1 Flash.
• Chronologie de DeepSeek V4.1 Flash 1017: La sortie de V4.1 Flash par DeepSeek, sa mise à jour du 17 octobre, ses prix et ses paramètres.
• Chronologie de Meta Muse Spark Open: La publication de Meta Muse Spark Open, dans l’ordre du temps.
• Chronologie de Reflection Beam 501B: La publication des poids de Reflection Beam 501B, dans l’ordre du temps.

Questions fréquentes

Sources

• jialinyyzz/humanizer model card
• jialinyyzz/humanizer-GGUF