Training your PyTorch model using components and pipelines in Azure ML


Topic: Azure ML + PyTorch: better together


In this post, we’ll explore how you can take your PyTorch model training to the next level, using Azure ML. In particular, we’ll see how you can split your training code into multiple steps that can be easily shared and reused by others, and how you can connect those steps into a training graph to be executed in the cloud.

If you’re looking to get started with bringing your PyTorch model to the cloud, make sure you read my post on Training and deploying your PyTorch model in the cloud with Azure ML first.

The project associated with this post can be found on GitHub.

Step 1: Train and test your PyTorch model locally

The first step is to make sure we can train and test our PyTorch model on our development machine. Our scenario for this post uses the Fashion MNIST dataset, and has two steps: a training step where we produce a model, and a test step where we make sure our trained model gives us good predictions. I discussed and showed the PyTorch training code in my previous post, so I won’t go over it again. The project for this post adds a PyTorch test step, which you can find in the file, and also below:

"""Tests the model."""

import argparse
import logging

import mlflow
import torch
from torch import nn
from import DataLoader
from torchvision import datasets
from torchvision.transforms import ToTensor

from common import DATA_DIR, MODEL_DIR
from utils_train_nn import evaluate

def load_test_data(data_dir: str, batch_size: int) -> DataLoader[torch.Tensor]:
    Returns a DataLoader object that wraps test data.
    test_data = datasets.FashionMNIST(data_dir,
    test_loader = DataLoader(test_data, batch_size=batch_size, shuffle=True)

    return test_loader

def test(data_dir: str, model_dir: str, device: str) -> None:
    Tests the model on test data.
    batch_size = 64
    loss_fn = nn.CrossEntropyLoss()
    test_dataloader = load_test_data(data_dir, batch_size)
    model = mlflow.pytorch.load_model(model_uri=model_dir)

    (test_loss, test_accuracy) = evaluate(device, test_dataloader, model,

    mlflow.log_param("test_loss", test_loss)
    mlflow.log_param("test_accuracy", test_accuracy)"Test loss: %f", test_loss)"Test accuracy: %f", test_accuracy)

def main() -> None:

    parser = argparse.ArgumentParser()
    parser.add_argument("--data_dir", dest="data_dir", default=DATA_DIR)
    parser.add_argument("--model_dir", dest="model_dir", default=MODEL_DIR)
    args = parser.parse_args()"input parameters: %s", vars(args))

    device = "cuda" if torch.cuda.is_available() else "cpu"

    test(**vars(args), device=device)

if __name__ == "__main__":

Just like the training code, my test code uses the MLflow open-source framework to log metrics. And because we used MLflow to save the model, we need to do the same to load it.

We now have two executable files that we need to run in sequence: first we execute to produce the model, and then we execute to test it. Our goal is to make sure that the training results in a model that has a satisfactory accuracy when we make predictions on test data. In this case, when you run the test code, you should get an accuracy of somewhere around 85%. Once we’re happy with the results, we’re ready to move our code to the cloud!

Step 2: Train your model in the cloud

Training our model in the cloud using Azure ML requires the creation of a few different cloud entities. Similarly to our previous project, we need to create a compute resource (which specifies the details about the VM), a data asset (which contains a copy of our data), and an environment (which has information about the software packages we want installed). In our previous project, we used a command job to gather the previous resources together with the command used to run our training script, and to execute that script in the cloud. But we can’t do that this time because we don’t have a single script, we have two scripts! That’s where Azure ML components and pipelines come in. We can register each script as a component, and then connect those components into a pipeline job, which is capable of running multiple steps. Let’s take a look at the Azure ML code we need to write to create these resources, which you can find in the file:

"""Creates and runs an Azure ML pipeline."""

import logging
from pathlib import Path

from import MLClient, Input, Output
from import AssetTypes
from import pipeline
from import (AmlCompute, CommandComponent, Data,
                                  Environment, Model)
from azure.identity import DefaultAzureCredential

from common import MODEL_NAME

COMPUTE_NAME = "cluster-cpu"
DATA_NAME = "data-fashion-mnist"
DATA_PATH = Path(Path(__file__).parent.parent, "data")
COMPONENT_TRAIN_NAME = "component_pipeline_sdk_train"
COMPONENT_TEST_NAME = "component_pipeline_sdk_test"
COMPONENT_CODE = Path(Path(__file__).parent.parent, "src")
ENVIRONMENT_NAME = "environment-pipeline-sdk"
CONDA_PATH = Path(Path(__file__).parent, "conda.yml")
EXPERIMENT_NAME = "aml_pipeline_sdk"
DOWNLOADED_MODEL_PATH = Path(Path(__file__).parent.parent)

def main() -> None:
    credential = DefaultAzureCredential()
    ml_client = MLClient.from_config(credential=credential)

    # Create the compute cluster.
    cluster_cpu = AmlCompute(

    # Create the data set.
    dataset = Data(
        description="Fashion MNIST data set",
    registered_dataset =

    # Create environment for components. We won't register it.
    environment = Environment(name=ENVIRONMENT_NAME,
                              image="" +

    # Create the components.
    train_component = CommandComponent(
        command="python --data_dir ${{inputs.data_dir}} " +
        "--model_dir ${{outputs.model_dir}}",

    test_component = CommandComponent(
        command="python --model_dir ${{inputs.model_dir}}")

    registered_train_component = ml_client.components.create_or_update(

    registered_test_component = ml_client.components.create_or_update(

    # Create and submit pipeline.
    @pipeline(experiment_name=EXPERIMENT_NAME, default_compute=COMPUTE_NAME)
    def pipeline_func(data_dir: Input) -> dict[str, str]:
        train_job = registered_train_component(data_dir=data_dir)
        # Ignoring pylint because "test_job" shows up in the Studio UI.
        test_job = registered_test_component(  # pylint: disable=unused-variable

        return {
            "model_dir": train_job.outputs.model_dir,

    pipeline_job = pipeline_func(

    pipeline_job =

    # Create the model.
    model_path = f"azureml://jobs/{}/outputs/model_dir"
    model = Model(name=MODEL_NAME,
    registered_model = ml_client.models.create_or_update(model)

    # Download the model (this is optional).,

if __name__ == "__main__":

As you can see, each component specifies a path to the folder containing the code, inputs and outputs to the script, and a command that runs the script. The train component takes as input a path to the training data and produces a trained model. The test component takes as input the path to the test data and the trained model, and logs loss and accuracy.

The pipeline runs the two components in sequence. In our demo we have a very simple pipeline with just two components, but in more realistic scenarios we typically have a graph of components, some of which have to run sequentially and others which can run in parallel. These components can contain any code you’d like, including pre-processing steps.

Running this script will register the trained model with Azure ML, and it will also download it to your development machine. You can verify that your Azure ML model was registered by going to the Azure ML portal and clicking on “Model” in the left navigation pane. Once you have a trained model registered with Azure ML, you can deploy it by running the file. (If you do so, don’t forget to run the file to delete the endpoint when you’re done and avoid unnecessary charges.)

My favorite aspect of components is that once they’re registered with Azure ML, I can easily reuse them in future projects by simply adding them to another pipeline. I can also share them with my teammates through the use of registries, a feature that the Azure ML team recently announced.

Hopefully I’ve inspired you to take your next step in your journey of moving your PyTorch training to the cloud. Thanks for reading!