Déployer un modèle

Portée — lisez d'abord ceci. Cette skill crée des déploiements de modèle hors bande via Azure CLI / MCP / portail. Pour les projets Foundry gérés par azd (ceux scaffoldisés à partir de azd-ai-starter-basic ou via azd ai agent init), déclarez les déploiements dans azure.yaml services.ai-project.deployments[] à la place — azd ai agent init écrit l'entrée à partir du manifeste exemple et azd provision crée le déploiement via Bicep. Consultez foundry-agent/create/create-hosted.md pour le Chemin d'Or. Utilisez cette skill uniquement pour : (a) les projets Foundry non gérés par un projet azd, (b) les déploiements ad-hoc en dehors du cycle de vie azd.

Point d'entrée unifié pour tous les workflows de déploiement de modèle Azure OpenAI. Analyse l'intention de l'utilisateur et route vers le mode de déploiement approprié.

Référence rapide

Détection d'intention

Analysez l'invite de l'utilisateur et routez vers le mode approprié :

User Prompt
    │
    ├─ Déploiement simple (pas de modificateurs)
    │  "deploy gpt-4o", "set up a model"
    │  └─> Mode PRESET
    │
    ├─ Mots-clés de personnalisation présents
    │  "custom settings", "choose version", "select SKU",
    │  "set capacity to X", "configure content filter",
    │  "PTU deployment", "with specific quota"
    │  └─> Mode CUSTOMIZE
    │
    ├─ Requête capacité/disponibilité
    │  "find where I can deploy", "check capacity",
    │  "which region has X capacity", "best region for 10K TPM",
    │  "where is this model available"
    │  └─> Mode CAPACITY DISCOVERY
    │
    └─ Ambigu (a une cible de capacité + intention de déployer)
       "deploy gpt-4o with 10K capacity to best region"
       └─> CAPACITY DISCOVERY d'abord → puis PRESET ou CUSTOMIZE

Règles de routage

Chaînage multi-mode

Certaines invites nécessitent deux modes en séquence :

Modèle : Capacity → Deploy Quand un utilisateur spécifie une exigence de capacité ET veut un déploiement :

1. Exécutez Capacity Discovery pour trouver les régions/projets avec quota suffisant
2. Présentez les résultats à l'utilisateur
3. Demandez : « Voulez-vous déployer avec des valeurs par défaut rapides ou personnaliser les paramètres ? »
4. Routez vers Preset ou Customize selon la réponse

💡 Conseil : Si vous hésitez sur le mode que l'utilisateur veut, préférez Preset (déploiement rapide). Les utilisateurs qui veulent de la personnalisation utilisent généralement des mots-clés explicites comme « custom », « configure » ou « with specific settings ».

Sélection du projet (tous les modes)

Avant tout déploiement, résolvez le projet vers lequel déployer. Cela s'applique à tous les modes (preset, customize, et après la capacity discovery).

Ordre de résolution

1. Vérifiez la variable d'environnement PROJECT_RESOURCE_ID — si définie, utilisez-la comme défaut
2. Vérifiez l'invite de l'utilisateur — si l'utilisateur a nommé un projet ou une région spécifique, utilisez-le
3. Sinon — interrogez les projets de l'utilisateur et suggérez l'actuel

Étape de confirmation (obligatoire)

Confirmez toujours la cible avant de déployer. Montrez à l'utilisateur ce qui sera utilisé et donnez-lui une chance de le changer :

Déploiement vers :
  Project:  <project-name>
  Region:   <region>
  Resource: <resource-group>

Est-ce correct ? Ou choisissez un autre projet :
  1. ✅ Oui, déployer ici (défaut)
  2. 📋 Montrez-moi d'autres projets dans cette région
  3. 🌍 Choisir une région différente

Si l'utilisateur choisit l'option 2, montrez les 5 premiers projets de cette région :

Projects in <region>:
  1. project-alpha (rg-alpha)
  2. project-beta (rg-beta)
  3. project-gamma (rg-gamma)
  ...

⚠️ Ne déployez jamais sans montrer à l'utilisateur quel projet sera utilisé. Cela prévient les déploiements accidentels vers la mauvaise ressource.

Validation de pré-déploiement (tous les modes)

Avant de présenter des options de déploiement (SKU, capacité), validez toujours ces deux éléments :

1. Le modèle supporte le SKU — interrogez le catalogue de modèles pour confirmer que le modèle+version sélectionné supporte le SKU cible :

   az cognitiveservices model list --location <region> --subscription <sub-id> -o json

   Filtrez pour le modèle, extrayez .model.skus[].name pour obtenir les SKUs supportés.

2. L'abonnement a un quota disponible — vérifiez que l'abonnement de l'utilisateur a un quota non alloué pour la combinaison SKU+modèle :

   az cognitiveservices usage list --location <region> --subscription <sub-id> -o json

   Correspondez par le motif du nom d'utilisation OpenAI.<SKU>.<model-name> (p. ex., OpenAI.GlobalStandard.gpt-4o). Calculez available = limit - currentValue.

⚠️ Avertissement : Présentez uniquement les options qui passent les deux vérifications. N'AFFICHEZ PAS de listes SKU codées en dur — interrogez toujours dynamiquement. Les SKUs avec 0 quota disponible doivent être affichés comme des éléments informationnels ❌, pas comme options sélectionnables.

💡 Gestion du quota : Pour les demandes d'augmentation de quota, la surveillance de l'utilisation et la résolution des erreurs de quota, référez-vous à la skill quota au lieu de dupliquer ces conseils en ligne.

Prérequis

Tous les modes de déploiement nécessitent :

• Azure CLI installé et authentifié (az login)
• Abonnement Azure actif avec des permissions de déploiement
• ID de ressource du projet Azure AI Foundry (ou l'agent aidera à le découvrir via la variable d'environnement PROJECT_RESOURCE_ID)

Sub-Skills

• preset/SKILL.md — Déploiement rapide vers la région optimale avec des valeurs par défaut sensées
• customize/SKILL.md — Flux guidé interactif avec contrôle complet de la configuration
• capacity/SKILL.md — Découvrez la capacité disponible dans les régions et les projets