Pourquoi nous avons créé HivenetQuant

Un modèle open source ne passe pas directement de Hugging Face à la production.

Avant de pouvoir fonctionner efficacement sur un parc de GPU spécifique, une série de décisions doit être prise. Quelle précision est nécessaire pour le modèle ? Quelles couches peuvent être compressées sans risque ? Qu'advient-il des capacités de codage, de raisonnement, de vision ou d'utilisation d'outils après compression ? Un point de contrôle plus léger est-il réellement plus rapide sur le matériel qui l'hébergera ?

Nous prenons ces décisions pour les modèles que nous exploitons chez Hivenet.

Nous commençons désormais à publier les travaux qui sous-tendent ces choix.

HivenetQuant est notre nouveau compte Hugging Face dédié aux travaux d'optimisation de modèles de Hivenet. C'est là que nous publierons les points de contrôle de modèles optimisés, accompagnés des benchmarks, des configurations de service et des informations de reproductibilité que nous utilisons pour les évaluer.

Nos premières publications se concentrent sur la quantification NVFP4 pour les GPU NVIDIA Blackwell. L'objectif est pragmatique : rendre les modèles open source performants plus faciles et plus efficaces à exécuter, tout en mesurant les changements induits par ce processus.

C'est ce dernier point qui est le plus important.

Un modèle qui consomme moins de mémoire n'est d'aucune utilité si la compression altère discrètement les capacités dont vous aviez besoin au départ.

La quantification fait partie intégrante du déploiement d'un modèle

Les grands modèles sont généralement entraînés et publiés avec une précision numérique relativement élevée. Cela permet de préserver la précision, mais entraîne également une consommation de mémoire plus importante et un volume de données plus élevé circulant dans le GPU.

La quantification réduit cette précision.

Un poids de 16 bits, par exemple, peut être représenté en utilisant seulement quatre bits. Appliquée à des milliards de paramètres, la différence est considérable. Des poids plus légers permettent d'accueillir des modèles plus volumineux, des contextes plus longs, davantage de requêtes simultanées ou de réduire le nombre de GPU nécessaires.

La difficulté réside dans le choix des éléments pouvant être convertis en quatre bits sans risque.

Les différentes parties d'un modèle réagissent différemment à une réduction de précision. Une méthode uniforme peut fonctionner pour une architecture et échouer pour une autre. Elle peut préserver les connaissances générales tout en dégradant la génération de code, ou réduire la taille du modèle sans apporter le gain de vitesse escompté.

C'est pourquoi nous ne considérons pas la quantification comme une simple étape de conversion de fichier.

Pour les modèles que nous optimisons nous-mêmes, nous mesurons la sensibilité des différentes parties du réseau, adaptons la précision en conséquence, reconstruisons le modèle, puis comparons directement le résultat avec les poids d'origine.

HivenetQuant est l'endroit où nous rendons ces décisions transparentes.

En commençant par NVFP4 et Blackwell

Nos travaux actuels se concentrent sur le NVFP4, le format à virgule flottante quatre bits de NVIDIA pour les GPU Blackwell.

Le NVFP4 stocke les valeurs à l'aide d'une représentation à virgule flottante sur quatre bits tout en utilisant une mise à l'échelle plus fine pour préserver la plage numérique. Des groupes de 16 valeurs partagent une échelle FP8. Ce format est directement pris en charge par les Tensor Cores Blackwell, y compris les GPU RTX 5090 que nous utilisons pour ces travaux.

Cette combinaison le rend intéressant pour l'inférence. Il réduit les besoins en mémoire tout en permettant au matériel d'effectuer directement les calculs en précision réduite.

Cependant, le choix du NVFP4 laisse une question importante sans réponse.

Où devons-nous l'utiliser ?

Notre premier point de contrôle publié pour Qwen3.6-27B en est un bon exemple.

Ce que nous avons modifié dans Qwen3.6-27B

Pour HivenetQuant/Qwen3.6-27B-NVFP4, nous ne nous contentons pas de quantifier chaque couche disponible à la même précision.

Les couches MLP plus larges du modèle utilisent le NVFP4 à la fois pour les poids et les activations. Les couches d'attention et les couches récurrentes DeltaNet, plus sensibles, restent en FP8. L'encodeur de vision et la tête de décodage spéculatif MTP demeurent en BF16, tout comme plusieurs autres composants que nous avons délibérément laissés intacts.

Cette répartition repose sur des mesures.

Notre pipeline estime l'erreur introduite par chaque couche lors de sa réduction en NVFP4. Il évalue ensuite la part de cette erreur que GPTQ peut récupérer lors de la reconstruction et conserve une précision plus élevée là où elle apporte le gain de précision le plus significatif.

Le résultat est un modèle à précision mixte plutôt qu'une conversion globale en quatre bits.

Cette distinction n'aurait que peu de sens sans une vérification ultérieure.

Nous comparons donc le point de contrôle obtenu avec le modèle FP16 d'origine en utilisant les mêmes invites, outils d'évaluation, paramètres de décodage et environnement de service.

Nous accordons moins d'importance à l'obtention d'un score de référence impressionnant qu'à la réponse à une question plus utile :

Qu'est-ce que la quantification a changé ?

Les pertes sont faibles, mais elles ne sont pas uniformes

Sur l'ensemble des tâches testées, Qwen3.6-27B est resté proche du modèle FP16 d'origine.

Quelques exemples :

TaskFP16HivenetQuant NVFP4DifferenceMMLU-Pro84.9183.66-1.25GPQA-Diamond85.6684.24-1.41AIME2590.6790.670.00MMMU-Pro73.5373.07-0.47LiveCodeBench v685.4281.60-3.82NIAH long-context retrieval100.0099.50-0.50

La moyenne ne raconte qu'une partie de l'histoire. Les tâches individuelles nous en disent bien plus.

Les connaissances, les mathématiques de compétition, le raisonnement visuel et la récupération de contexte long sont restés proches du FP16 lors de ces tests. Le codage s'est révélé plus sensible.

Nous pensons que cette différence mérite d'être publiée.

Une légère régression moyenne peut masquer un changement plus important dans la charge de travail qui vous intéresse réellement. Si vous déployez un modèle de codage, une perte de quatre points est plus significative qu'une moyenne regroupant des mathématiques, des connaissances, de la vision et des tâches sans rapport.

Cela nous donne également un point concret à améliorer.

La quantification ne nous intéresse pas en tant que compétition pour obtenir le plus petit point de contrôle possible. Le compromis pertinent est l'efficacité gagnée par rapport aux capacités sacrifiées.

Les modèles plus petits peuvent être plus rapides, mais tout dépend de la charge de travail

Nous évaluons également les points de contrôle optimisés sur le matériel pour lequel ils sont conçus.

Pour le modèle Qwen3.6-27B sur des GPU RTX 5090, la version NVFP4 a atteint 116 jetons par seconde lors de notre test de décodage à flux unique avec un contexte de 1 000 jetons, contre 83 jetons par seconde pour le FP16 dans la même configuration.

Avec dix requêtes simultanées, le débit de sortie global est passé de 484 à 688 jetons par seconde.

Il s'agit dans les deux cas d'une amélioration d'environ 1,4 fois.

Le traitement des invites s'est comporté différemment. Avec une entrée de 1 000 jetons, la différence de vitesse était minime. Avec un contexte de 10 000 jetons, les performances de pré-remplissage sont passées de 6 266 à 8 701 jetons par seconde.

C'est pourquoi nous évitons de décrire la quantification par un chiffre de vitesse universel.

La longueur du contexte, le traitement par lots, la bande passante mémoire, l'architecture du modèle et les noyaux utilisés influencent tous le résultat.

Cette leçon est devenue encore plus évidente lorsque nous avons commencé à tester différentes architectures de modèles.

Une recette unique ne convient pas à tous les modèles

Nos premiers travaux sur les modèles denses suggéraient que la réduction des poids et des activations à quatre bits pouvait offrir une combinaison utile d'économies de mémoire et de vitesse.

Cela s'est vérifié pour les modèles denses tels que Qwen3.6-27B et le modèle Gemma 31B que nous avons testés.

Les modèles de type « mixture-of-experts » ont changé la donne.

Un modèle MoE peut contenir des dizaines de milliards de paramètres tout en n'en activant qu'une fraction pour chaque jeton. Cela déplace les goulots d'étranglement informatiques.

Lors de nos tests, la réduction de la précision d'activation sur ces modèles a apporté beaucoup moins d'avantages. La surcharge liée à la quantification et aux noyaux peut annuler les gains de performance.

Pour les architectures MoE que nous avons testées, une approche hybride utilisant des poids sur quatre bits avec des activations de plus haute précision a offert le meilleur compromis.

Cela a modifié notre pipeline.

Nous continuons d'utiliser la sélection de précision basée sur la sensibilité lorsque les mesures montrent qu'elle est bénéfique. Pour les modèles MoE à experts regroupés, nous utilisons plutôt une recette hybride plus directe.

Il n'y a aucune raison d'effectuer une optimisation simplement parce qu'elle semble sophistiquée. Elle doit prouver sa valeur par les résultats.

C'est l'une des raisons principales pour lesquelles nous avons créé HivenetQuant. L'optimisation de modèle devient bien plus utile lorsqu'elle est traitée comme une ingénierie expérimentale plutôt que comme une recette figée.

Le calibrage est également crucial

L'architecture du modèle n'est pas la seule variable.

La quantification post-entraînement nécessite des données de calibrage pour déterminer comment les valeurs numériques originales doivent être représentées avec une précision moindre.

L'ensemble de calibrage influence donc le point de contrôle (checkpoint).

Nous avons constaté qu'un calibrage basé sur un seul type de contenu ne se généralisait pas assez bien à l'ensemble des charges de travail que nous souhaitions préserver. Notre mélange actuel inclut du texte web, du contenu encyclopédique, du code, des mathématiques et des données conversationnelles.

Nous vérifions également que ce matériel de calibrage ne chevauche pas les questions de référence que nous utilisons ultérieurement pour évaluer le modèle.

Cette séparation est facile à négliger.

Si des données d'évaluation s'infiltrent dans le calibrage, le benchmark résultant peut faire paraître une recette de quantification meilleure qu'elle ne l'est, sans pour autant nous donner une image fidèle de son comportement sur des tâches inédites.

Une bonne optimisation de modèle dépend autant de la rigueur de la mesure que des formats numériques.

Publier les preuves avec le point de contrôle

C'est là que le compte Hugging Face devient important.

Nous ne voulons pas que HivenetQuant devienne une simple liste de noms de modèles accompagnés d'affirmations selon lesquelles ils sont « optimisés » ou « quasi sans perte ».

Pour les points de contrôle que nous publions, nous voulons que les développeurs puissent comprendre comment ces conclusions ont été atteintes.

Cela signifie publier les choix de précision, les comparaisons avec le modèle original, la configuration de service et les informations nécessaires pour reproduire l'évaluation.

Notre fiche de modèle Qwen3.6-27B, par exemple, inclut la comparaison FP16 en matière de connaissances, de raisonnement, de codage, de vision, d'utilisation d'outils, de récupération de contexte long et de décodage spéculatif. Elle documente également la configuration vLLM utilisée pour le service et renvoie vers la configuration détaillée pour la reproductibilité.

Le benchmark inclut aussi bien les régressions que les améliorations.

Nous pensons que c'est la manière utile de publier des modèles quantifiés.

Si le codage se dégrade, la fiche doit le mentionner.

Si un format permet d'économiser de la mémoire mais n'améliore pas une phase particulière de l'inférence, cela doit également figurer dans les résultats.

Et si un futur modèle nécessite une recette complètement différente de celle qui a fonctionné la semaine dernière, le processus doit être capable de le découvrir.

Quelle est la suite pour HivenetQuant

HivenetQuant est récent, et le compte se développera parallèlement à nos travaux sur l'inférence.

Nous l'utiliserons pour publier des modèles ouverts optimisés que nous avons créés ou vérifiés indépendamment, accompagnés des mesures qui les justifient.

Certains utiliseront NVFP4. Différents matériels et architectures de modèles nous conduiront à d'autres approches au fil du temps. Le format en lui-même n'est pas l'essentiel.

Nous nous intéressons à la couche située entre la publication d'un modèle ouvert et le système qui finit par le servir : choix de précision, comportement matériel, performances, reproductibilité et les petites décisions d'ingénierie qui déterminent si un modèle efficace se comporte toujours comme le modèle que vous aviez l'intention de déployer.

La majeure partie de ce travail reste généralement au sein des équipes d'infrastructure.

Nous pensons qu'une partie mérite d'être publiée.

Vous pouvez suivre les modèles et les résultats des benchmarks sur HivenetQuant sur Hugging Face.