[kekellllll]

Summary

The student log_softmax + gather pattern in verl/trainer/distillation/fsdp/losses.py
materializes a full [N, V] tensor before reducing to top-K. For long-context distillation
(64K+ tokens with V=152064 Qwen vocab), this single line allocates ~28 GB persistent
memory in bf16, dominating the activation budget and causing OOM.

This PR replaces the line with a mathematically equivalent chunked computation that:

• Uses the identity log_softmax(x).gather(idx) ≡ x.gather(idx) - logsumexp(x, keepdim=True)
• Streams the reduction in chunks of 4K tokens along the (B*T) dimension
• Casts to fp32 inside the chunk for numerical stability, returns to original dtype

The optimization pattern is already used elsewhere in verl (see verl/utils/torch_functional.py
which has a chunked log-probs implementation with the comment "avoid creating full log_softmax
tensors in memory"). This PR brings the same optimization to the distillation top-K path,
which was missed when the distillation module was added.

Opt-in design (added in latest commit): the chunked path is gated behind
distillation.distillation_loss.use_chunked_topk=True (default False) to preserve the
pre-PR latency at short context. Short-context users see no behavior change; long-context
users opt in to trade time for memory headroom.

Scope (which OOM tier this PR addresses)

compute_forward_kl_topk allocates two [B, T, V] peaks. This PR eliminates one of them:

Tier	Tensor	Where allocated	Memory at V=152K, N=96K	Status
1	student_logits	prepare_model_outputs (caller)	~28 GB	Out of scope (requires LM-head skip; follow-up PR)
2	log_softmax(logits) buffer	inside the loss fn	~20 GB at N=64K	Eliminated by this PR (when use_chunked_topk=True)

Users hitting OOM at the log_softmax allocation get full relief. Users hitting OOM at the upstream student_logits allocation itself will need the follow-up.

Benchmark (single H20, V=152064, K=64, bf16, fwd+bwd, chunk_size=4096)

Measured with compute_forward_kl_topk's inner _chunked_topk_log_probs in isolation, comparing to the pre-PR baseline (F.log_softmax + gather):

context (B,T,V)	baseline (default)	chunked (use_chunked_topk=True)
short (1, 14336, 152064)	21.81 GB / 16.3 ms	30.53 GB / 94.8 ms (+40% peak, +482% time)
mid (1, 64512, 152064)	OOM at student_logits + log_softmax	79.78 GB / 556.9 ms (only path that runs)
long (1, 96256, 152064)	OOM (tier-1 student_logits)	OOM (tier-1, requires follow-up PR)

Reading the table:

• Short context: baseline is 6x faster and 40% lighter than chunked. This is why the chunked path is opt-in (default False) -- short-context users see zero behavior change.
• Mid context (~64K): baseline OOMs because tier-2 log_softmax buffer (~20 GB) plus tier-1 student_logits (~20 GB) cannot fit alongside FSDP weights/grads/optim state. Chunked path eliminates the tier-2 buffer and runs at 79.78 GB peak. This is the regime this PR targets.
• Long context (>=96K): both paths OOM at the upstream student_logits allocation itself, before either log_softmax path runs. This requires a separate refactor (_forward_skip_lm_head + chunk over hidden_states) tracked as future work.

Numerical equivalence (vs fp64 reference, bf16 input)

Same inputs as benchmark, B=1 T=512 to keep memory in fp64 reference small:

implementation	max abs diff vs fp64 reference
baseline (F.log_softmax + gather)	3.12e-2 (~bf16 noise floor)
chunked (_chunked_topk_log_probs, fp32 cast inside chunk)	3.12e-2 (identical to baseline)

Chunked path matches baseline exactly at bf16 precision because the explicit .float() cast inside each chunk preserves the same fp32 reduction PyTorch's F.log_softmax does internally. This is consistent with the verl/utils/torch_functional.py chunked log-probs convention.

Motivation

Background

In OPD (On-Policy Distillation) with top-K teacher logits, the student-side loss computation
needs both:

1. student_log_probs.gather(target_ids) — used in policy gradient
2. student_log_probs.gather(teacher_topk_ids) — used in KL distillation

Both gathers reuse the same student_log_probs, forcing the [N, V] tensor to persist in
memory rather than be freed as a transient.

The OOM

For Qwen-class models with V = 152064 and remove-padding enabled:

N (concatenated valid tokens) ~= batch_size * num_rollouts * mean_seq_len / world_size

At 64K context, mini_batch=2, n=4, world_size=8:
  N ~= 2 * 4 * 60K / 8 ~= 60K tokens
  [N, V] in bf16 = 60K * 152K * 2 bytes ~= 18 GB persistent

At 96K effective tokens: ~= 28 GB persistent

This single allocation dominates a 96 GB H20 / 141 GB H200 GPU when combined with FSDP
weight shards, gradient shards, and activation memory.

Why this matters

Long-context distillation is becoming standard for agent/coding/long-trace tasks (32K-256K
context). Without this fix, the only workarounds are:

• Reduce context length (defeats the purpose)
• Add nodes for SPREAD topology (expensive, not always available)
• Disable colocated rollout (reduces throughput)

Solution

Mathematical equivalence

log_softmax(x)[i] = x[i] - logsumexp(x)
log_softmax(x).gather(idx) = x.gather(idx) - logsumexp(x, keepdim=True)

Since softmax reduces only along the vocab dimension, computation is independent across
the (B*T) dimension. We can chunk along this axis without affecting numerics.

Implementation

def _chunked_topk_log_probs(
    logits: torch.Tensor,    # [B, T, V]
    topk_ids: torch.Tensor,  # [B, T, K]
    chunk_size: int = 4096,
) -> torch.Tensor:
    B, T, V = logits.shape
    K = topk_ids.shape[-1]
    flat_logits = logits.reshape(-1, V)      # [N, V]
    flat_topk = topk_ids.reshape(-1, K)       # [N, K]
    out = torch.empty((flat_logits.shape[0], K),
                      dtype=logits.dtype, device=logits.device)
    for s in range(0, flat_logits.shape[0], chunk_size):
        e = min(s + chunk_size, flat_logits.shape[0])
        chunk = flat_logits[s:e].float()                       # fp32 stable
        log_z = torch.logsumexp(chunk, dim=-1, keepdim=True)
        out[s:e] = (chunk.gather(dim=-1, index=flat_topk[s:e])
                    - log_z).to(logits.dtype)
    return out.reshape(B, T, K)

The change in losses.py replaces a 2-line log_softmax + gather with a single call to
this helper.

Related work

This optimization belongs to the well-established online softmax family
(Milakov & Gimelshein, NVIDIA 2018):

• FlashAttention (Dao et al., 2022): streams softmax over the K/seq dimension of attention
• Liger Kernel (LinkedIn, 2024): FusedLinearCrossEntropy chunks LM head loss
• Cut Cross Entropy / CCE (Apple ML, 2024, arxiv 2411.09009): more aggressive variant
• verl utils/torch_functional.py: chunked log-probs already implemented, just not
  used in the distillation path (this PR's motivation)

This PR is the conservative middle ground: minimal code change, no Triton kernel needed,
fully PyTorch-native, drop-in compatible.

Testing

Numerical equivalence (vs torch.log_softmax(...).gather(...))

Tested on a single H20 GPU (PyTorch 2.8.0+cu126):

dtype	shape (B, T, V, K)	max |diff|	mean abs	tolerance
float32	(2, 64, 152064, 64)	1.907e-6	3.29e-7	5e-6 ✅
float32	(2, 256, 152064, 64)	1.907e-6	3.38e-7	5e-6 ✅
float32	(1, 4096, 152064, 64)	1.907e-6	3.37e-7	5e-6 ✅
bfloat16	(2, 64, 152064, 64)	0.000e+0	0	5e-3 ✅
bfloat16	(2, 256, 152064, 64)	0.000e+0	0	5e-3 ✅
bfloat16	(1, 4096, 152064, 64)	0.000e+0	0	5e-3 ✅
float16	(2, 64, 152064, 64)	0.000e+0	0	1e-3 ✅
float16	(2, 256, 152064, 64)	0.000e+0	0	1e-3 ✅
float16	(1, 4096, 152064, 64)	7.81e-3	2.98e-8	1e-2 ✅

Notes:

• fp32: max diff 1.91e-6 is within the expected precision of PyTorch's fused
  log_softmax kernel vs explicit logsumexp (mantissa ~1.2e-7 scaled by logits
  magnitude ~10).
• bf16: identically 0 across all tested shapes — both PyTorch's fused kernel
  and our chunked implementation internally upcast to fp32, then cast back to
  bf16 (7-bit mantissa truncates to identical bits).
• fp16: identically 0 in most cases; occasional max diff up to ~8e-3 in
  long-sequence cases due to fp16 range limits (max ±65504), where PyTorch's
  fused vs explicit logsumexp paths produce slightly different rounding at
  edge values. Mean absolute diff remains ~3e-8, indicating only a handful of
  affected indices. This is orthogonal to chunking (same diff appears with
  chunk_size = N). Modern LLM training uses bf16, so fp16 edge behavior should
  not affect production runs.

Chunk size invariance

Verified that chunk_size in {1, 64, 256, 1024, 4096, 16384} all produce identical
results vs the un-chunked baseline (max diff <= 1.91e-6).

Backward / gradient correctness

Compared out.sum().backward() gradients of logits.grad:

fp32 max grad diff vs reference: 2.38e-7 (atol 1e-5 ✅)

Memory benchmark (B=1, T=N, V=152064, K=64, bf16, double-gather pattern)

Reproducing the OPD memory pattern (log_probs_all materialized for two gathers):

seq len	Reference peak	Chunked peak	Saving
16K	1.2 GB	5.0 GB	-3.7 GB ⚠️
32K	2.5 GB	5.0 GB	-2.5 GB ⚠️
64K	5.0 GB	5.0 GB	0 (break-even)
128K	10.0 GB	5.0 GB	+5.0 GB (50%) ✅

Honest caveat: with the default chunk_size=4096, fp32 chunk buffer (~2.5 GB) is
fixed overhead. For T < 64K under this benchmark shape, chunked is slightly worse.
Real-world distillation runs hit the savings because: (a) N is the concatenated
valid token count after remove-padding, often much larger than per-sample T; (b) the
double-gather pattern forces the reference path to persist log_probs_all, while
chunked never materializes it.

A larger chunk_size (e.g. 16384) makes chunked match reference at all seq lengths.
We picked 4096 as a balance; users can tune via configuration if needed.

Speed

forward only, B=1, T=4096, V=152064, K=64, bf16:
  reference (log_softmax + gather):  1.7 ms
  chunked (chunk_size=4096):        11.7 ms
  overhead:                         +10 ms

In end-to-end distillation training, this is <0.5% of step time (typical step
time 30-70s with vLLM rollout + FSDP backward + optimizer).

Real-world validation

We ran the patched verl in two production setups:

1. 7B-yarn 125K context, 2-node setup: 5/5 step completed, 207 tok/s throughput,
   no OOM. Without chunked, the same configuration cannot start training (vLLM init
   passes but first step's distillation forward exceeds memory budget).

2. 72B + 64K context, 2-node colocated rollout: chunked path passes; the run later
   hit a separate OOM caused by colocated vLLM sibling process (8.58 GB) plus FSDP
   weight unsharding, unrelated to chunked patch. Without chunked, the run wouldn't
   even reach step 1 because log_softmax's 70+ GB allocation alone would fail.

This is consistent with the math: chunked patch removes the [N, V] persistent
allocation; downstream memory pressure (FSDP unshard, vLLM colocate) is orthogonal.

Backward compatibility

• ✅ No change to losses.py API
• ✅ No change to model checkpoints / config schema
• ✅ No new dependencies
• ✅ Identical loss values (within fp32 mantissa precision)
• ✅ Identical gradients (verified within 2.38e-7)

The change is a drop-in internal optimization. Users do not need to update anything.

Future work (out of scope)

• Tier-1 student_logits elimination (follow-up PR): skip the LM head in
  prepare_model_outputs and compute log-probs chunked directly from
  (hidden_states, lm_head_weight) -- avoids the upstream [B, T, V] materialisation
  and brings the loss-side peak from ~28 GB to ~0. Touches the FSDP unshard
  lifecycle, so kept separate from this PR.
• Make chunk_size configurable via distillation.distillation_loss.chunk_size
  (currently hardcoded at 4096)
• Investigate Liger-kernel-style fused Triton implementation for further savings
• Apply same pattern if loss_mode=k2 introduces a similar bottleneck

Checklist

• Code follows existing style (no Triton, pure PyTorch)
• Mathematically equivalent to original
• Unit test for numerical equivalence (5 dtype/shape cases)
• Unit test for chunk_size invariance
• Unit test for gradient correctness
• Memory benchmark
• Speed benchmark
• Validated end-to-end on 7B (125K) and 72B (64K)
• No external API changes
• No checkpoint format changes

---

Files changed

verl/trainer/distillation/fsdp/losses.py    # 1 line replaced + helper added

(Optional second commit, if maintainer prefers: extract _chunked_topk_log_probs to
verl/utils/torch_functional.py to live alongside the existing chunked log-probs
helper. Happy to do this in a follow-up.)

---

Reproducer (for reviewer)

import torch
import torch.nn.functional as F

def reference(logits, topk_ids):
    log_probs = F.log_softmax(logits, dim=-1)
    return torch.gather(log_probs, dim=-1, index=topk_ids)

def chunked(logits, topk_ids, chunk_size=4096):
    B, T, V = logits.shape
    K = topk_ids.shape[-1]
    flat_l = logits.reshape(-1, V)
    flat_t = topk_ids.reshape(-1, K)
    out = torch.empty((flat_l.shape[0], K), dtype=logits.dtype, device=logits.device)
    for s in range(0, flat_l.shape[0], chunk_size):
        e = min(s + chunk_size, flat_l.shape[0])
        chunk = flat_l[s:e].float()
        log_z = torch.logsumexp(chunk, dim=-1, keepdim=True)
        out[s:e] = (chunk.gather(-1, flat_t[s:e]) - log_z).to(logits.dtype)
    return out.reshape(B, T, K)

torch.manual_seed(42)
logits = torch.randn(2, 256, 152064, dtype=torch.float32, device='cuda')
topk = torch.randint(0, 152064, (2, 256, 64), device='cuda')

ref = reference(logits, topk)
out = chunked(logits, topk)
print(f"max abs diff: {(ref - out).abs().max().item():.2e}")
# Expected: ~1.9e-6

[gemini-code-assist]

Code Review

This pull request introduces a memory optimization in compute_forward_kl_topk by avoiding the materialization of the large [B, T, V] student log probabilities tensor. It implements a chunked helper, _chunked_topk_log_probs, to compute gathered log probabilities, and adds corresponding unit tests. The reviewer identified a critical issue in the helper where pre-allocating a tensor and performing in-place slice assignments can disrupt PyTorch's autograd gradient propagation, and provided a code suggestion to accumulate chunks and use torch.cat instead.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[kekellllll]

Thanks for the careful review! I want to address the autograd concern, since I think there's a misconception worth clarifying for anyone reading this thread later.

The autograd claim is incorrect. torch.empty(...) followed by in-place slice assignment out[s:e] = ... is fully supported by PyTorch's autograd: Tensor.__setitem__ dispatches to the differentiable aten.index_put_ op, and out becomes a non-leaf tensor with grad_fn=<CopySlices>. Gradients propagate correctly back to logits.

I verified this on CUDA (PyTorch 2.8.0+cu126):

>>> out = torch.empty((N, K), ...)
>>> # before slice assigns: is_leaf=True,  requires_grad=False, grad_fn=None
>>> for s in range(0, N, chunk_size):
...     out[s:e] = (chunk_topk_logits - log_z).to(...)
>>> # after slice assigns:  is_leaf=False, requires_grad=True,  grad_fn=<CopySlices>
>>>
>>> out.sum().backward()
>>> # logits.grad is non-None, finite, non-zero
>>> # max diff vs F.log_softmax(logits, -1).gather(-1, topk_ids) gradient: 7.45e-08
>>> # max diff vs torch.cat-based variant gradient:                       0.00e+00

This is also covered by:

• test_gradient_correctness (already in the PR): forward 9.5e-7, backward 7.5e-8 vs the standard F.log_softmax + gather reference.
• test_gradient_flows_through_slice_assignment (just added): explicit regression guard asserting out.is_leaf == False, out.grad_fn == CopySlices, and that logits.grad is finite and non-zero.

Why I prefer torch.empty + slice over torch.cat:

• torch.empty + slice: peak memory = 1× output (chunks freed as they're written).
• torch.cat(chunks, dim=0): peak memory = 2× output (all chunks kept alive until concat).

Since this PR exists specifically to reduce memory at long context, the lower-peak version is preferred.

The if N == 0 edge case is a great suggestion — accepted, just pushed. Also added the explicit gradient-flow regression test, so future readers don't need to rediscover this.

Updated commit: 072cf9b (force-pushed). 16/16 unit tests pass.

[kekellllll]

Update: chunked path is now opt-in (commit 73dd434)

Following the discussion above re: the tier-2 / tier-1 split, I've made the chunked path opt-in via a config flag, defaulting to False. The default behavior is now identical to the pre-PR F.log_softmax + gather, so short-context users see zero regression. Long-context users opt in via:

distillation:
  distillation_loss:
    use_chunked_topk: true
    chunked_topk_chunk_size: 4096   # tunable; default 4096

Why opt-in

Benchmarked the chunked vs baseline paths on H20 (V=152064, K=64, bf16, fwd+bwd):

context	baseline	chunked
short (N=14K)	21.8 GB / 16.3 ms	30.5 GB / 94.8 ms (+40% peak, +482% time)
mid (N=64K)	OOM	79.8 GB / 556 ms (only path that runs)
long (N=96K)	OOM (tier-1)	OOM (tier-1)

A note on the +482% short-context time figure -- it's the function in
isolation. In a real training step the function accounts for only a small
fraction:

In our production OPD setup (Qwen-7B, FSDP-8, real prompt length 64K):

• Total step time: ~225s
• update_actor: ~108s (48%)
  • transformer fwd+bwd: ~80-90s
  • lm_head + log_softmax + gather: ~5-15s <- where this function sits
• rollout (vLLM gen): ~50s
• update_weights / others: ~67s

So _chunked_topk_log_probs is ~2-5% of total step time. With the +482%
local slowdown, the worst-case step time impact is +1-3%, and only when
use_chunked_topk=True is explicitly enabled (which a user would only
do if they're hitting OOM at long context, where the alternative is the
training failing entirely).

In the current agent scenario, long trajectory situations often exceed 64k, which is very necessary, and it only increases the total training time by 1% to 3%.

For default users (use_chunked_topk=False), there is zero impact.

The 6x time overhead at short context is too high to make the chunked path the default, but the OOM relief at mid context (~64K) is exactly what some users need. Opt-in solves both: short-context users keep their current performance; long-context users get a path that runs.

What I added

• DistillationLossConfig.use_chunked_topk: bool = False
• DistillationLossConfig.chunked_topk_chunk_size: int = 4096
• Branch in compute_forward_kl_topk: default → F.log_softmax + gather (pre-PR baseline); opt-in → _chunked_topk_log_probs (this PR's helper, unchanged from previous commits).

What I didn't change

• _chunked_topk_log_probs itself: unchanged, all 16 existing unit tests still pass.
• Pre-existing baseline behaviour: bit-identical to before this PR (verified: same exact ops, same dtype path).
• PR description: updated with the full benchmark table and the opt-in semantics; please re-skim the "Benchmark" section.

Re: tier-1 (student_logits materialisation)

Still out of scope for this PR -- I'll open a follow-up that skips the LM head in prepare_model_outputs and chunks over hidden_states directly, so neither [B, T, V] peak materialises. That's the path needed for the long (>=96K) tier where both implementations here still OOM.

[kekellllll]

Hi Tianle, #6593 Thank you for the feedback. I have updated the comments in the PR as suggested, streamlining the inline notes and cleaning up the developer comments to improve readability. Could you please take another look at the latest changes? If everything looks good on your end, I would appreciate it if you could invite the lead reviewer to move forward with the final review so we can complete the process. Best regards, Zifeng Wang

…

On Sun, Jun 7, 2026 at 7:49 AM 鐘天楽 ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In verl/trainer/distillation/fsdp/losses.py <#6593 (comment)>: > @@ -63,12 +115,47 @@ def compute_forward_kl_topk( assert teacher_topk_log_probs.shape[:2] == teacher_topk_ids.shape[:2] == student_logits.shape[:2] # 2. compute token-wise KL divergence across sp groups - student_log_probs = F.log_softmax(student_logits, dim=-1) - student_topk_ids = torch.topk(student_log_probs, k=teacher_topk_ids.shape[-1], dim=-1).indices - student_topk_log_probs = torch.gather(student_log_probs, dim=-1, index=teacher_topk_ids) + # Two paths, controlled by ``loss_config.use_chunked_topk``: we can concise the inline comments to make it easier to read ------------------------------ In verl/trainer/distillation/fsdp/losses.py <#6593 (comment)>: > + # upstream ``student_logits`` allocation (tier-1, ~28 GB at N=96K) is + # still materialised by the caller; eliminating that requires a separate + # ``forward``-side refactor (skip LM head, chunk over hidden_states), + # tracked as future work. + loss_config: DistillationLossConfig = config.distillation_loss + if loss_config.use_chunked_topk: + # log_softmax is monotonic, so topk(log_softmax(x)) == topk(x); use + # student_logits directly to avoid the extra [B, T, V] log_softmax. + student_topk_ids = torch.topk(student_logits, k=teacher_topk_ids.shape[-1], dim=-1).indices + student_topk_log_probs = _chunked_topk_log_probs( + student_logits, + teacher_topk_ids, + chunk_size=loss_config.chunked_topk_chunk_size, + ) + else: + # Baseline path -- unchanged from the pre-PR implementation. Lowest clean up this dev comment ------------------------------ In verl/trainer/distillation/fsdp/losses.py <#6593 (comment)>: > @@ -23,6 +23,58 @@ from verl.workers.config import DistillationConfig, DistillationLossConfig + +def _chunked_topk_log_probs( + logits: torch.Tensor, + topk_ids: torch.Tensor, + chunk_size: int = 4096, +) -> torch.Tensor: + """Compute log_softmax(logits).gather(topk_ids) without materializing [B, T, V]. + + Uses the identity: + log_softmax(x).gather(idx) == x.gather(idx) - logsumexp(x, keepdim=True) + Streams the reduction in chunks of `chunk_size` tokens along (B*T) with fp32 + logsumexp for numerical stability. Mathematically equivalent to the direct + formulation; max diff ~1.9e-6 in fp32, exact (max diff = 0) in bf16. + + Note on autograd: `out = torch.empty(...)` followed by `out[s:e] = ...` is not necessary comments — Reply to this email directly, view it on GitHub <#6593?email_source=notifications&email_token=BHZJA3VYFKBJCSORRT7F5BD46SUXXA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINBUGQYDGOBUGY22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4444038465>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BHZJA3VPUNPHCMKCJG354AL46SUXXAVCNFSM6AAAAACZY2HVJSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DINBUGAZTQNBWGU> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BHZJA3ULMMJL3IFTFFJV2KT46SUXXA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINBUGQYDGOBUGY22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/BHZJA3UB25CY66VXOIBRZKL46SUXXA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINBUGQYDGOBUGY22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[Luosuu]

@kekellllll please fix pre-commit.

[kekellllll]

Done in e088d91 — applied ruff check --fix + ruff format to the two changed files (5 insertions, 7 deletions, all whitespace / import-sort / assert-line cosmetics, no behavior change). 16 unit tests still pass.

[kekellllll]

Hi Luosuu, Thank you for the reminder. I have fixed the pre-commit issues as requested. Could you please approve and trigger the tests again? Best regards, Zifeng Wang ***@***.***

…

On Tue, Jun 9, 2026 at 2:34 PM 鐘天楽 ***@***.***> wrote: *Luosuu* left a comment (verl-project/verl#6593) <#6593 (comment)> @kekellllll <https://github.com/kekellllll> please fix pre-commit. — Reply to this email directly, view it on GitHub <#6593?email_source=notifications&email_token=BHZJA3UTBXV4AJXHWAWGEYT466VXLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRVGY3TSOBZHAYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4656798980>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BHZJA3T6BJVYOSIRU5NT7QL466VXLAVCNFSM6AAAAACZY2HVJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DMNJWG44TQOJYGA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BHZJA3W63J53GQE2HYL7ZGD466VXLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRVGY3TSOBZHAYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BHZJA3XYH2JBXORM4OFD47D466VXLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRVGY3TSOBZHAYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>