Train DEIM
Overview
Fine-tunes a DEIM object detector from your workspace registry on OvalBee datasets, and registers the result as a new version of that model.
The node exports the train and validation datasets to COCO format inside its own working directory, trains on them, and uploads the checkpoints to the new version, so no conversion or upload node sits in between. The run publishes a live report that updates while it goes, and the Best Loss badge shows the lowest training loss reached.
DEIM covers three architecture families, from tiny HGNetV2 variants that suit an edge device to DINOv3 backbones that trade speed for accuracy. The DEIMv2 entries are covered by a separate non-commercial license, while the D-FINE and RT-DETRv2 entries are Apache-2.0.
Pretrained Models
- DEIMv2 HGNetV2-Atto
- DEIMv2 HGNetV2-Femto
- DEIMv2 HGNetV2-Pico
- DEIMv2 HGNetV2-N
- DEIMv2 DINOv3-S
- DEIMv2 DINOv3-M
- DEIMv2 DINOv3-L
- DEIMv2 DINOv3-X
- D-FINE HGNetV2-N
- D-FINE HGNetV2-S
- D-FINE HGNetV2-M
- D-FINE HGNetV2-L
- D-FINE HGNetV2-X
- RT-DETRv2-S (r18vd)
- RT-DETRv2-M (r34vd)
- RT-DETRv2-M* (r50vd_m)
- RT-DETRv2-L (r50vd)
- RT-DETRv2-X (r101vd)
Prerequisites
What the node builds
Both directories are ephemeral: they live only for the duration of the task, and the checkpoints are uploaded to the model version before it ends. A rerun exports its datasets again.
How it works
Exports the train and validation datasets to COCO format in one pass, so both splits share the same class index space.
Loads the starting weights: the picked version’s own checkpoint, or the public COCO weights of its architecture for a catalog model.
FAQ
Do I need a conversion node in front of this one?
No. The node exports its datasets to COCO itself. Connect the datasets directly. DEIM trains on bounding boxes, so polygon and mask annotations are used through their bounding boxes.
What happens when I rerun the node?
Every run adds a new version to the model, or to Destination model when one is set. Earlier versions stay in the registry and the source datasets aren’t changed. When Model names the model itself rather than a pinned version, it follows the newest ready version, so a rerun that trains into the same model continues from the previous run’s result.
Where do the trained files end up?
On the new model version: the best and last checkpoints (not the periodic ones DEIM writes as it goes), the training config the weights need at prediction time, the training log, and your hyperparameters. The version also records the class list, both datasets, the version training started from, the training report, and the last epoch’s mAP50, mAP50-95, and training loss.
What happens if training fails partway through?
The version receives the latest best and last checkpoints about every two minutes, so a run that fails keeps what it uploaded. Its version is marked failed and isn’t offered in the model pickers. If uploading fails five times in a row, the node stops training rather than carry on with no way to save the result.
What if I leave the validation dataset empty?
The export points validation at the training images, so the mAP the run reports is measured on data the model trained on and reads higher than it will score on new images.
Which classes does the model learn?
When the train dataset is pinned to an ontology, the model learns that ontology’s object classes in its order, and labels of any other class are skipped. Otherwise the classes come from the annotations in the datasets. The class list is also stored inside the checkpoints, so prediction names classes the same way.
Which architecture should I start with?
One of the small HGNetV2 variants when you need speed or an edge deployment, and a DINOv3 backbone when accuracy matters more than latency. Check the license first: the DEIMv2 entries are non-commercial, and the D-FINE and RT-DETRv2 entries are Apache-2.0.
Why does the run stop with an out-of-memory error?
The architecture, batch_size, and eval_spatial_size together decide GPU memory. Lower the batch size first, then the input size, before moving to a smaller backbone.
Why did the run fail right at the start?
Usually the datasets, the model, or the config. The datasets have to carry annotation classes, the picked version has to name one of the DEIM architectures listed above, and Hyperparameters has to be YAML whose keys the trainer accepts.
Inputs
Dataset the model learns from. Its annotations define the classes the trained model will detect. Key: TRAIN_DATASET.
Dataset held back to measure accuracy after each epoch. Leave it empty and accuracy is measured on the training assets instead, which makes the reported mAP look better than it is. Key: VAL_DATASET.
Model to fine-tune. A version copied from the zoo starts from the public COCO weights of that architecture. One from an earlier run continues from its checkpoint. The run is registered as a new version of this model unless Destination Model names another one. Key: MODEL.
Model the new trained version is added to, when it should not go to the model you are training. Leave empty to add it to the Model above. Key: DESTINATION_MODEL.
Training settings in YAML - how many epochs to run, batch size, learning-rate schedule and augmentation. Dataset paths and the number of classes are filled in for you. Key: CONFIG.
Outputs
ID of the asset containing the live DEIM training report. Shown as an artifact. Key: REPORT_ID.
Reference to the registry version this run produced, as <model id>@<version id>. It wires into the Model input of a predict, evaluate or export node and pins it to exactly these weights. Empty when the run could not be registered. Shown as an artifact. Key: MODEL.
Lowest total training loss achieved (shown as a badge). Shown on the node as a badge. Key: BEST_LOSS.
Models and configuration
Model is both what training starts from and where its result is filed: the run adds a version to that model. A version copied from the catalog has no weights of its own, so the run downloads the public COCO weights of that architecture. One produced by an earlier run continues from its checkpoint. Either way the new version records the picked version as its starting point.
Set Destination model to file the result elsewhere. The trained version is created there instead, and Model is then only the starting weights. Both pickers list only DEIM detection models of this workspace, and only their ready versions.
Hyperparameters is the DEIM training config as YAML. The dataset paths and the class count are injected by the node from its own export, so leave those out and set what you want to change: epoches for run length, batch_size for memory, eval_spatial_size for input resolution. Nested keys merge into the architecture’s base config rather than replacing whole sections.
The defaults are a full training schedule, including the augmentation policy, the EMA settings, and the learning-rate curve. Removing a key restores the architecture’s own default rather than disabling the feature.
Report
The report appears near the start of the run and updates as training produces results. It opens from the node.
Report sections
Runtime
The node runs in its own GPU container. Memory use follows the architecture, the input size, and the batch size, so a model that won’t fit is the first thing to check when a run dies early.
The first run takes longer while the worker pulls the image, and a catalog model downloads its pretrained weights on every run that starts from it. Every run exports its datasets before training starts, so a large dataset adds a download phase ahead of the first epoch.
JSON config
Machine-readable node interface for automation and advanced usage.