[Bugfix][Ray] Fix RayExecutorV2 actor name collision with DP > 1

[tomeras91]

Summary

• RayExecutorV2 names its TP worker actors as vllm_Worker_{instance_id}[_TP{n}] (see vllm/v1/executor/ray_utils.py::build_actor_name). When data_parallel_size > 1, CoreEngineActorManager.__init__ produces each DP engine's VllmConfig via copy.deepcopy(vllm_config), which preserves the original instance_id across all DP replicas.
• With a single shared instance_id, every DP engine attempts to create Ray actors with the same names and all but the first crash with:

  ray.exceptions.ActorAlreadyExistsError: Actor with name
  'vllm_Worker_<id>_TP0' already exists in the namespace ...
  

• Fix: append the global DP rank to instance_id in each per-engine config copy, matching the existing precedent that does the same for kv_transfer_config.engine_id in the same function. Gated on dp_size > 1 so single-DP deployments are unaffected.

Bug only reproduces when VLLM_USE_RAY_V2_EXECUTOR_BACKEND=1 (added in #36836); the legacy RayDistributedExecutor doesn't use named Ray actors and is unaffected.

Test plan

• Reproduced on Nemotron-Super NVFP4, TP=2, DP=32, 16-node GB200 cluster with `VLLM_USE_RAY_V2_EXECUTOR_BACKEND=1` + `VLLM_RAY_DP_PACK_STRATEGY=strict` — server previously crashed during actor creation with `ActorAlreadyExistsError`.
• With this patch, all 32 DP engines start and the server serves requests normally.
• No behavior change when DP=1 (guarded by `if dp_size > 1`).
• Existing unit tests in `tests/distributed/test_ray_v2_executor*.py` still pass.

AI assistance disclosure

AI assistance was used to audit `instance_id` usage across the codebase and draft the patch.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[gemini-code-assist]

Code Review

This pull request updates the engine configuration in vllm/v1/engine/utils.py to append the DP rank to the instance_id, ensuring unique identifiers for Ray actors across data-parallel replicas. While this addresses the initial startup, feedback indicates that similar logic is missing in the elastic EP scale-up path and the multiprocessing DP path, which could still result in naming collisions or incorrect KV transfer behavior.

[gemini-code-assist]

The fix correctly addresses the actor name collision for the initial Ray DP startup. However, the same logic appears to be missing in two other critical locations where per-engine configurations are initialized:

1. Elastic EP Scale-up: In CoreEngineActorManager.scale_up_elastic_ep (around line 766), new engines are launched but their instance_id is not updated with the new DP rank. Additionally, the kv_transfer_config.engine_id update (present in __init__ at line 399) is also missing here. This will cause collisions and incorrect behavior when scaling up a cluster using RayExecutorV2 or KV transfer.
2. Multiprocessing DP Path: In vllm/v1/engine/core.py::run_engine_core (around line 1083), the vllm_config is modified for kv_transfer_config, but instance_id is not updated. If data_parallel_backend="mp" is used in conjunction with RayExecutorV2, collisions will occur.

To ensure full coverage and consistency, please apply the instance_id update in these locations as well, using the global DP rank (rank and dp_rank respectively). You should also fix the missing kv_transfer_config update in scale_up_elastic_ep.

[jeffreywang-anyscale]

Thanks for the fix!