You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
input_projections are not registered as PyTorch modules, causing missing parameters and CUDA device mismatch #49698
Transformers: Issue confirmed in the source code of v5.20.0.
Who can help?
No response
Reproduction
In Hugging Face Mask2Former, input_projections is a regular Python list instead of nn.ModuleList. As a result, projection parameters are not registered, excluded from optimizers, and not moved to CUDA.
The input_projections layers should be registered using nn.ModuleList, as in the original Facebook implementation.
This ensures that their parameters are included in model.parameters(), optimizers, and state_dict(), and are correctly moved to the target device using model.to(device).
Suggested fix:
Replace self.input_projections = [] with self.input_projections = nn.ModuleList().
I opened PR #49703 with the fix: self.input_projections = [] → nn.ModuleList() in Mask2FormerTransformerModule, matching the pixel decoder's existing pattern and the original Meta implementation, plus a regression test asserting the projection parameters are registered (visible in state_dict()/named_parameters()) with enforce_input_projection=True. @akhil9tiet I hope you don't mind — saw the bug was still unassigned, so to avoid losing time I put a full fix forward rather than waiting.
Activity
akhil9tiet commentedon Oct 17, 2026
I'd like to work on this — please assign it to me.
Omarinho12345 commentedon Oct 17, 2026
I opened PR #49703 with the fix:
self.input_projections = []→nn.ModuleList()inMask2FormerTransformerModule, matching the pixel decoder's existing pattern and the original Meta implementation, plus a regression test asserting the projection parameters are registered (visible instate_dict()/named_parameters()) withenforce_input_projection=True. @akhil9tiet I hope you don't mind — saw the bug was still unassigned, so to avoid losing time I put a full fix forward rather than waiting.akhil9tiet commentedon Oct 17, 2026
Thanks for the heads-up — withdrawing my claim since PR #49703 has the fix covered. The ModuleList + regression-test approach looks right.