[Core] Enable LoRA support for classification model

[jeejeelee]

Purpose

FIX #23719
FIX #19623

Test Plan

Test Result

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[gemini-code-assist]

Code Review

This pull request introduces ClassifierWithLoRA to enable LoRA support for classification models. However, the implementation in the new file vllm/lora/layers/classifier.py has several critical issues. These include a hardcoded value that should be configurable, incorrect initialization of an internal state variable that will lead to runtime errors, and an incorrect and incomplete forward method implementation. These issues must be addressed for the layer to function correctly.

[gemini-code-assist]

The max_class_label is hardcoded to 3. This appears to be a placeholder and should be derived from lora_config as suggested by the commented-out code. Hardcoding this value prevents the layer from being used for classification tasks with a different number of labels.

Suggested change

	self.max_class_label =3 # self.lora_config.max_class_label
	self.max_class_label = self.lora_config.max_class_label

[gemini-code-assist]

The _label_slot list is initialized with a size of self.max_class_label. However, it is indexed by a LoRA slot index in reset_lora and set_lora, which can go up to max_loras - 1. If max_loras is greater than max_class_label, this will cause an IndexError. The size of _label_slot should be max_loras to correctly track the state for each LoRA slot.

Suggested change

	self._label_slot = [-1] * self.max_class_label
	self._label_slot = [-1] * max_loras

[gemini-code-assist]

The forward method has several critical issues making it non-functional and incomplete:

1. Unused Input: The input_ tensor is not used in the computation, which is incorrect for a forward pass.
2. Incorrect add_shrink Call: The arguments to self.punica_wrapper.add_shrink are mismatched with its definition (add_shrink(y, x, lora_a_stacked, scale, **kwargs)). The input_ tensor should be passed as x, self.lora_a_stacked should be wrapped in a tuple for the lora_a_stacked argument, and a scale factor is missing. The current call will cause a TypeError.
3. Incomplete Logic: The comment # Cast y using self._label_slot on line 79 indicates missing implementation.
4. Incorrect y Shape: The y tensor is initialized with shape (self.input_size, self.max_class_label), which is missing a batch dimension.
5. Missing LoRA 'B' weights: A standard LoRA layer uses both A and B weight matrices. This implementation only seems to use lora_a, and lora_b is ignored in set_lora. The forward method should incorporate the full LoRA logic.

This method needs a complete rewrite to correctly implement the forward pass.

[pb-sameerreddy]

Had a question on this PR, I thought LoRA already works for classification models? Or is this to extend support for LoRA weights for the classifier head as well as the base model?

[jeejeelee]

Had a question on this PR, I thought LoRA already works for classification models? Or is this to extend support for LoRA weights for the classifier head as well as the base model?

Yes, mainly for the multi-lora of the classifier head

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @jeejeelee.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork