[Qwen3-TTS] Remove hardcoded distributed_executor_backend to improve single-GPU performance

[iancarrasco-b10]

Summary

• Remove hardcoded distributed_executor_backend: "mp" from qwen3_tts.yaml stage config

This improves single-GPU performance by avoiding unnecessary multiprocessing overhead from the mp executor when only one device is in use. This still preserves the current behavior of using mp in world_size > 1 scenarios.

Test Plan

Test Qwen3-TTS with uniproc and mp executors and both worked in the single-gpu case. More results can be found here: #2603

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[linyueqian]

fix pre-commit please

[linyueqian]

fix dco please

[iancarrasco-b10]

vllm already defaults to uniproc executor when distributed_executor_backend is None and world_size=1 so this is actually just a config change. Similarly mp is used by default when world_size > 1.
https://github.com/vllm-project/vllm/blob/main/vllm/config/parallel.py#L825

[linyueqian]

Thanks for the investigation! We ran the same benchmark on H20 (141GB) to verify the claim generalizes beyond H100.

Setup: Qwen/Qwen3-TTS-12Hz-1.7B-CustomVoice, bs16 config, single GPU, 50 prompts per concurrency level.

Results (H20):

Concurrency	Mean RTF (mp)	Mean RTF (uni)	Delta
1	0.155	0.151	~tied
4	0.221	0.308	mp 39.6% better
10	0.372	0.423	mp 13.7% better
16	0.430	0.541	mp 25.8% better

On H20, mp executor is consistently faster at concurrency 4+, which is the opposite of the H100 results in #2603. The throughput gap is significant: at concurrency 4, mp delivers 18.12 audio s/s vs 12.84 for uni (+29%).

This suggests the performance tradeoff is hardware-dependent. Auto-defaulting to uni for all single-GPU stages would regress performance on H20.

A few observations on the PR itself:

1. The Python code change (_default_executor_backend + setdefault) is redundant. vLLM already defaults to uni when distributed_executor_backend is None and world_size=1. Just removing the YAML line would have the same effect.
2. The scope is narrow. Only qwen3_tts.yaml is updated, but 80+ other YAML configs also hardcode "mp".

Suggestion: keep the default as "mp" in the configs, and let users opt into "uni" explicitly if their hardware benefits from it. Or, could you share more details about the H100 setup so we can understand what drives the difference?

@tzhouam @hsliuustc0106 Could you help confirm these findings or share any thoughts on the mp vs uni tradeoff?

[iancarrasco-b10]

Very interesting to see that it doesn't hold up on H200. I think it is fair to leave this up to users to flip based on their desired throughput/latency targets and hardware setup. Outside of what I shared about the setup in the related issue, what could be helpful here for getting a better sense of the discrepancy?

[iancarrasco-b10]

Have you tried running the Base cloning task? This is what I actually got the results for vs. CustomVoice so arguably that could be playing a role. I'll also run CustomVoice on my setup to see if I observe the same.

[linyueqian]

Follow-up: Base (voice cloning) task shows different results on the same H20 hardware.

Concurrency	Mean RTF (mp)	Mean RTF (uni)	Delta
1	0.297	0.240	uni 19.3% better
4	0.626	0.607	~tied
10	1.193	1.044	uni 12.5% better
16	1.936	1.388	uni 28.3% better

For the Base task, uni is consistently better, consistent with the original findings in #2603. However, using CustomVoice on the same H20 GPU, we saw the opposite (mp winning at concurrency 4+).

This suggests the tradeoff is task-dependent, not just hardware-dependent. The Base task involves heavier per-request processing (reference audio encoding), making IPC serialization overhead a larger fraction of the total cost, which favors uni. CustomVoice is lighter per-request, so the process-level parallelism of mp dominates.

Given this, a blanket default change seems risky. Keeping mp as the explicit default in configs and letting users opt into uni for their specific workload would be the safer path.

[iancarrasco-b10]

Thanks for running @linyueqian! Agreed to not merge the blanket change. I think it would be worth potentially adding this to the docs or commenting somewhere more permanent and that future deployments can take advantage of these perf gains. Potentially having a task-specific stage config?

[hsliuustc0106]

does it also apply to qwen-omni as well? @ZeldaHuang @amy-why-3459