> ## 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. # Exécuter un bac à sable GPU > Demandez des GPU pour un bac à sable sur une capacité sans serveur, qui est virtualisée, ou sur votre propre cluster CKS, qui ne l’est pas. Ce guide explique comment créer un bac à sable doté d’un ou plusieurs GPU, vérifier que le GPU est bien visible depuis le bac à sable et définir les demandes de ressources CPU et mémoire correspondantes. Les bacs à sable GPU s’exécutent dans l’un ou l’autre des deux modes de placement : sur une capacité sans serveur gérée par CoreWeave, ou sur un cluster CoreWeave Kubernetes Service (CKS) qui vous appartient. Ces deux modes diffèrent par le type d’isolation du bac à sable, les GPU disponibles et l’entité qui définit les limites ; c’est pourquoi cette page les traite dans des sections distinctes. Pour les bacs à sable CPU uniquement, consultez [Premiers pas](/fr/products/sandboxes/get-started). Pour comparer la capacité sans serveur et la capacité CKS, consultez [Placement et débordement des bacs à sable](/fr/products/sandboxes/placement). Les bacs à sable GPU sont en préversion privée : votre organisation doit figurer sur une liste d’autorisation, même si elle utilise déjà des bacs à sable CPU uniquement. Pour demander l’accès, contactez votre équipe de compte ou écrivez à [forge-support@coreweave.com](mailto:forge-support@coreweave.com). Tant que votre organisation ne figure pas sur cette liste, les requêtes de création de bacs à sable GPU échouent avec l’erreur `CWSANDBOX_GPU_NOT_ALLOWED`. Pour les quotas de bacs à sable simultanés et les limites de ressources, consultez [Limites et quotas](/fr/products/sandboxes/reference/limits-and-quotas).

L’isolation dépend du mode de placement

La virtualisation GPU n’est prise en charge que sur la capacité sans serveur. Sur un cluster CKS qui vous appartient, les sandbox GPU ne sont pas virtualisés. | | Sans serveur | Votre cluster CKS | | - | - | - | | Runtime | Runtime de machine virtuelle GPU, sélectionné automatiquement | La classe de runtime par défaut du cluster, qui exécute les conteneurs avec `runc` | | Virtualisation GPU | Oui. Les GPU sont associés à la machine virtuelle du sandbox. | Non. Le sandbox est un conteneur standard qui partage le noyau du Node. | | Environnement d’exécution de conteneurs sécurisé | Oui | **Non** | | Adapté au code non fiable | Oui | **Non.** N’exécutez que du code de confiance. | Sur votre propre cluster CKS, les sandbox GPU s’exécutent avec la classe de runtime par défaut (`runc`), sans virtualisation. Ils bénéficient de la même isolation que n’importe quel autre conteneur du Node et **ne peuvent pas être considérés comme un environnement d’exécution de conteneurs sécurisé**. N’utilisez pas les sandbox GPU CKS pour exécuter du code non fiable, par exemple du code généré par un modèle ou soumis par des utilisateurs. Pour exécuter du code non fiable sur un GPU, utilisez la [capacité sans serveur](#run-a-gpu-sandbox-on-serverless-capacity).

Avant de commencer

Vous avez besoin des éléments suivants : * Les bacs à sable GPU doivent être activés pour votre organisation. * Une [clé API Forge](https://forge.coreweave.com/settings#apikeys) pour les exemples sans serveur. Le placement CKS nécessite un jeton d’accès à l’API CoreWeave disposant de l’action de gestion des identités et des accès (IAM) `SANDBOX_USER`. Voir [Choisir et obtenir des identifiants d’authentification](/fr/products/sandboxes/placement#choose-and-get-credentials). * Le client Python, `cwsandbox` 1.14.2 ou version ultérieure : ```bash theme={"system"} uv pip install 'cwsandbox>=1.14.2' ``` Le client TypeScript ne prend pas encore en charge les ressources GPU. Utilisez le client Python pour les bacs à sable GPU.

Fonctionnement des demandes de GPU

Les mêmes règles s’appliquent dans les deux modes de placement : * **Une demande de GPU réserve des GPU, et rien d’autre.** Définissez explicitement le CPU et la mémoire, en les dimensionnant en fonction du travail que vous exécuterez en parallèle du GPU. Si vous omettez les valeurs de CPU et de mémoire, les valeurs `defaultCpu` et `defaultMemory` de la politique peuvent s’appliquer, mais l’allocation résultante doit tout de même respecter les exigences de ressources de la politique. * **Les bacs à sable obtiennent des GPU entiers.** Les GPU ne sont ni partagés, ni partitionnés, ni découpés en tranches de temps entre les bacs à sable. * **Une sandbox s’exécute sur un seul Nœud.** Sur une capacité sans serveur, une sandbox obtient exactement 1 GPU. Sur votre cluster CKS, la plus grande sandbox occupe un Nœud complet, et le nombre de GPU correspondant dépend du type de GPU. Sur un Nœud doté de 8 GPU, une sandbox CKS peut demander de 1 à 8 GPU. Une demande portant sur plusieurs GPU nécessite qu’autant de GPU libres, ainsi que le CPU et la mémoire demandés, soient disponibles simultanément sur un même Nœud. * **Le type de GPU est un filtre, pas un menu.** La clé facultative `type` doit correspondre exactement, casse comprise, à l’un des types de GPU annoncés par l’exécuteur. Omettez-la pour accepter n’importe quel GPU dont dispose l’exécuteur.

Exécuter une sandbox GPU sur une capacité sans serveur

Le placement sans serveur ne nécessite ni exécuteur ni politique qui vous soit propre. CoreWeave fournit la politique et le matériel. Les sandboxes GPU s’exécutent dans une machine virtuelle et conviennent donc à l’exécution de code non fiable.

GPU disponibles

La capacité sans serveur repose sur un seul modèle de GPU, la NVIDIA RTX PRO 6000 Blackwell Server Edition. Seules les sandboxes à 1 GPU sont prises en charge sur la capacité sans serveur. Pour exécuter une sandbox avec plus d’un GPU, utilisez [votre cluster CKS](#run-a-gpu-sandbox-on-your-cks-cluster). | GPU | Mémoire GPU | GPU par sandbox | | - | - | - | | NVIDIA RTX PRO 6000 Blackwell Server Edition | 96 Go | 1 | Deux types d’instance en sont équipés : [High Memory](/platform/instances/gpu/rtxp6000-8x) et [Standard Memory](/platform/instances/gpu/rtxp6000-8x-v2). Ils diffèrent par la RAM de l’hôte, et non par le GPU, et présentent tous deux le même type de GPU à une sandbox. Vous ne choisissez donc pas le type d’instance sur lequel une sandbox est placée. Omettez la clé `type` dans la requête de GPU afin que la plateforme attribue un GPU issu du calcul managé par CoreWeave. Le champ reste accepté ici, mais il sert de filtre et non de sélecteur : un `type` qui ne correspond à aucun exécuteur échoue avec `CWSANDBOX_RUNNER_UNAVAILABLE`. Un exécuteur qui reçoit un type non pris en charge le rejette avec `CWSANDBOX_PLACEMENT_CONSTRAINT_UNSATISFIED`. Utilisez `resources` pour choisir le CPU et la mémoire en plus du nombre de GPU, comme le montre l’exemple suivant. Le disque ne se demande pas avec le CPU, la mémoire et le GPU, mais séparément : `ResourceOptions` ne comporte aucun champ de disque. Le système de fichiers racine du conteneur est un stockage éphémère node-local dont la sandbox ne réserve aucune part ; la commande `df` exécutée dans la sandbox indique donc le système de fichiers du nœud plutôt qu’un quota propre à la sandbox. Pour disposer d’un chemin dédié accessible en écriture, déclarez un volume temporaire : ```python theme={"system"} import os from cwsandbox import AuthHeaders, Sandbox, ScratchVolumeOptions forge_auth = AuthHeaders( headers={"x-wandb-api-key": os.environ["FORGE_API_KEY"]}, strategy="wandb_api_key", ) with Sandbox.run( auth=forge_auth, resources={"cpu": "2", "memory": "8Gi", "gpu": 1}, volumes=[ScratchVolumeOptions(name="work", mount_path="/work", size="20Gi")], max_lifetime_seconds=3600, ) as sandbox: result = sandbox.exec(["df", "-h", "/work"]).result() print(result.stdout) ``` Un volume sur disque, l’option par défaut, puise dans le même stockage node-local que le système de fichiers racine. Pour obtenir plutôt un tmpfs, définissez `medium="memory"` : un volume en mémoire doit déclarer une taille, et le total des volumes en mémoire d’un même conteneur ne peut pas dépasser 80 % de sa requête de mémoire. Ne définissez pas non plus `runtime_class`. Une requête de GPU sélectionne d’elle-même la classe de runtime de machine virtuelle GPU, et une classe de runtime que vous imposez est appliquée telle quelle : si vous imposez la classe CPU en plus d’une requête de GPU, vous obtenez donc une sandbox qui ne peut pas accéder au GPU.

Créer la sandbox

Définissez `FORGE_API_KEY` sur votre clé API Forge, puis exécutez l’exemple suivant. Il crée une sandbox dotée de 1 GPU, de 2 CPU et de 8 Gio de mémoire, puis affiche le GPU détecté par `nvidia-smi`. Cet exemple transmet une clé API Forge via `AuthHeaders`. ```python theme={"system"} import os from cwsandbox import AuthHeaders, Sandbox forge_auth = AuthHeaders( headers={"x-wandb-api-key": os.environ["FORGE_API_KEY"]}, strategy="wandb_api_key", ) with Sandbox.run( auth=forge_auth, resources={"cpu": "2", "memory": "8Gi", "gpu": 1}, max_lifetime_seconds=3600, ) as sandbox: result = sandbox.exec( ["nvidia-smi", "--query-gpu=name,memory.total", "--format=csv"] ).result() print(result.stdout) print(sandbox.resource_gpu) ``` Le dict `resources` à plat attribue les mêmes valeurs aux demandes de ressources et aux limites. `"gpu": 1` est un raccourci pour `"gpu": {"count": 1}`. Le mode sans serveur ne prend en charge qu’un seul GPU par sandbox ; laissez donc le nombre à `1`. La propriété `resource_gpu` renvoie l’allocation GPU confirmée par la plateforme, par exemple `{'count': 1}`. Le paquet `@coreweave/cwsandbox` n'accepte pas encore les ressources GPU. Son option `resources` ne couvre que le CPU et la mémoire, et toute clé `gpu` est ignorée : la sandbox démarre donc sans GPU. Utilisez le client Python pour créer des sandboxes GPU. Exemple de sortie : ```text theme={"system"} name, memory.total [MiB] NVIDIA RTX PRO 6000 Blackwell Server Edition, 97887 MiB {'count': 1} ``` Les bacs à sable GPU mettent plus de temps à démarrer que les bacs à sable CPU uniquement, car la plateforme doit rattacher les GPU à la machine virtuelle de la sandbox. Si vous définissez un délai d’expiration de requête, prévoyez plusieurs minutes.

Exécuter une sandbox GPU sur votre cluster CKS

Avec le placement sur CKS, ce sont vos administrateurs qui décident quels GPU les bacs à sable peuvent utiliser, et en quelle quantité. L’exécuteur propose les types de GPU présents sur les Nœuds du cluster, et la politique qui lui est associée délimite ce qu’une sandbox peut demander. La virtualisation GPU n’est pas prise en charge sur votre propre cluster CKS. Par défaut, les bacs à sable GPU sur CKS s’exécutent avec la classe de runtime par défaut du cluster, qui utilise `runc`. La sandbox est alors un conteneur ordinaire qui partage le noyau du Nœud et accède directement aux périphériques GPU qui lui sont attribués. Ce mode **n’est pas un environnement d’exécution de conteneurs sécurisé** : ne l’utilisez pas pour exécuter du code non fiable. Réservez-le aux charges de travail que vous exécuteriez déjà sans hésiter en tant que Pod standard sur le cluster. Pour du code non fiable, utilisez la [capacité sans serveur](#run-a-gpu-sandbox-on-serverless-capacity).

Prérequis

Avant de demander un GPU sur CKS, assurez-vous de disposer des éléments suivants : * Un cluster CKS doté de nœuds GPU et d’un exécuteur à l’état `Ready`. Voir [Utiliser votre propre infrastructure de calcul](/fr/products/sandboxes/get-started-cks). * Une politique sur cet exécuteur qui autorise les GPU. Le champ `maxGpuCount` sous `resources` plafonne le nombre de GPU qu’une sandbox peut demander : omettez-le pour ne fixer aucun plafond, ou définissez-le sur `0` pour refuser les demandes de GPU. Laissez `defaultGpuRuntimeClass` non défini afin que les sandboxes GPU s’exécutent avec la classe de runtime par défaut du cluster. Les classes de runtime GPU basées sur Kata, comme `cw-kata-nvidia-gpu`, ne sont pas prises en charge sur les clusters CKS des clients. Pour la description de chaque champ, voir [Configurer une politique de sandbox](/fr/products/sandboxes/profiles/configure). * L’action IAM `SANDBOX_USER` et un jeton d’accès à l’API CoreWeave, défini dans `CWSANDBOX_API_KEY`.

Trouver les types de GPU de votre exécuteur

Chaque exécuteur expose les types de GPU dont disposent ses nœuds. Listez-les avant de choisir un `type` : ```python theme={"system"} from cwsandbox import list_runners for runner in list_runners(): print(runner.runner_id, runner.supported_gpu_types, runner.max_gpu_count) ``` Les valeurs correspondent aux chaînes de caractères exactes à transmettre comme `type`. La correspondance est sensible à la casse : `B200` et `b200` ne désignent donc pas le même type. Pour filtrer plutôt les exécuteurs par type de GPU, transmettez `gpu_type` à `list_runners()`. Pour en savoir plus, voir [Découvrir les exécuteurs disponibles](/fr/products/sandboxes/client/guides/discovery).

Créer la sandbox

L’exemple suivant déploie une sandbox sur CKS avec 2 GPU d’un type donné, 8 CPU et 32 Gio de mémoire. Remplacez `[GPU-TYPE]` par l’un des types proposés par votre exécuteur, ou supprimez la clé `type` pour accepter n’importe quel GPU de l’exécuteur. Laissez `runtime_class` non défini afin que la sandbox utilise la classe de runtime par défaut du cluster. ```python theme={"system"} from cwsandbox import ResourceOptions, Sandbox with Sandbox.run( placement_mode="cks", resources=ResourceOptions( requests={"cpu": "8", "memory": "32Gi"}, limits={"cpu": "8", "memory": "32Gi"}, gpu={"count": 2, "type": "[GPU-TYPE]"}, ), max_lifetime_seconds=3600, ) as sandbox: result = sandbox.exec(["nvidia-smi", "-L"]).result() print(result.stdout) print(sandbox.resource_gpu) ``` Pour cibler un exécuteur précis plutôt que n’importe quel exécuteur CKS de votre organisation, ajoutez `runner_ids=["[RUNNER-ID]"]`. L’allocation confirmée dans `resource_gpu` indique uniquement le nombre, par exemple `{'count': 2}`, même si vous avez demandé un type. Le nombre de GPU est plafonné par le `maxGpuCount` de la politique et par le nombre de GPU libres sur un seul Nœud. Une requête qui dépasse le plafond de la politique échoue avec `CWSANDBOX_RESOURCE_CEILING_EXCEEDED`. Si vous indiquez un `type` que l'exécuteur ne propose pas, ou dont la casse diffère, aucun exécuteur éligible n’est trouvé et la requête échoue avec `CWSANDBOX_RUNNER_UNAVAILABLE`.

Images de conteneur

L’exemple suivant utilise la capacité sans serveur et la clé API Forge configurée précédemment. Dans une sandbox GPU, la plateforme fournit le pilote NVIDIA et l’outil `nvidia-smi`, si bien que l’image par défaut voit déjà le GPU. Pour exécuter des applications CUDA, utilisez une image qui embarque le runtime CUDA et les bibliothèques dont votre code a besoin, comme une image `pytorch/pytorch` ou `nvidia/cuda`. Choisissez une image adaptée au GPU. La RTX PRO 6000 Blackwell Server Edition a une capacité de calcul 12.0 (`sm_120`), qui nécessite CUDA 12.8 ou une version ultérieure, et PyTorch 2.7 est la première version compilée pour cette architecture. Une image plus ancienne affiche quand même correctement le nom du GPU, car celui-ci est lu dans les métadonnées du périphérique via le pilote, mais elle échoue dès le premier lancement de noyau avec `CUDA error: no kernel image is available for execution on the device`. Au lieu de vous fier au nom du périphérique, vérifiez que votre framework liste bien `sm_120` : ```python theme={"system"} import os from cwsandbox import AuthHeaders, Sandbox forge_auth = AuthHeaders( headers={"x-wandb-api-key": os.environ["FORGE_API_KEY"]}, strategy="wandb_api_key", ) CHECK_GPU = """ import torch print(torch.cuda.get_device_capability(0)) print(torch.cuda.get_arch_list()) x = torch.ones(32, device="cuda") print((x + x).sum().item()) torch.cuda.synchronize() """ with Sandbox.run( auth=forge_auth, container_image="pytorch/pytorch:2.8.0-cuda12.8-cudnn9-runtime", resources={"cpu": "2", "memory": "8Gi", "gpu": 1}, ) as sandbox: result = sandbox.exec(["python", "-c", CHECK_GPU]).result() print(result.stdout) ``` Exemple de sortie : ```text theme={"system"} (12, 0) ['sm_70', 'sm_75', 'sm_80', 'sm_86', 'sm_90', 'sm_100', 'sm_120'] 64.0 ``` Une image de framework volumineuse met plus de temps à être récupérée que l’image par défaut. Prévoyez donc quelques minutes avant que la sandbox soit prête.

Erreurs courantes

| Erreur | Cause | Que faire | | - | - | - | | `CWSANDBOX_GPU_NOT_ALLOWED` | Votre organisation ne figure pas sur la liste d’autorisation des sandbox GPU. | Contactez votre équipe de compte ou écrivez à [forge-support@coreweave.com](mailto:forge-support@coreweave.com) pour demander l’accès. | | `SandboxResourceExhaustedError` (`runner capacity exhausted`) | Aucun nœud ne dispose actuellement de suffisamment de GPU, de CPU ou de mémoire libres pour satisfaire la requête. | Patientez un instant, puis réessayez. Sur CKS, vous pouvez également demander moins de GPU. | | `CWSANDBOX_RUNNER_UNAVAILABLE` (`no eligible runner is available`) | Aucun exécuteur ne correspond à la requête. Cela peut notamment provenir d’un `type` de GPU qu’aucun exécuteur ne propose, y compris un type dont la casse est incorrecte. Ce code apparaît également lorsqu’aucun exécuteur éligible n’est connecté pour le moment. | En mode sans serveur, supprimez `type`. Sur CKS, utilisez un type figurant dans `supported_gpu_types`, ou supprimez `type`. Si `type` est déjà correct, réessayez. | | `CWSANDBOX_RESOURCE_CEILING_EXCEEDED` (`gpu count exceeds the policy maximum`) | La requête demande plus de GPU que la valeur `maxGpuCount` définie par la politique. | Réduisez le nombre de GPU ou demandez à un administrateur de relever le plafond. | | `nvidia-smi: not found` | La sandbox ne dispose d’aucun GPU, ou son image n’expose pas les outils NVIDIA. | Vérifiez d’abord `sandbox.resource_gpu`. S’il indique un nombre positif, les GPU sont bien alloués et c’est l’image qu’il faut modifier. |

Étapes suivantes

* [Configuration du bac à sable](/fr/products/sandboxes/client/guides/sandbox-configuration) décrit chaque champ `ResourceOptions`, les classes QoS et les délais d’expiration. * [Configurer une politique de sandbox](/fr/products/sandboxes/profiles/configure) explique les contraintes de GPU, de classe de runtime et de ressources que les administrateurs définissent sur un exécuteur CKS. * [Premiers pas](/fr/products/sandboxes/get-started) présente les bacs à sable sans serveur limités au CPU ainsi que les identifiants d’authentification. * [Utiliser votre propre capacité de calcul](/fr/products/sandboxes/get-started-cks) explique comment configurer l’exécuteur et créer votre premier sandbox sur un cluster.