[remat3] re-implement handling of checkpoint_name in custom_vjp fwd - #40309
Closed
mattjj wants to merge 2 commits into
Closed
[remat3] re-implement handling of checkpoint_name in custom_vjp fwd#40309mattjj wants to merge 2 commits into
mattjj wants to merge 2 commits into
Conversation
mattjj
force-pushed
the
push-krlmspyotypy
branch
3 times, most recently
from
August 28, 2026 22:35
c119b98 to
40ef336
Compare
yashk2810
approved these changes
Aug 28, 2026
mattjj
force-pushed
the
push-krlmspyotypy
branch
2 times, most recently
from
August 28, 2026 23:46
5330286 to
1f352de
Compare
Recover the support for policy-driving saving of residuals in custom_vjp fwd rules by using partial eval. This is a much more limited use of partial eval than under remat2, and it's essentially necessary since handling checkpoint_name in custom_vjp fwd rules basically means automatically unzipping the function into a fwd pass and a remat pass. By using the good ol' partial eval machinery, rather than bespoke stuff, regressions and unexpected bugs seem less likely. This complexity, indeed the entire `CustomVJPTraced.remat` method, can be deleted when we migrate users to custom_remat or similar. But for now it's necessary to avoid the regression. We're basically using partial eval to compile a custom_vjp(primal, fwd, bwd) into a custom_remat(primal, fwd', rem, bwd). One diff from the remat2 behavior is that this doesn't work with symbolic_zeros=True on custom_vjp. It essentially can't because with remat3 we're doing the remat pass *before* autodiff, ie here we need to trace (and then unzip) the fwd during the remat pass, and the symbolic zeros information is only available during autodiff. An error is raised rather than silent failure.
mattjj
force-pushed
the
push-krlmspyotypy
branch
from
August 29, 2026 19:13
bd4e6d0 to
c0485e0
Compare
Collaborator
Author
|
I'm going to split this change into multiple PRs. |
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
2 participants
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.
Recover the support for policy-driving saving of residuals in custom_vjp fwd rules by using partial eval. This is a much more limited use of partial eval than under remat2, and it's essentially necessary since handling checkpoint_name in custom_vjp fwd rules basically means automatically unzipping the function into a fwd pass and a remat pass. By using the good ol' partial eval machinery, rather than bespoke stuff, regressions and unexpected bugs seem less likely.
This complexity, indeed the entire
CustomVJPTraced.rematmethod, can be deleted when we migrate users to custom_remat or similar. But for now it's necessary to avoid the regression.One diff from the remat2 behavior is that this doesn't work with symbolic_zeros=True on custom_vjp. It essentially can't because with remat3 we're doing the remat pass before autodiff, ie here we need to trace (and then unzip) the fwd during the remat pass, and the symbolic zeros information is only available during autodiff. An error is raised rather than silent failure.
Another issue here is we re-trace the fwd rule on each application of a rematted function. Again, that'll just disappear.
The numbers correspond to sections of custom_vjp_fwd_unzip_demos.py. I'm just leaving it here for my own future reference.