[vllm_omni, rollout] fix: forward-compat with vllm-omni multi-LoRA API rename

[ultranationalism]

What does this PR do?

Makes vllm_omni_async_server.generate() forward-compatible with the upcoming vllm-omni multi-LoRA API rename (vllm-project/vllm-omni#2309), which renames

• OmniDiffusionSamplingParams.lora_request: LoRARequest | None → lora_requests: list[LoRARequest]
• OmniDiffusionSamplingParams.lora_scale: float → lora_scales: list[float]

to support multi-LoRA composition on a single diffusion request.

Today VERL constructs sampling params with the singular key:

if lora_request is not None:
    sampling_kwargs["lora_request"] = lora_request

That TypeErrors the moment rollout installs a vllm-omni release containing the rename, because the dataclass no longer has a lora_request field. This PR detects which field name the installed vllm-omni exposes at runtime via OmniDiffusionSamplingParams.__dataclass_fields__ and populates the correct one — keeping the adapter working on both the currently-pinned vllm-omni==0.18.0 (singular) and any post-rename release (plural, one element list wrapping the single LoRA that this adapter currently supports).

Checklist Before Starting

• Search for similar PRs:
  • gh pr list --repo volcengine/verl --state all --search \"vllm_omni_async_server\" — no results
  • gh pr list --repo volcengine/verl --state open --search \"vllm_omni lora\" — no results
  • gh issue list --repo volcengine/verl --state all --search \"vllm_omni multi-lora\" — no results
• PR title format: [vllm_omni, rollout] fix: …
• Not a breaking change: both API shapes remain supported on the VERL side.

Test

CI pins vllm-omni==0.18.0 (singular API). Under that pin, the branch selected at runtime is the else branch, which is byte-identical to the pre-patch behavior, so all existing tests in tests/workers/rollout/rollout_vllm/test_vllm_omni_generate.py continue to hold without modification.

The plural branch activates once rollout bumps its pin past the rename; at that point the same test file exercises the new path. No additional unit tests are added in this PR because the rename hasn't landed in a released vllm-omni yet — pinning a test against a future API shape would require vendoring it.

Manually verified the dataclass-field probe on both branches of vllm-omni:

# vllm-omni 0.18.0
>>> "lora_requests" in OmniDiffusionSamplingParams.__dataclass_fields__
False
# vllm-omni multi-lora-v2 (PR #2309 head)
>>> "lora_requests" in OmniDiffusionSamplingParams.__dataclass_fields__
True

API and Usage Example

No public VERL API change. The rollout continues to accept exactly one LoRA adapter per request (same self.lora_as_adapter / VLLM_LORA_INT_ID plumbing as today); the patch only affects how that single adapter is handed to OmniDiffusionSamplingParams.

Design & Code Changes

Single file touched: verl/workers/rollout/vllm_rollout/vllm_omni_async_server.py — 8 inserted, 1 deleted.

if lora_request is not None:
    # vllm-omni >=0.19 renames lora_request/lora_scale to the plural
    # lora_requests/lora_scales (list form) for multi-LoRA composition.
    # Detect which field the installed version exposes so this adapter
    # works on both pre- and post-rename releases.
    if "lora_requests" in OmniDiffusionSamplingParams.__dataclass_fields__:
        sampling_kwargs["lora_requests"] = [lora_request]
    else:
        sampling_kwargs["lora_request"] = lora_request

AI assistance disclosure

This PR was drafted with Claude Code. The human submitter reviewed every changed line and defends the change end-to-end.

Checklist Before Submitting

• Read the Contribute Guide.
• Pre-commit clean (one-file, dataclass-fields probe, no format/lint changes).
• Not related to the recipe submodule.

Signed-off-by: ultranationalism www913363043@gmail.com

[gemini-code-assist]

Code Review

This pull request introduces forward-compatibility for vllm-omni versions 0.19 and above by dynamically mapping 'lora_request' to the new plural 'lora_requests' field. Feedback suggests extending this logic to include 'lora_scale' (mapping it to 'lora_scales'), as the current implementation only addresses the request field despite the code comments mentioning both.

[gemini-code-assist]

The PR description and the added code comments (lines 174-175) explicitly mention that both lora_request and lora_scale are being renamed to their plural forms (lora_requests and lora_scales) in vllm-omni >= 0.19. However, the current implementation only handles the forward-compatibility for lora_request.

If a user passes lora_scale in sampling_params, it will be moved to extra_args by the loop at lines 167-171 when running on a newer version of the library. This value will then be ignored by the OmniDiffusionSamplingParams constructor. To ensure full forward-compatibility as intended, lora_scale should also be mapped to lora_scales (as a single-element list) when the plural API is detected.

Suggested change

	if "lora_requests" in OmniDiffusionSamplingParams.__dataclass_fields__:
	sampling_kwargs["lora_requests"] = [lora_request]
	else:
	sampling_kwargs["lora_request"] = lora_request
	if "lora_requests" in OmniDiffusionSamplingParams.__dataclass_fields__:
	sampling_kwargs["lora_requests"] = [lora_request]
	if "lora_scale" in extra_args:
	sampling_kwargs["lora_scales"] = [extra_args.pop("lora_scale")]
	else:
	sampling_kwargs["lora_request"] = lora_request

[ultranationalism]

Addressed gemini-code-assist review in f3d95ce — lora_scale from sampling_params now gets lifted out of extra_args into the plural lora_scales when the post-rename API is in use. No VERL code path currently sets lora_scale (grepped: zero hits outside the new comment; DiffusionSamplingConfig doesn't declare it), so this is purely guarding future / external callers who pass it through the loose sampling_params: dict surface — matches the symmetry the commit message / code comment already promised.