GPU provider

Run workloads on AMD GPUs with DigitalOcean

Use DigitalOcean GPU Droplets as the provisioning provider, AMD Instinct as the accelerator target, and ROCm as the runtime.

Production profile

•Provider: digitalocean. Provider target: digitalocean_amd. Runtime: ROCm.
•Jungle Grid creates an AMD GPU Droplet, starts a scoped cloud-init runner, streams runtime data, then tears the VM down.
•The older amd_hackathon_runner profile remains a bring-your-own Jupyter runner fallback.

Configure DigitalOcean AMD capacity

The orchestrator needs a DigitalOcean token with Droplet create/read/delete plus size, region, and image read access. GPU availability is discovered from the sizes API for the configured account and region.

•gpu-amd-base is the default AMD AI/ML-ready image.
•Optional VPC, tags, snapshot, firewall, and keepalive controls are supported.
•Every Droplet is tagged junglegrid, managed, gpu, amd, organization, job, and environment.

Required environment

DIGITALOCEAN_API_TOKEN=...
DIGITALOCEAN_ENABLE_AMD=true
DIGITALOCEAN_DEFAULT_REGION=atl1
DIGITALOCEAN_AMD_IMAGE_SLUG=gpu-amd-base
DIGITALOCEAN_SSH_KEY_IDS=...
DIGITALOCEAN_PROJECT_ID=...

Run the first ROCm smoke test

VM script mode is the initial execution mode. The runner captures rocm-smi, Python, Docker, disk, and callback diagnostics before it executes the command.

Job request

POST /v1/jobs
{
  "name": "digitalocean-amd-smoke",
  "image": "python:3.12",
  "command": "bash",
  "args": ["-lc", "mkdir -p artifacts && rocm-smi > artifacts/rocm-smi.txt && echo 'Hello from Jungle Grid on DigitalOcean AMD'"],
  "workload_type": "batch",
  "provider_target": "digitalocean_amd",
  "gpu_vendor": "amd",
  "runtime": "rocm"
}

ROCm-aware routing and screening

Explicit AMD, ROCm, or digitalocean_amd requests only consider AMD-compatible capacity. CUDA images, NVIDIA labels, nvidia-smi commands, and known CUDA-only workload hints are blocked before provisioning.

•Use io.junglegrid.runtime=rocm or an AMD label when a build pipeline can supply OCI metadata.
•Recognized framework hints are pytorch-rocm, vllm-rocm, llama.cpp-rocm, and onnx-rocm.
•Unknown CUDA-heavy containers are never silently moved to AMD; declare ROCm compatibility or select an NVIDIA route.

Execution modes and lifecycle

vm_script is the default proof path. Container mode uses Docker with /dev/kfd and /dev/dri, seccomp=unconfined, and the video group for tested ROCm images. In either mode, cloud-init installs the runner configuration and systemd starts junglegrid-runner.service.

•The token is scoped to one job and managed node for registration, callback, log, artifact, and status operations.
•The runner phones home before workload execution and reports the public VM lifecycle through Jungle Grid.
•Completed, failed, timed-out, manually terminated, and orphan-repair workflows use the provider Droplet ID and managed tags for cleanup.

Troubleshooting

No available AMD size normally means the token lacks GPU entitlement or the desired region has no capacity. If the VM is active but the runner has not registered, ensure ORCH_BASE_URL is public HTTPS, then inspect journalctl -u junglegrid-runner with an optional configured SSH key.

•Use gpu-amd-base, or a tested snapshot derived from it, when rocm-smi is missing.
•Set keepalive: true on a failing AMD job for post-mortem debugging; normal completed and cancelled jobs still clean up.
•The Admin provider view reports missing token, disabled profile, API error, or discovered AMD capacity.