Skip to main content
This guide shows you how to run Group Relative Policy Optimization (GRPO) training with veRL on SUNK using the Qwen3 8B model. GRPO is a reinforcement learning technique for fine-tuning large language models on reasoning tasks, and veRL provides a trainer that scales across multiple GPUs with Ray. By the end of this tutorial, you have a reproducible Slurm batch script that pulls the veRL container, preprocesses the GSM8K dataset, launches a Ray cluster on SUNK, and runs GRPO training end-to-end. This guide is intended for ML practitioners who already have access to a SUNK cluster and want to run GRPO experiments without assembling the toolchain themselves. The provided Slurm script handles container setup, dataset preparation, and Ray orchestration. It also writes logs and checkpoints to a run directory, and automatically logs to Weights & Biases if you provide a 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_KEY to 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)
Override through 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 a WANDB_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 the verl-grpo-qwen3-8B-gsm8k.sbatch script in your working directory:

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.
After saving the file, you have a self-contained batch script that encodes the full GRPO training workflow and is ready to submit to Slurm.

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 with sbatch, as follows:
Once submitted, the job performs the following steps:
  1. Pull and cache the veRL container.
  2. Download and preprocess the GSM8K dataset, if missing.
  3. Start a Ray cluster inside the allocation.
  4. Run GRPO training, with 1 epoch by default.
  5. 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 from squeue, as follows:

View the job status

Once you have the job ID, you can inspect the status of each step using sacct, as follows:
This outputs the status of each srun step in the sbatch script. With sacct, each step appears in its own row, in the following order:
  1. Container image creation
  2. Dataset processing
  3. Ray node startup
  4. Training job execution
  5. Ray cluster cleanup

Stream runtime logs

To stream runtime logs, use tail as follows:

View the dataset

The GSM8K dataset is saved at the following path:

View the run directory artifacts

To view the run directory artifacts, use ls as follows:
Before a checkpoint is written, wandb is likely the only directory you’ll see listed. To find the W&B link in logs, use grep as follows:
The job can take about 15 minutes to reach the W&B initialization step. Once initialized, the W&B project and run URLs print in the logs and resemble the following:

Example outputs

The following examples show what a successful run produces on disk and in the logs, so you can confirm your own run matches the expected shape.

Directories created

Sample log excerpt

Last modified on May 27, 2026