WANDB_API_KEY.
Prerequisites
To use this guide, you need the following:- Access to a SUNK cluster.
- One available GPU node, at minimum. We recommend using an H200 node. By default, the script requests 1 node with 8 GPUs. If you use a smaller node, you need to adjust the hyperparameters to reduce GPU memory consumption.
- An NFS-backed working directory visible to all nodes (for data, checkpoints, container cache).
- Optionally, a
WANDB_API_KEYto log to W&B.
Tested versionThis script uses the following defaults:
- veRL container tag:
app-verl0.5-transformers4.55.4-vllm0.10.0-mcore0.13.0-te2.2 - veRL commit:
8fdc4d3f202f41461f4de9f42a637228e342668b(v0.5.0)
VERL_TAG and VERL_VERSION if needed.Choose an NFS-backed working directory
Because the training job spans multiple processes that must read and write the same data, container image, and checkpoints, you must place these artifacts on storage that every node in the allocation can see. Select a directory mounted on all nodes. In many SUNK clusters, your home directory suffices. Optionally, you can export overrides for data, checkpoints, and container cache locations. This guide uses the default values, with no overrides, when showing example commands. If you set custom paths, substitute them in the commands below where indicated.Optional: Export your W&B API key
If you set aWANDB_API_KEY, the veRL job logs to W&B automatically. To set your API key, run the following commands:
Create the batch script
The batch script is the entry point for the entire training run. It declares the Slurm resource request, configures the container and Ray environment, prepares the dataset, and launches GRPO training. Create theverl-grpo-qwen3-8B-gsm8k.sbatch script in your working directory:
How the script works
Detailed explanation of how the script works
Detailed explanation of how the script works
SUNK supports running Slurm jobs inside
enroot containers through the Pyxis plugin. Rather than rebuild dependencies each time, the batch script saves a container image locally before launching the training job, or reuses one that already exists. The script uses srun with the --container-image flag pointing to a public veRL base image, already bundled with vLLM, SGLang, and Megatron. Since this container does not include veRL itself, the script clones the veRL repository at the pinned commit and installs the veRL package from source, including the Qwen3-8B training launch script used in this tutorial. The --container-save flag then saves the container image to a local NFS directory.To prepare the dataset, a follow-up srun executes verl/examples/data_preprocess/gsm8k.py, which downloads the GSM8K dataset from Hugging Face and writes train.parquet and test.parquet into DATA_DIR/gsm8k so future runs can reuse the results without re-downloading.The script then starts a Ray head on the first node and workers on the remaining nodes, and exports RAY_ADDRESS so veRL can attach. This pattern mirrors the guidance in the Run Ray on SUNK guide.With the container cached and the dataset ready, the tutorial launches the Qwen3-8B GRPO script with srun on rank 0. veRL’s trainer then uses the previously created Ray cluster to orchestrate processes across the nodes. The script passes config overrides to the trainer as CLI arguments, including input and output paths and a reduced total number of epochs. After the training script completes, it launches a final srun to gracefully tear down the Ray cluster.Submit the job
With the batch script in place, the next step is to hand it to Slurm so the scheduler can allocate the requested nodes and run the workflow. After creating the script, submit the job to Slurm withsbatch, as follows:
- Pull and cache the veRL container.
- Download and preprocess the
GSM8Kdataset, if missing. - Start a Ray cluster inside the allocation.
- Run GRPO training, with 1 epoch by default.
- Write logs and checkpoints to your run directory.
Monitor progress
After submission, the job runs asynchronously on the cluster. The following sections describe how to locate the job, inspect its progress, and find the artifacts it produces.Fetch the job ID
The job ID is the handle Slurm uses to identify your run. Capturing it in an environment variable makes the rest of the monitoring commands easier to copy and reuse. Fetch the Slurm job ID fromsqueue, as follows:
View the job status
Once you have the job ID, you can inspect the status of each step usingsacct, as follows:
srun step in the sbatch script. With sacct, each step appears in its own row, in the following order:
- Container image creation
- Dataset processing
- Ray node startup
- Training job execution
- Ray cluster cleanup
Stream runtime logs
To stream runtime logs, usetail as follows:
View the dataset
TheGSM8K dataset is saved at the following path:
View the run directory artifacts
To view the run directory artifacts, usels as follows:
wandb is likely the only directory you’ll see listed.
Find the W&B link in logs
To find the W&B link in logs, usegrep as follows: