[vllm] fix: is_fp8_weight() skips fused-MoE expert weights with non-".weight" checkpoint names

[YolandaLyj]

What does this PR do?

is_fp8_weight() in verl/utils/vllm/vllm_quant_utils.py used name.endswith("weight") to filter bias parameters before resolving the module and checking its dtype. The comment says "Filter out bias params", but the check is stricter than that: it requires the name to end in "weight", which silently excludes fused-MoE expert weights whose checkpoint names carry no .weight suffix (e.g. mlp.experts.gate_up_proj, mlp.experts.down_proj).

As a result, on any model whose checkpoint stores expert weights in the fused 3D layout, quant_weights() never quantizes, and never yields the companion *_scale_inv tensor, for any expert-weight parameter — across every layer, for the entire training run.

Root cause and fix: Replace the single suffix guard with an explicit whitelist (_FP8_LINEAR_LEAF / _FP8_MOE_LEAVES) that (1) correctly admits fused expert parameter names and (2) serves as a fast path — module resolution via get_module_from_param_name is only triggered for leaf names that can actually be fp8 weights, avoiding unnecessary calls for embeddings, norms, and biases. The real fp8-eligibility decision (is_fp8_linear / is_fp8_moe) is structurally unchanged — it still checks the resolved module's actual dtype.

Affected models: Any MoE model whose checkpoint uses the fused expert layout (one [num_experts, in_dim, out_dim] tensor per projection, no per-expert index in the name). Examples include Qwen3-MoE-style checkpoints. Models with per-expert layout (experts.{id}.gate_proj.weight) are not affected.

Duplicate check: gh pr list --repo verl-project/verl --state open --search "is_fp8_weight OR fused expert" — no open PR addresses this fix.

Checklist Before Starting

• Search for similar PRs. Query: gh pr list --repo verl-project/verl --state open --search "is_fp8_weight OR fused expert" — no duplicates found.
• Format the PR title as [{modules}] {type}: {description}

Test

This bug only triggers at runtime with a fused-MoE fp8 checkpoint, which requires a GPU environment.

Suggested verification:

• Construct (or mock) a model with a fused-MoE expert module whose w13_weight/w2_weight are float8_e4m3fn and a parameter name like model.layers.0.mlp.experts.gate_up_proj; assert is_fp8_weight(name, model) returns True (was False before fix).
• Confirm dense linear weights (*.weight) and bias params (*.bias) return the same result as before.

Design & Code Changes

• Add two module-level constants: _FP8_LINEAR_LEAF = "weight" and _FP8_MOE_LEAVES = {"gate_up_proj": "w13_weight", "down_proj": "w2_weight"}.
• In is_fp8_weight(), extract the parameter leaf name via name.rsplit(".", 1)[-1] and gate module resolution on leaf == _FP8_LINEAR_LEAF or leaf in _FP8_MOE_LEAVES.
• Use getattr(module, _FP8_MOE_LEAVES[leaf]) in is_fp8_moe so the whitelist is the single source of truth for the leaf→attribute mapping.

Checklist Before Submitting

• Read the Contribute Guide.
• Apply pre-commit checks: ruff and mypy pass. (autogen-trainer-cfg fails due to missing local hydra-core; check-docs-time-info and check-naming-conventions fail on untracked docs/custom/ files unrelated to this PR.)
• Add / Update the documentation. (No doc changes needed for this bug fix.)
• Add unit or end-to-end test(s). A GPU environment with a fused-MoE fp8 checkpoint is required; not feasible in local CI without one.

This fix was identified with AI assistance. The submitter has reviewed every changed line and understands the change end-to-end.

[YolandaLyj]

@wuxibin89 @HollowMan6 It seems that none of the failed CI assignments involve the changed files.

[HollowMan6]

LGTM