FLOPs

Les FLOPs (opérations en virgule flottante) comptent les opérations arithmétiques qu’un réseau neuronal effectue pour traiter une entrée, comme une image ou un jeton, principalement les multiplications et les additions dans ses couches. Ce nombre mesure le coût de calcul d’un modèle indépendamment du matériel utilisé ; c’est donc la méthode standard pour comparer la charge de différentes architectures. Les modèles de vision sont généralement exprimés en GFLOPs (milliards d’opérations) pour une taille d’entrée donnée, et le calcul total nécessaire à l’entraînement d’un grand modèle est également exprimé en FLOPs.

FLOPs, FLOPS et MACs#

Trois termes similaires sont faciles à confondre :

• FLOPs (s minuscule) : nombre d’opérations en virgule flottante, une caractéristique du modèle et de la taille d’entrée. Il mesure le travail à effectuer.
• FLOPS (S majuscule) : nombre d’opérations en virgule flottante par seconde, une caractéristique du matériel comme un GPU. Il mesure la vitesse d’exécution ; diviser les FLOPs d’un modèle par le débit maximal en FLOPS d’un appareil donne le temps d’exécution minimal possible.
• MACs : opérations de multiplication-accumulation. Un MAC correspond à une multiplication et une addition, soit deux FLOPs. Certains articles et outils indiquent les MACs sous le nom FLOPs, ce qui divise leurs valeurs par deux.

Calcul des FLOPs#

La majeure partie des FLOPs d’un réseau provient des multiplications matricielles et des convolutions. Une couche entièrement connectée avec n entrées et m sorties coûte environ 2 × n × m FLOPs par entrée. Une convolution calcule un produit scalaire pour chaque valeur de sortie ; son coût est donc de 2 × C_in × k × k × C_out × H_out × W_out, où k est la taille du noyau et H_out × W_out la résolution de sortie. Les fonctions d’activation, la normalisation et les additions représentent un coût relativement faible. L’exemple ci-dessous calcule le coût d’une convolution à l’aide d’une formule et le vérifie avec le compteur de FLOPs intégré à PyTorch :

import torch
from torch.utils.flop_counter import FlopCounterMode

# A 3x3 convolution mapping 64 channels to 128 on an 80x80 feature map
conv = torch.nn.Conv2d(64, 128, kernel_size=3, padding=1, bias=False)
x = torch.randn(1, 64, 80, 80)

# Each output value needs 64*3*3 multiply-accumulates (MACs); 1 MAC = 2 FLOPs
macs = 128 * 80 * 80 * 64 * 3 * 3
print(f"By formula: {2 * macs / 1e9:.3f} GFLOPs ({macs / 1e9:.3f} GMACs)")

# PyTorch's FLOP counter traces the real forward pass
with FlopCounterMode(display=False) as counter:
    conv(x)
print(f"Counted:    {counter.get_total_flops() / 1e9:.3f} GFLOPs")

Les deux lignes affichent 0,944 GFLOPs, et la ligne de la formule présente la même couche à 0,472 GMACs, soit la moitié des FLOPs. Pour les transformeurs, une passe avant coûte environ 2 FLOPs par paramètre et par jeton, et l’entraînement en coûte environ 6. Cette règle empirique issue des travaux sur les lois d’échelle permet d’estimer le calcul total d’un entraînement à 6 × le nombre de paramètres × le nombre de jetons d’entraînement.

FLOPs et vitesse réelle#

Les FLOPs ne donnent qu’une estimation approximative de la vitesse. La latence dépend aussi du trafic mémoire, du degré de parallélisation de chaque opération et de la disponibilité de noyaux optimisés sur le matériel. L’article sur ShuffleNet V2 a montré que des réseaux ayant des FLOPs similaires peuvent avoir des vitesses très différentes sur un même appareil, et que les convolutions depthwise, peu coûteuses en FLOPs, sont souvent limitées par la bande passante mémoire plutôt que par le calcul. Les optimisations agissent elles aussi sur différents facteurs. L’élagage de modèles et la réduction de la taille d’entrée suppriment des opérations, tandis que la quantification de modèles conserve le nombre d’opérations et réduit le coût de chacune en effectuant les calculs sur des entiers de 8 bits. Les FLOPs sont donc surtout utiles comme premier filtre avant de mesurer la latence d’inférence sur l’appareil cible, par exemple avec le mode benchmark Ultralytics :

FLOPs et sélection de modèles#

Les familles de modèles sont proposées en plusieurs tailles afin que les équipes puissent arbitrer entre précision et calcul, un choix expliqué dans la leçon de l’Ultralytics Academy sur la taille des modèles. Ultralytics YOLO26 va de 5,5 GFLOPs pour YOLO26n à 194,4 GFLOPs pour YOLO26x avec une entrée de 640×640, et model.info() affiche les GFLOPs de tout modèle chargé. Les drones et les téléphones alimentés par batterie utilisent les plus petites variantes, tandis que les serveurs cloud peuvent se permettre les plus grandes. Comme le coût d’un réseau convolutif évolue avec le nombre de pixels, la taille d’entrée modifie les FLOPs autant que la taille du modèle :

from ultralytics import YOLO
from ultralytics.utils.torch_utils import get_flops

# Load the smallest YOLO26 detection model and fuse its layers, as for inference
model = YOLO("yolo26n.pt")
model.fuse()

# Count GFLOPs for the same model at three input resolutions
for imgsz in [320, 640, 1280]:
    print(f"{imgsz}px: {get_flops(model.model, imgsz):.1f} GFLOPs")

La boucle affiche 1,3, 5,5 et 23,4 GFLOPs : chaque doublement du côté de l’entrée multiplie le nombre par environ quatre. Exécuter YOLO26n à 1 280 pixels coûte donc plus que les 20,9 GFLOPs de YOLO26s, un modèle qui possède quatre fois plus de paramètres, à 640 pixels.