Add time/per_group_wall_time metric

[finbarrtimbers]

Summary

• Adds a new time/per_group_wall_time metric: the mean of per-group generation wall-clock times across the batch.
• Distinct from existing time/getting_response, which is the max of per-group times and gets dominated by tail-inflated groups when many requests are in flight (high --num_async_steps, many engines, etc.).
• Underlying timestamps are already captured (metadata["start_time"] in add_request; current_time in finalize_completed_request); per-group generation_time is already on TokenStatistics. This change just plumbs the mean through make_batch_from_groups and emits it as a new metric.

Applies to both grpo_fast.py and grpo.py since they share DataPreparationActor.

Test plan

• scripts/train/debug/single_gpu_grpo.sh succeeds; time/per_group_wall_time appears in wandb.
• scripts/train/qwen/qwen3_4b_dapo_math_oc.sh (50 steps): inspect time/per_group_wall_time vs time/getting_response; mean should be <= max.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces the time/per_group_wall_time metric, which calculates the mean generation time across a batch to provide a more consistent timing signal. The implementation updates the TokenStatistics data structure, the data loader's batch aggregation logic, and the training loop's metric logging. Review feedback suggests moving the changelog entry to the 'Added' section for better organization and optimizing the mean calculation by using a running sum instead of a list to improve memory efficiency and simplify the code.

[hamishivi]

would median or mean be better? I worry about weird outlier group times?

[finbarrtimbers]

I like mean for exactly that reason, it'll capture the aggregate times. I worry with the median we won't see the worst times.