FLOPs
Los FLOPs cuentan las operaciones de coma flotante que necesita un modelo para una pasada hacia delante; son una medida estándar del coste computacional. Cómo contarlos, compararlos y reducirlos.
Los FLOPs (operaciones de coma flotante) cuentan las operaciones aritméticas que realiza una red neuronal para procesar una entrada, como una imagen o un token, sobre todo las multiplicaciones y sumas de sus capas. El recuento mide el coste computacional de un modelo independientemente del hardware en el que se ejecute, por lo que es la forma estándar de comparar el coste de distintas arquitecturas. Los modelos de visión suelen expresarse en GFLOPs (miles de millones de operaciones) para un tamaño de entrada concreto; el cómputo total utilizado para entrenar un modelo grande también se expresa en FLOPs.
FLOPs frente a FLOPS y MACs#
Es fácil confundir estos tres términos similares:
- FLOPs (s minúscula): número de operaciones de coma flotante, una característica del modelo y del tamaño de entrada. Mide el trabajo que hay que realizar.
- FLOPS (S mayúscula): operaciones de coma flotante por segundo, una característica del hardware, como una GPU. Mide la velocidad a la que se puede trabajar; dividir los FLOPs de un modelo por los FLOPS máximos de un dispositivo da el tiempo de ejecución mínimo posible.
- MACs: operaciones de multiplicación y acumulación. Una MAC es una multiplicación más una suma, así que equivale a dos FLOPs. Algunos artículos y herramientas informan de los MACs con el nombre de FLOPs, lo que reduce sus cifras a la mitad.
Cómo se cuentan los FLOPs#
La mayor parte de los FLOPs de una red procede de las multiplicaciones de matrices y las convoluciones. Una capa totalmente conectada con n entradas y m salidas cuesta aproximadamente 2 × n × m FLOPs por entrada. Una convolución calcula un producto escalar por cada valor de salida, por lo que su coste es 2 × C_in × k × k × C_out × H_out × W_out, donde k es el tamaño del kernel y H_out × W_out, la resolución de salida. Las funciones de activación, la normalización y las sumas añaden un coste comparativamente bajo. El siguiente ejemplo calcula mediante una fórmula el coste de una convolución y lo comprueba con el contador de FLOPs integrado de 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")Ambas líneas imprimen 0,944 GFLOPs, y la línea de la fórmula muestra la misma capa como 0,472 GMACs, la mitad de la cifra en FLOPs. En los transformers, una pasada hacia delante cuesta aproximadamente 2 FLOPs por parámetro y token, y el entrenamiento, unos 6; es una regla general derivada de la investigación sobre las leyes de escalado que calcula el cómputo total de un entrenamiento como 6 × parámetros × tokens de entrenamiento.
FLOPs y velocidad en el mundo real#
Los FLOPs solo permiten predecir la velocidad de forma aproximada. La latencia también depende del tráfico de memoria, de la capacidad de paralelizar cada operación y de si el hardware dispone de kernels optimizados para ella. El artículo sobre ShuffleNet V2 mostró que redes con FLOPs similares pueden ejecutarse a velocidades muy distintas en el mismo dispositivo, y que las convoluciones separables en profundidad, aunque requieren pocos FLOPs, suelen estar limitadas por el ancho de banda de memoria en lugar de por la capacidad de cálculo. Las optimizaciones también actúan sobre distintos factores. La poda de modelos y la reducción del tamaño de entrada eliminan operaciones, mientras que la cuantización de modelos mantiene el número de operaciones y abarata cada una al calcular con enteros de 8 bits. Por tanto, los FLOPs son más útiles como primer filtro antes de medir la latencia de inferencia en el dispositivo de destino, por ejemplo, con el modo de benchmark de Ultralytics:
FLOPs en la selección de modelos#
Las familias de modelos se publican en varios tamaños para que los equipos puedan intercambiar precisión por capacidad de cálculo; la lección sobre el tamaño de los modelos de Ultralytics Academy explica esta elección. Ultralytics YOLO26 va de los 5,5 GFLOPs de YOLO26n a los 194,4 GFLOPs de YOLO26x con una entrada de 640×640, y model.info() muestra los GFLOPs de cualquier modelo cargado. Los drones y móviles con batería utilizan las variantes más pequeñas, mientras que los servidores en la nube pueden permitirse las más grandes. Como el coste de una red convolucional aumenta con el número de píxeles, el tamaño de entrada modifica los FLOPs tanto como el tamaño del 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")El bucle imprime 1,3, 5,5 y 23,4 GFLOPs: cada vez que se duplica el lado de la entrada, el recuento se multiplica por aproximadamente cuatro, así que ejecutar YOLO26n a 1280 píxeles cuesta más que los 20,9 GFLOPs de YOLO26s, un modelo con cuatro veces más parámetros, a 640.










