Model Training, Jobs, and Model Catalog/Deployment
Domain 3 - Model Training, Jobs, and Model Catalog/Deployment
This domain tests the batch-to-endpoint path: defining jobs, running and scheduling them, registering artifacts, and deploying a model that can be called securely.
Core rules
- A job defines the script, conda environment, shape, block storage, subnet, command-line arguments, environment variables, and output URI. A job run is one execution with logs and a lifecycle state.
- Jobs are suited to repeatable training, batch scoring, and pipeline steps. They are not interactive; write artifacts to Object Storage because local storage is ephemeral.
- The model catalog stores model metadata and artifacts with provenance. A model deployment serves a catalog model on an HTTP endpoint with a shape, instance count, bandwidth, and logging configuration.
- Deployment traffic stays in the VCN. Put the deployment in a subnet that can reach required services; clients need the endpoint URL and appropriate IAM/auth.
- ADS can save and deploy models, but the same rules apply: artifact location, environment, and network path.
Worked example
A job trains a model and writes model.pkl to oci://ml-bucket@namespace/models/v1/. Register that artifact in the model catalog with the training job OCID and environment. Create a model deployment in the application subnet with a CPU shape and two instances. Invoke the endpoint from an application in the same VCN. For a new version, register a new catalog entry and update the deployment rather than editing the running container.
Traps
- Writing to
/home/datasciencein a job and expecting it to persist. - Omitting the output URI or using a bucket the job's subnet cannot reach.
- Deploying with a shape that cannot load the artifact, or with too few instances for the SLA.
- Forgetting IAM policies for model deployment invocation and catalog access.