[RFC] Liger FlexChunkLoss: Alignment and Distillation loss

[shivam15s]

🚀 The feature, motivation and pitch

We want to support various alignment and distillation loss functions.
Refer this PR on ORPO: #362

Progress

Alignment

• ORPO Add Chunked ORPO Loss #362
• CPO Adds the CPO Alignment Loss Function #382
• DPO Support Chunked DPO Loss Kernel #378
• SimPO
• IRPO
• KTO

Distillation

• KL divergence
• cosine_similarity
• earth_mover_distance
• JSD
• KVD

Design

Approach Overview:

The core idea is to extend the methods used in chunked Fused Linear Cross Entropy (FLCE) to various alignment algorithms. Here's how the process is structured:

1. Modular Optimization Process:
   • Every alignment algorithm’s optimization can be broken into three key steps:
     • Linear layer computation
     • Loss computation
     • Gradient calculation
2. Fused Linear and Loss Computation:
   • Similar to FLCE, we aim to fuse the linear layer with the loss computation for efficiency.
3. Chunking & Forward Optimization:
   • Since this is the final step in the model’s forward pass, we can also compute gradients directly during the forward pass instead of waiting for a separate backward pass.
   • We also chunk the input within the forward pass of the model, allowing significant reduction in peak gpu memory required.
4. Torch Compile for Kernel Optimization:
   • Instead of manually handling kernel-level optimizations, we let torch.compile automatically optimize kernel execution. This reduces the need for low-level optimizations while still achieving performance gains.

By combining these strategies, we efficiently optimize alignment algorithms while also simplifying development.

Key Findings

By leveraging torch.compile alongside optimization techniques like chunking, online softmax, etc, we observed close to custom triton kernel performance and reduced development time. This is why we want to introduce torch.compile as a key component of Liger.
References:

1. Torch compiled FLCE is 2x faster than the current FLCE #227
2. https://gist.github.com/Chillee/22cd93e11b887db1f596ab754d60a899#file-lce_benchmark-py

Interface

Have a base class FlexChunkLoss that handles chunking, accumulation and compiling strategies.
A custom loss class wraps the FlexChunkLoss and implements the loss fn that operates on a given chunk.

class Mycustomloss(FlexChunkLoss):
  def loss_fn(...):
    ..do something here

Alternatives

No response

Additional context

No response

[austin362667]

take DPO

[hongpeng-guo]

I can take fused linear kl div. BTW, really nice illustration on the chunk linear op fusion from the paper. Very clear to new contributors 😄

[pramodith]

@shivam15s @ByronHsu I think we should also consider including some of the loss functions commonly used for training embedding models, especially the popular ones supported in Sentence transformers.

It's quite common for embedding models to require large batch sizes to be trained well. Coupled with the fact that their batch/input structure is kind of similar to RLHF where we have positive and negative pairs, I believe that this can prove to be useful. I'd recommend supporting CoSENTLoss, MatryokshaLoss and TripleLoss for starters https://sbert.net/docs/package_reference/sentence_transformer/losses.html#cosentloss. Perhaps this can be its own roadmap separate to this one although the idea of chunking and fusing remains the same.

[ByronHsu]

@pramodith that is a good idea! do you know if the models in embedding also has large vocab and suffer from memory bottleneck?

[pramodith]

@ByronHsu most embedding models have a final Linear layer of shape (hidden_dim, hidden_dim), so vocab size doesn't really come into the picture for them so you're right to point it out, but it is common to have an effective batch size of 65k

[ByronHsu]

Then i think chunk loss is still helpful given the large batch size

[pramodith]

Then i think chunk loss is still helpful given the large batch size

Yes, I think so too. I can give this a try after we wrap up all the important RLHF and distillation losses. I'll also get Tom Aarsen's perspective since he's the lead of Sentence Transformers.

[pramodith]

#take Simpo and Irpo since they are just extensions of CPO.