[Refactor] profiler config optimze

[mengchengTang]

What this PR does / why we need it?

This PR optimizes the torch_npu profiler configuration to significantly reduce overhead and trace file size. The key changes include:
Enable Data Simplification: Explicitly sets data_simplification=True in _ExperimentalConfig. This filters out unnecessary intermediate data during profiling, drastically reducing the memory footprint and I/O overhead.
Use Lightweight Stack Tracing: Replaces with_stack with with_modules when torch_profiler_with_stack is enabled. In torch_npu, with_stack introduces heavy latency. with_modules provides equivalent semantic information with much lower overhead.
Code Simplification: Removes redundant parameter configurations in _ExperimentalConfig by utilizing default values, making the codebase cleaner and easier to maintain.

Test setup:
max length = 50, profiler + stack enabled

Before optimization:
Profiler data size: 651 MB
Generate time: 3 seconds

After optimization:
Profiler data size: 156 MB (≈76% reduction)
Generate time: <1 second

Does this PR introduce any user-facing change?

No API changes. Users profiling on Ascend will experience faster profiling execution and smaller trace files when stack tracing is enabled.

How was this patch tested?

Manually verified on Ascend NPU by running vLLM with the profiler enabled. Confirmed that trace files are generated correctly containing necessary stack/module info, while showing the reported reduction in size and time.

• vLLM version: v0.13.0
• vLLM main: vllm-project/vllm@d682094

[github-actions]

👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:‌‌

• A PR should do only one thing, smaller PRs enable faster reviews.
• Every PR should include unit tests and end-to-end tests ‌to ensure it works and is not broken by other future PRs.
• Write the commit message by fulfilling the PR description to help reviewer and future developers understand.

If CI fails, you can run linting and testing checks locally according Contributing and Testing.

[gemini-code-assist]

Code Review

This pull request optimizes the profiler configuration for torch_npu. The changes include simplifying the _ExperimentalConfig, enabling data_simplification, and using the with_modules parameter instead of with_stack for better performance when capturing stack traces.

My review focuses on the robustness of the changes. While simplifying the code is good, relying on default values of an internal, experimental API can be risky. I've suggested explicitly setting the parameters to avoid potential future performance regressions if the defaults change. The rest of the changes look like reasonable optimizations.

[gemini-code-assist]

While simplifying the call to _ExperimentalConfig makes the code shorter, it now relies on the default values for several parameters (msprof_tx, l2_cache, op_attr, record_op_args, gc_detect_threshold). Since _ExperimentalConfig is an internal, experimental API, its defaults could change in future torch_npu versions. This could unexpectedly enable a resource-intensive profiling feature, leading to performance degradation. To make the code more robust and future-proof, it's safer to explicitly specify these parameters to ensure the intended behavior.

            experimental_config = torch_npu.profiler._ExperimentalConfig(
                export_type=torch_npu.profiler.ExportType.Text,
                profiler_level=torch_npu.profiler.ProfilerLevel.Level1,
                msprof_tx=False,
                aic_metrics=torch_npu.profiler.AiCMetrics.AiCoreNone,
                l2_cache=False,
                op_attr=False,
                data_simplification=True,
                record_op_args=False,
                gc_detect_threshold=None,
            )

[mengchengTang]

The default values for these parameters are stable and will not change. We prefer to keep the code concise by relying on these defaults."

[whx-sjtu]

I think it's better to keep these default values in case user wants to enable one of these parameters but don't known concrete param name.

[mengchengTang]

Thanks for the suggestion. I agree that explicitly listing these parameters makes it easier for users to discover and enable them if needed. I have restored the parameters with their default values.

[MengqingCao]

LGTM