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.
-
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 :
-
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. Ajoutez votre jeton à .env :Conservez le paramètre AUTH par défaut de la recette :
-
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