Contexte et enjeux

Les charges de travail d’intelligence artificielle s’exécutent majoritairement sur des clusters Kubernetes où les limites de mémoire (OOM), les interruptions de nœuds et la préemption de conteneurs sont fréquentes. Ces incidents interrompent les pipelines d’entraînement ou d’inférence, entraînant des pertes de calcul et des retards de mise en production. Flyte, projet open source comptant plus de 7 200 étoiles GitHub, propose avec la version 2 une approche centrée sur la résilience afin de réduire ces pertes.

Mécanismes d’exécution durable

Flyte 2 intègre trois leviers : les workflows auto‑guérissants, l’exécution native d’agents et le support unifié du batch et du temps réel. En cas d’OOM, le moteur intercepte le signal d’erreur, collecte les métriques de consommation et relance la tâche avec un profil de ressources augmenté. Cette adaptation se fait sans intervention manuelle, grâce à un diagnostic automatisé qui identifie la cause exacte (mémoire, CPU ou perte de nœud) avant de réallouer les ressources.

Le modèle « agent‑native » autorise les développeurs à écrire des workflows entièrement en Python. Le code peut contenir des boucles conditionnelles, des branches dynamiques et des appels à des outils externes, tout en restant sous le contrôle du scheduler Flyte. Cette flexibilité évite la fragmentation entre orchestration et exécution, car le même code pilote le traitement en temps réel et le traitement par lots.

Architecture infrastructure‑as‑context

Flyte 2 traite l’infrastructure comme un contexte d’exécution. Chaque tâche reçoit un objet d’environnement qui expose les API Kubernetes (events, pod specs, quotas). Lorsqu’une interruption survient, le contexte déclenche un processus de récupération : il crée un nouveau pod, ajuste les limites de mémoire/CPU et réinjecte les artefacts d’entrée. Cette approche repose sur des contrôleurs personnalisés qui observent les états du cluster et appliquent des politiques de re‑planification définies par l’utilisateur.

Le système conserve l’état intermédiaire des tâches dans un magasin de métadonnées persistant, ce qui permet de reprendre l’exécution exactement là où elle s’est arrêtée. Ainsi, même les pipelines complexes avec plusieurs étapes de pré‑traitement, entraînement et post‑traitement peuvent survivre à des pannes d’infrastructure sans redémarrer depuis le début.

Implications pour les charges de travail AI

En unifiant le runtime batch et le runtime temps réel, Flyte 2 élimine le besoin d’une pile de serving distincte. Les modèles peuvent être invoqués directement depuis le même workflow qui les a entraînés, réduisant la latence de déploiement. Cependant, la résilience a un coût : la création de pods supplémentaires augmente la consommation de ressources et peut entraîner des frais cloud plus élevés si les politiques de scaling ne sont pas calibrées. De plus, la dépendance à Kubernetes implique que les clusters doivent exposer les métriques nécessaires (cgroup, events) ; dans des environnements restreints, la récupération automatique peut être partiellement limitée.

En résumé, Flyte 2 propose une exécution durable basée sur l’observation en temps réel de l’infrastructure et la réallocation dynamique des ressources. Cette stratégie répond aux principaux points de défaillance des workloads AI, tout en introduisant de nouvelles exigences de configuration et de suivi des coûts.