A9 - SDK, CLI & YAML

• consider a job:

Code: ./src
Command: python train.py --data <input>
Data: detector-data:v5
Environment: sklearn-env:v3
Compute: cpu-cluster

• it can be created through any of these:
  • python SDK
  • CLI + YAML
  • Studio

python SDK

from azure.ai.ml import MLClient, command, Input

# Construct job definition
job = command(
    code="./src",
    command="python train.py --data ${{inputs.data}}",
    inputs={
        "data": Input(
            type="uri_folder",
            path="azureml:detector-data:5"
        )
    },
    environment="azureml:sklearn-env:3",
    compute="cpu-cluster"
)

# Programmatic clinent to interact with the wokspace
returned_job = ml_client.jobs.create_or_update(job)

• use this if:
  • job config depends on python logic, eg: if dataset_size > threshold: compute = "large-cluster" else: compute = "small-cluster"
  • writing an ML app that programmatically creates assets, submits jobs, queries results, constructs pipelines

YAML

$schema: <command-job-schema>

type: command

code: ./src

command: >
  python train.py
  --data ${{inputs.data}}

inputs:
  data:
    type: uri_folder
    path: azureml:detector-data:5

environment: azureml:sklearn-env:3
compute: azureml:cpu-cluster

• this works very similarly to Bicep, to describe the configuration in a file

• note that Bicep and Azure ML YAML are not interchangeable as Bicep describes the infrastructure whereas YAML describes entities/workloads such as job configs.

• CLI submits the YAML as: az ml job create --file job.yml

• this approach is useful as the YAML is version controlled, and Ci can run the command automatically

Studio

• this is best for:
  • learning
  • exploration
  • debugging
  • inspecting jobs/assets
• the downfalls are in reproducibility and automation

asset references

• azureml:detector-data:5 includes the name and the version, which is the AML asset reference

• local path provides where the file is in the machine, eg: ./src

• ARM resource IDs are different:

/subscriptions/<id>/
resourceGroups/<rg>/
providers/Microsoft.MachineLearningServices/
workspaces/<workspace>

• they identify the Azure resource in the ARM hierarchy

• creating assets through SDK:

ml_client.jobs
ml_client.data
ml_client.environments
ml_client.models
ml_client.compute
...

• similarly, for the CLI:

az ml job ...
az ml data ...
az ml environment ...
az ml compute ...
az ml model ...

• so these two are conceptually the same:

job = command(
    code="./src",
    environment="azureml:env:3",
    compute="cpu-cluster"
)

type: command
code: ./src
environment: azureml:env:3
compute: azureml:cpu-cluster

• this is how it all fits in a Git repo:

Git repository
├── src/
│   └── train.py
├── jobs/
│   └── train.yml
├── environments/
│   └── environment.yml
├── infra/
│   └── main.bicep
└── .github/
    └── workflows/
        └── train.yml

• it can be set up as an Action:

Dev > git push > Actions > authenticate via workload ID > Azure CLI > az ml job create --file ... > Azure ML > training job

• SDK and CLI can coexist
• SDK can be used to develop complex pipelines
• CLI can be used for CI/Cd deployment/submission
• Studio can be used to inspect runs and debug

infrastructure > ML assets/config > ML workloads