GPU サンドボックスを実行する

This guide shows how to create a sandbox with one or more GPUs, confirm the GPU is visible from inside the sandbox, and set the CPU and memory requests that go with it. GPU sandboxes run in either placement mode: on serverless capacity that CoreWeave operates, or on a CoreWeave Kubernetes Service (CKS) cluster you own. The two modes differ in how the sandbox is isolated, which GPUs you can get, and who sets the limits, so this page covers them in separate sections. CPU のみのサンドボックスについては、はじめにを参照してください。

GPU sandboxes are in private preview and require your organization to be allowlisted, even if it already has access to CPU-only sandboxes in public preview. To request access, contact your account team or email forge-support@coreweave.com. Until your organization is allowlisted, requests to create GPU sandboxes fail with CWSANDBOX_GPU_NOT_ALLOWED.

For concurrent sandbox quotas and resource limits, see Limits and quotas.

Before you begin

You need the following:

組織で GPU サンドボックスが有効になっていること。
W&B APIキー。
wandb extra 付きの Python クライアント cwsandbox (バージョン 1.14.2 以降) :
uv pip install 'cwsandbox[wandb]>=1.14.2'

The TypeScript client doesn’t expose GPU resources yet. Use the Python client for GPU sandboxes.

GPU リクエストの仕組み

GPU リクエストには次のルールが適用されます。

GPU リクエストで予約されるのは GPU のみです。 CPU とメモリは、GPU と並行して実行する処理に見合ったサイズで明示的に設定してください。CPU とメモリの値を省略すると、ポリシーの defaultCpu と defaultMemory が使用される場合がありますが、最終的に決定される割り当ては、ポリシーのリソース要件を満たしている必要があります。
サンドボックスには GPU が 1 基単位で割り当てられます。 GPU がサンドボックス間で共有、分割、タイムスライスされることはありません。
1 つのサンドボックスに割り当てられる GPU は必ず 1 基です。 サーバーレスキャパシティでサポートされるのは、GPU 1 基構成のサンドボックスのみです。
GPU タイプは選択肢ではなくフィルターです。 オプションの type キーは、ランナーが提示する GPU タイプのいずれかと、大文字と小文字の区別も含めて完全に一致する必要があります。ランナーが持つどの GPU でも受け入れる場合は、このキーを省略してください。

サーバーレスキャパシティで GPU サンドボックスを実行する

サーバーレス配置では、ランナーやポリシーを独自に用意する必要はありません。ポリシーとハードウェアは CoreWeave が管理します。GPU サンドボックスは仮想マシン内で実行されるため、信頼できないコードの実行に適しています。

利用可能な GPU

サーバーレスキャパシティで利用できる GPU モデルは、NVIDIA RTX PRO 6000 Blackwell Server Edition の 1 種類のみです。また、サーバーレスキャパシティでサポートされるのは 1 GPU のサンドボックスのみです。

GPU	GPU memory	GPUs per sandbox
NVIDIA RTX PRO 6000 Blackwell Server Edition	96 GB	1

Two instance types carry it: High Memory and Standard Memory. They differ in host RAM, not in the GPU, and both present the same GPU type to a sandbox, so which one a sandbox lands on isn’t something you select. Leave the type key out of the GPU request so the platform assigns a GPU from CoreWeave-managed compute. The field is still accepted here, but it filters rather than selects: a type that matches no runner fails with CWSANDBOX_RUNNER_UNAVAILABLE. A runner that receives an unsupported type rejects it with CWSANDBOX_PLACEMENT_CONSTRAINT_UNSATISFIED. Use resources to choose CPU and memory alongside the GPU count, as shown in the following example. Disk is requested separately from CPU, memory, and GPU rather than alongside them: ResourceOptions has no disk field. The container’s root filesystem is Node-local ephemeral storage that the sandbox doesn’t reserve a share of, so df inside the sandbox reports the Node’s filesystem rather than a per-sandbox quota. For a dedicated writable path, declare a scratch volume:

from cwsandbox import AuthStrategy, Sandbox, ScratchVolumeOptions

with Sandbox.run(
    auth=AuthStrategy.WANDB,
    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)

A disk-backed volume, the default, draws on the same Node-local storage as the root filesystem. Set medium="memory" for a tmpfs instead: a memory-backed volume must declare a size, and the memory-backed volumes on one container can’t total more than 80% of its memory request. Leave runtime_class unset too. A GPU request selects the GPU virtual machine runtime class on its own, and a runtime class you pin is used exactly as given, so pinning the CPU class alongside a GPU request produces a sandbox that can’t reach the GPU.

Create the sandbox

WANDB_API_KEY に W&B APIキーを設定してから、次の例を実行します。この例では、GPU 1 基、CPU 2 コア、メモリ 8 GiB のサンドボックスを作成し、nvidia-smi が報告する GPU を出力します。

Python
TypeScript

この例では、W&B APIキーで認証するために AuthStrategy.WANDB を使用します。

from cwsandbox import AuthStrategy, Sandbox

with Sandbox.run(
    auth=AuthStrategy.WANDB,
    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)

フラットな resources dict を指定すると、リクエストと制限が同じ値に設定されます。"gpu": 1 は "gpu": {"count": 1} の省略形です。サーバーレスでサポートされる GPU はサンドボックスあたり 1 基のみのため、count は 1 のままにしてください。resource_gpu プロパティは、プラットフォームによって確定された GPU の割り当て ({'count': 1} など) を返します。

@coreweave/cwsandbox パッケージは、現時点では GPU リソースの指定に対応していません。resources オプションで指定できるのは CPU とメモリのみで、gpu キーは無視されるため、サンドボックスは GPU なしで起動します。GPU サンドボックスを作成するには Python クライアントを使用してください。

Sample output:

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

{'count': 1}

GPU sandboxes take longer to start than CPU-only sandboxes because the platform attaches the GPUs to the sandbox’s virtual machine. Allow several minutes if you set a request timeout.

Container images

The platform provides the NVIDIA driver and the nvidia-smi tool inside a GPU sandbox, so the default image can already see the GPU. To run CUDA applications, use an image that ships the CUDA runtime and libraries your code needs, such as a pytorch/pytorch or nvidia/cuda image. Match the image to the GPU. The RTX PRO 6000 Blackwell Server Edition is compute capability 12.0 (sm_120), which needs CUDA 12.8 or later, and PyTorch 2.7 was the first release built for it. An older image still reports the GPU’s name correctly, because that reads device metadata through the driver, then fails at the first kernel launch with CUDA error: no kernel image is available for execution on the device. Check that your framework lists sm_120 rather than trusting the device name:

from cwsandbox import AuthStrategy, Sandbox

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=AuthStrategy.WANDB,
    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)

Sample output:

(12, 0)
['sm_70', 'sm_75', 'sm_80', 'sm_86', 'sm_90', 'sm_100', 'sm_120']
64.0

A large framework image takes longer to pull than the default image, so allow a few minutes for the sandbox to become ready.

Common errors

エラー	原因	対処方法
`CWSANDBOX_GPU_NOT_ALLOWED`	組織が GPU サンドボックスの許可リストに登録されていません。	アカウントチームまたは forge-support@coreweave.com に連絡して、アクセスをリクエストしてください。
`SandboxResourceExhaustedError` (`runner capacity exhausted`)	現在、リクエストを満たすだけの空き GPU、CPU、またはメモリを持つノードがありません。	しばらく待ってから再試行してください。
`CWSANDBOX_RUNNER_UNAVAILABLE` (`no eligible runner is available`)	リクエストに一致するキャパシティがありません。原因の 1 つは、サーバーレスキャパシティで提供されていない GPU の `type` を指定していることです (大文字と小文字の誤りも含みます)。また、現在接続されているキャパシティがない場合にも同じコードが返されます。	`type` を削除してください。リクエストに問題がない場合は、再試行してください。
`nvidia-smi: not found`	サンドボックスに GPU が割り当てられていないか、イメージで NVIDIA ツールが利用できない状態になっています。	まず `sandbox.resource_gpu` を確認してください。正の値が返される場合、GPU は割り当て済みなので、イメージを変更する必要があります。

Next steps

サンドボックスの設定では、ResourceOptions の全フィールド、QoS クラス、タイムアウトについて説明しています。
はじめにでは、CPU のみのサーバーレスサンドボックスと認証情報について説明しています。

​Before you begin

​GPU リクエストの仕組み

​サーバーレスキャパシティで GPU サンドボックスを実行する

​利用可能な GPU

​Create the sandbox

​Container images

​Common errors

​Next steps

Before you begin

GPU リクエストの仕組み

サーバーレスキャパシティで GPU サンドボックスを実行する

利用可能な GPU

Create the sandbox

Container images

Common errors

Next steps