Azure ML Inference Pool
Does ZopNight manage Azure ML Inference Pool?
Azure ML inference pools provision a shared block of serving capacity that multiple endpoints can draw on, and the whole block bills whether endpoints use 100 percent of it or none. ZopNight discovers each pool's capacity configuration and attributes its spend so utilization can be reviewed against what was provisioned.
Rules that fire on Azure ML Inference Pool
No active rule family targets Azure ML Inference Pool 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. |
Inference pools group provisioned serving capacity that multiple endpoints can share. Pooled capacity bills whether or not endpoints consume it.
Shared capacity, single meter
An inference pool inverts the usual serving economics: instead of each deployment holding its own instances, a pool provisions one block of serving capacity and lets multiple endpoints draw from it. The efficiency pitch is consolidation: several small models sharing headroom instead of each padding its own. The billing reality is that the block itself is the meter: the pool’s provisioned capacity bills continuously, at full rate, independent of how much of it the member endpoints actually consume.
Pool visibility through the AML enricher
Discovered via the AML enricher with capacity configuration, and Cost Management billing attributes pooled-capacity spend for utilization review. Because the pool’s charge is one line covering many models, this attribution is what turns “the shared pool costs what it costs” into a reviewable question: how much capacity was provisioned, and for which tenants.
A rightsizing target, not a scheduling one
ZopNight scopes pools to discovery and cost visibility. There is no per-endpoint meter to pause, and draining shared capacity on a schedule would degrade every model riding on it at once. The actionable lever is the provisioned size of the block, revisited as tenant models come and go.
How pools drift into overprovisioning
Pools inherit the sins of every shared resource. Capacity gets sized for the sum of peak estimates rather than observed concurrency. Models migrate off the pool but their headroom allowance stays. And because no single team owns the shared line, nobody feels individually responsible for shrinking it. The drift only surfaces when someone compares the block’s size against what its endpoints ever draw.
Where to inspect pooled serving capacity
Azure ML studio’s endpoint views show which endpoints are pool-backed and the pool’s capacity configuration. Compare the provisioned block against its members’ combined usage before renewing its size.