Skip to content

fix(algorithms): honour the configured KL clamps in the reward-side KL - #3853

Open
tianyi-zhang-02 wants to merge 1 commit into
NVIDIA-NeMo:mainfrom
tianyi-zhang-02:fix-reward-kl-clamp
Open

tianyi-zhang-02 wants to merge 1 commit into
NVIDIA-NeMo:mainfrom
tianyi-zhang-02:fix-reward-kl-clamp

Conversation

@tianyi-zhang-02

@tianyi-zhang-02 tianyi-zhang-02 commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Makes reward-side KL calculations honor loss_fn.kl_input_clamp_value and loss_fn.kl_output_clamp_value.

Both reward-based advantage estimators already read the KL coefficient and approximation type from ClippedPGLossConfig, but their calls to calculate_kl omitted the two clamp values. A configured clamp therefore affected the loss-side KL while reward-side KL silently used the function defaults.

The test inputs use non-uniform policy/reference divergence because a constant KL disappears during final advantage normalization and would not detect this regression.

Validation

Current head 1e7d3121b001782acd8ed77a115a474051031216, rebased onto upstream main at 90a2a212d503455d8590be5c8de3cb989d3425b0.

  • tests/unit/algorithms/test_reward_kl_clamp.py + tests/unit/algorithms/test_grpo.py: 171 passed
  • caller-level tensor coverage proves each configured clamp changes the computed advantages
  • Ruff check, Ruff format check, and git diff --check: passed

These are CPU tensor-math regressions; no GPU workload is required.

@tianyi-zhang-02
tianyi-zhang-02 requested review from a team as code owners August 26, 2026 18:43
@copy-pr-bot

copy-pr-bot Bot commented Aug 26, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@svcnvidia-nemo-ci svcnvidia-nemo-ci added the waiting-on-maintainers Waiting on maintainers to respond label Aug 28, 2026
Under use_kl_in_reward, GeneralizedAdvantageEstimator and
ReinforcePlusPlusAdvantageEstimator both call calculate_kl without
input_clamp_value / output_clamp_value, so the user's configured values are
silently replaced by the function defaults (20.0 / 10.0).

They already read reference_policy_kl_penalty and reference_policy_kl_type
off the same ClippedPGLossConfig that carries the two clamps, and
ClippedPGLossFn passes both through -- so setting kl_output_clamp_value moves
the loss-side KL and leaves the reward-side one alone. Same config, same
approximation, two different bounds, no error.

Tests are CPU-only. Note what they had to do to be non-vacuous: both
estimators normalize the advantage globally at the end, so a KL that is
constant across the batch normalizes away to zeros whatever the clamp does.
The reference has to diverge by a different amount at each position for the
clamp to be observable at all.

Mutation-tested: dropping the two kwargs from either call site, and hardcoding
a clamp to its old default, each turn one of these red.

Signed-off-by: Tianyi Zhang <zhangtianyi975@gmail.com>
Signed-off-by: Tianyi Zhang <123608656+tianyi-zhang-02@users.noreply.github.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community-request waiting-on-maintainers Waiting on maintainers to respond

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants