-
Notifications
You must be signed in to change notification settings - Fork 28.2k
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
[Proposal, open for discussion] Better way of extracting hidden states #27873
Conversation
Yep I like this optimisation, non breaking overall |
@ArthurZucker it is a breaking change in its current state, since |
We can set it to |
I'd like to have @amyeroberts's opinion on this one |
This was just matching the logic that was originally implemented for the As it stands this, I'm not in favour of this as this requires adding in backbone API / logic into standard model APIs. This is essentially making things leaky: why do I need to know about Moreover, this is going to break a tonne of stuff, as users who have created checkpoints which are not backbones will still have It introduces inconsistencies in our models forward passes, which makes the code harder to understand and is tying non-backbone logic to an API which still isn't 100% stable at the moment. An alternative approach would be to have a different argument in the config which defaults to all the layers but then can be overridden by the config's |
Actually, not another config parameter - because then the source of truth isn't clear and behaviour for the user can be unexpected. |
This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread. Please note that issues that do not follow the contributing guidelines are likely to be ignored. |
What does this PR do?
Currently, our
AutoBackbone
classes allow to get specific feature maps out of a certain vision model. For example:However, they currently extract all intermediate hidden states, store them in memory, and return the ones required by the user. This is not efficient, we should store only activations required by the user in memory.
This current PR proposes to only return the hidden states specified by
config.out_indices
when the user setsoutput_hidden_states=True
. However, this is not backwards compatible (as by default we do return all hidden states). So I'm open for suggestions on how we could improve this. Alternatively, we could make it backwards compatible by settingout_indices
to all stages by default.I think this could be an argument that is part of all configs, or at least vision encoders, which typically only require certain hidden states to be extracted.
Curious to hear opinions of @ArthurZucker @amyeroberts