Lar
deploy-model
microsoft/skills
Cria implantações de modelos do Azure OpenAI com roteamento inteligente baseado em intenção, oferecendo suporte a predefinições rápidas, personalização total e descoberta de capacidade entre regiões e projetos.
...Expandir tudoImplantar modelo
Escopo — leia isto primeiro. Esta habilidade cria implantações de modelo fora da banda por meio da CLI do Azure / MCP / portal. Para projetos do Foundry gerenciados pelo azd (aqueles gerados a partir
do azd-ai-starter-basicou por meio do comando `azd ai agent init`), declare as implantações nosserviços do arquivo `azure.yaml`.em vez disso — o comando `.config.deployments[] azd ai agent init`grava a entrada a partir do manifesto de exemplo eo `azd provision`cria a implantação por meio do Bicep. Consulte foundry-agent/create/create-hosted.md para conhecer o caminho recomendado. Use essa funcionalidade apenas para: (a) projetos do Foundry não gerenciados por um projeto azd, (b) implantações ad hoc fora do ciclo de vida do azd.
Ponto de entrada unificado para todos os fluxos de trabalho de implantação de modelos do Azure OpenAI. Analisa a intenção do usuário e direciona para o modo de implantação apropriado.
Referência rápida
| Modo | Quando usar | Subhabilidade |
|---|---|---|
| Predefinição | Implantação rápida, sem necessidade de personalização | predefinição/SKILL.md |
| Personalizar | Controle total: versão, SKU, capacidade, política de RAI | customize/SKILL.md |
| Detecção de capacidade | Descubra onde é possível fazer a implantação com uma capacidade específica | capacity/SKILL.md |
Detecção de intenção
Analise o prompt do usuário e encaminhe para o modo correto:
Solicitação do usuário
│
├─ Implantação simples (sem modificadores)
│ “implantar gpt-4o”, “configurar um modelo”
│ └─> modo PRÉ-CONFIGURADO
│
├─ Presença de palavras-chave de personalização
│ “configurações personalizadas”, “escolher versão”, “selecionar SKU”,
│ “definir capacidade para X”, “configurar filtro de conteúdo”,
│ “implantação de PTU”, “com cota específica”
│ └─> modo CUSTOMIZE
│
├─ Consulta de capacidade/disponibilidade
│ “descobrir onde posso implantar”, “verificar capacidade”,
│ “qual região tem capacidade X”, “melhor região para 10 mil TPM”,
│ “onde este modelo está disponível”
│ └─> modo DESCOBERTA DE CAPACIDADE
│
└─ Ambíguo (possui meta de capacidade + intenção de implantação)
“implantar o gpt-4o com capacidade de 10 mil na melhor região”
└─> primeiro DESCOBERTA DE CAPACIDADE → depois PRÉ-CONFIGURAÇÃO ou PERSONALIZAÇÃO
Regras de roteamento
| Sinal no prompt | Rotear para | Motivo |
|---|---|---|
| Apenas o nome do modelo, sem opções | Predefinição | O usuário deseja uma implantação rápida |
| “personalizar”, “configurar”, “escolher”, “selecionar” | Personalizar | O usuário deseja controle |
| “encontrar”, “verificar”, “onde”, “qual região”, “disponível” | Capacidade | O usuário deseja identificar |
| Número específico de capacidade + “melhor região” | Capacidade → Predefinição | Descobrir e, em seguida, implantar rapidamente |
| Número específico de capacidade + palavras-chave “personalizadas” | Capacidade → Personalizar | Descubra e, em seguida, implante com opções |
| “PTU”, “taxa de transferência provisionada” | Personalizar | O PTU requer a seleção de SKU |
| “região ideal”, “melhor região” (sem meta de capacidade) | Predefinição | A otimização da região é a especialidade das configurações predefinidas |
Encadeamento multimodo
Algumas solicitações exigem dois modos em sequência:
Padrão: Capacidade → Implantação Quando um usuário especifica um requisito de capacidade E deseja a implantação:
- Execute a Descoberta de Capacidade para localizar regiões/projetos com cota suficiente
- Apresente os resultados ao usuário
- Pergunte: “Você gostaria de fazer a implantação com as configurações padrão rápidas ou personalizar as configurações?”
- Direcione para “Predefinição” ou “Personalizar” com base na resposta
💡 Dica: Se não tiver certeza de qual modo o usuário deseja, use “Pré-definido” (implantação rápida) como padrão. Usuários que desejam personalização geralmente usam palavras-chave explícitas como “personalizado”, “configurar” ou “com configurações específicas”.
Seleção do projeto (todos os modos)
Antes de qualquer implantação, decida em qual projeto a implantação será feita. Isso se aplica a todos os modos (predefinido, personalizado e após a descoberta de capacidade).
Ordem de resolução
- Verifique a variável de ambiente
PROJECT_RESOURCE_ID— se estiver definida, use-a como padrão - Verifique a solicitação do usuário — se o usuário tiver indicado um projeto ou região específica, use essa informação
- Se nenhuma das opções acima — consulte os projetos do usuário e sugira o projeto atual
Etapa de confirmação (obrigatória)
Sempre confirme o destino antes da implantação. Mostre ao usuário o que será utilizado e dê a ele a oportunidade de alterá-lo:
Implantando em:
Projeto:
Região:
Recurso:
Está correto? Ou escolha um projeto diferente:
1. ✅ Sim, implantar aqui (padrão)
2. 📋 Mostrar outros projetos nesta região
3. 🌍 Escolher uma região diferente
Se o usuário escolher a opção 2, mostre os 5 principais projetos nessa região:
Projetos em :
1. project-alpha (rg-alpha)
2. project-beta (rg-beta)
3. project-gamma (rg-gamma)
...
⚠️ Nunca faça uma implantação sem mostrar ao usuário qual projeto será usado. Isso evita implantações acidentais no recurso errado.
Validação pré-implantação (todos os modos)
Antes de apresentar quaisquer opções de implantação (SKU, capacidade), sempre valide estes dois aspectos:
O modelo é compatível com o SKU — consulte o catálogo de modelos para confirmar se o modelo e a versão selecionados são compatíveis com o SKU de destino:
az cognitiveservices model list --location--subscription -o json Filtre pelo modelo e extraia
.model.skus[].namepara obter os SKUs compatíveis.A assinatura possui cota disponível — verifique se a assinatura do usuário possui cota não alocada para a combinação de SKU e modelo:
az cognitiveservices usage list --location--subscription -o json Faça a correspondência pelo padrão de nome de uso
OpenAI.(por exemplo,. OpenAI.GlobalStandard.gpt-4o). Capa de computaçãodisponível = limite - valor atual.
⚠️ Aviso: Apresente apenas as opções que passarem nas duas verificações. NÃO mostre listas de SKUs codificadas — sempre faça a consulta dinamicamente. SKUs com cota disponível igual a 0 devem ser exibidos como ❌ itens informativos, não como opções selecionáveis.
💡 Gerenciamento de cota: para solicitações de aumento de cota, monitoramento de uso e solução de erros de cota, consulte a skill de cota em vez de duplicar essas orientações no texto.
Pré-requisitos
Todos os modos de implantação exigem:
- CLI do Azure instalado e autenticado (
az login) - Assinatura ativa do Azure com permissões de implantação
- ID do recurso do projeto do Azure AI Foundry (ou o agente ajudará a identificá-lo por meio da variável de ambiente
PROJECT_RESOURCE_ID)
Subhabilidades
- preset/SKILL.md — Implantação rápida na região ideal com configurações padrão adequadas
- customize/SKILL.md — Fluxo interativo guiado com controle total da configuração
- capacity/SKILL.md — Descubra a capacidade disponível em todas as regiões e projetos
---
name: deploy-model
description: Creates Azure OpenAI model deployments with intelligent intent-based routing, supporting quick presets, full customization, and capacity discovery across regions and projects.
license: MIT
---
# Deploy Model
> **Scope — read this first.** This skill creates model deployments **out-of-band** via Azure CLI / MCP / portal. For azd-managed Foundry projects (those scaffolded from `azd-ai-starter-basic` or via `azd ai agent init`), declare deployments in `azure.yaml services.<name>.config.deployments[]` instead — `azd ai agent init` writes the entry from the sample manifest and `azd provision` creates the deployment through Bicep. See [foundry-agent/create/create-hosted.md](../../foundry-agent/create/create-hosted.md) for the Golden Path. Use this skill only for: (a) Foundry projects not managed by an azd project, (b) ad-hoc deployments outside the azd lifecycle.
Unified entry point for all Azure OpenAI model deployment workflows. Analyzes user intent and routes to the appropriate deployment mode.
## Quick Reference
| Mode | When to Use | Sub-Skill |
|------|-------------|-----------|
| **Preset** | Quick deployment, no customization needed | [preset/SKILL.md](preset/SKILL.md) |
| **Customize** | Full control: version, SKU, capacity, RAI policy | [customize/SKILL.md](customize/SKILL.md) |
| **Capacity Discovery** | Find where you can deploy with specific capacity | [capacity/SKILL.md](capacity/SKILL.md) |
## Intent Detection
Analyze the user's prompt and route to the correct mode:
```
User Prompt
│
├─ Simple deployment (no modifiers)
│ "deploy gpt-4o", "set up a model"
│ └─> PRESET mode
│
├─ Customization keywords present
│ "custom settings", "choose version", "select SKU",
│ "set capacity to X", "configure content filter",
│ "PTU deployment", "with specific quota"
│ └─> CUSTOMIZE mode
│
├─ Capacity/availability query
│ "find where I can deploy", "check capacity",
│ "which region has X capacity", "best region for 10K TPM",
│ "where is this model available"
│ └─> CAPACITY DISCOVERY mode
│
└─ Ambiguous (has capacity target + deploy intent)
"deploy gpt-4o with 10K capacity to best region"
└─> CAPACITY DISCOVERY first → then PRESET or CUSTOMIZE
```
### Routing Rules
| Signal in Prompt | Route To | Reason |
|------------------|----------|--------|
| Just model name, no options | **Preset** | User wants quick deployment |
| "custom", "configure", "choose", "select" | **Customize** | User wants control |
| "find", "check", "where", "which region", "available" | **Capacity** | User wants discovery |
| Specific capacity number + "best region" | **Capacity → Preset** | Discover then deploy quickly |
| Specific capacity number + "custom" keywords | **Capacity → Customize** | Discover then deploy with options |
| "PTU", "provisioned throughput" | **Customize** | PTU requires SKU selection |
| "optimal region", "best region" (no capacity target) | **Preset** | Region optimization is preset's specialty |
### Multi-Mode Chaining
Some prompts require two modes in sequence:
**Pattern: Capacity → Deploy**
When a user specifies a capacity requirement AND wants deployment:
1. Run **Capacity Discovery** to find regions/projects with sufficient quota
2. Present findings to user
3. Ask: "Would you like to deploy with **quick defaults** or **customize settings**?"
4. Route to **Preset** or **Customize** based on answer
> 💡 **Tip:** If unsure which mode the user wants, default to **Preset** (quick deployment). Users who want customization will typically use explicit keywords like "custom", "configure", or "with specific settings".
## Project Selection (All Modes)
Before any deployment, resolve which project to deploy to. This applies to **all** modes (preset, customize, and after capacity discovery).
### Resolution Order
1. **Check `PROJECT_RESOURCE_ID` env var** — if set, use it as the default
2. **Check user prompt** — if user named a specific project or region, use that
3. **If neither** — query the user's projects and suggest the current one
### Confirmation Step (Required)
**Always confirm the target before deploying.** Show the user what will be used and give them a chance to change it:
```
Deploying to:
Project: <project-name>
Region: <region>
Resource: <resource-group>
Is this correct? Or choose a different project:
1. ✅ Yes, deploy here (default)
2. 📋 Show me other projects in this region
3. 🌍 Choose a different region
```
If user picks option 2, show top 5 projects in that region:
```
Projects in <region>:
1. project-alpha (rg-alpha)
2. project-beta (rg-beta)
3. project-gamma (rg-gamma)
...
```
> ⚠️ **Never deploy without showing the user which project will be used.** This prevents accidental deployments to the wrong resource.
## Pre-Deployment Validation (All Modes)
Before presenting any deployment options (SKU, capacity), always validate both of these:
1. **Model supports the SKU** — query the model catalog to confirm the selected model+version supports the target SKU:
```bash
az cognitiveservices model list --location <region> --subscription <sub-id> -o json
```
Filter for the model, extract `.model.skus[].name` to get supported SKUs.
2. **Subscription has available quota** — check that the user's subscription has unallocated quota for the SKU+model combination:
```bash
az cognitiveservices usage list --location <region> --subscription <sub-id> -o json
```
Match by usage name pattern `OpenAI.<SKU>.<model-name>` (e.g., `OpenAI.GlobalStandard.gpt-4o`). Compute `available = limit - currentValue`.
> ⚠️ **Warning:** Only present options that pass both checks. Do NOT show hardcoded SKU lists — always query dynamically. SKUs with 0 available quota should be shown as ❌ informational items, not selectable options.
> 💡 **Quota management:** For quota increase requests, usage monitoring, and troubleshooting quota errors, defer to the [quota skill](../../quota/quota.md) instead of duplicating that guidance inline.
## Prerequisites
All deployment modes require:
- Azure CLI installed and authenticated (`az login`)
- Active Azure subscription with deployment permissions
- Azure AI Foundry project resource ID (or agent will help discover it via `PROJECT_RESOURCE_ID` env var)
## Sub-Skills
- **[preset/SKILL.md](preset/SKILL.md)** — Quick deployment to optimal region with sensible defaults
- **[customize/SKILL.md](customize/SKILL.md)** — Interactive guided flow with full configuration control
- **[capacity/SKILL.md](capacity/SKILL.md)** — Discover available capacity across regions and projects
Todos os arquivos
0 arquivosInstalar deploy-model
Baixe e descompacte os arquivos das habilidades no diretório .claude/skills/.
Baixar ZIPClone o repositório e copie os arquivos da habilidade para o seu projeto.
git clone https://github.com/microsoft/skills/tree/main/.github/plugins/azure-skills/skills/microsoft-foundry/models/deploy-model # Copy SKILL.md to your .claude/skills/ directory
Copiar
