Skip to content

[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.

Sign up for GitHub

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

Closed
wants to merge 10 commits into from
Closed

[RFC] Lift freqs_cis as an input of models #1797

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
8a42c0c
Update
fegin Oct 4, 2025
d6d06d5
Update
fegin Oct 8, 2025
705eebd
Update
fegin Oct 8, 2025
e9c4cf7
Update
fegin Oct 8, 2025
d60c3d6
Update
fegin Oct 9, 2025
827ba00
Update
fegin Oct 9, 2025
f0dfa69
Update
fegin Oct 9, 2025
b05f40d
Update
fegin Oct 10, 2025
5b813a2
Update
fegin Oct 12, 2025
321fe63
Update
fegin Oct 27, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Update 
[ghstack-poisoned]
  • Loading branch information
@fegin
fegin committed Oct 9, 2025
commit 827ba00cc677e8795d47040f58c0acf4364a07cd
4 changes: 2 additions & 2 deletions torchtitan/models/llama3/model/model.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -477,9 +477,9 @@ def get_order_sensitive_buffers(
self,
batch_size: int,
seq_len: int,
) -> tuple[tuple[torch.Tensor, ...], tuple[int, ...]]:
) -> tuple[dict[str, torch.Tensor], dict[str, int]]:
freqs_cis = self.freqs_cis[:seq_len].repeat(batch_size, 1, 1)
Copy link
Contributor

@tianyu-l tianyu-l Oct 5, 2025

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:

  • we create self.freqs_cis in model code
  • then copy it to freqs_cis, which technically is outside the model
  • we then send freqs_cis into model

Would like to hear your thoughts.

Copy link
Contributor Author

@fegin fegin Oct 6, 2025 •
edited
Loading

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.

Copy link
Contributor

@tianyu-l tianyu-l Oct 6, 2025

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.

Copy link
Contributor

@tianyu-l tianyu-l Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the (maybe unlikely) case when both seq len and batch size are large, this code is creating a big buffer (which may not peak the memory anyway?).
Might be OK as in reality for ultra-long seq len we should probably set batch size = 1.

return ((freqs_cis,), (1,))
return ({"freqs_cis": freqs_cis}, {"freqs_cis": 1})

def forward(
self,
Expand Down
6 changes: 3 additions & 3 deletions torchtitan/train.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -426,6 +426,7 @@ def forward_backward_step(
order_sensitive_buffers = model_parts[0].get_order_sensitive_buffers(
inputs.size(0), inputs.size(1)
)
extra_args.update(order_sensitive_buffers[0])

# apply context parallelism if cp is enabled
# ensure CP handles the separate freqs_cis buffer for each pp stage
Expand All @@ -451,7 +452,6 @@ def forward_backward_step(
if self.pp_has_first_stage:
self.pp_schedule.step(
inputs,
*order_sensitive_buffers[0],
**extra_inputs,
**extra_args,
target=targets,
Expand All @@ -460,7 +460,7 @@ def forward_backward_step(
)
else:
self.pp_schedule.step(
*order_sensitive_buffers[0],
**extra_args,
target=targets,
losses=losses,
input_batch=inputs,
Expand All @@ -483,8 +483,8 @@ def forward_backward_step(
with self.maybe_enable_amp:
pred = model_parts[0](
inputs,
*order_sensitive_buffers[0],
**extra_inputs,
**extra_args,
)
loss = self.loss_fn(pred, labels)
# need to free pred before bwd to avoid peaking memory
Expand Down
Loading
You are viewing a condensed version of this merge commit. You can view the full changes here.