fix: clamp max_new_tokens on retry to prevent response_length overflow#2003
Open
YaoweiFan wants to merge 1 commit into
Open
fix: clamp max_new_tokens on retry to prevent response_length overflow#2003YaoweiFan wants to merge 1 commit into
YaoweiFan wants to merge 1 commit into
Conversation
ABORTED samples are pushed back into the data buffer by fully_async_rollout's done callback and re-picked by the worker, but their sample.tokens / response_length carry over the partial output from the first attempt. Meanwhile the per-call sampling_params is a shallow copy of GenerateState.sampling_params, whose max_new_tokens is fixed at args.rollout_max_response_len and never decremented. On retry sglang sees a new context and generates up to another full rollout_max_response_len tokens, so sample.response_length += new_tokens can climb to ~2x the configured cap (or higher across retry chains), breaking the training-side per-GPU token budget. Clamp max_new_tokens to (rollout_max_response_len - response_length) at the entry of generate(), and mark the sample TRUNCATED when the budget is already exhausted. Mirrors the retool multi-turn fix in THUDM#1861. Symptoms previously surfaced as the loss_mask/response_length mismatch in THUDM#1440 (response_len/max=16384 with rollout_max_response_len=8192) and the partial-resume TODO noted in examples/fully_async/README.md after THUDM#1920.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ABORTED samples are pushed back into the data buffer by
fully_async_rollout's done callback and re-picked by the worker, but theirsample.tokens/response_lengthcarry over the partial output from the first attempt. Meanwhile the per-callsampling_paramsis a shallow copy ofGenerateState.sampling_params, whosemax_new_tokensis fixed atargs.rollout_max_response_lenand never decremented. On retry sglang sees a new context and generates up to another fullrollout_max_response_lentokens, sosample.response_length += new_tokenscan climb to ~2x the configured cap (or higher across retry chains), breaking the training-side per-GPU token budget.This PR clamps
max_new_tokensto(rollout_max_response_len - response_length)at the entry ofgenerate(), and marks the sampleTRUNCATEDwhen the budget is already exhausted. Mirrors the retool multi-turn fix in #1861.