Add support for LoRA with NVFP4 MoE models

[danisereb]

Purpose

In current vLLM main there is not support for LoRA with NVFP4 MoE models.

This PR enables LoRA support by using the existing MarlinExperts backend.

Requires this fix:
#34575

Test Plan

Test support for LoRA adapters with Nemotron Nano NVFP4:
https://huggingface.co/nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-NVFP4

LoRA adapters for testing can be found here:
https://huggingface.co/models?other=base_model:adapter:nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-BF16

Test Result

Tested on B200 (requires env-var VLLM_LORA_DISABLE_PDL=1).

---

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 adds support for LoRA with NVFP4 Mixture-of-Experts models. The changes achieve this by forcing the selection of the MARLIN backend when LoRA is enabled for NVFP4 MoE, as it provides the necessary moe_sum method for LoRA injection. A warning is correctly logged to inform the user about this backend selection. Additionally, the pull request includes a robustness improvement in vllm/lora/layers/fused_moe.py to handle both positional and keyword arguments when accessing parameters in a decorated function, which prevents potential KeyError exceptions for optional arguments. The changes appear correct and well-implemented.

[pavanimajety]

LGTM, thanks! What's needed from Flashinfer or other experts backends to support this feature?

[danisereb]

@pavanimajety as far as I understand, CUTLASS requires changes in flashinfer to support LoRA (same for cutlass with FP8 models).

And for trtllm_fp4_block_scale_moe, seems like it doesn't have input parameters for LoRA.
Adding LoRA support for trtllm_fp4_block_scale_moe looks like a non-trivial task.

As far as I can see - most quantizations support LoRA only with Triton MoE (or Marlin for NVFP4).

[robertgshaw2-redhat]

remove comment

[robertgshaw2-redhat]

I agree this adds NVFP4 kernel support for LoRA (in the same way it is added for FP8), but I consider how we do this for FP8 to be a hack.

Instead, we should add an attribute to the Kernels _supports_lora() and then the oracles can query the kernels to see if they support it.

Could you update the code to add this feature? Im okay if we want to merge the NVFP4 first, assuming you agree to make the follow up to improve the structure

[danisereb]

@robertgshaw2-redhat it's not urgent to merge this PR.

We can follow the structure you suggested (I would have to review the code areas you mentioned to understand the effort required).

[mergify]

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

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