06 · AKS, conteneurs et IA / LLM

Version : 1.0 · Date : 2026-10-21 · Parcours AKS (niveau architecte, préparation d'entretiens)

En une phrase : sur Azure, on peut soit héberger soi-même un modèle (GPU node pools, KAITO, vLLM sur AKS), soit héberger l'application ou l'agent qui consomme un modèle managé (Microsoft Foundry, Azure OpenAI) ; l'architecte choisit le service le plus managé qui répond au besoin, puis sécurise, met à l'échelle et observe la chaîne avec des signaux propres à l'IA (jetons, file d'attente, mémoire GPU).

Ce chapitre suppose les bases d'AKS (01), le réseau (02) et l'identité (03). Les contrôles de sécurité propres à l'IA (AI gateway, guardrails de Foundry, Defender for AI Services) sont détaillés dans le cours SC-500, chapitre 07 : on y renvoie plutôt que de les répéter.

1. Les deux grands cas#

Ces raisons du cas 1 sont celles que Microsoft donne pour KAITO : prix au jeton qui « peut rapidement devenir incontrôlable », besoin d'ajuster ou de personnaliser le modèle, données sensibles dans la finance, la santé ou la défense.

En entretien : la plupart des projets d'entreprise sont des cas 2 (une application RAG ou un agent sur AKS qui appelle Foundry). Le cas 1 se justifie par le volume, la conformité ou la personnalisation, pas par goût de la technique.

2. Où exécuter quoi#

2.1 Les quatre options#

Points vérifiés à connaître :

• Container Apps serverless GPUs : seulement dans les profils de charge de travail Consumption d'un environnement workload profiles (pas dans un environnement Consumption-only) ; quota GPU à demander ; les conteneurs doivent tourner sans root ; un exemple Microsoft mesure 1 à 2 minutes de démarrage à froid pour un modèle d'environ 5 Go.
• Azure Machine Learning : le managed online endpoint est la voie recommandée (calcul, réseau, mises à jour de l'OS gérés, déploiement sûr, coût par déploiement). Le Kubernetes online endpoint (extension Azure ML sur AKS ou Arc) laisse les nodes, le réseau et le monitoring à votre charge ; les modèles du Model catalog n'y sont pas pris en charge et la création d'un déploiement est limitée à 20 minutes. L'ancienne cible AksCompute (SDK v1) est remplacée par KubernetesCompute.
• Repère de dimensionnement donné par Microsoft (guide coût IA) : T4 ou L4 suffisent pour moins d'environ 13 milliards de paramètres ; A100 ou H100 ne se justifient qu'au-delà d'environ 34 milliards ou à fort débit ; L4 et H100 demandent AKS (Container Apps ne propose que T4 et A100).

2.2 L'arbre de décision#

flowchart TD
    A["Besoin : un modèle d'IA dans l'application"] --> B{"Un modèle du catalogue Foundry convient ?"}
    B -- Oui --> F["Microsoft Foundry<br/>+ application sur AKS ou Container Apps"]
    B -- Non --> C{"Modèle à vous (open source, ajusté) ?"}
    C -- Oui --> D{"Charge intermittente,<br/>T4 ou A100 suffisent ?"}
    D -- Oui --> ACA["Azure Container Apps<br/>serverless GPUs"]
    D -- Non --> E{"Cycle ML complet<br/>(entraînement, registre, monitoring) ?"}
    E -- Oui --> AML["Azure Machine Learning<br/>managed online endpoint"]
    E -- Non --> AKS["AKS + GPU node pools<br/>KAITO, vLLM"]

Règle d'architecte : commencer par le plus managé. AKS se justifie quand on a déjà une plateforme Kubernetes et une équipe, ou quand il faut un GPU précis, un réseau particulier, des données qui restent dans le cluster ou un coût maîtrisé à gros volume.

3. Les GPU sur AKS#

3.1 Les familles de VM GPU#

Règles AKS :

• taille minimale conseillée pour un pool GPU : Standard_NC4as_T4_v3 ; la série NVv4 (AMD) n'est pas prise en charge ;
• une taille de VM et un taint se choisissent à la création du pool : impossible d'ajouter une taille GPU à un pool existant ;
• KAITO exige des GPU NVIDIA Ampere ou plus récents (capacité CUDA 8.0) : T4, V100, M60, K80 sont exclus de KAITO.

3.2 La pile logicielle NVIDIA#

Un node GPU a besoin de trois briques : le pilote NVIDIA, le device plugin Kubernetes (qui annonce la ressource nvidia.com/gpu au kubelet) et un exportateur de métriques (DCGM exporter). AKS propose trois profils :

• Le profil est immuable : pour en changer, créer un nouveau pool. L'ancien drapeau --skip-gpu-driver-install n'est plus accepté depuis le 14 août 2025 (remplacé par --gpu-driver None).
• Le NVIDIA GPU Operator sert aux configurations avancées (version de pilote, time-slicing) ; garder alors au moins 1 node si le cluster autoscaler est actif.
• Pièges : pas de correctifs de sécurité automatiques sur un pool GPU Azure Linux (vérifier le canal de mise à niveau de l'image de node) ; Flatcar Container Linux et Azure Linux avec OS Guard ne prennent pas les GPU NVIDIA.

3.3 Placer les pods sur les GPU#

Kubernetes traite le GPU comme une ressource étendue, jamais surallouée : le pod demande nvidia.com/gpu, et le pool GPU porte un taint que seuls les pods GPU tolèrent (pour ne pas gaspiller des nodes coûteux avec des pods ordinaires).

# Pool utilisateur GPU, pile gérée par AKS (préversion), à l'échelle de 0 à 4 nodes
az aks nodepool add --resource-group rg-ia --cluster-name aks-ia --name gpunp \
  --mode User --node-vm-size Standard_NC24ads_A100_v4 \
  --node-taints sku=gpu:NoSchedule --labels accelerator=nvidia \
  --enable-cluster-autoscaler --min-count 0 --max-count 4 \
  --enable-managed-gpu=true

# Extrait de Deployment : tolérer le taint, viser le pool GPU, demander 1 GPU
spec:
  template:
    spec:
      nodeSelector:
        accelerator: nvidia
      tolerations:
        - key: sku
          operator: Equal
          value: gpu
          effect: NoSchedule
      containers:
        - name: inference
          image: monacr.azurecr.io/llm/serveur:1.0
          resources:
            requests: { nvidia.com/gpu: 1 }
            limits:   { nvidia.com/gpu: 1 }

Vérifier : kubectl describe node <node> doit afficher nvidia.com/gpu dans Capacity et Allocatable.

3.4 Partager un GPU#

• MIG existe sur les A100, H100 et H200 : un GPU se découpe en jusqu'à 7 instances. Exemple Standard_ND96asr_v4 : profils MIG1g (1g.5gb, 7 instances) à MIG7g (7g.40gb, 1 instance). Le profil (--gpu-instance-profile) est fixé à la création.
• Stratégie d'exposition : Single (chaque instance vue comme nvidia.com/gpu: 1) ou Mixed (ressource par profil, par exemple nvidia.com/mig-1g.10gb).

3.5 Autoscaling, Spot, quotas et coût#

• Cluster autoscaler : un pod GPU en attente ne déclenche l'ajout d'un node que si toutes ses contraintes collent au pool (requête GPU, labels, taints, affinités, nombre maximal, quota Azure). Un pool à 0 coûte zéro au repos mais ajoute création de VM, téléchargement de l'image, montage des données et chargement du modèle au premier appel : garder un minimum non nul quand la latence compte.
• AKS Automatic et le node autoprovisioning (NAP, basé sur Karpenter) peuvent créer la capacité GPU à partir des pods en attente. KAITO sur Automatic : la page de l'extension VS Code dit qu'il ne s'installe pas aujourd'hui sur un cluster Automatic ; la page de l'add-on ne le cite pas dans ses limites. Prévoir un cluster Standard pour KAITO tant que ce n'est pas clarifié.
• Spot node pool : pool secondaire seulement, sans SLA, éviction avec 30 secondes de préavis, taint kubernetes.azure.com/scalesetpriority=spot:NoSchedule à tolérer. À réserver aux lots, évaluations et ajustements fins avec points de reprise ; jamais pour l'inférence face aux utilisateurs.
• Quota : par famille de VM et par région, à demander avant ; c'est la première cause d'échec d'un Workspace KAITO.
• Coût : l'analyse des coûts AKS montre le coût par node et le coût d'inactivité ; les A100 sont chers, ne les prendre que si la charge l'exige.

4. KAITO (AI toolchain operator)#

4.1 Ce que c'est#

KAITO (Kubernetes AI Toolchain Operator) est un projet CNCF Sandbox ; AKS le propose en add-on managé (AI toolchain operator). Un seul objet, le Workspace (CRD), décrit le modèle et la taille de VM ; KAITO :

• crée les nodes GPU à la bonne taille (Karpenter) ;
• lance le serveur d'inférence, vLLM par défaut, avec une API compatible OpenAI, la mise en forme des invites et les réponses en flux ;
• propose des préréglages (presets) de modèles publiés comme images de conteneur, ou un modèle Hugging Face au choix (gabarit personnalisé, runtime Transformers uniquement) ;
• gère l'ajustement fin (LoRA, QLoRA) dont les adaptateurs sont stockés comme images dans ACR ;
• expose le tool calling et la connexion à des serveurs MCP ; publie les métriques vLLM pour Prometheus.

# Activer l'add-on (nouveau cluster ou cluster existant)
az aks update --resource-group rg-ia --name aks-ia --enable-ai-toolchain-operator --enable-oidc-issuer

# Workspace d'inférence (structure documentée ; prendre la taille de VM indiquée par le préréglage choisi)
apiVersion: kaito.sh/v1beta1
kind: Workspace
metadata:
  name: workspace-phi-4-mini
resource:
  instanceType: "Standard_NC24ads_A100_v4"
  labelSelector:
    matchLabels:
      apps: phi-4-mini
inference:
  preset:
    name: phi-4-mini-instruct

4.2 Le cycle d'un Workspace#

sequenceDiagram
    actor E as Équipe ML
    participant K as AI toolchain operator (KAITO)
    participant N as Node autoprovisioning
    participant P as Pod vLLM
    E->>K: kubectl apply Workspace (preset, instanceType)
    K->>N: Demande des nodes GPU de la taille indiquée
    N-->>K: Nodes prêts (jusqu'à 10 min)
    K->>P: Démarre vLLM avec l'image du modèle
    P-->>K: Modèle chargé (Workspace prêt : jusqu'à 20 min)
    E->>P: POST /v1/chat/completions via le Service
    Note over E,K: Supprimer le Workspace ne supprime pas le GPU node pool : à faire à la main

4.3 Limites à connaître#

KAITO existe aussi en extension pour AKS sur Azure Local (préversion), pour l'inférence au plus près des données.

5. Les moteurs d'inférence#

Ollama n'apparaît pas dans la documentation AKS consultée : c'est surtout un outil de poste de développeur.

Pourquoi vLLM compte en entretien : le goulot d'un LLM est la mémoire GPU (poids + cache KV des conversations en cours). Un moteur comme vLLM gère ce cache pour servir plus de requêtes simultanées par GPU ; ses métriques de file d'attente et de cache KV sont les bons signaux de mise à l'échelle et de routage.

6. Mettre un LLM à l'échelle#

6.1 Les bons signaux#

Le CPU est un mauvais signal pour un LLM : le GPU peut être saturé alors que le CPU est bas. KEDA lit les métriques du Managed Prometheus (espace Azure Monitor) depuis KEDA 2.10, avec une Workload Identity qui a le rôle Monitoring Data Reader ; KEDA doit être le seul adaptateur de métriques externes du cluster.

# Mise à l'échelle d'un Deployment vLLM sur les requêtes en attente (Prometheus managé, Workload Identity)
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-managed-prometheus-auth
spec:
  podIdentity:
    provider: azure-workload
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-scaler
spec:
  scaleTargetRef:
    name: vllm-phi
  minReplicaCount: 1            # un réplica chaud : pas de démarrage à froid en journée
  maxReplicaCount: 6
  triggers:
    - type: prometheus
      metadata:
        serverAddress: https://<espace>.<region>.prometheus.monitor.azure.com
        query: sum(vllm:num_requests_waiting)   # exemple construit : Microsoft recommande de scaler sur la file d'attente ou le cache KV
        threshold: "10"
      authenticationRef:
        name: azure-managed-prometheus-auth

6.2 Le démarrage à froid et les images lourdes#

Un nouveau réplica sur un nouveau node = création de la VM + téléchargement de l'image (souvent 5 à 15 Go pour une image GPU) + chargement du modèle en mémoire GPU. Leviers documentés :

7. Applications et agents qui consomment des modèles managés#

7.1 Le schéma de référence#

Le RAG (retrieval-augmented generation) : l'application récupère des passages dans un index (Azure AI Search, vectoriel et hybride), augmente l'invite avec ce contexte, puis le modèle génère une réponse fondée et citée. Sur AKS : front, API/orchestrateur (ou agent) et éventuellement l'ingestion en pods CPU ; le modèle reste dans Foundry.

sequenceDiagram
    actor U as Utilisateur
    participant O as Orchestrateur (pod AKS)
    participant E as Microsoft Entra ID
    participant S as Azure AI Search
    participant F as Foundry (Azure OpenAI)
    participant C as Cosmos DB
    U->>O: Question
    O->>E: Jeton du service account (Workload Identity)
    E-->>O: Jeton d'accès Entra (sans clé)
    O->>F: Embedding de la question
    O->>S: Recherche vectorielle / hybride
    S-->>O: Passages pertinents + métadonnées
    O->>F: Invite augmentée (question + passages)
    F-->>O: Réponse fondée
    O->>C: Historique de conversation
    O-->>U: Réponse avec citations

7.2 Sans clé : Workload Identity#

1. Activer --enable-oidc-issuer --enable-workload-identity sur le cluster.
2. Créer une user-assigned managed identity et lui donner le rôle Cognitive Services OpenAI User sur la ressource (Contributor seulement pour les Assistants). La ressource doit avoir un custom subdomain pour l'authentification Entra.
3. Créer la federated credential : émetteur OIDC du cluster, sujet system:serviceaccount:<namespace>:<service account>, audience api://AzureADTokenExchange.
4. Annoter le ServiceAccount azure.workload.identity/client-id et mettre le label azure.workload.identity/use: "true" sur le pod (obligatoire). Le code utilise DefaultAzureCredential (bibliothèque Azure Identity).

az identity federated-credential create --name fic-agent --identity-name id-agent --resource-group rg-ia \
  --issuer "$(az aks show -g rg-ia -n aks-ia --query oidcIssuerProfile.issuerUrl -o tsv)" \
  --subject system:serviceaccount:agents:sa-agent --audience api://AzureADTokenExchange
# Variante guidée : Service Connector crée identité, rôle et ServiceAccount
az aks connection create cognitiveservices --workload-identity <id-de-l-identite>

Points d'architecte : une identité par charge de travail ; une user-assigned managed identity accepte au plus 20 federated credentials (les identity bindings AKS contournent cette limite pour de nombreux clusters) ; désactiver ensuite les clés locales de la ressource IA (recommandation Defender for Cloud) ; trafic par Private Endpoints.

8. AI gateway et routage d'inférence#

8.1 Azure API Management comme AI gateway#

L'AI gateway d'APIM met un seul point d'entrée devant tous les modèles : Foundry (import direct, authentification au back-end par managed identity), modèles auto-hébergés importés comme Language Model API OpenAI-compatible (vLLM, TGI…) ou en passthrough, et autres fournisseurs. Policies clés : validate-azure-ad-token, llm-token-limit (429 au-delà du débit, 403 au-delà du quota), llm-content-safety, llm-semantic-cache-lookup / store, llm-emit-token-metric, pool de back-ends avec disjoncteur. Détail et exemple XML : SC-500, chapitre 07, section 8.

Piège : llm-token-limit compte les jetons selon le schéma de l'API (OpenAI Chat Completions ou Responses, Anthropic Messages, Vertex AI) ; pour un modèle open source auto-hébergé, vérifier que le comptage correspond à son tokenizer.

8.2 Dans le cluster : l'inference gateway (préversion)#

Application Gateway for Containers propose une inference gateway fondée sur la Gateway API Inference Extension :

• InferencePool : le groupe de pods de modèle et l'Endpoint Picker (EPP) qui choisit le pod pour chaque requête ;
• l'EPP note les réplicas selon la file d'attente, l'occupation du cache KV et l'affinité de préfixe : moins de délai avant le premier jeton, moins de timeouts, meilleure utilisation des GPU ;
• routage par modèle (le champ model du corps OpenAI-compatible), répartition pondérée pour les déploiements canary, InferenceObjective pour prioriser les requêtes critiques ;
• associée au WAF d'Application Gateway for Containers pour filtrer avant de consommer du GPU.

Limite : elle vise les modèles auto-hébergés sur Kubernetes, pas les fournisseurs managés (c'est le rôle d'APIM).

9. MCP, tool calling et serveurs d'outils#

• Tool calling : le modèle décide d'appeler une fonction décrite en JSON (météo, base de données…) et renvoie un tool_calls structuré ; KAITO le prend en charge pour les préréglages vLLM listés.
• MCP (Model Context Protocol) : un serveur d'outils autonome expose des tools, resources et prompts en JSON-RPC sur HTTP streamable ; on met à jour les outils indépendamment du modèle. Un espace de travail KAITO peut appeler un serveur MCP externe (exemple Microsoft avec AutoGen).

Où héberger un serveur MCP (guide Microsoft) :

Sur AKS, un exemple Microsoft Learn déploie un serveur MCP avec le contrôleur open source KMCP (ressource MCPServer). APIM peut aussi exposer une API REST comme serveur MCP ou gouverner un serveur MCP existant.

10. Sécurité propre à une plateforme d'IA#

Responsabilité : les logiciels open source que vous déployez (moteur d'inférence, opérateurs) sont hors SLA AKS et support Azure ; ceux que Microsoft déploie via un add-on (KAITO) sont construits, analysés et signés par Microsoft.

Pour l'entraînement distribué, attention : NCCL négocie des ports dynamiques ; une Network Policy trop étroite fait « pendre » les jobs. Autoriser tout le trafic entre les réplicas du job et le DNS, pas au-delà.

11. Observabilité d'une charge d'IA#

• Managed Prometheus + Container Insights + Azure Managed Grafana : la base.
• vLLM : KAITO publie /metrics ; un ServiceMonitor (CRD azmonitoring.coreos.com/v1, dans kube-system) les envoie au Managed Prometheus ; vLLM fournit un tableau de bord Grafana à importer.
• GPU : DCGM exporter (port 19400 avec le Managed GPU), récupéré par un PodMonitor ; ne pas déployer deux exportateurs si le GPU Operator en a déjà un.

• Santé GPU : le Node Problem Detector expose des conditions de node (UnhealthyNvidiaDevicePlugin, UnhealthyNvidiaDCGMServices, nombre de GPU incorrect) : alerte, isolement du node, replanification.
• Jetons et coût : llm-emit-token-metric d'APIM vers Application Insights, par client et par modèle.

12. Entraînement et ajustement fin (en bref)#

13. Erreurs fréquentes#

14. Lab#

Coût : un node A100 coûte cher à l'heure. Faire le lab dans un abonnement de test, supprimer tout à la fin. Rien n'est à lancer sur un environnement partagé.

Lab A : un LLM open source avec KAITO (environ 1 h)

1. Vérifier le quota GPU de la famille visée dans la région.
2. Créer un cluster avec --enable-ai-toolchain-operator --enable-oidc-issuer.
3. kubectl apply du Workspace Phi-4-mini de l'exemple officiel ; suivre kubectl get workspace -w (ResourceReady, InferenceReady, WorkspaceSucceeded).
4. Tester l'API compatible OpenAI depuis un pod curl sur l'IP du Service.
5. Ajouter un ServiceMonitor, importer le tableau de bord vLLM dans Grafana, envoyer quelques requêtes.
6. Nettoyer : kubectl delete workspace …, puis supprimer le GPU node pool créé, puis le resource group.

Lab B : une application qui appelle Azure OpenAI sans clé (environ 45 min)

1. Déployer l'application d'exemple « AKS Store » du démarrage rapide OpenAI sur AKS.
2. Suivre « Secure access to Azure OpenAI from AKS » : managed identity, rôle Cognitive Services OpenAI User, federated credential, ServiceAccount annoté, label sur le pod.
3. Vérifier avec kubectl describe pod que plus aucune clé n'apparaît dans les variables d'environnement.

15. Questions d'entretien#

1. Un client veut « mettre ChatGPT dans AKS ». Que lui proposez-vous ?

Clarifier d'abord : s'il veut une application qui utilise un modèle, l'application va sur AKS et le modèle reste dans Foundry (Azure OpenAI), appelé sans clé par Workload Identity et Private Endpoint. On n'héberge un modèle sur AKS que pour un modèle open source ou ajusté, un gros volume, ou des données qui ne doivent pas sortir.

2. AKS, Container Apps ou Azure ML pour servir un modèle open source ?

Container Apps serverless GPUs si la charge est intermittente et que T4 ou A100 suffisent (mise à zéro, à la seconde). Azure ML managed online endpoint si l'équipe fait du MLOps complet (déploiement sûr, monitoring de modèle). AKS si on a déjà la plateforme et l'équipe, ou besoin de H100/L4, d'un réseau particulier, d'un coût maîtrisé à gros volume.

3. Comment empêcher les pods ordinaires d'aller sur les nodes GPU ?

Pool GPU dédié avec un taint (sku=gpu:NoSchedule), toleration et requête nvidia.com/gpu dans les seuls pods GPU, plus un label pour le nodeSelector. Le taint et la taille se fixent à la création du pool.

4. Comment partager un A100 entre plusieurs petits modèles ?

MIG en production : découpage matériel jusqu'à 7 instances isolées, profil fixé à la création du pool, exposé en Single ou Mixed. Time-slicing ou MPS (via le GPU Operator) en développement : plus souples mais sans isolation.

5. Sur quoi mettre à l'échelle un service LLM ?

Sur la charge d'inférence : file d'attente (Service Bus) ou métriques vLLM (requêtes en attente, cache KV) via KEDA et le Managed Prometheus ; le cluster autoscaler ou NAP ajoute les nodes GPU. Pas sur le CPU.

6. Le premier appel après une nuit prend trois minutes. Pourquoi, et que faire ?

Démarrage à froid : création du node GPU, téléchargement d'une image de plusieurs Go, chargement du modèle. Garder un réplica chaud en journée, Artifact Streaming (préversion), poids sur stockage monté, disque OS éphémère, Prepared Image Specification.

7. Qu'apporte KAITO par rapport à un Deployment vLLM écrit à la main ?

Un Workspace provisionne les nodes GPU à la bonne taille, applique une configuration testée pour le modèle (pas d'OOM à régler), expose une API compatible OpenAI, gère l'ajustement fin et les métriques. Limites : GPU Ampere+, pas de Windows, une version de retard, pool à supprimer à la main.

8. Comment l'application accède-t-elle à Azure OpenAI sans clé ?

Workload Identity : OIDC issuer du cluster, user-assigned managed identity avec le rôle Cognitive Services OpenAI User, federated credential sur le service account, annotation client-id et label azure.workload.identity/use ; DefaultAzureCredential dans le code. Puis clés locales désactivées et Private Endpoint.

9. Pourquoi une AI gateway, et pourquoi en plus une inference gateway ?

L'AI gateway (APIM) gouverne tous les modèles, managés ou non : authentification Entra, quotas de jetons par client, Content Safety, cache sémantique, métriques de coût, bascule PTU vers paiement à l'usage. L'inference gateway (Application Gateway for Containers, préversion) agit dans le cluster : elle choisit le réplica vLLM selon sa file et son cache KV.

10. Quels contrôles de sécurité propres à l'IA ajoutez-vous sur AKS ?

Sources de modèles approuvées et images analysées dans un ACR privé ; sortie filtrée par Azure Firewall ; Network Policies ; Prompt Shields et Content Safety à la passerelle ; Defender for Containers sur le cluster et Defender for AI Services sur Foundry ; aucune clé (Workload Identity) ; journalisation des jetons et des invites selon la politique de données.

16. Fiche à retenir#

• Deux cas : héberger le modèle (GPU, KAITO, vLLM) ou héberger l'application qui appelle Foundry (le plus fréquent).
• Choix : Foundry → Container Apps serverless GPUs (T4, A100, mise à zéro) → Azure ML (online endpoints) → AKS (contrôle total).
• L4 et H100 : AKS ; Container Apps ne propose que T4 et A100.
• GPU node pool dédié, taint + toleration + nvidia.com/gpu ; taille et taint fixés à la création.
• Pile NVIDIA : pilote, device plugin, DCGM exporter ; profils Managed GPU (préversion), driver only (défaut), BYO.
• MIG (A100, H100, H200) : jusqu'à 7 instances isolées, pour la production ; time-slicing et MPS sans isolation.
• Spot : lots seulement (30 s de préavis, sans SLA) ; quota GPU par famille et région à demander avant.
• KAITO : Workspace → nodes GPU + vLLM + API compatible OpenAI ; Ampere+, pas de Windows ; pool à supprimer à la main.
• Mise à l'échelle sur la file ou les métriques vLLM (KEDA ≥ 2.10 + Managed Prometheus), pas sur le CPU.
• Démarrage à froid = VM + image + modèle : réplica chaud, Artifact Streaming (tag, ACR Premium), poids sur stockage.
• Sans clé : Workload Identity + Cognitive Services OpenAI User + Private Endpoint ; 20 federated credentials par identité.
• AI gateway (APIM) devant tous les modèles ; inference gateway (préversion) dans le cluster pour choisir le réplica.
• Observer le service (file, latence, jetons), le GPU (DCGM, XID) et le coût (jetons par client).

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Déployer un modèle IA sur AKS avec l'AI toolchain operator
• Ajuster et déployer un modèle avec l'AI toolchain operator
• Concepts : ajustement fin des modèles de langage
• Intégrer des modèles personnalisés avec KAITO
• Tool calling avec KAITO
• Connecter un serveur MCP à KAITO
• Surveiller les métriques d'inférence KAITO
• KAITO dans Visual Studio Code
• Utiliser des GPU sur AKS
• Pool de nœuds GPU entièrement managé (préversion)
• Pool de nœuds GPU multi-instance
• Stratégies de partitionnement GPU
• Bonnes pratiques MLOps sur AKS
• Utiliser AKS pour des charges GPU (Architecture Center)
• Tailles de VM GPU
• Spot node pool sur AKS
• Module complémentaire KEDA
• Intégrer KEDA à Managed Prometheus
• Artifact Streaming sur AKS
• Prepared Image Specification (préversion)
• Améliorer le tirage des images sur AKS
• Serverless GPUs dans Azure Container Apps
• Online endpoints d'Azure Machine Learning
• Kubernetes compute target dans Azure Machine Learning
• Optimiser le coût des charges d'IA
• Sécuriser l'accès à Azure OpenAI depuis AKS
• Déployer une application qui utilise OpenAI sur AKS
• Microsoft Entra Workload ID sur AKS
• Utiliser Azure OpenAI sans clé
• Connecter AKS à Azure OpenAI avec Service Connector
• RAG et index dans Foundry
• AI gateway dans Azure API Management
• Importer une Language Model API dans APIM
• Policy llm-token-limit
• Application Gateway for Containers : inference gateway
• Configurer l'inference gateway
• Choisir un service Azure pour un serveur MCP
• Héberger des serveurs MCP sur Container Apps
• Serveur MCP Open-WebSearch sur AKS
• Sécuriser les services PaaS pour l'IA (CAF)
• AI security posture management
• Activer la protection contre les menaces pour les services d'IA