[Core] Modify the initialization parameters of the lora manager

[jeejeelee]

Purpose

• Pass vllm_config to the internal lora manager to facilitate the advancement of #[Core] Enable LoRA support for classification model #24596 , as [Core] Enable LoRA support for classification model #24596 needs to obtain detail information such as task type.
• Optimize the script name for lora weights(lora.py->lora_weight.py)

This PR will slight affect the loRA implementation of hardware plugins. cc @xuechendi @Yikun

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 refactors the initialization of the LoRA manager to use a single vllm_config object, which simplifies the API and improves code clarity. The changes are well-implemented across the codebase. However, I've found a critical issue in one of the updated tests where the configuration for the test is not correctly set up, which will lead to test failures. I've provided a suggestion to fix it.

[gemini-code-assist]

The vllm_config is not correctly initialized for the test. The ModelConfig within it doesn't have the hf_config from the dummy_model, which will cause vllm_config.model_config.get_vocab_size() to return 0 inside LRUCacheWorkerLoRAManager. This leads to incorrect behavior, especially when calculating target_embedding_padding.

To fix this, you should associate the dummy_model.config with the vllm_config's model_config. Also, the manual setting of max_num_seqs and max_num_batched_tokens on worker_adapter_manager is redundant as these are already set during initialization from the vllm_config.

Suggested change

	model_config = ModelConfig(max_model_len=16)
	vllm_config = VllmConfig(model_config=model_config,
	lora_config=lora_config)
	vllm_config.scheduler_config.max_num_seqs = 4
	vllm_config.scheduler_config.max_num_batched_tokens = 2
	worker_adapter_manager = LRUCacheWorkerLoRAManager(
	4, 2,
	dummy_model.unpadded_vocab_size - lora_config.lora_extra_vocab_size,
	lora_config, device, EMBEDDING_MODULES, EMBEDDING_PADDING_MODULES)
	vllm_config, device, EMBEDDING_MODULES, EMBEDDING_PADDING_MODULES)
	worker_adapter_manager.max_num_seqs = 4
	worker_adapter_manager.max_num_batched_tokens = 2
	model_config = ModelConfig(max_model_len=16)
	vllm_config = VllmConfig(model_config=model_config,
	lora_config=lora_config)
	# Manually set hf_config for the test since ModelConfig doesn't take it
	# in __init__ and we are not loading from a real model path.
	vllm_config.model_config.hf_config = dummy_model.config
	vllm_config.scheduler_config.max_num_seqs = 4
	vllm_config.scheduler_config.max_num_batched_tokens = 2
	worker_adapter_manager = LRUCacheWorkerLoRAManager(
	vllm_config, device, EMBEDDING_MODULES, EMBEDDING_PADDING_MODULES)

[Isotr0py]

Just some nits. Otherwise LGTM

[Yikun]

Thanks for reminder! @jeejeelee
also cc @paulyu12 @wangxiyuan

[xuechendi]

@jeejeelee , thanks for the CC, will update in our plugin accordingly

[paulyu12]

Thanks for reminder! @jeejeelee also cc @paulyu12 @wangxiyuan

@Yikun @wangxiyuan Updated our plugin: vllm-project/vllm-ascend#3095

[vanbasten23]

This PR broke the lora in TPU plugin. But thanks @gpolovets1 for the fix https://github.com/vllm-project/tpu_commons/pull/720. cc: @jeejeelee @Isotr0py