Custom DPO losses support

[krammnic]

Context

What is the purpose of this PR? Is it to

• add a new feature
• fix a bug
• update tests and/or documentation
• other (please add here)

Please link to any issues this PR addresses.

Changelog

What are the changes made in this PR?

• Add Qwen2.5 to live docs #1949

Test plan

Please make sure to do each of the following if applicable to your PR. If you're unsure about any one of these just ask and we will happily help. We also have a contributing page for some guidance on contributing.

• run pre-commit hooks and linters (make sure you've first installed via pre-commit install)
• add unit tests for any new functionality
• update docstrings for any new or updated methods or classes
• run unit tests via pytest tests
• run recipe tests via pytest tests -m integration_test
• manually run any new or modified recipes with sufficient proof of correctness
• include relevant commands and any other artifacts in this summary (pastes of loss curves, eval results, etc.)

UX

If your function changed a public API, please add a dummy example of what the user experience will look like when calling it.
Here is a docstring example
and a tutorial example

• I did not change any public API
• I have added an example to docs or docstrings

Was able to forward with external loss and concatenated_forward.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/torchtune/2292

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[krammnic]

@SalmanMohammadi Hey! Can you take a look please?

[RdoubleA]

What's the motivation for this change?

[RdoubleA]

I am a bit confused on why a custom forward class needs to be created, can't everything be contained in the custom loss module, as long as it follows a certain contract?

[krammnic]

I am a bit confused on why a custom forward class needs to be created, can't everything be contained in the custom loss module, as long as it follows a certain contract?

Do you want to make it in one class?

[SalmanMohammadi]

Hey @krammnic. Thanks for opening this.

What's the motivation for this change?

@RdoubleA to try and provide some context (@krammnic feel free to correct me here since this is your PR) - the core issue is that our DPO recipe(s) as they are today are not easily extensible to other DPO-esque losses. As the recipes are now, we could start to see that adding new losses would overall be harmful to the code quality. This is why we removed SimPO in #2063 - it was a "reference-free" loss, which meant the logic for calculating the loss was slightly different.

If a user wishes to add SimPO in today, they'd have to duplicate the recipe file and make the same changes which we removed. If you'd like to estimate the space of possible DPO-style losses and the degree of branching logic they require, I'd reccomend taking a look at TRL's code.

As it is, I'm not sure if this PR is heading in the right direction. In the example with SimPO which you've provided, we're still making the extra forward pass in the recipe to obtain the reference logprobs, and passing these into the SimPOLoss which would be instantiated, which would error out.

I think it would be helpful to enumerate the different cases we would need to handle to support the most commonly used DPO-style losses, which would allow us to generalize in the right place. I would need to spend a little more time to come up with a suitable design, but right now I'm leaning towards pulling most of the logic for forward passes and loss calculation (e.g. from here to here) out of the recipe, and into the losses. I'd rather duplicate this logic for losses that are very similar than over-generalize.

I'd love to hear your thoughts @krammnic (and @RdoubleA and anyone else who has stuck with my ramblings).

[krammnic]

We can handle this case related to reference logprobs with adding parameter related to such possibility in the recipe. Speaking about the design overall, I actually could not find better alternative to save adaptiveness and code quality

Hey @krammnic. Thanks for opening this.

What's the motivation for this change?

@RdoubleA to try and provide some context (@krammnic feel free to correct me here since this is your PR) - the core issue is that our DPO recipe(s) as they are today are not easily extensible to other DPO-esque losses. As the recipes are now, we could start to see that adding new losses would overall be harmful to the code quality. This is why we removed SimPO in #2063 - it was a "reference-free" loss, which meant the logic for calculating the loss was slightly different.

If a user wishes to add SimPO in today, they'd have to duplicate the recipe file and make the same changes which we removed. If you'd like to estimate the space of possible DPO-style losses and the degree of branching logic they require, I'd reccomend taking a look at TRL's code.

As it is, I'm not sure if this PR is heading in the right direction. In the example with SimPO which you've provided, we're still making the extra forward pass in the recipe to obtain the reference logprobs, and passing these into the SimPOLoss which would be instantiated, which would error out.

I think it would be helpful to enumerate the different cases we would need to handle to support the most commonly used DPO-style losses, which would allow us to generalize in the right place. I would need to spend a little more time to come up with a suitable design, but right now I'm leaning towards pulling most of the logic for forward passes and loss calculation (e.g. from here to here) out of the recipe, and into the losses. I'd rather duplicate this logic for losses that are very similar than over-generalize.

I'd love to hear your thoughts @krammnic (and @RdoubleA and anyone else who has stuck with my ramblings).