Scheduling Azure ML Compute Instance
Can ZopNight schedule Azure ML Compute Instance?
An Azure ML compute instance is a single-user VM, and its schedule issues the ML compute stop operation: VM billing halts, the OS disk and notebooks persist, and running kernels die. Compared with the native idle shutdown, the calendar stop wins whenever a long cell or an open browser tab fakes activity past 19:00.
How the stop works
| Field | Value |
|---|---|
| Behaviour | stopped via the ML compute stop operation and started on schedule, halting VM billing while stopped. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
One user, one VM, one obvious schedule
A compute instance is a researcher’s personal machine, and personal machines follow personal calendars. The stop operation deallocates the underlying VM at the scheduled hour and the start operation brings it back. The compute instance has the simplest cost story in the ML workspace, and is often the most wasteful resource without one, because a GPU-backed instance left running over a weekend burns 60-plus idle hours.
Files persist, kernels do not
The instance’s disk survives stops: notebooks, cloned repos, data under the user’s directory all return in the morning. What dies is live state: running kernels, in-memory dataframes, half-finished cells, unattended terminal sessions. The 19:00 cron is effectively a nightly reminder that anything longer than a working day belongs in a submitted job on a compute cluster, not in a notebook cell.
Mounted workspace datastores are unaffected either way; they belong to the workspace, not to the VM being cycled.
The idle detector versus the calendar
Compute instances offer a native idle shutdown, and it is worth enabling, but idleness is inferred, and inference is gameable by accident. A cell blocked on a slow query, an auto-refreshing dashboard tab, a forgotten SSH session: all look like activity and hold the VM up all night. The scheduled stop is unconditional. Run both, with idle shutdown for the early finish and the calendar as the backstop.
Setup scripts rerun at start
Instances configured with a startup script execute it on every scheduled start. Keep environment rebuilds there rather than in a wiki: the morning instance then arrives with mounts, kernels and packages ready instead of arriving broken in a way only its owner knows how to fix.
The residual line
A deallocated instance stops VM and GPU charges; its OS disk keeps billing per GB, and workspace-level storage is untouched. Small numbers against an idle GPU rate. The disk on a stopped instance typically costs less per month than the GPU costs per day.