You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/machine-learning/how-to-use-low-priority-batch.md
+19-19Lines changed: 19 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,14 +29,13 @@ Azure Machine Learning Batch Deployments provides several capabilities that make
29
29
30
30
- Batch deployment jobs consume low priority VMs by running on Azure Machine Learning compute clusters created with low priority VMs. Once a deployment is associated with a low priority VMs' cluster, all the jobs produced by such deployment will use low priority VMs. Per-job configuration is not possible.
31
31
- 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.
32
-
- When a job is interrupted, it is resubmitted to run again. Rescheduling is done at the mini batch level, regardless of the progress. No checkpointing capability is provided.
33
32
- 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 offer type. 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](how-to-manage-quotas.md#azure-machine-learning-compute).
34
33
35
34
## Considerations and use cases
36
35
37
36
Many batch workloads are a good fit for low priority VMs. Although this may introduce further execution delays when deallocation of VMs occurs, the potential drops in capacity can be tolerated at expenses of running with a lower cost if there is flexibility in the time jobs have to complete.
38
37
39
-
Since batch endpoints distribute the work at the mini-batch level, deallocation only impacts those mini-batches that are currently being processed and not finished on the affected node.
38
+
When **deploying models** under batch endpoints, rescheduling can be done at the minibatch level. That has the extra benefit that deallocation only impacts those mini-batches that are currently being processed and not finished on the affected node. Every completed progress is kept.
40
39
41
40
## Creating batch deployments with low priority VMs
42
41
@@ -99,19 +98,19 @@ Once you have the new compute created, you can create or update your deployment
99
98
endpoint_name: heart-classifier-batch
100
99
name: classifier-xgboost
101
100
description: A heart condition classifier based on XGBoost
101
+
type: model
102
102
model: azureml:heart-classifier@latest
103
103
compute: azureml:low-pri-cluster
104
104
resources:
105
105
instance_count: 2
106
-
max_concurrency_per_instance: 2
107
-
mini_batch_size: 2
108
-
output_action: append_row
109
-
output_file_name: predictions.csv
110
-
retry_settings:
111
-
max_retries: 3
112
-
timeout: 300
113
-
error_threshold: -1
114
-
logging_level: info
106
+
settings:
107
+
max_concurrency_per_instance: 2
108
+
mini_batch_size: 2
109
+
output_action: append_row
110
+
output_file_name: predictions.csv
111
+
retry_settings:
112
+
max_retries: 3
113
+
timeout: 300
115
114
```
116
115
117
116
Then, create the deployment with the following command:
@@ -125,19 +124,20 @@ Once you have the new compute created, you can create or update your deployment
125
124
To create or update a deployment under the new compute cluster, use the following script:
126
125
127
126
```python
128
-
deployment =BatchDeployment(
127
+
deployment =ModelBatchDeployment(
129
128
name="classifier-xgboost",
130
129
description="A heart condition classifier based on XGBoost",
0 commit comments