> ## 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.
# GPU サンドボックスを実行する
> 仮想化されたサーバーレスキャパシティ、または仮想化されていないお客様所有の CKS クラスター上のサンドボックスに GPU をリクエストします。
このガイドでは、1 つ以上の GPU を搭載したサンドボックスを作成し、サンドボックス内から GPU が認識されていることを確認したうえで、GPU に合わせて CPU とメモリのリクエストを設定する方法を説明します。GPU サンドボックスは、CoreWeave が運用するサーバーレスキャパシティと、お客様所有の CoreWeave Kubernetes Service (CKS) クラスターのどちらの配置モードでも実行できます。サンドボックスの分離方法、利用できる GPU の種類、制限を設定する主体はモードによって異なるため、このページではモードごとにセクションを分けて説明します。
CPU のみのサンドボックスについては、[はじめに](/ja/products/sandboxes/get-started)を参照してください。サーバーレスキャパシティと CKS キャパシティの比較については、[サンドボックスの配置とスピルオーバー](/ja/products/sandboxes/placement)を参照してください。
GPU サンドボックスはプライベートプレビュー段階にあり、すでに CPU のみのサンドボックスを使用している組織であっても、許可リストへの登録が必要です。アクセスをリクエストするには、担当のアカウント担当チームに連絡するか、[forge-support@coreweave.com](mailto:forge-support@coreweave.com) までメールでお問い合わせください。組織が許可リストに登録されるまでは、GPU サンドボックスの作成リクエストはエラー `CWSANDBOX_GPU_NOT_ALLOWED` を返して失敗します。
同時実行サンドボックスのクォータとリソース制限については、[制限とクォータ](/ja/products/sandboxes/reference/limits-and-quotas)を参照してください。
分離レベルは配置モードによって異なります
GPU 仮想化はサーバーレスキャパシティでのみサポートされています。お客様が所有する CKS クラスターでは、GPU サンドボックスは仮想化されません。
| | サーバーレス | お客様の CKS クラスター |
| - | - | - |
| ランタイム | GPU 仮想マシンランタイム (自動的に選択) | クラスターのデフォルトのランタイムクラス (`runc` でコンテナーを実行) |
| GPU 仮想化 | はい。GPU はサンドボックスの仮想マシンに付加されます。 | いいえ。サンドボックスは、ノードのカーネルを共有する標準のコンテナーです。 |
| セキュアなコンテナーランタイム | はい | **いいえ** |
| 信頼できないコードの実行 | 可 | **不可。** 信頼できるコードのみを実行してください。 |
お客様自身の CKS クラスター上の GPU サンドボックスは、デフォルトのランタイムクラス (`runc`) で実行され、仮想化されません。分離レベルはノード上の他のコンテナーと同等であり、**セキュアなコンテナーランタイムとは見なせません**。モデルが生成したコードやユーザーが送信したコードなど、信頼できないコードを CKS の GPU サンドボックスで実行しないでください。信頼できないコードを GPU で実行するには、[サーバーレスキャパシティ](#run-a-gpu-sandbox-on-serverless-capacity)を使用してください。
始める前に
以下が必要です。
* 組織で GPU サンドボックスが有効になっていること。
* サーバーレスの例を実行するための [Forge APIキー](https://forge.coreweave.com/settings#apikeys)。CKS に配置する場合は、`SANDBOX_USER` アイデンティティとアクセス管理 (IAM) action を持つ CoreWeave API アクセストークンが必要です。詳しくは、[認証情報を選択して取得する](/ja/products/sandboxes/placement#choose-and-get-credentials)を参照してください。
* Python クライアント `cwsandbox` 1.14.2 以降。
```bash theme={"system"}
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 クラスター](#run-a-gpu-sandbox-on-your-cks-cluster)を使用してください。
| GPU | GPU メモリ | サンドボックスあたりの GPU 数 |
| - | - | - |
| NVIDIA RTX PRO 6000 Blackwell Server Edition | 96 GB | 1 |
この GPU を搭載するインスタンスタイプは、[High Memory](/platform/instances/gpu/rtxp6000-8x) と [Standard Memory](/platform/instances/gpu/rtxp6000-8x-v2) の 2 つです。両者の違いは GPU ではなくホストの RAM で、どちらもサンドボックスからは同じ GPU タイプとして認識されます。そのため、サンドボックスがどちらに配置されるかをユーザーが選択することはできません。
GPU リクエストでは `type` キーを省略し、CoreWeave が管理するコンピュートから GPU をプラットフォームに割り当てさせてください。このフィールド自体は指定可能ですが、選択ではなくフィルターとして機能します。どのランナーにも一致しない `type` を指定すると、`CWSANDBOX_RUNNER_UNAVAILABLE` で失敗します。また、サポートされていないタイプを受け取ったランナーは、`CWSANDBOX_PLACEMENT_CONSTRAINT_UNSATISFIED` を返してリクエストを拒否します。
次の例に示すように、`resources` を使用して、GPU 数と併せて CPU とメモリを指定してください。
ディスクは、CPU、メモリ、GPU とは別にリクエストします。`ResourceOptions` にはディスク用のフィールドがありません。コンテナーのルートファイルシステムはノードローカルのエフェメラルストレージであり、サンドボックスはその領域を予約しません。そのため、サンドボックス内で `df` を実行すると、サンドボックスごとのクォータではなくノードのファイルシステムの情報が表示されます。専用の書き込み可能なパスが必要な場合は、スクラッチボリュームを宣言してください。
```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)
```
ディスクベースのボリューム (デフォルト) は、ルートファイルシステムと同じノードローカルストレージを使用します。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 を出力します。
この例では、`AuthHeaders` を介して Forge APIキーを渡します。
```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)
```
フラットな `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 クライアントを使用してください。
出力例:
```text theme={"system"}
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 として実行しても問題ないワークロードにのみ使用してください。信頼できないコードには、[サーバーレスキャパシティ](#run-a-gpu-sandbox-on-serverless-capacity)を使用してください。
前提条件
CKS で GPU をリクエストする前に、以下を完了してください。
* GPU Node を備え、ランナーが `Ready` 状態にある CKS クラスター。[独自のコンピュートを使用する](/ja/products/sandboxes/get-started-cks)を参照してください。
* そのランナーに設定された、GPU を許可するポリシー。`resources` の `maxGpuCount` で、1 つのサンドボックスがリクエストできる GPU 数の上限を指定します。上限を設けない場合は省略し、GPU リクエストを拒否する場合は `0` に設定します。GPU サンドボックスがクラスターのデフォルトのランタイムクラスで実行されるよう、`defaultGpuRuntimeClass` は設定しないでください。`cw-kata-nvidia-gpu` などの Kata ベースの GPU ランタイムクラスは、お客様の CKS クラスターではサポートされていません。各フィールドの詳細については、[サンドボックスポリシーを設定する](/ja/products/sandboxes/profiles/configure)を参照してください。
* `SANDBOX_USER` IAM action と、`CWSANDBOX_API_KEY` として設定された CoreWeave API アクセストークン。
ランナーで利用可能な GPU タイプを検索する
各ランナーは、自身のノードに搭載されている GPU タイプを公開しています。`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)
```
これらの値は、`type` にそのまま渡す strings です。大文字と小文字は区別されるため、`B200` と `b200` は別のタイプとして扱われます。GPU タイプでランナーを絞り込む場合は、代わりに `list_runners()` に `gpu_type` を渡してください。詳細については、[利用可能なランナーのディスカバリー](/ja/products/sandboxes/client/guides/discovery)を参照してください。
サンドボックスを作成する
次の例では、特定のタイプの GPU を 2 基、CPU を 8 個、メモリを 32 GiB 割り当てたサンドボックスを CKS 上に配置します。`[GPU-TYPE]` は、ランナーが公開しているタイプのいずれかに置き換えてください。ランナー上のどの GPU でも構わない場合は、`type` キーを削除してください。`runtime_class` は設定しないでください。設定しなければ、サンドボックスにはクラスターのデフォルトのランタイムクラスが使用されます。
```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)
```
組織内の任意の 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` が含まれていることを確認してください。
```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)
```
出力例:
```text theme={"system"}
(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](mailto: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 が割り当てられているため、イメージを変更する必要があります。 |
次のステップ
* [サンドボックスの設定](/ja/products/sandboxes/client/guides/sandbox-configuration) では、`ResourceOptions` の全フィールド、QoS クラス、タイムアウトについて説明します。
* [サンドボックスポリシーを設定する](/ja/products/sandboxes/profiles/configure) では、管理者が CKS ランナーに設定する GPU、ランタイムクラス、リソースの制約について説明します。
* [はじめに](/ja/products/sandboxes/get-started) では、CPU のみのサーバーレスサンドボックスと認証情報について説明します。
* [独自のコンピュートを使用する](/ja/products/sandboxes/get-started-cks) では、ランナーのセットアップと、クラスター上での最初のサンドボックスについて説明します。