Skip to main content
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 이상이 필요합니다.
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를 통째로 할당받습니다. GPU는 샌드박스 간에 공유, 분할 또는 시분할되지 않습니다.
  • 샌드박스에는 정확히 1개의 GPU가 할당됩니다. 서버리스 용량에서는 GPU 1개짜리 샌드박스만 지원합니다.
  • GPU 유형은 선택 메뉴가 아니라 필터입니다. 선택 항목인 type 키는 러너가 제공하는 GPU 유형 중 하나와 대소문자까지 정확히 일치해야 합니다. 러너에 있는 GPU라면 무엇이든 허용하려면 이 키를 생략하세요.

서버리스 용량에서 GPU 샌드박스 실행하기

서버리스 배치를 사용하면 러너나 정책을 직접 마련할 필요가 없습니다. 정책과 하드웨어는 CoreWeave가 소유합니다. GPU 샌드박스는 가상 머신에서 실행되므로 신뢰할 수 없는 코드를 실행하기에 적합합니다.

사용 가능한 GPU

서버리스 용량에서는 NVIDIA RTX PRO 6000 Blackwell Server Edition 한 가지 GPU 모델만 제공됩니다. 또한 서버리스 용량에서는 GPU 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:
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개, 메모리 8GiB로 샌드박스를 생성한 뒤 nvidia-smi가 보고하는 GPU 정보를 출력합니다.
이 예제는 W&B API 키로 인증하기 위해 AuthStrategy.WANDB를 사용합니다.
평면 구조의 resources dict를 사용하면 requests와 limits가 같은 값으로 설정됩니다. "gpu": 1은 "gpu": {"count": 1}의 축약형입니다. 서버리스에서는 샌드박스당 GPU를 1개만 지원하므로 개수는 1로 유지하세요.resource_gpu 속성은 플랫폼이 확정한 GPU 할당(예: {'count': 1})을 반환합니다.
Sample output:
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:
Sample output:
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

Next steps

  • 샌드박스 설정에서는 모든 ResourceOptions 필드, QoS 클래스, timeout을 설명합니다.
  • 시작하기에서는 CPU 전용 서버리스 샌드박스와 자격 증명을 설명합니다.
마지막 수정일 2026년 9월 30일