AI Managed Compute Deployment
Does ZopNight manage AI Managed Compute Deployment?
Azure AI managed compute deployments run open-weight catalog models on dedicated VMs, often GPU SKUs, billed per instance-hour whether or not a single request arrives. ZopNight discovers each deployment's instance type and count via the AI enricher, attributes the VM-layer spend, and surfaces idle deployments in recommendations.
Rules that fire on AI Managed Compute Deployment
No active rule family targets AI Managed Compute Deployment today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only. |
Managed compute deployments serve open-weight catalog models on dedicated VM capacity billed per instance-hour. Unlike per-token serving, these bill continuously whether or not requests arrive, often on expensive GPU SKUs.
Dedicated GPUs behind a catalog model
Choosing managed compute for a catalog model swaps the pay-per-token meter for a very different one: dedicated VM instances, typically GPU SKUs, billing per instance-hour from deployment until deletion. Request volume is irrelevant to the charge. The same open-weight model available serverlessly can cost orders of magnitude more served this way at low volume, which makes the serving-mode choice itself the biggest cost decision on this resource.
Instance-level facts ZopNight captures
Discovered via the AI enricher with instance type and count. Cost Management billing attributes the VM-layer spend, and idle managed-compute deployments surface in recommendations. Those are the deployments paying GPU rates for traffic that a serverless endpoint would serve for a fraction of the cost, or for no traffic at all.
Visibility first, structural fixes second
ZopNight scopes this type to discovery and cost visibility; there is no stop operation that preserves the deployment. Acting on an idle finding means resizing the instance count, moving the workload to serverless token billing, or deleting the deployment. Those decisions belong to the owning team, made visible by the per-deployment attribution.
The experiments that never got torn down
The canonical waste here is the evaluation deployment: a team spins up an open-weight model on managed GPU capacity to benchmark it, the benchmark ends, the deployment stays. Its cousins are deployments sized for a latency target nobody measured again, and duplicate deployments of one model across projects that never discovered each other. Each one is a continuously billing GPU allocation wearing a finished experiment’s name.
Auditing managed compute in AI Foundry
The AI Foundry portal’s Deployments view (and Azure ML studio’s endpoint pages) lists managed compute deployments with instance type and count. Cross-reference against request traffic before believing any of them still earn their GPUs.