> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Implémenter un pool de préchauffage

> Gardez des Sandbox prêts à traiter les tâches entrantes grâce à une recette Python de pool de préchauffage.

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](https://github.com/coreweave/cwsandbox-recipes/tree/main/recipes/warm-pool) 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.

<h2 id="how-the-pool-works">
  Fonctionnement du pool
</h2>

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.

<h2 id="run-the-recipe">
  Exécuter la recette
</h2>

Vous avez besoin de Python 3.11+, de [`uv`](https://docs.astral.sh/uv/getting-started/installation/),
ainsi que d’un [accès sans serveur et des identifiants d’authentification correspondants](/fr/products/sandboxes/get-started#run-a-sandbox-on-serverless-capacity).

1. Téléchargez ou clonez le [dépôt de la recette](https://github.com/coreweave/cwsandbox-recipes/tree/main/recipes/warm-pool), puis ouvrez
   `recipes/warm-pool`. Installez les dépendances et créez votre fichier d’environnement :

   ```bash theme={"system"}
   uv sync --frozen
   cp .env.example .env
   ```

2. Configurez votre identifiant d’authentification dans `.env` et au début de `demo.py` :

   <Tabs>
     <Tab title="Clé API Forge">
       Ajoutez votre clé API Forge à `.env` :

       ```bash theme={"system"}
       FORGE_API_KEY="[FORGE-API-KEY]"
       ```

       Dans `demo.py`, ajoutez les imports suivants et remplacez l’affectation `AUTH` existante :

       ```python theme={"system"}
       import os
       from cwsandbox import AuthHeaders

       AUTH = AuthHeaders(
           headers={"x-wandb-api-key": os.environ["FORGE_API_KEY"]},
           strategy="wandb_api_key",
       )
       ```

       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.
     </Tab>

     <Tab title="Jeton d’accès à l’API CoreWeave">
       Ajoutez votre jeton à `.env` :

       ```bash theme={"system"}
       CWSANDBOX_API_KEY="[API-ACCESS-TOKEN]"
       ```

       Conservez le paramètre `AUTH` par défaut de la recette :

       ```python theme={"system"}
       from cwsandbox import AuthStrategy

       AUTH = AuthStrategy.COREWEAVE_API_KEY
       ```
     </Tab>
   </Tabs>

3. Exécutez la comparaison :

   ```bash theme={"system"}
   uv run --frozen --env-file .env demo.py
   ```

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 :

```text theme={"system"}
8 sandboxes de charge de travail distincts vérifiés ; tous les sandboxes ont été arrêtés.
```

<h2 id="adapt-the-pool-to-your-workload">
  Adapter le pool à votre charge de travail
</h2>

Modifiez les constantes dans `demo.py` :

```python theme={"system"}
POOL_SIZE = 2     # Nombre cible de bacs à sable inactifs.
CONCURRENCY = 2   # Nombre maximum de charges de travail actives.
REQUESTS = 4      # Requêtes par mode de comparaison.
```

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 :

```python theme={"system"}
async with pool.claim() as sandbox:
    await sandbox.exec(["sh", "-c", "echo hello > /tmp/result.txt"], check=True)
    result = await sandbox.exec(["cat", "/tmp/result.txt"], check=True)
    print(result.stdout)
```

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é.

<h2 id="keep-the-pool-running">
  Maintenir le pool actif
</h2>

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](https://github.com/coreweave/cwsandbox-recipes/tree/main/recipes/warm-pool).

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](/fr/products/sandboxes/file-system-snapshots).
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](/fr/products/sandboxes/profiles/templates)
peut stocker la configuration partagée de l’image et de l’instantané.