Upload model
Overview
Registers a PyTorch checkpoint from your machine as a new version in the workspace model registry.
Drop a .pt or .pth file onto the node, say what the model does, and the run turns it into a registered model version that the predict, train, and export nodes of its framework can pick.
Prerequisites
How it works
FAQ
Which model does the new version belong to?
The one named by model_name in Model info, or by the checkpoint’s filename when that is empty. If the workspace already has a model with that name, the upload is added to it as its next version, otherwise a new model is created. Every run registers a new version, even when you upload the same file again.
Why did the run fail with an empty storage path?
Nothing was uploaded. The drag-and-drop widget fills Storage path for you, so an empty field means the file never reached storage.
Task type is marked optional, so why does the run fail without it?
The field is optional in the interface but the run rejects an empty value. Downstream nodes match a model by its task, so a model registered without one cannot be picked.
Which checkpoint gets marked as the best one?
A single uploaded file is always the best one. Upload several and the ones whose filename contains best are marked instead. When several files are uploaded and none matches, no checkpoint is marked and the run logs a warning.
Why did the run fail with no checkpoint found?
The uploaded folder holds no .pt or .pth file. Other formats, including ONNX and TensorRT exports, are not accepted here.
How should I fill Classes?
Pick the ontology whose classes the model predicts, and tick a subset only when the model predicts just those. Picking the ontology without ticking anything takes all of its classes. They are stored in the ontology’s order, which has to match the order the model outputs them in, because predictions are named by position. A classification model’s classes are stored as tags, every other task’s as object classes.
What can I put in Model info?
A YAML mapping. model_name, framework, baseline_model, and img_size are recognized: model_name names the model in the registry, and baseline_model is the upstream architecture the checkpoint was fine-tuned from (yolo11m), which is what the predict and train nodes rebuild it with. Any other key is kept with the files as extra info, verbatim. Content that is not valid YAML is ignored, and the run then fails because framework is missing.
Why does Framework matter?
The model pickers of the predict, train, and export nodes filter on it, so a model without the right framework can’t be picked anywhere. Leave it empty and the run fails, so fill it with the framework the checkpoint was trained with, such as yolo or deim. What you type is turned into that key: YOLOv8 and Grounding DINO are registered as yolo and grounding_dino.
Which frameworks work with an uploaded checkpoint?
A YOLO checkpoint carries everything Predict YOLO and Train YOLO need. DEIM and EdgeCrafter prediction also read the training config stored with a trained version, which an upload doesn’t include, so use such a checkpoint as a starting point for training. For those frameworks, baseline_model must name the architecture exactly as the train node knows it, e.g. deim_dfine_l or ecdet_s.
Inputs
Classes the uploaded model predicts, stored with it in the registry. Key: CLASSES.
Task the model performs. Upload fails without it, since the nodes that take a model select by task. Key: TASK_TYPE.
Options:
- Object Detection (
object_detection) - Classification (
classification) - Semantic Segmentation (
semantic_segmentation) - Instance Segmentation (
instance_segmentation)
Details of the uploaded model in YAML. Framework is required - predict, train and export nodes filter on it, so a model without one cannot be picked anywhere. Key: MODEL_INFO.
S3 location your checkpoint was uploaded to. Filled in automatically when you drop a .pt or .pth file onto the node, and the run fails while it is empty. Placeholder: s3://workspace/user-uploads/%DateTime%/. Key: STORAGE_PATH.
Outputs
Reference to the registry version created for the uploaded checkpoint, as <model id>@<version id>. It wires into the Model input of a predict, train, export or evaluate node and pins it to exactly these weights. Shown as an artifact. Key: MODEL.
JSON config
Machine-readable node interface for automation and advanced usage.