Fix VoxCPM2 perf server trust remote code

[liuyao0322]

Summary

Fixes #4975.

This PR ensures server_params.trust_remote_code from DFX perf/stability JSON configs is propagated to the OmniServer startup
command.

Previously, trust_remote_code: true in tests/dfx/perf/tests/test_voxcpm2.json was only used when constructing benchmark client args. The server fixture did not pass --trust-remote-code to vllm serve, so the StageEngine still initialized with trust_remote_code=False. This caused VoxCPM2 startup to fail when StructuredOutputManager loaded the tokenizer via AutoTokenizer.from_pretrained(...).

Changes

• Add server-side propagation of server_params.trust_remote_code to --trust-remote-code.
• Avoid duplicating the flag if it is already present in extra_cli_args or serve_args.
• Add regression tests for server-side trust remote code propagation.

Test

python -m pytest -q tests/dfx/perf/tests/test_runner_metadata.py

Result:

4 passed

## Reproduction Notes

Before this fix, starting VoxCPM2 without an explicit server --trust-remote-code reproduced:

ValueError: The repository ... VoxCPM2 contains custom code ...
Please pass the argument `trust_remote_code=True`

After this fix, the generated server args include:

--trust-remote-code

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

[liuyao0322]

@yenuo26 hello maintainer, could you plz review my code? thank you very much

[yenuo26]

@yenuo26 hello maintainer, could you plz review my code? thank you very much

Thanks for tracking this down — the failure mode in #4975 is real: server_params.trust_remote_code currently only affects benchmark client args in run_benchmark.py, so OmniServer still starts without --trust-remote-code.

However, I don't think mapping that field inside create_unique_server_params is the right fix.

server_params.trust_remote_code is already treated as client-side metadata (it's in the client exclude_keys path). Making the same key also inject server CLI flags gives one field two meanings, and adds a special-case path that existing DFX configs already avoid:

• Higgs uses extra_cli_args: ["--trust-remote-code"]
• Hunyuan puts trust_remote_code under serve_args / deploy config

_build_serve_args already expands those into server startup args, so the minimal fix should be to update tests/dfx/perf/tests/test_voxcpm2.json to pass the flag explicitly, e.g.:

"server_params": {
  "model": "openbmb/VoxCPM2",
  "extra_cli_args": ["--trust-remote-code"]
}

[liuyao0322]

@yenuo26 hello maintainer, could you plz review my code? thank you very much

Thanks for tracking this down — the failure mode in #4975 is real: server_params.trust_remote_code currently only affects benchmark client args in run_benchmark.py, so OmniServer still starts without --trust-remote-code.

However, I don't think mapping that field inside create_unique_server_params is the right fix.

server_params.trust_remote_code is already treated as client-side metadata (it's in the client exclude_keys path). Making the same key also inject server CLI flags gives one field two meanings, and adds a special-case path that existing DFX configs already avoid:

• Higgs uses extra_cli_args: ["--trust-remote-code"]
• Hunyuan puts trust_remote_code under serve_args / deploy config

_build_serve_args already expands those into server startup args, so the minimal fix should be to update tests/dfx/perf/tests/test_voxcpm2.json to pass the flag explicitly, e.g.:

"server_params": {
  "model": "openbmb/VoxCPM2",
  "extra_cli_args": ["--trust-remote-code"]
}

Thanks for the review. I agree with your point that server_params.trust_remote_code should not implicitly gain
server-startup semantics.

I updated the PR to follow the existing DFX pattern instead:

• reverted the create_unique_server_params logic change
• removed the extra regression tests for that behavior
• added extra_cli_args: ["--trust-remote-code"] directly to tests/dfx/perf/tests/test_voxcpm2.json

I also kept trust_remote_code: true in the config so the benchmark client path continues to behave as before.

Validated with:

python -m json.tool tests/dfx/perf/tests/test_voxcpm2.json
python -m pytest -q tests/dfx/perf/tests/test_runner_metadata.py

Result: 2 passed.

[yenuo26]

@yenuo26 hello maintainer, could you plz review my code? thank you very much

Thanks for tracking this down — the failure mode in #4975 is real: server_params.trust_remote_code currently only affects benchmark client args in run_benchmark.py, so OmniServer still starts without --trust-remote-code.
However, I don't think mapping that field inside create_unique_server_params is the right fix.
server_params.trust_remote_code is already treated as client-side metadata (it's in the client exclude_keys path). Making the same key also inject server CLI flags gives one field two meanings, and adds a special-case path that existing DFX configs already avoid:

• Higgs uses extra_cli_args: ["--trust-remote-code"]
• Hunyuan puts trust_remote_code under serve_args / deploy config

_build_serve_args already expands those into server startup args, so the minimal fix should be to update tests/dfx/perf/tests/test_voxcpm2.json to pass the flag explicitly, e.g.:

"server_params": {
  "model": "openbmb/VoxCPM2",
  "extra_cli_args": ["--trust-remote-code"]
}

Thanks for the review. I agree with your point that server_params.trust_remote_code should not implicitly gain server-startup semantics.

I updated the PR to follow the existing DFX pattern instead:

• reverted the create_unique_server_params logic change
• removed the extra regression tests for that behavior
• added extra_cli_args: ["--trust-remote-code"] directly to tests/dfx/perf/tests/test_voxcpm2.json

I also kept trust_remote_code: true in the config so the benchmark client path continues to behave as before.

Validated with:

python -m json.tool tests/dfx/perf/tests/test_voxcpm2.json
python -m pytest -q tests/dfx/perf/tests/test_runner_metadata.py

Result: 2 passed.

@Gaohan123 I have verified this change locally and confirmed that it fixes the current issue. Could you please take a look and see if it can be merged?

[yenuo26]

LGTM

[Gaohan123]

LGTM. Thanks