Built-in training runtimes
The YOLO · RF-DETR · Pointcept runtimes the platform builds itself, and the data each one takes.
The platform has three training runtimes it builds and uses itself. They run under the same contract as this section. Use them as reference implementations when you build a new trainer.
One framework = one runtime image. Frameworks with different dependencies are not packed into one image. You choose the framework when you create a variant, and cannot change it later.
| Framework | Task | Model variants (wizard step 3) | Data | GPU |
|---|---|---|---|---|
| YOLO (ultralytics) | Object detection | yolo26n · yolo12n · yolo12s · yolo11n · yolo11s | Images + annotations | Optional |
| Instance segmentation | yolo11n-seg · yolo11s-seg · yolo11m-seg | Images + polygon annotations | Optional | |
| RF-DETR | Object detection | rf-detr-nano · -small · -medium · -large | Images + annotations | Optional |
| Instance segmentation | rf-detr-seg-nano · -small · -medium | Images + polygon annotations | Optional | |
| Pointcept (PTv3) | Semantic segmentation | pt-v3 | PLY point clouds + classes | Required |
| Instance segmentation (PointGroup) | pg-ptv3 | PLY point clouds + instance IDs (classes optional) | Required |
What differs
| YOLO | RF-DETR | Pointcept | |
|---|---|---|---|
| Dockerfile | Dockerfile | Dockerfile.rfdetr | Dockerfile.pointcept (two-stage build) |
| Pinned versions | ultralytics 8.4.68 | rfdetr 1.9.4 | A specific Pointcept commit, torch 2.9.1 |
| Training data it builds | YOLO labels (images/labels/{train,val} + data.yaml) | COCO ({train,valid}/_annotations.coco.json, category ids from 1) | {train,val}/{scene}/{coord,color,segment}.npy (plus instance.npy for instance segmentation) |
| Label source | COCO · LabelMe · VOC annotations | Same | Integer properties inside the PLY (class, instance ID), following the dataset's point label reading |
| Pretrained weight location | Working directory (/geo) | RF_HOME (/geo/work/weights) | /geo/work/weights (the trainer looks there itself) |
- All three trainers build a dataset in their own format in
GEO_WORK_DIR, and link images with symbolic links instead of copying them (/geo/datasetis read-only, so there is no reason to copy). Only point clouds are converted from.plyto.npy. - Labels without polygons are downgraded to bbox rectangles for segmentation training.
- Pointcept uses CUDA-only extensions, so submitting without a GPU is rejected at submission. Semantic segmentation needs at least two classes, and instance segmentation needs an instance property set on the dataset, or the submission is rejected.
- Which point cloud property is the class and which is the instance ID is decided by the dataset's point label reading. If the reading is not confirmed, it is decided by name: a name containing
inst·object·obj_id·objidis the instance ID (or the class, if it also containsclass·semantic); a name containinglabel·class·segment·semanticis the class; if neither applies, the first integer property that is not a coordinate or color is the class. A float property whose values are all integers is also read as an integer. - The instance ID is not used as a class. In a dataset that assigns a class per instance, the assignment table sets each point's class, and points of unassigned instances or negative IDs are ignored in training. Points with a background instance ID train as the background class if one is chosen, and are ignored otherwise.
To use them
A built-in runtime is used for training only after its image is published (built inside the cluster and pushed to the registry). A tenant administrator creates and publishes a variant per framework in Training runtime (학습 런타임), or a system administrator hands one out as a shared image. The detailed procedure is in the Administration guide.