Aller au contenu principal
Essentiel•8–14 heures

Laboratoire capacité, coût et chaos pour l’IA

Testez une workload IA sous charge : concurrence, budgets tokens/tools, files, backpressure, 429/5xx/timeouts, load shedding, mode dégradé et coût par tâche vérifiée avec succès.

capacity planningautoscalingfiles d’attentebackpressureinjection de panneséconomie unitaire IA

Scénario

Tâche

Un endpoint IA est stable en charge de démonstration, mais le trafic production comporte des arrivées en rafales, de longs contextes, des appels parallèles aux tools et des quotas fournisseur. Un autoscaling CPU simple ne résout ni le throughput de tokens, ni les délais de file, ni les 429, ni l’amplification des retries, ni l’explosion des coûts. Construisez un modèle de capacité qui mesure les tâches vérifiées avec succès plutôt que le nombre de pods lancés.

Exécution pas à pas

1. Construisez le modèle de workload

Résultat: Le capacity planning reflète la demande propre à l’IA plutôt qu’un nombre moyen de requêtes HTTP.

Tâches

  • →Mesurer le taux d’arrivée et les rafales
  • →Collecter les distributions de tokens input/output
  • →Enregistrer le fan-out des tools et la dépendance la plus lente
  • →Séparer les workloads user-facing, batch et haute priorité

Vérifications

  • ✓Le workload P95/P99 diffère du cas moyen
  • ✓Les quotas ou limites fournisseur inconnus sont marqués comme risques
  • ✓La policy de priorité n’affame pas les tâches critiques

2. Fixez budgets et signaux de scaling

Résultat: L’autoscaling réagit à la saturation, aux files et au throughput de tokens, pas seulement au CPU.

Tâches

  • →Définir le plafond de concurrence
  • →Fixer les budgets tokens/tools/temps
  • →Ajouter les signaux âge/profondeur de file et saturation
  • →Calculer le coût par tâche vérifiée avec succès

Vérifications

  • ✓L’épuisement d’un budget termine ou dégrade la tâche de façon contrôlée
  • ✓Le signal de scaling a une relation causale avec le bottleneck
  • ✓Les tâches échouées ou dangereuses ne comptent pas comme succès

3. Exécutez les tests de chaos et de charge

Résultat: Les pannes connues de surcharge et de dépendances produisent une réaction système prévisible.

Tâches

  • →Injecter 429/5xx/timeouts
  • →Ralentir une dépendance tool/retrieval
  • →Créer une rafale de requêtes long-context
  • →Tester l’amplification des retries et la récupération de file

Vérifications

  • ✓Aucun retry infini ni croissance de file non bornée
  • ✓Le test de charge ne contourne pas les limites tenant/risque
  • ✓La récupération ne provoque pas un second pic via retries synchronisés

4. Vérifiez la graceful degradation

Résultat: En manque de capacité, le système réduit les fonctions plutôt que les contrôles.

Tâches

  • →Tester le load shedding
  • →Utiliser un modèle moins coûteux/fallback uniquement pour les tâches éligibles
  • →Désactiver les tools non essentiels
  • →Documenter les critères de récupération et de retour au mode normal

Vérifications

  • ✓Le fallback passe le contrat d’évaluation minimal
  • ✓Le mode dégradé n’augmente pas l’autonomie
  • ✓Le mode normal ne reprend qu’après stabilisation des dépendances

Critères d’acceptation

  • Le modèle de workload inclut burst, tokens, tools, files et quotas fournisseur
  • La policy de capacité possède des budgets bornés concurrence/tokens/tools/temps et des signaux d’autoscaling explicites
  • La suite de chaos couvre 429, 5xx, timeout, dépendance lente, quota épuisé et amplification des retries
  • Load shedding/mode dégradé existe avec des limites d’autorité et de confidentialité inchangées
  • Le coût est mesuré par tâche vérifiée avec succès plutôt que par requête