Repository navigation
[1/3] Run GPTQ on HF fused MoE experts #2840
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
Merged
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
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.
[P1] Persist GPTQ updates for native FP8 experts
Could we ensure the expert weights passed to
update_weights()are persistent, writable model weights? Native_QuantFP8Expertsalso enters this path, but its inheritediter_weights_for_calibration()callsget_expert_weight(), which returns a newly allocated, scaled/dequantized tensor for FP8-backed parameters.update_weights()copies the GPTQ result into that temporary; neither the stored FP8 parameter nor its scales are updated. The next forward/export dequantizes the original weights again, silently losing the GPTQ result.I reproduced this on CPU with Transformers 5.18
FP8Experts(two experts, hidden/intermediate size 256, native FP8 blocks 128x128) and INT4 GPTQ (128-column groups). Starting from max calibration, then runningmtq.calibrate(..., algorithm={"method": "gptq", "block_size": 128, "perc_damp": 0.01}, forward_loop=...), all four projections report successful GPTQ updates with 96 routed tokens each, but their dequantized weights and model predictions remain exactly unchanged. Callingunpack_weight()before the same GPTQ calibration makes the updates persist and changes predictions.Please materialize persistent floating-point weights under the appropriate weight-access/writeback context, or otherwise explicitly persist the optimized result in the representation used by subsequent inference/export. A regression test using native
FP8Expertsand comparing against its unpacked equivalent would catch this; the current floating-point toy experts always return views and cannot exercise the issue.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.
Thanks, reproduced. With Transformers 5.18
FP8Experts, the stored weights stay unchanged after GPTQ, and after imatrix too, since imatrix makes the same in-place write throughiter_weights_for_calibration(). Afterunpack_weight(), both updates persist.cedb19e makes GPTQ and imatrix refuse fused experts that store a projection they would update in 8 bits. They raise a
ValueErrorasking forunpack_weight()before any calibration state changes, the same contractfold_weightalready enforces.test_native_fp8_experts_reject_packed_weight_updateschecks both methods: the refusal leaves the state untouched, and the updates persist once the experts are unpacked.I chose refusing over unpacking inside calibration because
unpack_weight()swaps the parameters for float copies. I'd rather not do that implicitly where layerwise and offload contexts manage those parameters.