RFDETRSegPreview validation calls are extremely slow. Can we speed up?

[Abdul-Mukit]

Search before asking

• I have searched the RF-DETR issues and found no similar feature requests.

Description

I have a dummy dataset of train:val = 1500 : 200 size. On this dataset, with a batch size of 16 on a A100-80GB GPU,
1 epoch (1500 images) of training takes a total time: 0:06:20 (3.9606 s / it)
1 epoch (200 images) of validation takes a total time: 0:07:34 (34.9950 s / it)
That is nearly 10x slower compared to training.

This is complicated by RFDETR running two validation calls. Once with the base model. Another time with the EMA model. So I spend 6 minutes training one epoch. Then I wait for another 15 minutes to finish the validation calls and resume training again. This makes the training process extremely slow.

To compare with YOLOv8sSeg, on the same GPU, the validation call on 2800 images takes 34 seconds or less. With a batch size of 160.

I noticed that during validation calls, the postprocessor upsamples masks to the original input image size of the dataset. Is that really necessary? But even with that turned off, I believe there is something wrong with the validation call. It is way too slow.

Can we please optimize validation calls?

Use case

No response

Additional

No response

Are you willing to submit a PR?

• Yes I'd like to help by submitting a PR!

[Wavelet303]

I’m facing the same problem on my setup (RTX 4060 8 GB).

Training runs relatively smoothly, but evaluation is dramatically slower — often several times longer than training itself. This happens even on small validation sets, and it becomes a major bottleneck when the EMA model is also evaluated each epoch.

In addition, the --run_test parameter doesn’t seem to work properly — it either doesn’t trigger the evaluation or hangs during initialization.

[Abdul-Mukit]

I was able to reduce the time per epoch (training + validation) from 21 minutes to ~3 minutes. About 7 times speedup.

Realized that this delay is due to the old cocoAPI being slow:
facebookresearch/maskrcnn-benchmark#522
DeNA/PyTorch_YOLOv3#56
facebookresearch/detectron2#5221

Easy things that worked great:

• Set num_select=100 in training config and model config. It cuts down computation by half. For COCO, a single image can contain max 100 annotations anyway. So there is no point in going for 200 detections per image. My application allowed for 100 detections per image, luckily.
• I edited the code to use the flag use_ema differently. If use_ema==True, I run validation only using the EMA model and don't run the same using the regular model. This again cuts down the total validation compute by half. From my tests, the EMA model always outperforms the regular model. So running evaluations on both was unnecessary. I also adjusted the plots accordingly so that when use_ema==True, only that model's metrics are plotted.
• Resized my dataset to a lower resolution. I used datumaro Add RescaleTransform: allow to resize images while maintaining aspect ratio. open-edge-platform/datumaro#1932. A lot of my images were of resolution 1920. Resized them to a max 640 resolution (similar to COCO).

Still, the evaluation call is very slow compared to Ultralytics.

Things that can be tried to increase further efficiency:

• Switching to detectron2 or faster-coco-eval for faster validation calls.
• Modify RF-DETR to preprocess the dataset and cache it. Ultralytics does a preprocessing and caching of the dataset before starting training. This speeds up training a lot. I never had any issues with Ultralytics with the same high-resolution datasets.
• Before running validation, do something like model.optimize_for_inference. This basically replaces the forward calls with forward_export calls. Thus, it will reduce the computation for validation. After validation, we can again "put back" the regular forward calls to resume training all 13 groups.
• Get rid of Group-DETR and replace it with something like DN-DETR Replace usage of Group-DETR with DN-DETR #390.