-
Notifications
You must be signed in to change notification settings - Fork 552
[RFC] Lift freqs_cis as an input of models #1797
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
base: gh/fegin/7/base
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -70,3 +70,11 @@ def get_attention_masks( | |
raise NotImplementedError( | ||
"This model does not support attention masking/Flex Attention." | ||
) | ||
|
||
def get_order_sensitive_buffers( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Naming is a bit vague. I think here we are only targeting "sequence dim" order-sensitive buffers, not the batch dim. |
||
self, | ||
batch_size: int, | ||
seq_len: int, | ||
) -> tuple[tuple[torch.Tensor, ...], tuple[int, ...]]: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we add some notes here what does this 2 return values mean? Seems like the first return value is the buffer itself |
||
raise NotImplementedError() | ||
return ((), ()) |
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.
I wonder what's the benefit of keeping
self.freqs_cis
.If seq len changes from iteration to iteration (e.g. in forge), it might be good to keep a central
self.freqs_cis
instead of computing it each iteration. The other benefit is that we may not want torchtitan model definition to deviate from "original" / "conventional" model definitions too much.On the other hand, the dependency sounds indirect and error-prone:
self.freqs_cis
in model codefreqs_cis
, which technically is outside the modelfreqs_cis
into modelWould like to hear your thoughts.
Uh oh!
There was an error while loading. Please reload this page.
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.
Re-computation is the main reason why I decided to keep
self.freqs_cis
. I agree it's a bit awkward.One alternative is to sill keep
self.freqs_cis
but set it as an optional field (self.freqs_cis: torch.Tensor | None
) for bookkeeping only. And we only initialize it in this function. So the creation logic flow (precompute and slicing) is mainly in this function. The model code still provides precompute function. So this way we do not change the code structure too much while keeping the logic together. Not a perfect solution though.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.
I think it's fine to keep the current way for now, as it sounds more lightweight change, and as I mentioned downstream application (e.g. forge, and simple generation) may change
seq_len
from iteration to iteration, where we can avoid recomputation this way.