[tzhouam]

Purpose

Fixes the HunyuanImage-3 NPU performance regression introduced by #9443 (reached release/v0.32.0 through batch-7 backport #9470) without reverting it, so #9232 stays fixed.

#9443 wraps MoE runners eagerly and publishes a no-adapter (slot-0) mapping before the first forward, so LoRA-typed MoE kernels have a context on HunyuanImage-3's baseline generate(). On GPU this is free: punica sets no_lora_flag for slot 0 and the TRTLLM / Triton LoRA experts return early.

Ascend's unquantized MoE path instead branches on whether a context is published at all, not on whether any token selects an adapter:

• vllm_ascend/ops/fused_moe/routed_experts.py runs the argsort-based routing recovery plus moe_lora_apply_w13 / moe_lora_apply_w2 under if lora_context is not None:
• vllm_ascend/ops/fused_moe/token_dispatcher.py adds an all_to_all of the LoRA indices per layer, plus permute/unpermute
• vllm_ascend/lora/punica_npu.py: add_lora_fused_moe has no no_lora short-circuit, so bgmv_shrink / bgmv_expand_slice still launch over every row for a zero delta

(The Ascend quantized path already gates on has_lora(lora_context) in ops/fused_moe/moe_mlp.py; only the unquantized path keys on presence.)

Change

Keep the eager wrapping and the GPU publish; detach the context while no adapter is active on runners that expose set_lora_context(). The hook is attached by capability, so GPU wrappers — which have no such entry point and whose experts assert the context exists — are unchanged. Activation, re-arm and rollback all republish through _publish_moe_lora_context(), so an active adapter still gets a real context; deactivation now also releases the cost instead of leaving it published.

.buildkite/common/ci_source_file_dependencies.yml: add vllm_omni/diffusion/lora/ to the hunyuan_image3 anchor. HunyuanImage-3 is the MoE + PEFT model whose baseline path runs this code, and without it the HunyuanImage-3 perf/accuracy steps are filtered out of a LoRA-only diff — which is how this regression reached the release branch unnoticed.

Test Plan

vLLM version: 0.32.0    Base: release/v0.32.0 @ 2dbc92bc0d

• pytest -q tests/diffusion/lora/test_lora_manager.py (two new cases: idle detaches and publishes nothing; active still publishes the slot-1 mapping)
• NPU nightly perf A/B on A3, compared against the pre-regression nightly distribution rather than pass/fail: test_hunyuan_image_tp2_cfgp2, test_hunyuan_image_tp2_sp2, test_hunyuan_image_tp4
• Reference points already collected on the same queue: control with [Bugfix][Diffusion] Prepare the MoE LoRA context #9443 (#9505, build #10096) and revert of [Bugfix][Diffusion] Prepare the MoE LoRA context #9443 (#9502, build #10092)

Test Result

metric (tp2_cfgp2 / tp2_sp2 / tp4)	pre-regression median (13 nightlies)	with #9443 (control #9505)	revert of #9443 (#9502)	this PR
e2e mean (s)	5.43 / 5.70 / 5.81	7.90 / 8.25 / 8.44	5.88 / 5.74 / 5.81	pending
DiT stage_0_gen (s)	4.81 / 5.05 / 5.19	7.30 / 7.62 / 7.82	5.28 / 5.09 / 5.19	pending
model.forward (ms)	3.79 / 3.99 / 4.13	6.31 / 6.53 / 6.67	3.83 / 3.98 / 4.13	pending

H200 is unaffected either way: the 10-28 main nightly (18 commits ahead of #9443) is flat at 2189 / 2381 / 2265 ms.

Follow-up filed upstream: vllm-ascend should gate its unquantized MoE path on has_lora(lora_context) the way the quantized one already does, and/or short-circuit add_lora_fused_moe on punica_wrapper.no_lora. That is the general fix and also helps LLM serving batches that contain no LoRA tokens, but it needs a vllm-ascend release plus an image bump, so it cannot land for v0.32.0. The two changes compose.