Skip to main content
Utilisez un pool de préchauffage lorsque des requêtes doivent disposer d’un sandbox déjà en cours d’exécution, sans attendre son démarrage. La recette de pool de préchauffage maintient une mémoire tampon de Sandbox préparés, attribue à chaque charge de travail son propre sandbox et réalimente la mémoire tampon en arrière-plan. Les Sandbox inactifs consomment des ressources de calcul en attendant des tâches.

Fonctionnement du pool

L’assistant WarmPool de la recette démarre le nombre configuré de Sandbox et exécute une vérification de l’état de préparation dans chacun d’eux. Leurs processus principaux restent actifs entre les commandes. Aucun ping périodique n’est nécessaire. Chaque charge de travail demande un sandbox prêt, ce qui déclenche la préparation d’un sandbox de remplacement. Tous les appels exec() effectués dans le cadre de cette demande partagent le même sandbox et les mêmes fichiers. Lorsque la charge de travail se termine ou échoue, l’assistant arrête son sandbox. Les charges de travail suivantes reçoivent chacune leur propre Sandbox et n’héritent donc pas de l’état local des charges de travail précédentes.

Exécuter la recette

Vous avez besoin de Python 3.11+, de uv, ainsi que d’un accès sans serveur et des identifiants d’authentification correspondants.
  1. Téléchargez ou clonez le dépôt de la recette, puis ouvrez recipes/warm-pool. Installez les dépendances et créez votre fichier d’environnement :
  2. Configurez votre identifiant d’authentification dans .env et au début de demo.py :
    Ajoutez votre clé API Forge à .env :
    Dans demo.py, ajoutez les imports suivants et remplacez l’affectation AUTH existante :
    Ce code lit explicitement FORGE_API_KEY et utilise les en-têtes d’authentification pris en charge par le SDK. Les noms de l’en-tête et de la stratégie sont des identifiants de compatibilité ; l’identifiant d’authentification est bien une clé API Forge. La dépendance facultative wandb n’est pas nécessaire.
  3. Exécutez la comparaison :
La démo compare quatre requêtes avec création à la demande à quatre requêtes passant par le pool. Elle présente la préparation initiale du pool séparément des temps de requête et vérifie que chaque charge de travail reçoit une sandbox distincte. Le message final suivant doit s’afficher :

Adapter le pool à votre charge de travail

Modifiez les constantes dans demo.py :
Ces valeurs par défaut autorisent jusqu’à quatre Sandbox simultanés : deux Sandbox en réserve tampon, en plus de deux charges de travail actives. Chaque sandbox demande 2 vCPU et 4 Gio de RAM. Si le tampon se vide, les demandes attendent qu’il soit réapprovisionné. Si la limite de charges actives est atteinte, elles attendent qu’une charge de travail se termine. Effectuez des mesures avec votre propre profil d’arrivée des demandes avant d’agrandir le tampon. Remplacez WORKLOAD dans demo.py par votre code. Ajoutez la configuration partagée à prepare() dans warm_pool.py et utilisez une vérification de l’état de préparation adaptée à votre application. Dans un handler de charge de travail asynchrone, utilisez le contexte de demande de la recette pour exécuter plusieurs commandes :
Récupérez les sorties avant de quitter la demande. Fournissez les entrées et les identifiants d’authentification du client après la demande, et limitez la portée du stockage externe partagé au client concerné.

Maintenir le pool actif

Gardez le pool et les contextes Session englobants ouverts tant que vous acceptez des requêtes. Chaque processus Python possède son propre pool. La démo ferme les deux une fois la comparaison terminée. L’assistant remplace les Sandbox inactifs au bout de 5 minutes. Chaque sandbox a une durée de vie de 10 minutes. Le pool continue de se réapprovisionner tant que son contexte est ouvert. Avec ces valeurs par défaut, veillez à ce que les tâches durent nettement moins de 5 minutes : demander un sandbox ne réinitialise pas son échéance. Pour les paramètres adaptés aux tâches plus longues et le nettoyage après des runs interrompus, consultez la recette. Les échecs de préparation transitoires donnent lieu à trois tentatives au maximum. Si ces tentatives sont épuisées ou si la préparation rencontre une erreur non réessayable, toutes les demandes suivantes échouent, même s’il reste des Sandbox prêts. Quittez le pool et les contextes Session pour effectuer le nettoyage, puis créez un nouveau pool une fois le problème sous-jacent résolu. Pour accélérer le réapprovisionnement, intégrez les dépendances stables à votre image ou restaurez des fichiers de workspace préparés à partir d’un instantané du système de fichiers. Les instantanés capturent les fichiers du point de montage configuré. Les processus applicatifs doivent toutefois être démarrés séparément. Un modèle de sandbox peut stocker la configuration partagée de l’image et de l’instantané.
Dernière modification le 15 octobre 2026