# 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.

Source: https://zop.dev/integrations/azure/ai-managed-compute-deployment
Updated: 2026-08-19

---

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.