Hey everyone, I have been building TraceML, an open-source training diagnostic. I wanted a simple way to tell whether a slow RF-DETR run needs attention on the data side or the model side, before starting to change things.
I tested it against the non-JPEG loading regression reported in RF-DETR #1544.
On a large-PNG workload, 1.11.0 took about 15% longer per training step than 1.10.1, even though the measured GPU compute regions were faster. TraceML showed that input waiting had increased instead.
With 1.11.1, step time returned close to the baseline. Thanks to the RF-DETR contributors.
If you already have a standard RF-DETR `model.train()` script, you can try the current integration without adding instrumentation to your code:
```bash
pip install “traceml-ai==0.5.0”
traceml run train.py
```
It prints a diagnosis and saves a timing summary for comparison.
[Comparison setup and reproduction commands]( traceml/examples/case_studies/rfdetr_input_pipeline_regression at main · traceopt-ai/traceml · GitHub )
[Quick-start example with generated sample data]( RF-DETR - TraceML )
If you try it on your RF-DETR training, let me know whether it helped you find a bottleneck or check that a change worked. What would you want to see next, more detail on data loading, memory use, or something else?