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

このガイドでは、1 つ以上の GPU を搭載したサンドボックスを作成し、サンドボックス内から GPU が認識されていることを確認したうえで、GPU に合わせて CPU とメモリのリクエストを設定する方法を説明します。GPU サンドボックスは、CoreWeave が運用するサーバーレスキャパシティと、お客様所有の CoreWeave Kubernetes Service (CKS) クラスターのどちらの配置モードでも実行できます。サンドボックスの分離方法、利用できる GPU の種類、制限を設定する主体はモードによって異なるため、このページではモードごとにセクションを分けて説明します。 CPU のみのサンドボックスについては、はじめにを参照してください。サーバーレスキャパシティと CKS キャパシティの比較については、サンドボックスの配置とスピルオーバーを参照してください。

GPU サンドボックスはプライベートプレビュー段階にあり、すでに CPU のみのサンドボックスを使用している組織であっても、許可リストへの登録が必要です。アクセスをリクエストするには、担当のアカウント担当チームに連絡するか、forge-support@coreweave.com までメールでお問い合わせください。組織が許可リストに登録されるまでは、GPU サンドボックスの作成リクエストはエラー CWSANDBOX_GPU_NOT_ALLOWED を返して失敗します。

同時実行サンドボックスのクォータとリソース制限については、制限とクォータを参照してください。

分離レベルは配置モードによって異なります

GPU 仮想化はサーバーレスキャパシティでのみサポートされています。お客様が所有する CKS クラスターでは、GPU サンドボックスは仮想化されません。

	サーバーレス	お客様の CKS クラスター
ランタイム	GPU 仮想マシンランタイム (自動的に選択)	クラスターのデフォルトのランタイムクラス (`runc` でコンテナーを実行)
GPU 仮想化	はい。GPU はサンドボックスの仮想マシンに付加されます。	いいえ。サンドボックスは、ノードのカーネルを共有する標準のコンテナーです。
セキュアなコンテナーランタイム	はい	いいえ
信頼できないコードの実行	可	不可。信頼できるコードのみを実行してください。

お客様自身の CKS クラスター上の GPU サンドボックスは、デフォルトのランタイムクラス (runc) で実行され、仮想化されません。分離レベルはノード上の他のコンテナーと同等であり、セキュアなコンテナーランタイムとは見なせません。モデルが生成したコードやユーザーが送信したコードなど、信頼できないコードを CKS の GPU サンドボックスで実行しないでください。信頼できないコードを GPU で実行するには、サーバーレスキャパシティを使用してください。

始める前に

以下が必要です。

組織で GPU サンドボックスが有効になっていること。
サーバーレスの例を実行するための Forge APIキー。CKS に配置する場合は、SANDBOX_USER アイデンティティとアクセス管理 (IAM) action を持つ CoreWeave API アクセストークンが必要です。詳しくは、認証情報を選択して取得するを参照してください。
Python クライアント cwsandbox 1.14.2 以降。
uv pip install 'cwsandbox>=1.14.2'

TypeScript クライアントは、現時点では GPU リソースに対応していません。GPU サンドボックスには Python クライアントを使用してください。

GPU リクエストの仕組み

どちらの配置モードでも、同じルールが適用されます。

GPU リクエストで確保されるのは GPU のみです。 CPU とメモリは、GPU と並行して実行する処理に見合ったサイズで明示的に設定してください。CPU とメモリの値を省略した場合は、ポリシーの defaultCpu と defaultMemory が使用されることがあります。ただしその場合でも、最終的に決定された割り当てがポリシーのリソース要件を満たしている必要があります。
サンドボックスには GPU が 1 基単位で丸ごと割り当てられます。 GPU がサンドボックス間で共有、分割、またはタイムスライスされることはありません。
サンドボックスは単一のノード上で実行されます。 サーバーレスキャパシティでは、サンドボックスに割り当てられる GPU は常に 1 基です。お使いの CKS クラスターでは、サンドボックスの最大サイズはノード 1 台分で、その GPU 数は GPU タイプによって異なります。GPU を 8 基搭載したノードでは、CKS のサンドボックスは 1〜8 基の GPU をリクエストできます。複数の GPU をリクエストする場合は、その数の空き GPU と、リクエストした CPU およびメモリが、1 つのノード上で同時に確保できる必要があります。
GPU タイプは選択肢のメニューではなく、フィルターです。 オプションの type キーは、ランナーが提供する GPU タイプのいずれかと、大文字・小文字も含めて完全に一致している必要があります。省略すると、ランナーが持つどの GPU でも受け入れます。

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

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

利用可能な GPU

サーバーレスキャパシティで使用できる GPU モデルは、NVIDIA RTX PRO 6000 Blackwell Server Edition の 1 種類です。サーバーレスキャパシティでサポートされるのは、GPU 1 基のサンドボックスのみです。GPU を 2 基以上使用するサンドボックスを実行するには、CKS クラスターを使用してください。

GPU	GPU メモリ	サンドボックスあたりの GPU 数
NVIDIA RTX PRO 6000 Blackwell Server Edition	96 GB	1

この GPU を搭載するインスタンスタイプは、High Memory と Standard Memory の 2 つです。両者の違いは GPU ではなくホストの RAM で、どちらもサンドボックスからは同じ GPU タイプとして認識されます。そのため、サンドボックスがどちらに配置されるかをユーザーが選択することはできません。 GPU リクエストでは type キーを省略し、CoreWeave が管理するコンピュートから GPU をプラットフォームに割り当てさせてください。このフィールド自体は指定可能ですが、選択ではなくフィルターとして機能します。どのランナーにも一致しない type を指定すると、CWSANDBOX_RUNNER_UNAVAILABLE で失敗します。また、サポートされていないタイプを受け取ったランナーは、CWSANDBOX_PLACEMENT_CONSTRAINT_UNSATISFIED を返してリクエストを拒否します。次の例に示すように、resources を使用して、GPU 数と併せて CPU とメモリを指定してください。ディスクは、CPU、メモリ、GPU とは別にリクエストします。ResourceOptions にはディスク用のフィールドがありません。コンテナーのルートファイルシステムはノードローカルのエフェメラルストレージであり、サンドボックスはその領域を予約しません。そのため、サンドボックス内で df を実行すると、サンドボックスごとのクォータではなくノードのファイルシステムの情報が表示されます。専用の書き込み可能なパスが必要な場合は、スクラッチボリュームを宣言してください。

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)

ディスクベースのボリューム (デフォルト) は、ルートファイルシステムと同じノードローカルストレージを使用します。tmpfs を使用する場合は、代わりに medium="memory" を設定します。メモリベースのボリュームではサイズの宣言が必須で、1 つのコンテナー上のメモリベースのボリュームの合計は、そのコンテナーのメモリリクエストの 80% を超えることはできません。 runtime_class も未設定のままにしてください。GPU をリクエストすると GPU 仮想マシンのランタイムクラスが自動的に選択されます。一方、明示的に指定したランタイムクラスはそのとおりに使用されるため、GPU リクエストと併せて CPU クラスを指定すると、GPU にアクセスできないサンドボックスが作成されてしまいます。

サンドボックスを作成する

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

Python
TypeScript

この例では、AuthHeaders を介して Forge APIキーを渡します。

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)

フラットな 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 クライアントを使用してください。

出力例:

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

{'count': 1}

GPU サンドボックスは、プラットフォームがサンドボックスの仮想マシンに GPU をアタッチするため、CPU のみのサンドボックスよりも起動に時間がかかります。リクエストのタイムアウトを設定する場合は、数分程度の余裕を持たせてください。

CKS クラスターで GPU サンドボックスを実行する

CKS への配置では、サンドボックスで使用できる GPU の種類と数を管理者が決定します。ランナーはクラスターのノードに搭載されている GPU タイプを提供し、サンドボックスがリクエストできる範囲はランナーに適用されたポリシーによって制限されます。

独自の CKS クラスターでは GPU 仮想化はサポートされていません。CKS 上の GPU サンドボックスは、デフォルトではクラスターのデフォルトのランタイムクラス (runc を使用) で実行されます。サンドボックスはノードのカーネルを共有する通常のコンテナーであり、割り当てられた GPU デバイスに直接アクセスできます。このモードはセキュアなコンテナーランタイムではありません。信頼できないコードの実行には使用しないでください。クラスター上で通常の Pod として実行しても問題ないワークロードにのみ使用してください。信頼できないコードには、サーバーレスキャパシティを使用してください。

前提条件

CKS で GPU をリクエストする前に、以下を完了してください。

GPU Node を備え、ランナーが Ready 状態にある CKS クラスター。独自のコンピュートを使用するを参照してください。
そのランナーに設定された、GPU を許可するポリシー。resources の maxGpuCount で、1 つのサンドボックスがリクエストできる GPU 数の上限を指定します。上限を設けない場合は省略し、GPU リクエストを拒否する場合は 0 に設定します。GPU サンドボックスがクラスターのデフォルトのランタイムクラスで実行されるよう、defaultGpuRuntimeClass は設定しないでください。cw-kata-nvidia-gpu などの Kata ベースの GPU ランタイムクラスは、お客様の CKS クラスターではサポートされていません。各フィールドの詳細については、サンドボックスポリシーを設定するを参照してください。
SANDBOX_USER IAM action と、CWSANDBOX_API_KEY として設定された CoreWeave API アクセストークン。

ランナーで利用可能な GPU タイプを検索する

各ランナーは、自身のノードに搭載されている GPU タイプを公開しています。type を選択する前に、次のコマンドで一覧を表示してください。

from cwsandbox import list_runners

for runner in list_runners():
    print(runner.runner_id, runner.supported_gpu_types, runner.max_gpu_count)

これらの値は、type にそのまま渡す strings です。大文字と小文字は区別されるため、B200 と b200 は別のタイプとして扱われます。GPU タイプでランナーを絞り込む場合は、代わりに list_runners() に gpu_type を渡してください。詳細については、利用可能なランナーのディスカバリーを参照してください。

サンドボックスを作成する

次の例では、特定のタイプの GPU を 2 基、CPU を 8 個、メモリを 32 GiB 割り当てたサンドボックスを CKS 上に配置します。[GPU-TYPE] は、ランナーが公開しているタイプのいずれかに置き換えてください。ランナー上のどの GPU でも構わない場合は、type キーを削除してください。runtime_class は設定しないでください。設定しなければ、サンドボックスにはクラスターのデフォルトのランタイムクラスが使用されます。

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)

組織内の任意の CKS ランナーではなく特定のランナーを対象にするには、runner_ids=["[RUNNER-ID]"] を追加します。resource_gpu で確認される割り当てには、タイプを指定してリクエストした場合でも、{'count': 2} のように GPU 数のみが示されます。 GPU 数の上限は、ポリシーの maxGpuCount と、単一のノード上の空き GPU 数によって決まります。ポリシーの上限を超えるリクエストは、CWSANDBOX_RESOURCE_CEILING_EXCEEDED で失敗します。ランナーが提供していない type、または大文字と小文字が異なる type を指定すると、条件を満たすランナーが見つからず、CWSANDBOX_RUNNER_UNAVAILABLE で失敗します。

コンテナーイメージ

次の例では、サーバーレスキャパシティと、先ほど設定した Forge の APIキーを使用します。 GPU サンドボックス内では、プラットフォームによって NVIDIA ドライバーと nvidia-smi ツールが提供されるため、デフォルトのイメージでも GPU を認識できます。CUDA アプリケーションを実行するには、pytorch/pytorch や nvidia/cuda イメージなど、コードに必要な CUDA ランタイムとライブラリを含むイメージを使用してください。イメージは GPU に合わせて選択してください。RTX PRO 6000 Blackwell Server Edition の Compute Capability は 12.0 (sm_120) で、CUDA 12.8 以降が必要です。この GPU に対応したビルドが初めて提供されたのは PyTorch 2.7 です。古いイメージでも GPU の名前は正しく表示されます。これはドライバーを介してデバイスのメタデータを読み取るためです。しかし、最初のカーネル起動時に CUDA error: no kernel image is available for execution on the device というエラーで失敗します。デバイス名だけで判断せず、フレームワークのサポート対象に sm_120 が含まれていることを確認してください。

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)

出力例:

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

サイズの大きいフレームワークイメージは、デフォルトのイメージよりもプルに時間がかかるため、サンドボックスが準備完了になるまで数分ほどお待ちください。

よくあるエラー

エラー	原因	対処方法
`CWSANDBOX_GPU_NOT_ALLOWED`	組織が GPU サンドボックスの許可リストに登録されていません。	アカウント担当チームまたは forge-support@coreweave.com に連絡して、アクセスをリクエストしてください。
`SandboxResourceExhaustedError` (`runner capacity exhausted`)	現在、リクエストを満たすだけの空き GPU、CPU、またはメモリを持つノードがありません。	しばらく待ってから再試行してください。CKS の場合は、リクエストする GPU の数を減らすこともできます。
`CWSANDBOX_RUNNER_UNAVAILABLE` (`no eligible runner is available`)	リクエストに一致するランナーがありません。原因の 1 つとして、どのランナーも提供していない GPU `type` (大文字と小文字が誤っているものを含む) を指定していることが考えられます。条件を満たすランナーが現在接続されていない場合にも、同じコードが返されます。	サーバーレスの場合は `type` を削除してください。CKS の場合は `supported_gpu_types` に含まれるタイプを使用するか、`type` を削除してください。`type` が正しく指定されている場合は、再試行してください。
`CWSANDBOX_RESOURCE_CEILING_EXCEEDED` (`gpu count exceeds the policy maximum`)	リクエストした GPU の数が、ポリシーの `maxGpuCount` を超えています。	GPU の数を減らすか、管理者に上限の引き上げを依頼してください。
`nvidia-smi: not found`	サンドボックスに GPU がないか、イメージで NVIDIA ツールが利用できません。	まず `sandbox.resource_gpu` を確認してください。正の値が返される場合は GPU が割り当てられているため、イメージを変更する必要があります。

次のステップ

サンドボックスの設定では、ResourceOptions の全フィールド、QoS クラス、タイムアウトについて説明します。
サンドボックスポリシーを設定するでは、管理者が CKS ランナーに設定する GPU、ランタイムクラス、リソースの制約について説明します。
はじめにでは、CPU のみのサーバーレスサンドボックスと認証情報について説明します。
独自のコンピュートを使用するでは、ランナーのセットアップと、クラスター上での最初のサンドボックスについて説明します。

サンドボックス

サンドボックスを使用する

サンドボックスの管理

リファレンス

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

分離レベルは配置モードによって異なります

始める前に

GPU リクエストの仕組み

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

利用可能な GPU

サンドボックスを作成する

CKS クラスターで GPU サンドボックスを実行する

前提条件

ランナーで利用可能な GPU タイプを検索する

サンドボックスを作成する

コンテナーイメージ

よくあるエラー

次のステップ

​分離レベルは配置モードによって異なります

​始める前に

​GPU リクエストの仕組み

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

​利用可能な GPU

​サンドボックスを作成する

​CKS クラスターで GPU サンドボックスを実行する

​前提条件

​ランナーで利用可能な GPU タイプを検索する

​サンドボックスを作成する

​コンテナーイメージ

​よくあるエラー

​次のステップ

分離レベルは配置モードによって異なります

始める前に

GPU リクエストの仕組み

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

利用可能な GPU

サンドボックスを作成する

CKS クラスターで GPU サンドボックスを実行する

前提条件

ランナーで利用可能な GPU タイプを検索する

サンドボックスを作成する

コンテナーイメージ

よくあるエラー

次のステップ