Azure AI Foundry Model Deployment
Does ZopNight manage Azure AI Foundry Model Deployment?
AI Foundry model deployments serve catalog models such as OpenAI, Llama, and Mistral on per-token or provisioned billing, and a provisioned deployment bills its reserved capacity 24/7 whether tokens flow or not. ZopNight records each deployment's model, version, SKU, and capacity, and surfaces underused provisioned capacity in recommendations.
Rules that fire on Azure AI Foundry Model Deployment
No active rule family targets Azure AI Foundry Model 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. |
AI Foundry model deployments serve catalog models (OpenAI, Llama, Mistral, and others) with per-token or provisioned billing. Provisioned deployments bill their reserved capacity continuously.
Per-token versus provisioned capacity
The billing split is the whole story of this type. A pay-as-you-go deployment costs exactly what its callers consume: no traffic, no charge. A provisioned deployment reserves throughput capacity and bills for that reservation around the clock. The meter runs at full rate through nights, weekends, and the months after the workload that justified it has ended. The charge itself lands on the parent Cognitive Services account’s meters; the deployment row exists to explain which model and which capacity produced it.
Deployment detail ZopNight records
Discovered via the AI enricher with model and capacity detail: model name and version, SKU, capacity, and provisioning state per deployment. Accounts of kind AIServices emit these rows (their OpenAI-kind siblings emit the azure-openai-deployment type instead), and ZopNight groups them under a synthetic Model Deployments node per account so multi-model estates stay readable. Cost Management billing attributes spend, and underutilized provisioned capacity surfaces in recommendations. There is no stop verb for a deployment; the levers are deleting it or converting provisioned capacity to per-token.
Reserved throughput nobody is using
The classic leak: a provisioned deployment sized for a launch, still holding full capacity months later at single-digit utilization. Close behind are duplicate deployments of the same model created per team instead of shared, and stale model versions kept deployed “just in case” after an upgrade, each one either billing reserved capacity or cluttering the account with endpoints that could quietly serve production traffic.
Managing deployments from the Foundry portal
In the AI Foundry portal, each project’s Deployments page lists model deployments with their SKU and capacity, and is where capacity is resized or a deployment retired. The Azure portal shows the same rows as child resources of the Cognitive Services account, the view to use when reconciling deployments against the account’s bill.