-
Notifications
You must be signed in to change notification settings - Fork 608
Remove exception fall back on checkpoint loading #9660
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9660
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit aea9736 with merge base 07266f9 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
# Also, the checkpoint is loaded and dtype promoted to the transformer's dtype, which is | ||
# by default initialized to fp32. This is fine because every other supported type | ||
# losslessly converts to fp32, so we don't lose precision here. | ||
if checkpoint: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea i like this. If the user gives a checkpoint that doesn't work, we should fail, and not hide it under the rug and give them uninitialized model
@jackzhxng has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@jackzhxng has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
### Summary Remove the crutch of initializing with 0 weights when the checkpoint loading goes wrong (e.g. in most cases when the checkpoint keys don't match the parameters of the model). ### Test plan See if CI passes
Summary
Remove the crutch of initializing with 0 weights when the checkpoint loading goes wrong (e.g. in most cases when the checkpoint keys don't match the parameters of the model).
Test plan
See if CI passes