DFloat11 : compression sans perte pour l’inférence GPU qui réduit les LLM à 70 % de leur taille

• Les grands LLM sont difficiles à déployer en raison des limites de mémoire GPU, mais DFloat11 réduit les poids BFloat16 à environ 70 % de leur taille tout en conservant des sorties identiques bit à bit à l’original
• L’idée centrale est que l’exposant 8 bits de BFloat16 ne contient en réalité qu’environ 2,6 bits d’information ; le signe et la mantisse sont préservés, et seul l’exposant est compressé par codage de Huffman
• L’encodage à longueur variable pouvant facilement devenir un goulot d’étranglement sur GPU, DFloat11 est adapté à l’inférence parallèle grâce à des LUT hiérarchiques, un noyau en deux étapes et une décompression par bloc transformer
• Sur Llama 3.3, Qwen 3, Mistral 3, DeepSeek R1 Distilled, FLUX.1, Stable Diffusion 3.5, etc., il confirme une réduction d’environ 30 % de la taille du modèle tout en préservant les sorties originales
• Par rapport aux alternatives avec offload CPU, le débit de génération de tokens est 2,3 à 46,2 fois supérieur, et permet l’inférence sans perte du Llama 3.1 405B, d’environ 810 Go, sur un seul nœud de 8 GPU de 80 Go

---

Le goulot d’étranglement mémoire visé par DFloat11

• Les modèles de fondation comme les LLM et les Diffusion Models grossissent rapidement, ce qui les rend difficiles à déployer efficacement sur du matériel contraint en mémoire
• Llama 3.1 405B stocke ses 405 milliards de paramètres au format BFloat16 et nécessite environ 810 Go de mémoire pour une inférence complète
  • Cela dépasse la capacité d’un serveur GPU haut de gamme courant équipé de 8 GPU de 80 Go
  • Dès que plusieurs nœuds deviennent nécessaires, les coûts de déploiement et les contraintes d’accès augmentent
• DFloat11 vise à compresser les modèles BFloat16 à environ 70 % de leur taille d’origine, tout en préservant 100 % de la précision sur n’importe quelle tâche

Une approche différente de la quantification avec perte

• La quantification est une méthode de compression avec perte qui réduit la mémoire en abaissant la précision des poids
  • Elle peut fortement réduire l’usage mémoire et accélérer l’inférence, mais introduit des erreurs d’approximation
  • La perte de précision dépend du modèle de base, de la méthode de quantification, du benchmark d’évaluation et de la largeur en bits ciblée, ce qui la rend difficile à prédire
• Par exemple, appliquer SmoothQuant 8-bit à DeepSeek-R1-Distill-Qwen-1.5B entraîne une baisse de 9,09 % de la précision moyenne sur les tâches de raisonnement
• Même lorsque les indicateurs globaux de précision sont similaires, un modèle quantifié peut produire des comportements de réponse différents de l’original
  • Dutta et al. ont observé des phénomènes de flips, où une bonne réponse devient mauvaise, ou une mauvaise réponse devient bonne
  • Qwen2-1.5B quantifié avec W8A16 GPTQ ne perd que 0,3 % de précision sur GSM8K 8-shot, mais le statut correct/incorrect change pour 6,37 % des réponses
• Dans des domaines comme la finance ou la santé, les changements de sortie des modèles quantifiés peuvent rendre difficile le respect des exigences de réglementation et de fiabilité
• Les méthodes existantes de compression sans perte de modèles se concentrent surtout sur l’efficacité du stockage des checkpoints, la réduction du temps de téléchargement depuis les hubs de modèles, ou du matériel spécialisé comme les FPGA, avec peu d’avantages pour l’inférence sur GPU généraliste

La marge de compression restante dans l’exposant BFloat16

• BFloat16 répartit ses 16 bits entre 1 bit de signe, 8 bits d’exposant et 7 bits de mantisse
• Le point de départ de DFloat11 est une analyse de l’entropie de Shannon des composants BFloat16 des poids de LLM
  • L’entropie du signe et de la mantisse est proche de leur largeur en bits respective, ce qui limite la marge de compression
  • L’exposant dispose de 8 bits, mais son entropie n’est que d’environ 2,6 bits
• La distribution des valeurs d’exposant est très déséquilibrée
  • Sur les 256 valeurs 8 bits possibles, seules environ 40 sont utilisées
  • Les autres valeurs n’apparaissent pas
  • La fréquence chute également rapidement selon le rang
• Grâce à cette faible entropie, l’exposant devient une cible de compression sans perte, avec environ 5,4 bits d’information d’exposant compressibles

Le format DFloat11

• DFloat11 ou DF11 est un format à virgule flottante de longueur variable qui compresse uniquement l’exposant des poids BFloat16 par codage entropique
• L’arbre de Huffman est construit à partir de la distribution des exposants des poids du modèle
  • Les valeurs d’exposant fréquentes reçoivent des codes courts
  • Les valeurs rares reçoivent des codes longs
• Le signe et la mantisse sont conservés tels quels
  • L’exposant est stocké sous forme bit-packed dans un tableau d’octets EncodedExponent
  • Le signe et la mantisse sont stockés séparément dans un tableau d’octets PackedSignMantissa
• Au final, les poids BFloat16 sont réduits à environ 11 bits en moyenne, et peuvent être restaurés en valeurs BFloat16 d’origine sans perte de précision

Décompression adaptée à l’inférence GPU

• Les poids codés entropiquement utilisent un encodage à longueur variable, ils ne peuvent donc pas être injectés directement dans une multiplication matricielle
  • La weight matrix nécessaire doit être décompressée immédiatement dans son format BFloat16 d’origine
  • Une fois la multiplication matricielle terminée, la matrice BFloat16 est aussitôt supprimée afin d’économiser la mémoire GPU
• Le décodage Huffman classique parcourt l’arbre séquentiellement bit par bit, ce qui n’est pas adapté à l’architecture parallèle des GPU
  • Si un seul thread prend en charge la décompression, l’utilisation du GPU est faible et la latence augmente

Décodage fondé sur des LUT hiérarchiques

• DFloat11 utilise un décodage basé sur des lookup tables au lieu de parcourir l’arbre de Huffman
• Si la longueur maximale des codes de Huffman est L, une LUT unique nécessite une taille de 2^L
  • Dans les LLM, L se situe généralement entre 24 et 32
  • Une LUT de 2^32 entrées est difficile à placer dans la SRAM du GPU
• Pour éviter cela, l’arbre de Huffman est divisé en sous-arbres disjoints de hauteur 8, chacun étant transformé en une LUT compacte de 256 entrées
• Dans une LUT hiérarchique, certaines entrées doivent servir de références vers des LUT de niveau inférieur
  • DFloat11 exploite le fait que de nombreuses valeurs d’exposant ne sont pas utilisées dans les LLM
  • Les valeurs d’exposant inutilisées dans la plage 240–255 sont réutilisées comme pointeurs internes
  • Ces valeurs représentent des ordres de grandeur extrêmement élevés, de ±2^113 à ±2^128, et n’apparaissent pas dans les poids de LLM
• Dans les expériences, le nombre k de LUT compactes pour l’arbre de Huffman des exposants BFloat16 se situe entre 4 et 8
  • Avec CodeLengths, cela utilise au maximum (8 + 1) × 256 bytes de mémoire
  • Cette taille tient dans la SRAM et permet d’effectuer rapidement les lookups répétés

Noyau GPU en deux étapes et métadonnées auxiliaires

• Chaque thread GPU prend en charge une plage contiguë de n octets de l’exposant encodé
  • Les expériences utilisent n = 8
  • Le thread décode les codes de Huffman qui commencent dans sa propre plage
• Les codes à longueur variable créent deux problèmes
  • La position exacte du bit de départ de chaque thread n’est pas évidente
  • À l’exception du premier thread, il est difficile de connaître l’index de sortie des éléments décodés
• Le premier problème est résolu par le tableau Gaps
  • Gaps contient une entrée par thread
  • Chaque entrée indique l’offset en bits du premier code de Huffman valide par rapport à l’octet de départ du thread
  • Comme la longueur maximale des codes est de 32 bits, l’offset est dans l’intervalle [0, 31] et stocké sur 5 bits
• Le problème de position de sortie est réduit en ne stockant que la position au niveau du thread block
  • Stocker une position de sortie 32 bits pour chaque thread entraînerait un surcoût important, avec des dizaines de milliers de threads par weight matrix
  • DFloat11 ne stocke que la position de sortie du premier élément de chaque thread block
• Le noyau fonctionne en deux étapes
  • À la première étape, chaque thread décode sa plage et ne fait que compter le nombre d’éléments, sans écrire en HBM
  • Les threads à l’intérieur du block effectuent une prefix sum avec l’algorithme de Blelloch pour calculer la position de sortie de chaque thread
  • À la deuxième étape, la même plage est décodée à nouveau et les valeurs décodées sont écrites dans le write buffer SRAM selon les positions calculées
  • L’exposant encodé est chargé en SRAM avant la première passe afin d’éviter les accès répétés à la mémoire globale
  • Une fois tous les exposants décodés écrits en SRAM, une seule écriture coalesced vers la HBM est effectuée

Décompression par bloc transformer

• La décompression d’une seule weight matrix peut être trop petite pour exploiter suffisamment les ressources GPU
• Plus la matrice est grande, plus le débit de décompression de DFloat11 s’améliore
• Décompresser plusieurs matrices ensemble augmente le débit et masque la latence
  • Toutes les weight matrices DFloat11 d’un bloc transformer sont décompressées dans un même batch
  • Cette décompression batchée est effectuée juste avant le forward pass du bloc transformer correspondant
• Le token embedding et la language modeling head du LLM sont également compressés
  • Ces matrices sont suffisamment grandes pour saturer les ressources GPU, sans nécessiter de batching séparé

Résultats d’évaluation et effets pratiques

• DFloat11 a été évalué sur des LLM et des diffusion transformers, notamment Llama 3, Qwen 3, Mistral 3, DeepSeek R1 Distilled, FLUX.1 et Stable Diffusion 3.5
• Les résultats montrent une réduction d’environ 30 % de la taille du modèle et une préservation complète des sorties originales
  • Les sorties sont identiques bit-for-bit à celles du modèle original
  • Comme il ne s’agit pas d’une compression avec perte, la précision des poids BFloat16 d’origine est conservée
• Par rapport aux alternatives qui offloadent vers le CPU une partie du modèle non compressé pour respecter les contraintes mémoire, DFloat11 atteint un débit 2,3 à 46,2 fois supérieur en génération de tokens
• À budget mémoire GPU fixe, il permet une generation length 5,7 à 14,9 fois plus longue qu’un modèle non compressé
• Llama 3.1 405B est un modèle d’environ 810 Go, mais DFloat11 permet son inférence sans perte sur un seul nœud de 8 GPU A100 de 80 Go
• Ces résultats montrent qu’il est possible de réduire de moitié les exigences matérielles nécessaires à l’exécution de Llama-3.1-405B, tout en réalisant l’inférence sans accuracy loss