Remove --disable-log-requests from vLLM benchmark scripts

[Oseltamivir]

Summary

• Newer vLLM releases removed --disable-log-requests (request logging is now off by default; opt in with --enable-log-requests). Passing the old flag fails immediately with vllm: error: unrecognized arguments: --disable-log-requests (example CI failure).
• Drops the flag from the four remaining single-node benchmark scripts: gptoss_fp4_b200.sh, kimik2.5_int4_b200.sh, kimik2.5_int4_h200.sh, minimaxm2.5_fp8_mi300x.sh.
• Behavior matches the prior intent — logging stays off, no opt-in added.

Test plan

• Re-run the failing benchmark job(s) and confirm vllm serve starts without the argparse error.
• Spot-check server logs to confirm per-request logging is not emitted.

Out of scope

• perf-changelog.yaml mentions of the flag are historical PR descriptions — left untouched.
• utils/bench_serving/benchmark_serving.py docstring still references the flag; it is vendored upstream vLLM code, left to avoid future merge conflicts.

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://docs.sglang.io/cookbook/intro
• https://recipes.vllm.ai/

If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sglang/tree/main/docs_new

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

[claude]

Mechanical removal of deprecated vLLM flag from four benchmark scripts to fix CI argparse errors.

Extended reasoning...

Overview

This PR removes the --disable-log-requests flag from four single-node vLLM benchmark scripts (gptoss_fp4_b200.sh, kimik2.5_int4_b200.sh, kimik2.5_int4_h200.sh, minimaxm2.5_fp8_mi300x.sh). Newer vLLM releases removed this flag (request logging is now off by default, with opt-in via --enable-log-requests), so passing it causes vllm serve to fail at argparse. The behavior intent (logging stays off) is preserved.

Security risks

None. These are benchmark shell scripts that only modify vLLM server CLI arguments. No auth, crypto, network exposure, or data-handling logic is touched.

Level of scrutiny

Very low. This is a purely mechanical fix that follows the same pattern as the recent commit e03a0e5 ("Remove --disable-log-requests from vLLM single-node benchmark scripts"), which addressed other scripts. The diff is four identical line removals.

Other factors

No bugs were flagged by the bug hunting system. The PR description explains the out-of-scope items (vendored upstream code and historical changelog entries are intentionally left alone), which is the correct call. CI re-running the failing benchmark jobs will validate the fix.