FLOPs

FLOPs (operações de ponto flutuante) contam as operações aritméticas que uma rede neural executa para processar uma entrada, como uma imagem ou um token, principalmente as multiplicações e adições dentro de suas camadas. Essa contagem mede o custo computacional de um modelo independentemente do hardware em que ele é executado, por isso é a forma padrão de comparar o custo de diferentes arquiteturas. Os modelos de visão costumam ser descritos em GFLOPs (bilhões de operações) para um tamanho de entrada especificado, e o total de computação usado para treinar um modelo grande também é informado em FLOPs.

FLOPs versus FLOPS versus MACs#

É fácil confundir três termos semelhantes:

• FLOPs (s minúsculo): o número de operações de ponto flutuante, uma propriedade do modelo e do tamanho da entrada. Mede a quantidade de trabalho necessária.
• FLOPS (S maiúsculo): operações de ponto flutuante por segundo, uma propriedade do hardware, como uma GPU. Mede a velocidade com que o trabalho pode ser feito; dividir os FLOPs de um modelo pelo pico de FLOPS de um dispositivo fornece o menor tempo de execução possível.
• MACs: operações de multiplicação e acumulação. Um MAC é uma multiplicação mais uma adição, então um MAC equivale a dois FLOPs. Alguns artigos e ferramentas informam MACs com o nome FLOPs, reduzindo os valores pela metade.

Como os FLOPs são contados#

A maior parte dos FLOPs de uma rede vem de multiplicações de matrizes e convoluções. Uma camada totalmente conectada com n entradas e m saídas custa cerca de 2 × n × m FLOPs por entrada. Uma convolução calcula um produto escalar para cada valor de saída, então seu custo é 2 × C_in × k × k × C_out × H_out × W_out, em que k é o tamanho do kernel e H_out × W_out é a resolução de saída. As ativações, a normalização e as adições acrescentam relativamente pouco. O exemplo abaixo calcula o custo de uma convolução por meio de uma fórmula e confere o resultado com o contador de FLOPs integrado do 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")

As duas linhas imprimem 0,944 GFLOPs, e a linha da fórmula mostra a mesma camada como 0,472 GMACs, metade do valor em FLOPs. Para Transformers, uma passagem para frente custa cerca de 2 FLOPs por parâmetro por token, e o treinamento custa cerca de 6; essa regra prática vem da pesquisa sobre leis de escala, que estima a computação total de uma execução de treinamento como 6 × parâmetros × tokens de treinamento.

FLOPs e velocidade no mundo real#

Os FLOPs preveem a velocidade apenas de forma aproximada. A latência também depende do tráfego de memória, do grau de paralelismo de cada operação e da disponibilidade de kernels otimizados para o hardware. O artigo do ShuffleNet V2 mostrou que redes com FLOPs semelhantes podem ter velocidades bem diferentes no mesmo dispositivo, e as convoluções separáveis em profundidade, apesar de exigirem poucos FLOPs, muitas vezes são limitadas pela largura de banda da memória, não pelos cálculos. As otimizações também atuam em fatores diferentes. A poda de modelos e tamanhos de entrada menores removem operações, enquanto a quantização de modelos mantém a quantidade de operações e torna cada uma mais barata ao realizar cálculos com inteiros de 8 bits. Portanto, os FLOPs funcionam melhor como um primeiro filtro antes de medir a latência de inferência no dispositivo de destino, por exemplo, com o modo de benchmark da Ultralytics:

FLOPs na seleção de modelos#

As famílias de modelos são lançadas em vários tamanhos para que as equipes possam trocar precisão por capacidade de computação, uma escolha explicada na lição sobre tamanho de modelo da Ultralytics Academy. O Ultralytics YOLO26 varia de 5,5 GFLOPs para YOLO26n a 194,4 GFLOPs para YOLO26x com entrada de 640×640, e model.info() exibe os GFLOPs de qualquer modelo carregado. Drones e celulares alimentados por bateria usam as variantes menores, enquanto servidores na nuvem podem usar as maiores. Como o custo de uma rede convolucional aumenta com o número de pixels, o tamanho da entrada altera os FLOPs tanto quanto o tamanho do modelo:

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")

O loop imprime 1,3, 5,5 e 23,4 GFLOPs: cada duplicação do lado da entrada multiplica a contagem por cerca de quatro, então executar o YOLO26n a 1.280 pixels custa mais que os 20,9 GFLOPs do YOLO26s, um modelo com quatro vezes mais parâmetros, a 640.