GPU サンドボックスはプライベートプレビュー段階にあり、すでに CPU のみのサンドボックスを使用している組織であっても、許可リストへの登録が必要です。アクセスをリクエストするには、担当のアカウント担当チームに連絡するか、forge-support@coreweave.com までメールでお問い合わせください。組織が許可リストに登録されるまでは、GPU サンドボックスの作成リクエストはエラー
CWSANDBOX_GPU_NOT_ALLOWED を返して失敗します。分離レベルは配置モードによって異なります
GPU 仮想化はサーバーレスキャパシティでのみサポートされています。お客様が所有する CKS クラスターでは、GPU サンドボックスは仮想化されません。始める前に
以下が必要です。- 組織で GPU サンドボックスが有効になっていること。
- サーバーレスの例を実行するための、サーバーレスサンドボックスへのアクセス権を持つアカウントの Forge APIキーまたは CoreWeave API アクセストークン。CKS に配置する場合は、
sandbox_userアイデンティティとアクセス管理 (IAM) action を持つ CoreWeave API アクセストークンが必要です。詳しくは、認証情報を選択して取得するを参照してください。
ワークロード用のイメージを選択する
ランタイムイメージではビルド済みの GPU ライブラリを実行できますが、アプリケーションに必要なビルドツールが含まれていない場合があります。モデルの重みをダウンロードする前に、イメージとパッケージの正確なバージョンを確認してください。インポートやモデルの読み込みが成功しても、最初のカーネル起動時に行われる JIT (just-in-time) コンパイルまで検証できるわけではありません。
システムツールは、バージョンを固定したカスタムイメージに含めることをお勧めします。フレームワークの開発用イメージをベースにすることもできますが、その内容とお使いのスタックとの互換性を検証してください。大規模なスナップショットをビルドする前に、1 つのサンドボックスで、依存関係のインストール、代表的なカーネルまたは推論リクエスト 1 件、およびサーバーの起動をテストしてください。
ファイルシステムスナップショットは、設定済みのマウント内のファイルを取得します。
apt-get でコンテナーのルートファイルシステムにインストールしたパッケージは取得されません。リストア後もこれらのパッケージを利用できるよう、イメージに含めてください。Python 環境やプリコンパイル済みカーネルは、スナップショットのマウント内に保存しておけば保持されます。カーネルのインストーラーが pip を呼び出す場合は、その環境に pip がインストールされていることを確認してください。uv で作成した環境には pip が含まれていない場合があります。
認証を選択する
以下の例は、セクション内で CKS が指定されていない限り、サーバーレスキャパシティ上で実行されます。サンドボックスを所有するアカウントの認証情報を選択してください。 インストールコマンドは、有効化した Python 仮想環境で実行してください。 使用する認証情報のタブにある Python コードを、このページで実行する Python スクリプトと同じディレクトリにsandbox_auth.py として保存してください。このファイルに保存されるのは認証方式の選択であり、認証情報そのものではありません。各例ではこのファイルから AUTH をインポートし、新しいサンドボックスやセッションを作成するたびに明示的に渡します。
- Forge APIキー
- CoreWeave API アクセストークン
SDK の
wandb インテグレーションで Forge APIキーを使用します。[WANDB-API-KEY] をお使いの APIキーに置き換えてください。sandbox_auth.py
SandboxDefaults で placement_mode="cks" を設定してください。auth=AUTH を指定してセッションを作成すると、そのセッションが所有するサンドボックスも認証されます。サンドボックスへの再接続、一覧表示、クリーンアップを行う際も、同じ認証情報を使用してください。
GPU リクエストの仕組み
どちらの配置モードでも、同じルールが適用されます。- GPU リクエストで確保されるのは GPU のみです。 CPU とメモリは、GPU と並行して実行する処理に見合ったサイズで明示的に設定してください。CPU とメモリの値を省略した場合は、ポリシーの
defaultCpuとdefaultMemoryが使用されることがあります。ただしその場合でも、最終的に決定された割り当てがポリシーのリソース要件を満たしている必要があります。 - サンドボックスには GPU が 1 基単位で丸ごと割り当てられます。 GPU がサンドボックス間で共有、分割、またはタイムスライスされることはありません。
- サンドボックスは単一のノード上で実行されます。 サーバーレスキャパシティでは、サンドボックスに割り当てられる GPU は常に 1 基です。お使いの CKS クラスターでは、サンドボックスの最大サイズはノード 1 台分で、その GPU 数は GPU タイプによって異なります。GPU を 8 基搭載したノードでは、組織の上限とランナーのポリシーで許可されていれば、CKS のサンドボックスは最大 8 基の GPU をリクエストできます。複数の GPU をリクエストする場合は、その数の空き GPU と、リクエストした CPU およびメモリが、1 つのノード上で同時に確保できる必要があります。
- 組織には、サンドボックスあたりの GPU 数の上限があります。 CoreWeave が引き上げない限り、上限は 1 です。上限の引き上げを依頼するには、サポートまたはアカウント担当チームにお問い合わせください。上限を超えるリクエストは、
CWSANDBOX_GPU_COUNT_EXCEEDEDエラーで失敗します。 - GPU タイプは選択肢のメニューではなく、フィルターです。 オプションの
typeキーは、ランナーが提供する GPU タイプのいずれかと、大文字・小文字も含めて完全に一致している必要があります。省略すると、ランナーが持つどの GPU でも受け入れます。
サーバーレスキャパシティで GPU サンドボックスを実行する
サーバーレス配置では、ランナーやポリシーを自分で用意する必要はありません。ポリシーとハードウェアは CoreWeave が所有しています。GPU サンドボックスは仮想マシン内で実行されるため、信頼できないコードの実行に適しています。利用可能な GPU
サーバーレスキャパシティで使用できる GPU モデルは、NVIDIA RTX PRO 6000 Blackwell Server Edition の 1 種類です。サーバーレスキャパシティでサポートされるのは、GPU 1 基のサンドボックスのみです。GPU を 2 基以上使用するサンドボックスを実行するには、CKS クラスターを使用してください。
この 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 を実行すると、サンドボックスごとのクォータではなくノードのファイルシステムの情報が表示されます。専用の書き込み可能なパスが必要な場合は、スクラッチボリュームを宣言してください。
medium="memory" を設定します。メモリベースのボリュームではサイズの宣言が必須で、1 つのコンテナー上のメモリベースのボリュームの合計は、そのコンテナーのメモリリクエストの 80% を超えることはできません。
runtime_class も未設定のままにしてください。GPU をリクエストすると GPU 仮想マシンのランタイムクラスが自動的に選択されます。一方、明示的に指定したランタイムクラスはそのとおりに使用されるため、GPU リクエストと併せて CPU クラスを指定すると、GPU にアクセスできないサンドボックスが作成されてしまいます。
サンドボックスを作成する
認証を選択するの手順を完了してから、次の例を実行します。この例では、GPU 1 基、CPU 2 コア、メモリ 8 GiB のサンドボックスを作成し、nvidia-smi が報告する GPU を出力します。
- Python
- TypeScript
この例では、フラットな
sandbox_auth.py で選択した認証情報を使用します。resources dict を指定すると、リクエストと制限が同じ値に設定されます。"gpu": 1 は "gpu": {"count": 1} の省略形です。サーバーレスでサポートされる GPU はサンドボックスあたり 1 基のみのため、count は 1 のままにしてください。resource_gpu プロパティは、プラットフォームが確定した GPU の割り当て (例: {'count': 1}) を返します。sandbox.wait(timeout=600.0) を呼び出します。timeout を省略した場合、SDK は起動の待機に request_timeout_seconds (デフォルトは 300 秒) を使用します。これには exec() の前に暗黙的に行われる待機も含まれます。
request_timeout_seconds は、大半の個々のリモートプロシージャコール (RPC) の上限としても適用されます。ステータスのポーリングでは、各 RPC に poll_rpc_timeout_seconds (デフォルトは 15 秒) が使用されます。exec() の timeout_seconds パラメータは起動後に適用されます。タイムアウトの各フェーズと、サンドボックスの最大ライフタイムに起動時間が含まれる仕組みについては、タイムアウトのフェーズを参照してください。
CKS クラスターで GPU サンドボックスを実行する
CKS への配置では、サンドボックスで使用できる GPU の種類と数を管理者が決定します。ランナーはクラスターのノードに搭載されている GPU タイプを提供し、サンドボックスがリクエストできる範囲はランナーに適用されたポリシーによって制限されます。前提条件
CKS で GPU をリクエストする前に、以下を完了してください。-
GPU Node を備え、ランナーが
Ready状態にある CKS クラスター。独自のコンピュートを使用するを参照してください。 -
そのランナーに設定された、GPU を許可するポリシー。
resourcesのmaxGpuCountで、各コンテナーがリクエストできる GPU 数の上限を指定します。上限を設けない場合は省略し、GPU リクエストを拒否する場合は0に設定します。GPU サンドボックスがクラスターのデフォルトのランタイムクラスで実行されるよう、defaultGpuRuntimeClassは設定しないでください。cw-kata-nvidia-gpuなどの Kata ベースの GPU ランタイムクラスは、お客様の CKS クラスターではサポートされていません。各フィールドの詳細については、サンドボックスポリシーを設定するを参照してください。 -
sandbox_userIAM action と、CWSANDBOX_API_KEYとして設定された CoreWeave API アクセストークン。
ランナーで利用可能な GPU タイプを検索する
各ランナーは、自身のノードに搭載されている GPU タイプを公開しています。type を選択する前に、次のコマンドで一覧を表示してください。
type にそのまま渡す strings です。大文字と小文字は区別されるため、B200 と b200 は別のタイプとして扱われます。GPU タイプでランナーを絞り込む場合は、代わりに list_runners() に gpu_type を渡してください。詳細については、利用可能なランナーのディスカバリーを参照してください。
サンドボックスを作成する
次の例では、特定のタイプの GPU を 2 基、CPU を 8 個、メモリを 32 GiB 割り当てたサンドボックスを CKS 上に配置します。この例を実行するには、組織で設定されているサンドボックスあたりの GPU 数の最大値が 2 基以上である必要があります。[GPU-TYPE] は、ランナーが公開しているタイプのいずれかに置き換えてください。ランナー上のどの GPU でも構わない場合は、type キーを削除してください。runtime_class は設定しないでください。設定しなければ、サンドボックスにはクラスターのデフォルトのランタイムクラスが使用されます。
runner_ids=["[RUNNER-ID]"] を追加します。resource_gpu で確認される割り当てには、タイプを指定してリクエストした場合でも、{'count': 2} のように GPU 数のみが示されます。
GPU 数の上限は、組織の最大値、ポリシーの maxGpuCount、および単一のノード上の空き GPU 数によって決まります。組織の最大値を超えるリクエストは CWSANDBOX_GPU_COUNT_EXCEEDED で失敗し、ポリシーの上限を超えるリクエストは、CWSANDBOX_RESOURCE_CEILING_EXCEEDED で失敗します。ランナーが提供していない type、または大文字と小文字が異なる type を指定すると、条件を満たすランナーが見つからず、CWSANDBOX_RUNNER_UNAVAILABLE で失敗します。
コンテナーイメージ
次の例では、サーバーレスキャパシティと、sandbox_auth.py で選択した認証情報を使用します。CKS では、CoreWeave トークンを使用して placement_mode="cks" を設定し、クラスターの GPU に対応したイメージを選択してください。
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 が含まれていることを確認してください。
よくあるエラー
次のステップ
- サンドボックスの設定 では、
ResourceOptionsの全フィールド、QoS クラス、タイムアウトについて説明します。 - サンドボックスポリシーを設定する では、管理者が CKS ランナーに設定する GPU、ランタイムクラス、リソースの制約について説明します。
- はじめに では、CPU のみのサーバーレスサンドボックスと認証情報について説明します。
- 独自のコンピュートを使用する では、ランナーのセットアップと、クラスター上での最初のサンドボックスについて説明します。