
Le FP16 stocke chaque valeur à virgule flottante sur 16 bits, soit la moitié de l’espace du FP32. Il peut réduire le stockage des tenseurs et accélérer les opérations d’IA prises en charge. Sa plage numérique plus étroite et sa précision réduite changent toutefois le comportement du modèle. Mémoire, vitesse et qualité des résultats demandent des vérifications distinctes.
FP16 signifie « virgule flottante 16 bits ». On parle aussi de demi-précision, de float16 ou du format IEEE 754 binary16. Il comporte un bit de signe, cinq bits d’exposant et dix bits de fraction, souvent appelés bits de mantisse. Cela correspond à environ trois à quatre chiffres décimaux de précision.
La plus petite valeur positive représentable est d’environ 5,96 × 10−8, et la plus grande valeur finie vaut 65 504. Le FP16 ne peut donc pas représenter toutes les valeurs disponibles en FP32 ou FP64.
Une valeur FP16 occupe deux octets, contre quatre en FP32 et huit en FP64. Cette mesure décrit les données du tenseur, pas toute la mémoire d’un processus d’entraînement ou d’inférence.
À nombre de valeurs égal, passer un tenseur en FP16 réduit les octets à stocker ou à transférer. L’effet sur la charge complète dépend des tenseurs qui changent de type et des opérations ou transferts qui limitent les performances.
La demi-précision est utilisée lorsque sa précision suffit, notamment pour certaines données graphiques et opérations de réseaux neuronaux. Sa plage dynamique diffère de celle des entiers sur 8 ou 16 bits. Son intérêt doit être évalué pour les données et les calculs concernés.
Le FP32 stocke chaque valeur sur 32 bits ; le FP16 utilise 16 bits. Ce gain de stockage s’accompagne d’une précision moindre et d’une plage plus étroite.
| Propriété | FP16 | FP32 |
|---|---|---|
| Stockage par valeur | 16 bits / 2 octets | 32 bits / 4 octets |
| Plus grande valeur positive finie | 65 504 | Environ 3,40 × 1038 |
| Plus petite valeur positive normale | Environ 6,10 × 10−5 | Environ 1,18 × 10−38 |
| Écart au-dessus de 1 (epsilon) | 2−10 | 2−23 |
Le tableau suit les définitions numériques de PyTorch. Des valeurs subnormales existent en dessous de la plus petite valeur normale. La taille des données d’un tenseur peut être inspectée avec element_size(), sans inclure la mémoire de l’allocateur ou du framework.
Le FP16 offre environ trois à quatre chiffres décimaux de précision, le FP32 environ sept, et le FP64 environ quinze à dix-sept. Une précision supérieure peut être nécessaire lorsque les erreurs d’arrondi s’accumulent ou lors de mises à jour fines des poids.
Passer des poids, activations, gradients ou tenseurs intermédiaires de FP32 à FP16 divise leur stockage par deux, à nombre d’éléments égal. La mémoire totale ne suit pas forcément ce ratio : états de l’optimiseur, cache KV, données de lot, buffers et autres allocations peuvent rester en précision supérieure.
Diviser les octets par valeur ne démontre pas un doublement du débit applicatif. Mesurez les transferts et le travail complet. Prétraitement CPU, petits kernels, communications et tenseurs conservés en FP32 peuvent limiter le gain.
Le risque est numérique. Une grande valeur peut devenir infinie lors d’une conversion en FP16 ; une petite valeur peut devenir subnormale ou être arrondie à zéro. Vérifiez les conversions et les valeurs intermédiaires, surtout si le modèle a été entraîné avec un format de plage plus large.
Les kernels de précision réduite pris en charge peuvent être plus rapides, sans multiplicateur universel. La recette AMP de PyTorch montre l’effet de la taille de la charge et de l’utilisation du GPU. Mesurez votre configuration.
Le FP16 et le BF16 utilisent tous deux 16 bits, répartis différemment. Le FP16 possède un bit de signe, cinq bits d’exposant et dix bits de fraction. Le BF16, ou bfloat16, possède un bit de signe, huit bits d’exposant et sept bits de fraction.
Le BF16 conserve autant de bits d’exposant que le FP32, ce qui lui donne une plage bien plus large que le FP16. Le FP16 dispose de davantage de bits de fraction et distingue donc plus finement certaines valeurs à échelle comparable.
La plage du BF16 peut aider lorsque gradients, activations ou pertes varient fortement. Elle ne garantit pas un entraînement stable. Le FP16 peut aussi convenir, mais l’entraînement utilise souvent une précision mixte et une mise à l’échelle de la perte.
Le FP16 peut convenir lorsque :
Le BF16 peut être utile lorsque :
Les NVIDIA A100 et H100 prennent en charge les deux formats. Les capacités des GPU plus anciens varient. Sur CPU et autres accélérateurs, les instructions, bibliothèques et compilateurs comptent aussi. Le choix concerne donc le modèle, le logiciel et le matériel.
Le FP16 est un format à virgule flottante. INT8 et INT4 sont des formats entiers ; leur quantification représente des valeurs initialement flottantes avec moins de bits, généralement avec des facteurs d’échelle. Le BF16 reste un autre format flottant. Les formats à virgule fixe utilisent, eux, une position fixe pour le point binaire ou décimal.
Les données INT8 utilisent huit bits par valeur et les données INT4 compactées quatre, contre seize pour FP16. La quantification peut réduire davantage le stockage, même si les facteurs d’échelle et les autres composants du modèle ajoutent de la mémoire. Consultez notre guide de quantification des LLM, en anglais pour le choix de la méthode.
Pour une inférence PyTorch compatible, model.to(dtype=torch.float16) convertit un module, mais les entrées flottantes et les opérations doivent rester compatibles. L’entraînement AMP suit une autre voie : autocast choisit les types par opération. La quantification entière peut nécessiter une calibration, des kernels spécialisés, un entraînement adapté ou une évaluation par couche.
Le FP16 peut être préférable lorsque la qualité doit être conservée, que les activations ont besoin d’une plage flottante, que le modèle tolère mal la quantification ou que la pile logicielle possède de meilleurs kernels FP16. L’entraînement et le fine-tuning peuvent aussi orienter ce choix.
INT8 ou INT4 peuvent convenir lorsqu’un modèle ne tient pas en FP16, qu’un checkpoint quantifié validé existe, ou que le matériel prend en charge efficacement les kernels nécessaires. La qualité doit rester conforme aux exigences de l’application.
Une configuration peut combiner des poids quantifiés, des activations ou un cache KV en FP16, et une accumulation FP32 pour des opérations sensibles. Choisissez le type par composant plutôt que le plus petit format partout.
Les poids des grands modèles occupent de la mémoire, auxquels s’ajoutent activations, gradients, états de l’optimiseur et buffers pendant l’entraînement. Pour un transformer en inférence, le cache KV peut croître avec le contexte. Le fichier du modèle ne représente donc qu’une partie du besoin.
Des poids stockés en FP16 occupent la moitié de l’espace des mêmes poids en FP32. Cela peut aider un modèle à tenir dans la VRAM, mais le résultat dépend aussi des activations, des lots et des autres allocations.
Les Tensor Cores proposent des opérations matricielles en précision réduite sur les GPU NVIDIA compatibles. Les dimensions, les kernels et le temps passé hors de ces opérations déterminent le bénéfice. Matrices et convolutions sont fréquentes dans les réseaux neuronaux, mais tous les modèles ne les exploitent pas de la même façon.
Si une accélération mesurée augmente le travail utile par heure GPU, le coût par résultat peut diminuer. Des choix de service comme le continuous batching pour les LLM interviennent aussi. Comparez les coûts à qualité et latence requises, pas seulement le débit arithmétique.
Le FP16 ne rend pas chaque charge deux fois plus rapide. Certaines opérations restent en FP32 et le CPU, le réseau, le stockage ou les petits kernels peuvent devenir le facteur limitant.
De petits gradients FP16 peuvent être arrondis à zéro, et de grandes activations ou gradients peuvent déborder. La précision mixte conserve une précision supérieure là où elle est nécessaire, mais demande une validation du modèle. Le guide NVIDIA explique les états en précision supérieure et la mise à l’échelle de la perte.
Avec PyTorch AMP, placez la passe avant et la perte dans torch.autocast(device_type="cuda", dtype=torch.float16). Gardez la rétropropagation hors de ce contexte. N’appelez pas half() sur le modèle ou les entrées avec autocast. L’entraînement FP16 CUDA utilise généralement torch.amp.GradScaler("cuda") ; les anciennes interfaces torch.cuda.amp sont dépréciées.
Les exemples officiels suivent cet ordre : effacer les gradients, calculer la perte sous autocast, puis appeler scaler.scale(loss).backward(), scaler.step(optimizer) et scaler.update(). Si un écrêtage est nécessaire, appelez scaler.unscale_(optimizer) une fois avant. Des gradients non finis peuvent faire sauter la mise à jour.
Avec l’accumulation des gradients, conservez la même échelle pendant toute la fenêtre et effectuez le pas à la limite de mise à jour de l’optimiseur. Sauvegardez l’état du scaler avec le modèle et l’optimiseur, comme expliqué dans notre guide des checkpoints.
Le BF16 a une plage plus large et n’a généralement pas besoin de scaling. Il exige néanmoins un matériel et des opérations compatibles. Notre guide PyTorch sur A100 contient les contrôles du périphérique et un exemple BF16. Ces instructions suivent la documentation ; cette révision n’a pas testé d’entraînement CUDA ou AMP.
Comparez pertes, gradients, qualité de validation et pic mémoire à une référence cohérente. Un scaler ne rend pas tous les modèles adaptés au FP16. Conservez une précision supérieure pour les opérations sensibles et recherchez la cause des valeurs non finies avant un entraînement long.
L’inférence n’utilise pas les gradients d’entraînement ni les mises à jour de l’optimiseur, mais la précision réduite peut modifier les sorties. Testez directement ce chemin du modèle ; des poids fixes ne garantissent pas que FP16 convient.
Le FP16 peut réduire le stockage des poids et activations, diminuer les octets transférés, permettre des lots plus grands et utiliser des kernels matriciels accélérés. Cela peut améliorer la latence ou le débit selon le modèle.
On le rencontre dans la génération de texte, les modèles de diffusion, la classification, la détection, la segmentation et les embeddings. Son intérêt dépend des opérations et du support logiciel, pas seulement du domaine d’application.
Passer de FP32 à FP16 peut réduire la mémoire ou améliorer la latence. L’effet sur le coût dépend du débit mesuré, de la qualité requise, de l’utilisation du GPU et de la configuration de service.
Les opérations flottantes sont sensibles aux arrondis et à l’ordre d’accumulation. Dans un LLM, de petites différences peuvent modifier les tokens choisis ; en vision, elles peuvent compter près d’une frontière de décision. Comparez qualité, résultats, latence, débit et mémoire avec une référence FP32 ou BF16.
Le FP16 convient si la charge bénéficie du stockage réduit ou des kernels disponibles et si le modèle tolère les effets numériques. Cela peut concerner l’inférence de LLM, le fine-tuning en précision mixte, la vision, la diffusion, les embeddings, le rendu GPU ou certaines simulations.
Les GPU NVIDIA équipés de Tensor Cores proposent des chemins de calcul adaptés aux formats pris en charge. Vérifiez les kernels et le modèle dans le guide des GPU pour l’IA, sans déduire la vitesse applicative de la seule génération du GPU.
Si un modèle dépasse légèrement la VRAM en FP32, le FP16 peut le faire tenir. Il peut aussi permettre un lot plus grand ou réduire le trafic mémoire. Notre guide pour choisir un GPU d’inférence LLM replace ces besoins dans la sélection du matériel.
Les transformers et CNN utilisent souvent des matrices et convolutions compatibles avec ces optimisations. Les calculs comportant de nombreuses réductions, un état récurrent ou des exigences numériques fortes peuvent nécessiter davantage de précision. FP16 reste un choix à valider.
Une plage, une précision ou une accumulation insuffisante peut entraîner une erreur visible ou une dégradation silencieuse. Au-delà de 65 504, certaines valeurs débordent ; des valeurs très petites peuvent disparaître. Les gradients, logits, normalisations et calculs d’attention peuvent être concernés.
Des calculs scientifiques, financiers, médicaux ou des simulations peuvent demander une évaluation numérique plus stricte. Les sommes de nombreuses petites valeurs et les décisions sensibles à l’arrondi méritent aussi une attention particulière.
Un entraînement mal adapté peut diverger, converger moins vite ou perdre en qualité. Des états FP32, la mise à l’échelle de la perte et le choix des opérations peuvent être nécessaires. Aucun format ne dispense de tester.
Certains matériels stockent le FP16 sans accélérer efficacement ses opérations. Des kernels peuvent revenir au FP32, et certaines implémentations traitent les subnormaux comme zéro. Le benchmark Hivenet Llama 3.1 8B lié utilise BF16 : il ne prouve pas le débit FP16 des GPU comparés.
Les lots, kernels, ordres d’accumulation et modes de calcul peuvent aussi modifier légèrement les résultats. Évaluez leur acceptabilité pour l’application, surtout lorsque les conséquences d’une erreur sont importantes.
Mesurez le modèle réel avec le matériel, le framework et les entrées prévus. Comparez au minimum :
Pour l’entraînement, comparez convergence, perte de validation, métriques finales et gradients. Recherchez NaN, inf, pics de perte et dégradation silencieuse. Selon la cause, gardez des opérations en FP32 ou évaluez BF16 si le matériel le permet.
Pour l’inférence, examinez les sorties et les cas limites : séquences de tokens, prompts représentatifs, qualité des images ou décisions de classification. Une moyenne de latence ne remplace pas ces contrôles.
Conservez le même GPU, la même VRAM disponible, les mêmes pilotes, versions logicielles, lots et entrées. Comparez séparément les offres matérielles actuelles : un tarif horaire ne démontre pas qu’un format est plus rapide ou plus économique.
Pour tester sur des GPU cloud :
Le FP16 réduit les octets par valeur et peut accélérer les opérations compatibles. Sa plage et sa précision créent aussi des risques. Partez d’une référence fonctionnelle, comparez le format candidat et conservez-le seulement si la qualité et les ressources répondent aux besoins.
Pour l’entraînement, testez la stabilité et la reprise dans une implémentation de précision mixte prise en charge. Pour l’inférence, comparez sorties, latence complète et pic mémoire. La précision participe au choix de déploiement ; elle ne garantit pas une baisse des coûts.
Oui. FP16 désigne couramment la virgule flottante en demi-précision, correspondant au format IEEE 754 binary16.
Environ trois à quatre, contre environ sept pour FP32 et quinze à dix-sept pour FP64.
Non. Il divise par deux le stockage par valeur face au FP32. La vitesse dépend du matériel, des kernels, des lots et du modèle ; le gain peut être faible.
Oui, si le modèle et les opérations le permettent, généralement avec une précision mixte et une mise à l’échelle des gradients. Vérifiez la stabilité et la qualité. Le FP16 pur présente davantage de risques numériques.
La plage FP16 est plus étroite que celle du FP32. Des valeurs trop petites peuvent être arrondies à zéro ou perdre des détails qui comptent pour la mise à jour des poids.
Comparez le support matériel, les kernels et le comportement du modèle. Le BF16 offre une plage plus large, tandis que le FP16 possède davantage de bits de fraction. La plage BF16 peut aider certains entraînements, sans garantir leur qualité.
Non. FP16 est flottant ; INT8 et INT4 sont des formats entiers. Une quantification peut réduire davantage le stockage, avec des contraintes de calibration, de kernels et de qualité propres à la méthode.
Pour une inférence compatible, model.to(dtype=torch.float16) convertit les paramètres et buffers flottants. Gardez les entrées flottantes compatibles et testez les sorties. Pour l’entraînement AMP, utilisez autocast au lieu de convertir manuellement tout le modèle.
Lorsque sa plage ou sa précision ne convient pas, que l’entraînement reste instable ou que le matériel n’exécute pas efficacement les opérations nécessaires. Évaluez FP32, FP64 ou une précision mixte contrôlée selon les exigences numériques.
Le FP16 réduit le stockage par valeur et peut accélérer les opérations compatibles. Son effet sur le temps d’entraînement, le coût de service ou la taille du modèle utilisable dépend de toute la charge de travail.
Choisissez une charge de travail d’IA, de calcul ou de stockage à tester sur Hivenet, ou échangez avec notre équipe sur sa mise en production.