Skip to main content
このガイドでは、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) で実行され、仮想化されません。分離レベルはノード上の他のコンテナーと同等であり、セキュアなコンテナーランタイムとは見なせません。モデルが生成したコードやユーザーが送信したコードなど、信頼できないコードを CKS の GPU サンドボックスで実行しないでください。信頼できないコードを GPU で実行するには、サーバーレスキャパシティを使用してください。

始める前に

以下が必要です。
  • 組織で GPU サンドボックスが有効になっていること。
  • サーバーレスの例を実行するための、サーバーレスサンドボックスへのアクセス権を持つアカウントの Forge APIキーまたは CoreWeave API アクセストークン。CKS に配置する場合は、sandbox_user アイデンティティとアクセス管理 (IAM) action を持つ CoreWeave API アクセストークンが必要です。詳しくは、認証情報を選択して取得するを参照してください。
TypeScript クライアントは、現時点では GPU リソースに対応していません。GPU サンドボックスには Python クライアントを使用してください。

ワークロード用のイメージを選択する

ランタイムイメージではビルド済みの GPU ライブラリを実行できますが、アプリケーションに必要なビルドツールが含まれていない場合があります。モデルの重みをダウンロードする前に、イメージとパッケージの正確なバージョンを確認してください。インポートやモデルの読み込みが成功しても、最初のカーネル起動時に行われる JIT (just-in-time) コンパイルまで検証できるわけではありません。 システムツールは、バージョンを固定したカスタムイメージに含めることをお勧めします。フレームワークの開発用イメージをベースにすることもできますが、その内容とお使いのスタックとの互換性を検証してください。大規模なスナップショットをビルドする前に、1 つのサンドボックスで、依存関係のインストール、代表的なカーネルまたは推論リクエスト 1 件、およびサーバーの起動をテストしてください。 ファイルシステムスナップショットは、設定済みのマウント内のファイルを取得します。apt-get でコンテナーのルートファイルシステムにインストールしたパッケージは取得されません。リストア後もこれらのパッケージを利用できるよう、イメージに含めてください。Python 環境やプリコンパイル済みカーネルは、スナップショットのマウント内に保存しておけば保持されます。カーネルのインストーラーが pip を呼び出す場合は、その環境に pip がインストールされていることを確認してください。uv で作成した環境には pip が含まれていない場合があります。

認証を選択する

以下の例は、セクション内で CKS が指定されていない限り、サーバーレスキャパシティ上で実行されます。サンドボックスを所有するアカウントの認証情報を選択してください。 インストールコマンドは、有効化した Python 仮想環境で実行してください。 使用する認証情報のタブにある Python コードを、このページで実行する Python スクリプトと同じディレクトリに sandbox_auth.py として保存してください。このファイルに保存されるのは認証方式の選択であり、認証情報そのものではありません。各例ではこのファイルから AUTH をインポートし、新しいサンドボックスやセッションを作成するたびに明示的に渡します。
SDK の wandb インテグレーションで Forge APIキーを使用します。[WANDB-API-KEY] をお使いの APIキーに置き換えてください。
sandbox_auth.py
CKS に配置する場合は、CoreWeave トークンを選択してランナーを有効にし、サンドボックスの作成時または 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 を実行すると、サンドボックスごとのクォータではなくノードのファイルシステムの情報が表示されます。専用の書き込み可能なパスが必要な場合は、スクラッチボリュームを宣言してください。
ディスクベースのボリューム (デフォルト) は、ルートファイルシステムと同じノードローカルストレージを使用します。tmpfs を使用する場合は、代わりに medium="memory" を設定します。メモリベースのボリュームではサイズの宣言が必須で、1 つのコンテナー上のメモリベースのボリュームの合計は、そのコンテナーのメモリリクエストの 80% を超えることはできません。 runtime_class も未設定のままにしてください。GPU をリクエストすると GPU 仮想マシンのランタイムクラスが自動的に選択されます。一方、明示的に指定したランタイムクラスはそのとおりに使用されるため、GPU リクエストと併せて CPU クラスを指定すると、GPU にアクセスできないサンドボックスが作成されてしまいます。

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

認証を選択するの手順を完了してから、次の例を実行します。この例では、GPU 1 基、CPU 2 コア、メモリ 8 GiB のサンドボックスを作成し、nvidia-smi が報告する GPU を出力します。
この例では、sandbox_auth.py で選択した認証情報を使用します。
フラットな resources dict を指定すると、リクエストと制限が同じ値に設定されます。"gpu": 1 は "gpu": {"count": 1} の省略形です。サーバーレスでサポートされる GPU はサンドボックスあたり 1 基のみのため、count は 1 のままにしてください。resource_gpu プロパティは、プラットフォームが確定した GPU の割り当て (例: {'count': 1}) を返します。
出力例:
GPU サンドボックスは、プラットフォームがサンドボックスの仮想マシンに GPU を付加するため、CPU のみのサンドボックスよりも起動に時間がかかります。起動には数分程度の余裕を持たせてください。起動の待機時間を最大 10 分まで確保するには、最初の操作の前に 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 仮想化はサポートされていません。CKS 上の GPU サンドボックスは、デフォルトではクラスターのデフォルトのランタイムクラス (runc を使用) で実行されます。サンドボックスはノードのカーネルを共有する通常のコンテナーであり、割り当てられた GPU デバイスに直接アクセスできます。このモードはセキュアなコンテナーランタイムではありません。信頼できないコードの実行には使用しないでください。クラスター上で通常の Pod として実行しても問題ないワークロードにのみ使用してください。信頼できないコードには、サーバーレスキャパシティを使用してください。

前提条件

CKS で GPU をリクエストする前に、以下を完了してください。
  • GPU Node を備え、ランナーが Ready 状態にある CKS クラスター。独自のコンピュートを使用するを参照してください。
  • そのランナーに設定された、GPU を許可するポリシー。resources の maxGpuCount で、各コンテナーがリクエストできる GPU 数の上限を指定します。上限を設けない場合は省略し、GPU リクエストを拒否する場合は 0 に設定します。GPU サンドボックスがクラスターのデフォルトのランタイムクラスで実行されるよう、defaultGpuRuntimeClass は設定しないでください。cw-kata-nvidia-gpu などの Kata ベースの GPU ランタイムクラスは、お客様の CKS クラスターではサポートされていません。各フィールドの詳細については、サンドボックスポリシーを設定するを参照してください。
  • sandbox_user IAM 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 は設定しないでください。設定しなければ、サンドボックスにはクラスターのデフォルトのランタイムクラスが使用されます。
組織内の任意の CKS ランナーではなく特定のランナーを対象にするには、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 が含まれていることを確認してください。
出力例:
サイズの大きいフレームワークイメージは、デフォルトのイメージよりもプルに時間がかかるため、サンドボックスが準備完了になるまで数分ほどお待ちください。

よくあるエラー

次のステップ

最終更新日 2026年11月4日