RFC: refactor causal lm loss to handle lm_head in loss function
Author: winglian
Pull request: yes

# What does this PR do?

The ecosystem is has a lot of patches to optimize the loss for causal models. Due to frequent api changes, these patches are hard to maintain and keep up to date.
- liger https://github.com/linkedin/Liger-Kernel/tree/main/src/liger_kernel/transformers/model
- cce https://github.com/apple/ml-cross-entropy/tree/main/cut_cross_entropy/transformers

The RFC proposes changes to the ForCausalLMLoss to accept the lm_head weights and last hidden_states as part of the loss function. By moving the loss calculation here, it's much easier to add various loss variations that leverage fusing the linear + cross entropy calculations.

<!-- Remove if not applicable -->

Fixes # (issue)


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [ ] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- text models: @ArthurZucker
- vision models: @amyeroberts, @qubvel
- speech models: @eustlb
- graph models: @clefourrier

Library:

- flax: @gante and @Rocketknight1
- generate: @zucchini-nlp (visual-language models) or @gante (all others)
- pipelines: @Rocketknight1
- tensorflow: @gante and @Rocketknight1
- tokenizers: @ArthurZucker
- trainer: @zach-huggingface, @SunMarc and @qgallouedec
- chat templates: @Rocketknight1

Integrations:

- deepspeed: HF Trainer/Accelerate: @SunMarc @zach-huggingface
- ray/raytune: @richardliaw, @amogkam
- Big Model Inference: @SunMarc
- quantization (bitsandbytes, autogpt): @SunMarc @MekkCyber

Documentation: @stevhliu

HF projects:

- accelerate: [different repo](https://github.com/huggingface/accelerate)
- datasets: [different repo](https://github.com/huggingface/datasets)
- diffusers: [different repo](https://github.com/huggingface/diffusers)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Maintained examples (not research project or legacy):

- Flax: @Rocketknight1
- PyTorch: See Models above and tag the person corresponding to the modality of the example.
- TensorFlow: @Rocketknight1

 -->


Comments:
Maybe some input from liger-kernel and cce maintainers would be helpful too @shimizust @lancerts @vaibhavjindal @erikwijmans

This is definitely a core change to the library layout, so cc @arthurzucker @cyrilvallez!

I definitely like the spirit behind this. This may get a bit complicated as sometimes how the logits are compute is specific to the model implementation (softcapping, like in Gemma 2, is what comes to mind).  I think given the memory saving that fusing the cross-entropy and linear layer enables, this is worth figuring out tho :)


I do think the example given would work because you can still specify the logits from the caller (the model) if needed and any uncommon extra arguments could be put in **kwargs. The default implementation should probably support softcapping and a bias, since both aren't common it may make sense to have those be in kwargs.

cc @ArthurZucker - could indeed allow nice training optimizations more easily, but we lose a bit of explicitness, and add a redundant codepaths if the loss is not overriden. WDYT?

One other thought: Accessing the lm head weights via `self.lm_head.weight` can have bad interactions with fully-sharded data-parallel. 

PyTorch's FSDP2 relies on the forward call to know when to unshard the weights. The default way transformers shards is for the lm_head to be part of the model-level sharding group, so this isn't a problem as it gets unsharded by `*ForCausalLM.forward`, but it could be a problem.

I haven't seen this issue with ZeRO as it relies on a different mechanism.

I don't have much experience with PyTorch's original FSDP, but I believe you to explicitly use [summon_full_params](https://docs.pytorch.org/docs/stable/fsdp.html#torch.distributed.fsdp.FullyShardedDataParallel.summon_full_params) to access the weights in this way.