Exécuter un bac à sable GPU

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. Pour comparer la capacité sans serveur et la capacité CKS, consultez Placement et débordement des bacs à sable.

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

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.

Avant de commencer

Vous avez besoin des éléments suivants :

Les sandboxes GPU doivent être activés pour votre organisation.
Pour les exemples sans serveur, une clé API Forge ou un jeton d’accès à l’API CoreWeave associé à un compte ayant accès aux sandboxes 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.

Le client TypeScript ne prend pas encore en charge les ressources GPU. Utilisez le client Python pour les sandboxes GPU.

Choisir une image pour votre charge de travail

Une image d’exécution peut faire fonctionner des bibliothèques GPU précompilées, mais il peut lui manquer des outils de compilation nécessaires à votre application. Vérifiez la version exacte de l’image et des paquets avant de télécharger les poids du modèle. La réussite d’un import ou d’un chargement de modèle ne garantit pas le bon fonctionnement de la compilation à la volée (JIT) lors du premier lancement d’un noyau.

Étape de la charge de travail	Élément à vérifier dans l’image
Installer une dépendance Python épinglée sur un commit Git	L’exécutable `git` est disponible.
Compiler le code hôte d’un noyau Triton	Un compilateur C et des en-têtes de développement sont disponibles, par exemple `gcc` et `libc6-dev` sous Ubuntu.
Compiler des noyaux CUDA, y compris pour les piles utilisant FlashInfer	Le CUDA Toolkit requis et `nvcc` sont disponibles, ou des noyaux précompilés compatibles sont installés. Les exigences dépendent des versions des paquets et de l’architecture du GPU.

Nous vous recommandons d’inclure les outils système dans une image personnalisée épinglée. L’image de développement d’un framework peut servir de point de départ, mais vérifiez son contenu et sa compatibilité avec votre pile. Avant de créer un instantané volumineux, testez sur une seule sandbox l’installation des dépendances, un noyau ou une requête d’inférence représentatifs, ainsi que le démarrage du serveur. Les instantanés du système de fichiers capturent les fichiers du point de montage configuré, mais pas les paquets installés avec apt-get dans le système de fichiers racine du conteneur. Incluez ces paquets dans l’image afin qu’ils restent disponibles après une restauration. Les environnements Python et les noyaux précompilés peuvent être conservés s’ils sont stockés dans le point de montage de l’instantané. Si le programme d’installation d’un noyau invoque pip, vérifiez que pip est bien installé dans cet environnement : un environnement créé avec uv ne l’inclut pas forcément.

Choisir l’authentification

Ces exemples s’exécutent sur une capacité sans serveur, sauf si une section indique CKS. Choisissez l’identifiant d’authentification du compte propriétaire de vos sandboxes. Exécutez les commandes d’installation dans un environnement virtuel Python actif. Enregistrez le code Python de l’onglet correspondant à votre identifiant d’authentification sous le nom sandbox_auth.py, dans le même répertoire que les scripts Python que vous exécutez depuis cette page. Ce fichier stocke le mode d’authentification choisi, et non votre identifiant d’authentification. Les exemples importent AUTH depuis ce fichier et le transmettent explicitement à chaque nouvelle sandbox ou session.

Clé API Forge
Jeton d’accès à l’API CoreWeave

Utilisez votre clé API Forge avec l’intégration wandb du SDK. Remplacez [WANDB-API-KEY] par votre clé API :

uv pip install 'cwsandbox[wandb]>=1.14.2'
export WANDB_API_KEY="[WANDB-API-KEY]"

sandbox_auth.py

from cwsandbox import AuthStrategy

AUTH = AuthStrategy.WANDB

Utilisez le jeton de votre organisation CoreWeave. Remplacez [API-ACCESS-TOKEN] par votre jeton :

uv pip install 'cwsandbox>=1.14.2'
export CWSANDBOX_API_KEY="[API-ACCESS-TOKEN]"

sandbox_auth.py

from cwsandbox import AuthStrategy

AUTH = AuthStrategy.COREWEAVE_API_KEY

Pour un placement sur CKS, choisissez le jeton CoreWeave, activez un exécuteur et définissez placement_mode="cks" lors de la création de la sandbox ou dans SandboxDefaults. Créer une session avec auth=AUTH authentifie également les sandboxes qui lui appartiennent. Utilisez le même identifiant d’authentification pour vous reconnecter à vos sandboxes, les lister ou les nettoyer.

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 sandbox obtiennent des GPU entiers. Les GPU ne sont ni partagés, ni partitionnés, ni découpés en tranches de temps entre les sandbox.
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 jusqu’à 8 GPU si le maximum de votre organisation et la politique de l’exécuteur le permettent. 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.
Votre organisation dispose d’un nombre maximum de GPU par sandbox. Il est fixé à 1, sauf si CoreWeave le relève. Pour obtenir un maximum plus élevé, contactez l’assistance ou votre équipe de compte. Toute demande qui dépasse ce maximum échoue avec l’erreur CWSANDBOX_GPU_COUNT_EXCEEDED.
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.

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 et Standard Memory. 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 demande 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 local au Nœud 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 :

from cwsandbox import Sandbox, ScratchVolumeOptions
from sandbox_auth import AUTH

with Sandbox.run(
    auth=AUTH,
    placement_mode="serverless",
    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 local au Nœud 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 demande 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 demande de GPU, vous obtenez donc une sandbox qui ne peut pas accéder au GPU.

Créer la sandbox

Effectuez les étapes de la section Choisir l’authentification, 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.

Python
TypeScript

Cet exemple utilise l’identifiant d’authentification sélectionné dans sandbox_auth.py.

from cwsandbox import Sandbox
from sandbox_auth import AUTH

with Sandbox.run(
    auth=AUTH,
    placement_mode="serverless",
    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 :

name, memory.total [MiB]
NVIDIA RTX PRO 6000 Blackwell Server Edition, 97887 MiB

{'count': 1}

Les sandboxes GPU mettent plus de temps à démarrer que les sandboxes CPU uniquement, car la plateforme doit rattacher les GPU à la machine virtuelle de la sandbox. Prévoyez plusieurs minutes pour le démarrage. Pour accorder jusqu’à 10 minutes au démarrage, appelez sandbox.wait(timeout=600.0) avant la première opération. Si vous omettez timeout, le SDK utilise request_timeout_seconds pour l’attente du démarrage (300 secondes par défaut). Cela vaut également pour l’attente implicite avant exec(). request_timeout_seconds limite également la durée de la plupart des appels de procédure distante (RPC) individuels. L’interrogation du statut utilise poll_rpc_timeout_seconds (15 secondes par défaut) pour chaque RPC. Le paramètre timeout_seconds de exec() s’applique après le démarrage. Pour en savoir plus sur les phases de délai d’expiration et sur la manière dont la durée de vie maximale de la sandbox inclut le démarrage, consultez Phases de délai d’expiration.

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.

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.
Une politique sur cet exécuteur qui autorise les GPU. Le champ maxGpuCount sous resources plafonne le nombre de GPU que chaque conteneur 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.
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 :

from cwsandbox import AuthStrategy, list_runners

for runner in list_runners(auth=AuthStrategy.COREWEAVE_API_KEY):
    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.

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. Pour exécuter cet exemple, le maximum autorisé pour votre organisation doit être d’au moins 2 GPU par sandbox. 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.

from cwsandbox import AuthStrategy, ResourceOptions, Sandbox

with Sandbox.run(
    auth=AuthStrategy.COREWEAVE_API_KEY,
    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 maximum de votre organisation, 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 maximum de votre organisation échoue avec CWSANDBOX_GPU_COUNT_EXCEEDED, et 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 l’identifiant d’authentification sélectionné dans sandbox_auth.py. Sur CKS, utilisez un jeton CoreWeave, définissez placement_mode="cks" et choisissez une image compatible avec le GPU de votre cluster. 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 :

from cwsandbox import Sandbox
from sandbox_auth import AUTH

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=AUTH,
    placement_mode="serverless",
    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 :

(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 pour demander l’accès.
`CWSANDBOX_GPU_COUNT_EXCEEDED`	La requête demande plus de GPU que le maximum autorisé par sandbox pour votre organisation, fixé à 1 sauf si CoreWeave le relève.	Réduisez le nombre de GPU. Sur la capacité sans serveur, définissez-le sur `1`. Pour relever ce maximum dans le cadre d’un placement sur CKS, contactez l’assistance ou votre équipe de compte.
`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 décrit chaque champ ResourceOptions, les classes QoS et les délais d’expiration.
Configurer une politique de sandbox explique les contraintes de GPU, de classe de runtime et de ressources que les administrateurs définissent sur un exécuteur CKS.
Premiers pas présente les bacs à sable sans serveur limités au CPU ainsi que les identifiants d’authentification.
Utiliser votre propre capacité de calcul explique comment configurer l’exécuteur et créer votre premier sandbox sur un cluster.

Sandbox

Utiliser les Sandbox

Gérer les bacs à sable

Référence

Exécuter un bac à sable GPU

L’isolation dépend du mode de placement

Avant de commencer

Choisir une image pour votre charge de travail

Choisir l’authentification

Fonctionnement des demandes de GPU

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

GPU disponibles

Créer la sandbox

Exécuter une sandbox GPU sur votre cluster CKS

Prérequis

Trouver les types de GPU de votre exécuteur

Créer la sandbox

Images de conteneur

Erreurs courantes

Étapes suivantes

​L’isolation dépend du mode de placement

​Avant de commencer

​Choisir une image pour votre charge de travail

​Choisir l’authentification

​Fonctionnement des demandes de GPU

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

​GPU disponibles

​Créer la sandbox

​Exécuter une sandbox GPU sur votre cluster CKS

​Prérequis

​Trouver les types de GPU de votre exécuteur

​Créer la sandbox

​Images de conteneur

​Erreurs courantes

​Étapes suivantes

L’isolation dépend du mode de placement

Avant de commencer

Choisir une image pour votre charge de travail

Choisir l’authentification

Fonctionnement des demandes de GPU

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

GPU disponibles

Créer la sandbox

Exécuter une sandbox GPU sur votre cluster CKS

Prérequis

Trouver les types de GPU de votre exécuteur

Créer la sandbox

Images de conteneur

Erreurs courantes

Étapes suivantes