[kahlun]

Currently moved from Ready to Draft.
By trying the mechanism of no new API mode, try to utilize the platform_base.

What does this PR do?

Lets a hardware platform plugin add its own device activity to verl's torch profiler (global_profiler.tool=torch).

Today get_torch_profiler knows only one device activity, ProfilerActivity.CUDA. PyTorch also has activities for other backends (e.g. XPU, HPU, MTIA), but verl has no way to request them. CUDA itself works fine on NVIDIA (and AMD ROCm, which reuses the CUDA activity). The problem is only on machines with a different accelerator and no CUDA device:

• with the default contents=[], verl asks for CUDA, torch warns CUDA is not available, disabling CUDA profiling, and the trace has CPU ops but no device kernels;
• asking for the device explicitly in contents fails config validation, because only cuda/cpu/memory/shapes/stack are accepted.

This PR adds two optional hooks to PlatformBase. A plugin uses them to tell the profiler which activity to record and what contents name turns it on. Both hooks default to None, so CUDA, ROCm and NPU behave exactly as they do now.

Related: #7408, #7099 (torch profiler rework).

Checklist Before Starting

• Search for similar PRs. Paste at least one query link here: https://github.com/verl-project/verl/pulls?q=is%3Apr+torch+profiler+activity
• Format the PR title as [{modules}] {type}: {description} (This will be checked by the CI)

Test

• Unit: tests/plugin/test_platform_abstraction.py::TestTorchProfilerHooks checks that the default hooks return None, which is the path every in-tree platform takes.
• No change on CUDA: no in-tree platform (cuda, rocm, npu) overrides the hooks, so get_torch_profiler builds the same activities list as before.
• Plugin path (mocked): tests/utils/test_torch_profile.py::TestPluginProfilerActivityHook and TestPluginContentNameConfigValidation cover the plugin path with a mocked platform — activity added for empty/matching contents, excluded for non-matching contents or when either hook returns None, and the regression case where an explicit contents=["cuda"] must still get real CUDA on a platform that also exposes a plugin hook (the plugin device must be requested, not just available).
• Conflicting selection: also covers the case where contents names both "cuda" and the plugin's keyword — only one activity is ever recorded (the plugin's), and get_torch_profiler now logs a warning saying so, instead of silently dropping "cuda".
• Plugin path (real hardware): checked by hand with an out-of-tree platform plugin on one non-CUDA backend (Intel XPU) on real B60 hardware. With the hooks set, the trace contains device kernel events for contents=[], ["xpu"], and ["cuda","xpu"] alike (XPU wins in the last case). Without the hooks, it contains CPU ops only.

No new e2e test is added to CI — the real-hardware path needs a non-CUDA device and an out-of-tree plugin, which CI has neither. The plugin path itself is now covered by mocked unit tests, so CI gets real coverage of the hook contract even without that hardware.

API and Usage Example

A platform plugin opts in by overriding both hooks:

class MyPlatform(PlatformBase):
    def torch_profiler_activity(self):
        # this backend's torch.profiler.ProfilerActivity member
        return torch.profiler.ProfilerActivity.HPU

    def torch_profiler_content_name(self) -> str:
        return "hpu"

User config does not change. An empty contents records CPU plus the plugin's device, just as an empty contents records CPU plus CUDA today. The plugin's name can also be listed explicitly:

profiler:
  tool_config:
    torch:
      contents: [hpu, shapes, memory]

Design & Code Changes

How other hardware is supported. The hooks map onto how torch.profiler already works. A single profiler session records one device backend, chosen from activities (_KinetoProfile.__init__). Each plugin therefore provides exactly one activity, plus a name for it in contents. Any backend that has a ProfilerActivity member can use this without changes in verl:

Backend	Activity	Uses this hook?
NVIDIA	CUDA	No, it's the existing default path
AMD ROCm	CUDA (HIP is exposed as torch.cuda)	No
Ascend NPU	n/a; uses verl's separate npu profiler tool	No
Other plugin backends	their own member, e.g. XPU / HPU / MTIA	Yes

Why CUDA is left out when a plugin device is active. torch.profiler checks for CUDA before every other activity. If CUDA is in the list on a machine without CUDA, torch turns off device profiling completely, which would drop the plugin's activity too. So when a plugin's device is actually requested — contents is empty, or contains the plugin's keyword — verl adds that activity instead of CUDA. The key word is requested: a platform merely exposing the hooks does not by itself suppress CUDA — contents=["cuda"] alone still gets real CUDA, even on a platform that also implements the hooks. CUDA machines are unaffected either way, because no CUDA-family platform overrides the hooks.

If contents names both "cuda" and the plugin's keyword in the same call — a self-contradictory request, since only one device activity is ever recorded and there's no CUDA device on a plugin platform to begin with — the plugin's activity wins and get_torch_profiler logs a warning naming which activity was kept and that "cuda" was ignored.

Changes

• verl/plugin/platform/platform_base.py: new torch_profiler_activity() and torch_profiler_content_name(), both returning None by default. A platform opts in only when both are non-None.

• verl/utils/profiler/config.py: TorchProfilerToolConfig validation accepts the plugin's content name when both hooks are set.

• verl/utils/profiler/torch_profile.py: get_torch_profiler adds the plugin activity when contents is empty or includes the plugin's name, and adds CUDA only when no plugin device is present.

• verl/utils/profiler/torch_profile.py: get_torch_profiler adds the plugin activity when contents is empty or includes the plugin's name, and adds CUDA only when the plugin device was not actually requested (not merely available); logs a warning when contents names both "cuda" and the plugin's keyword, since only the plugin's activity is recorded.

• tests/utils/test_torch_profile.py: TestPluginProfilerActivityHook and TestPluginContentNameConfigValidation cover the plugin path, the contents=["cuda"]-not-stolen regression, and the new conflicting-selection warning.

• verl/plugin/platform/README.md: documents both hooks in the platform API table.

• tests/plugin/test_platform_abstraction.py: tests the default behavior.

Checklist Before Submitting

• Read the Contribute Guide.
• Apply pre-commit checks: pre-commit install && pre-commit run --all-files --show-diff-on-failure --color=always
• Add / Update the documentation. (platform plugin README)
• Add unit or end-to-end test(s) to the CI workflow to cover all the code. If not feasible, explain why: the default (None) path is unit-tested. The plugin path needs a non-CUDA device and an out-of-tree plugin, and CI has neither (see Test).
• Once your PR is ready for CI, send a message in the ci-request channel in the verl Slack workspace.
• If your PR is related to the recipe submodule, please also update the reference to the submodule commit via git submodule update --remote or cd recipe && git pull origin main.