[Misc] Remove dead VLLM_RPC_TIMEOUT env var and fix profiling doc that references it

[DaoyuanLi2816]

Purpose

VLLM_RPC_TIMEOUT is documented in vllm/envs.py ("Time in ms for the zmq client to wait for a response from the backend server for simple data operations", default 10000), but it has no consumers anywhere in the tree — it is a V0 leftover.

In V1, the engine-core client waits on utility RPCs without any timeout:

• SyncMPClient.call_utility → future.result() (no timeout arg)
• AsyncMPClient._call_utility_async → await future (no timeout)

(both in vllm/v1/engine/core_client.py). So there is no client-side RPC timeout for this env var to control.

The problem this surfaces for users: the profiling guide actively tells people to set it —

docs/contributing/profiling.md
To stop the profiler ... Set the env variable VLLM_RPC_TIMEOUT to a big number before you start the server. export VLLM_RPC_TIMEOUT=1800000

Following that instruction has no effect, since nothing reads the variable. (In V1 the profiler-stop flush is awaited without a timeout anyway, so the original failure mode the tip was guarding against no longer exists.)

Changes

• docs/contributing/profiling.md: replace the obsolete VLLM_RPC_TIMEOUT instruction with an accurate note — the engine client waits for the trace flush to complete without timing out.
• vllm/envs.py: remove the orphaned VLLM_RPC_TIMEOUT entry (type stub + environment_variables lambda).

Net diff is +1 / -6.

Not a duplicate

Per AGENTS.md duplicate-work checks:

gh issue list --repo vllm-project/vllm --state all --search "VLLM_RPC_TIMEOUT"   # no issue about it being dead
gh pr list    --repo vllm-project/vllm --state all --search "VLLM_RPC_TIMEOUT"   # no PR touching it
gh pr list    --repo vllm-project/vllm --state open --search "profiling.md in:title"  # none

No existing issue or PR addresses the dead env var or the obsolete profiling instruction.

Test plan

Verified there are zero consumers before removing (static and dynamic access), on main @ 6bdabbad:

# whole tree, excluding the definition file — no matches:
grep -rn "VLLM_RPC_TIMEOUT" . --include='*.py' --include='*.sh' \
  --include='Dockerfile*' --include='*.cmake' --include='CMakeLists.txt' \
  --include='*.yaml' | grep -v vllm/envs.py

pre-commit on the changed files (Windows host, .venv Python 3.12.13):

pre-commit run --files vllm/envs.py docs/contributing/profiling.md

ruff check, ruff format, typos, markdownlint-cli2, mypy, Check SPDX headers, Validate configuration has default values and that each field has a docstring, and the remaining hooks pass on the changed files. (update-dockerfile-graph errors with Executable /bin/bash not found — a Windows-host limitation unrelated to these files; it runs on Linux CI.)

Risk

Removing the env var is safe: nothing reads it, so no runtime path changes. A user who still exports VLLM_RPC_TIMEOUT in their shell is simply left with an unused variable (same as today, since it was already ignored). If maintainers would instead prefer to restore a client-side RPC timeout in V1 and wire this variable back in, happy to take that direction instead.

---

AI-assisted (Claude Code); reviewed end-to-end by the submitter.

[mergify]

Documentation preview: https://vllm--44128.org.readthedocs.build/en/44128/

[njhill]

Thanks @DaoyuanLi2816

[DaoyuanLi2816]

@njhill friendly nudge — this has been ready + MERGEABLE/CLEAN for ~24h. Happy to address anything if needed.

[DaoyuanLi2816]

Looping in @sfeng33 — this is the same dead-code-cleanup shape as #44279.

Approved + ready since 2026-06-01T02:30Z (~40h), CI green, MERGEABLE/CLEAN. Happy to address any further changes.

[sfeng33]

Seems that there are still benchmark configs that set VLLM_RPC_TIMEOUT, e.g serving-tests-cpu.json, would be great to clean those up as well.

[DaoyuanLi2816]

Good catch — thanks @sfeng33! Pushed 36f99a3 removing VLLM_RPC_TIMEOUT from all 9 CPU benchmark configs in .buildkite/performance-benchmarks/tests/ (serving / latency / throughput, x86 and arm64). Each is just a single-line deletion since the value was already a no-op.

[sfeng33]

Thanks!