Use low priority VMs for batch deployments

APPLIES TO: Azure CLI ml extension v2 (current) Python SDK azure-ai-ml v2 (current)

Important

Low priority virtual machines (VMs) were retired for Azure Machine Learning on March 31, 2026. Compute clusters that specify tier: low_priority still pass validation and still run jobs, but Azure Batch now allocates their nodes as Spot VMs through a system-initiated migration. Spot pricing and Spot eviction behavior apply to every cluster described in this article, whether you created it before or after the retirement date. For the Batch-level details, see Run Batch workloads on cost-effective Spot VMs.

Azure Batch deployments support low priority VMs to reduce the cost of batch inference workloads. Low priority VMs enable a large amount of compute power to be used for a low cost. Low priority VMs take advantage of surplus capacity in Azure. When you specify low priority VMs in your pools, Azure can use this surplus, when available.

Tip

The tradeoff for using low priority VMs is that those virtual machines might not be available or they might be preempted at any time, depending on available capacity. For this reason, this approach is most suitable for batch and asynchronous processing workloads, where job completion time is flexible and the work is distributed across many virtual machines.

Because these nodes are now allocated as Spot VMs, you're charged the current Spot rate for the VM size in the region where the cluster runs. That rate is variable rather than a fixed discount. It changes with region and demand, and it can approach the pay-as-you-go price when a region has little surplus capacity. You're never charged more than the pay-as-you-go price for the same VM size. For more information, see Azure Spot Virtual Machines.

Check the current rate for your VM size and region before you choose a region. You can check it in the Azure pricing calculator or through the Azure retail prices API. For general pricing details, see Azure Machine Learning pricing.

Note

Azure Batch doesn't support setting a maximum price for Spot VMs, so you can't cap the rate that a compute cluster pays. Nodes are evicted only for capacity reasons, never because of price. See Run Batch workloads on cost-effective Spot VMs.

How batch deployment works with low priority VMs

Azure Machine Learning Batch Deployments provides several capabilities that make it easy to consume and benefit from low priority VMs:

Batch deployment jobs consume low priority VMs by running on Azure Machine Learning compute clusters created with low priority VMs. After a deployment is associated with a low priority VMs cluster, all the jobs produced by such deployment use low priority VMs. Per-job configuration isn't possible.
Batch deployment jobs automatically seek the target number of VMs in the available compute cluster based on the number of tasks to submit. If VMs are preempted or unavailable, batch deployment jobs attempt to replace the lost capacity by queuing the failed tasks to the cluster.
Low priority VMs have a separate vCPU quota that differs from the one for dedicated VMs. Low-priority cores per region have a default limit of 100 to 3,000, depending on your subscription. The number of low-priority cores per subscription can be increased and is a single value across VM families. See Azure Machine Learning compute quotas.

Considerations and use cases

Many batch workloads are a good fit for low priority VMs. Using low priority VMs can introduce execution delays when deallocation of VMs occurs. If you have flexibility in the time jobs have to finish, you might tolerate the potential drops in capacity.

When you deploy models under batch endpoints, rescheduling can be done at the minibatch level. That approach has the benefit that deallocation only impacts those minibatches that are currently being processed and not finished on the affected node. All completed progress is kept.

Limitations

After a deployment is associated with a low priority VMs cluster, all the jobs produced by such deployment use low priority VMs. Per-job configuration isn't possible.
Rescheduling is done at the minibatch level, regardless of the progress. No checkpointing capability is provided.
You're billed for every node in the cluster while it's powered on, including nodes that are evicted before they complete any work, and including the time each replacement node spends starting up. Eviction doesn't produce a refund or a credit, and Spot VMs carry no SLA. See Virtual machine states and billing status and Best practices for Azure Batch.
Frequent evictions can make a cluster cost more than a dedicated cluster for the same workload, especially in regions where the Spot rate is close to the pay-as-you-go rate.

Warning

In the cases where the entire cluster is preempted or running on a single-node cluster, the job is cancelled because there is no capacity available for it to run. Resubmitting is required in this case.

Create batch deployments that use low priority VMs

Batch deployment jobs consume low priority VMs by running on Azure Machine Learning compute clusters created with low priority VMs.

Note

After a deployment is associated with a low priority VMs cluster, all the jobs produced by such deployment use low priority VMs. Per-job configuration is not possible.

You can create a low priority Azure Machine Learning compute cluster as follows:

Azure CLI
Python

Create a compute definition YAML like the following one, low-pri-cluster.yml:

$schema: https://azuremlschemas.azureedge.net/latest/amlCompute.schema.json 
name: low-pri-cluster
type: amlcompute
size: STANDARD_DS3_v2
min_instances: 0
max_instances: 2
idle_time_before_scale_down: 120
tier: low_priority

Create the compute using the following command:

az ml compute create -f low-pri-cluster.yml

To create a new compute cluster with low priority VMs where to create the deployment, use the following script:

from azure.ai.ml.entities import AmlCompute

compute_name = "low-pri-cluster"
compute_cluster = AmlCompute(
   name=compute_name, 
   description="Low priority compute cluster", 
   min_instances=0, 
   max_instances=2,
   tier='LowPriority'
)

ml_client.begin_create_or_update(compute_cluster)

After you create the new compute, you can create or update your deployment to use the new cluster:

Azure CLI
Python

To create or update a deployment under the new compute cluster, create a YAML configuration file, endpoint.yml:

$schema: https://azuremlschemas.azureedge.net/latest/batchDeployment.schema.json
endpoint_name: heart-classifier-batch
name: classifier-xgboost
description: A heart condition classifier based on XGBoost
type: model
model: azureml:heart-classifier@latest
compute: azureml:low-pri-cluster
resources:
  instance_count: 2
settings:
  max_concurrency_per_instance: 2
  mini_batch_size: 2
  output_action: append_row
  output_file_name: predictions.csv
  retry_settings:
    max_retries: 3
    timeout: 300

Then, create the deployment with the following command:

az ml batch-endpoint create -f endpoint.yml

To create or update a deployment under the new compute cluster, use the following script:

deployment = ModelBatchDeployment(
    name="classifier-xgboost",
    description="A heart condition classifier based on XGBoost",
    endpoint_name=endpoint.name,
    model=model,
    compute=compute_name,
    settings=ModelBatchDeploymentSettings(
      instance_count=2,
      max_concurrency_per_instance=2,
      mini_batch_size=2,
      output_action=BatchDeploymentOutputAction.APPEND_ROW,
      output_file_name="predictions.csv",
      retry_settings=BatchRetrySettings(max_retries=3, timeout=300),
   )
)

ml_client.batch_deployments.begin_create_or_update(deployment)

View and monitor node deallocation

New metrics are available in the Azure portal for low priority VMs to monitor low priority VMs. These metrics are:

Preempted nodes
Preempted cores

To view these metrics in the Azure portal:

Navigate to your Azure Machine Learning workspace in the Azure portal.
Select Metrics from the Monitoring section.
Select the metrics you desire from the Metric list.

Feedback

Was this page helpful?

Last updated on 2026-07-30