Aller au contenu principal

Module 2 — Cibles de calcul : instances, grappes et calcul sans serveur

Le module précédent a mis en place l'espace de travail vide. Il faut maintenant décider où s'exécutent le notebook exploratoire, la tâche d'entraînement nocturne et le pipeline hebdomadaire du fil rouge. Azure ML propose trois cibles principales, avec des coûts et des latences très différents. Choisir la mauvaise, c'est payer 30 fois plus cher pour un même résultat.

L'instance de calcul : le bureau de la data scientist​

Une compute instance est une machine virtuelle personnelle, allouée à un utilisateur, avec JupyterLab, VS Code Server et le SDK v2 préinstallés. Elle sert au développement interactif : exploration du jeu de ventes hebdomadaires, mise au point d'un notebook de prétraitement, débogage d'un script avant de le passer en tâche.

az ml compute create --type ComputeInstance -n ci-alice \
  --size Standard_DS3_v2 -g rg-prev-demande -w mlw-prev-demande

Trois pièges à retenir :

  • L'instance est facturée tant qu'elle tourne, y compris la nuit et le week-end. La règle d'arrêt automatique (idle_time_before_shutdown_minutes: 60) est indispensable ; sinon on retrouve une facture à trois chiffres pour une semaine d'oubli.
  • Une instance appartient à un utilisateur unique et ne se partage pas. Deux data scientists = deux instances.
  • Elle ne convient pas à l'entraînement productif : pas d'auto-scaling, pas de reprise sur incident, pas de parallélisme.

La grappe de calcul : le cheval de trait de l'entraînement​

Une compute cluster (AmlCompute) est un groupe de machines virtuelles qui se dimensionne automatiquement entre un plancher et un plafond. C'est la cible de choix pour toute tâche non triviale.

az ml compute create --type AmlCompute -n cpu-cluster-32 \
  --size Standard_DS4_v2 --min-instances 0 --max-instances 8 \
  --idle-time-before-scale-down 300 \
  -g rg-prev-demande -w mlw-prev-demande

Le paramètre déterminant est min-instances: 0. Une grappe qui descend à zéro nœud entre les tâches coûte zéro euro entre deux exécutions. Une grappe avec min-instances: 1 — configuration hélas très courante — facture 24 h sur 24 une machine qui ne sert que 40 minutes par semaine. Sur le cluster ci-dessus en région westeurope, la différence sur un an dépasse \$2 000.

La grappe qui ne descend pas à zéro

La justification classique du min-instances: 1 est « éviter les 3 minutes de démarrage à froid ». Elle est presque toujours mauvaise : pour un pipeline hebdomadaire, ces 3 minutes sont négligeables devant le temps d'entraînement, et la facture mensuelle du plancher dépasse largement le coût de ces démarrages cumulés.

idle-time-before-scale-down fixe l'inertie : trop court, la grappe descend puis remonte entre deux tâches consécutives ; trop long, on paie du calcul inutile. 300 secondes est un bon point de départ pour un usage exploratoire, 60 secondes pour un pipeline unique.

Le calcul sans serveur : la nouvelle voie par défaut​

Depuis 2024, Azure ML propose un calcul sans serveur (serverless compute) accessible directement dans la définition de tâche, sans grappe préexistante :

$schema: https://azuremlschemas.azureedge.net/latest/commandJob.schema.json
command: python train.py --data ${{inputs.ventes}}
resources:
  instance_type: Standard_DS3_v2
  instance_count: 2

Aucune ressource de calcul persistante n'est créée : Azure alloue les nœuds à la demande, les libère à la fin, et facture à la seconde. Pour un pipeline occasionnel ou un test unitaire d'entraînement, c'est plus simple et souvent moins cher qu'une grappe à gérer.

La contrepartie : moins de contrôle sur le pool d'IP sortantes, incompatibilité avec certaines options de réseau isolé, et pas de mise en cache de conteneur inter-tâches. Pour un projet en Virtual Network privé, la grappe reste incontournable.

Machines à priorité basse : l'entraînement à moitié prix​

Les VM low-priority (encore appelées spot) coûtent typiquement 60 à 80 % moins cher que leur équivalent standard. En contrepartie, Azure peut les révoquer à tout moment, avec un préavis de 30 secondes. Pour le fil rouge, c'est idéal pour le balayage d'hyperparamètres du module 5 : la reprise est gratuite si l'expérience MLflow sauvegarde régulièrement. C'est à proscrire pour un déploiement en ligne dont la disponibilité doit être garantie.

Quotas régionaux : la contrainte qu'on découvre tard​

Chaque région Azure impose un plafond sur le nombre total de cœurs par famille de VM (vCPU quota). Un nouvel abonnement démarre souvent à 10 cœurs pour la famille Dv3 sur westeurope — de quoi lancer une seule grappe à 4 nœuds. La demande d'augmentation prend 24 à 72 heures ; il faut donc l'ouvrir dès le début du projet, avant que la première tâche ne bloque sur QuotaExceeded.

En résumé​

  • Instance de calcul pour le développement interactif ; toujours activer l'arrêt automatique
  • Grappe avec min-instances: 0 pour l'entraînement récurrent ; le plancher à un nœud est une erreur coûteuse
  • Calcul sans serveur pour les tâches ponctuelles et les pipelines simples, plus rapide à mettre en place
  • Priorité basse pour le balayage d'hyperparamètres, jamais pour la production ; anticiper les demandes de quota régional

Le module suivant équipe ces cibles de calcul avec la matière première : les jeux de données et les magasins de données.