Train and Deploy Models
Training and registration
A command job bundles code, an environment, a compute target, and outputs. After training, register the artifact in the model registry with a type - mlflow_model or custom_model. Registration gives versioning and a stable reference that deployments resolve by name and version.
Endpoints
Managed online endpoints serve real-time requests with key or Azure AD token (aml_token) authentication, autoscaling, traffic splitting, and traffic mirroring. An endpoint must have at least one deployment before invoke succeeds - deploying first and testing the endpoint URL is a classic ordering mistake. Batch endpoints handle large files asynchronously: you invoke with a data asset and configure mini_batch_size, output_action, and an output datastore; batch endpoints have no traffic split.
Scoring code
An MLflow model deployed no-code gets an auto-generated scorer. A custom model needs a scoring script with init() (load model once) and run(raw_data) returning JSON-serializable predictions, plus the inference packages pinned in the environment. Test locally with a local Docker deployment before pushing to the cloud.
Safe rollout
Deploy the new version as a second deployment at 0% traffic, validate it, then shift traffic gradually. Rollback is simply shifting traffic back; there is no redeploy required.
Rule of thumb
Canary by default: 10% of traffic to the new deployment, watch latency and error rate, then move to 50% and 100% (--all-traffic). Keep the previous deployment alive until the promotion is confirmed.