[Refactor] Remove redundant StageDeployConfig fields, delegate to vLLM defaults

[gcanlin]

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

Purpose

Remove fields from StageDeployConfig that duplicate vLLM EngineArgs defaults:

• gpu_memory_utilization
• tensor_parallel_size
• enforce_eager
• max_num_batched_tokens
• max_model_len
• async_scheduling

These fields now flow through engine_extras and inherit vLLM's hardware-specific defaults. Existing YAML configs remain compatible as unrecognized fields automatically enter engine_extras.

Retained fields with vllm-omni specific behavior:

• max_num_seqs (default 64 vs vLLM's 256)
• devices (stage device assignment)
• default_sampling_params / subtalker_sampling_params (per-stage sampling)

Test Plan

Test Result

---

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)

[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.

[gcanlin]

I found that this field is changing the default value from vllm. And it produces the different behavior before stage config refactoring. So I think we don't need to set the default on vllm-omni side. vLLM has the selector method for this field:

https://github.com/vllm-project/vllm/blob/e54894fc85a9861fb38a49701b5844462c3d77e4/vllm/engine/arg_utils.py#L2179-L2260

[gcanlin]

cc @amy-why-3459

[amy-why-3459]

cc @amy-why-3459

I completely agree with your point of view. I believe that the default parameters should be consistent with vLLM; otherwise, performance will be affected by the inconsistency in default parameters.

[amy-why-3459]

If it involves modifying deployment parameters, I suggest testing with nightly-test.

[gcanlin]

cc @yenuo26

[yenuo26]

maybe you can use get_deploy_config_path in tests/helpers/stage_config.py

[yenuo26]

Does this not support passing arguments from the command line?

[gcanlin]

Sounds good. But would be better to unify it in a follow-up PR.

[xiaohajiayou]

For the requirement where fields defined in deploy YAML are selectively overridden,
these fields still need to be retained as a whitelist to preserve the override semantics.

The core issue here is handling default values. A more consistent approach would be to treat
all values as optional (i.e., default to None), and introduce a filtering
step in deploy_create_from_registry(), such as:

explicit_overrides = {k: v for k, v in override_fields.items() if v is not None}

This ensures that only values explicitly provided in the deploy YAML are included in the resulting StageConfig, while missing fields are left unset and handled by downstream default resolution.

With this design, as discussed in #3162:

• For LLM stages, missing fields will fall back to the default values defined in vLLM's EngineArgs.
• For diffusion stages, missing fields will be handled by _create_default_diffusion_stage_cfg,
  which provides safe defaults.

This unifies the override behavior while delegating default resolution to the appropriate
downstream layer.

[hsliuustc0106]

lgtm, the CI failure may not relate to this PR, resolve conflicts please

[Gaohan123]

Fix conflicts and pre-commit problems please