PLE offload: TP=1 startup rendezvous fix and ptrace opt-in

[semerandre]

Purpose

Two fixes for vllm-project#53899 found while bringing it up on one RTX PRO 6000 (SM120), TP=1:

1. TP=1 startup rendezvous deadlock (port of [Bugfix] Fix TP=1 PLE CPU-offload startup rendezvous deadlock at kernel warmup #10 by David Tai): with a single
   GPU worker the registration barrier between the offload process and the worker never completed;
   the engine stayed alive but never became ready. Startup barrier with a private ACK endpoint before
   the first warmup forward, bounded named timeouts on the registration/ACK/engine-startup waits, and
   a wall-clock backstop in wait_for_engine_startup that turns a hung core into an error instead of a
   silent hang. Blocking recv is restored before busy_loop, so steady-state decode is unchanged.
2. ptrace opt-in for the pidfd handshake: the offload process rebuilds the worker's CUDA IPC
   tensors via pidfd_getfd, which Yama ptrace_scope=1 (the Ubuntu/Debian/Arch default) only allows
   from descendants; the offload worker is a sibling, so registration failed with
   pidfd_getfd: Operation not permitted on bare metal ([Bug]: VLLM_PLE_CPU_OFFLOAD deadlocks at kernel warmup on single GPU (TP=1) - Qwen3.8-Flash-Next on GB10/sm_121 vllm-project/vllm#53960). The exporting
   worker now calls prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY), scoping the exemption to that process
   instead of requiring a host-wide sysctl; debug log when prctl is unavailable.

Plus ruff/B904 cleanups on the touched files.

Duplicate check

gh pr list --repo vllm-project/vllm --state open --search "PLE offload" / "pidfd_getfd" /
"ptrace" and the vllm-project#53899 / vllm-project#53960 threads: the only related change is #10 (the
rendezvous fix by David Tai), which targets an older state of this branch and does not apply on the
current head; this PR carries that fix forward (credited as co-author) and adds the ptrace opt-in,
which no open PR covers. No change to model outputs: startup/registration only, decode path untouched.

Test Plan

Single RTX PRO 6000 Blackwell (SM120, 96 GB), TP=1, VLLM_PLE_CPU_OFFLOAD=1, NVFP4 checkpoint,
ptrace_scope=1 unchanged on the host. Boot, needle-in-a-haystack at ~125K, prefill and decode speed,
4 concurrent ~70K-token requests.

Commands: pytest tests/models/qwen4_exp/test_ple.py (CPU: 30 passed, 23 GPU-only skipped),
ruff check / ruff format --check on the touched files, then the serving runs below.

Test Result

The same two commits were validated on vllm-project#53899 rebased onto main at e962733e (the 2026-09-05
nightly); on top of the current branch head they cherry-pick cleanly and pass ruff, but I have not
booted this exact head yet (no nightly image for it at the time of writing).

• Without the fixes: engine alive but never ready (registration barrier hang), or
  pidfd_getfd: Operation not permitted unless kernel.yama.ptrace_scope=0.
• With the fixes: boot in 4-5 min cold (2.5 min with a warm compile cache), tables resident in host
  RAM (~86 GiB), weights 73.9 GiB on the GPU, KV pool 434,886 tokens (bf16) at util 0.91 / 262K.
• Needle 3/3 at 125K; prefill ~11,000 tok/s; decode 72 tok/s at 70K context (single request),
  52 tok/s each with 4 concurrent 70K requests (208 tok/s aggregate); no prefill failures up to 393K
  (YaRN 1.5) in 8 configurations, eager and CUDA graphs.

Analysis, scripts and text prepared with AI assistance (Claude, Anthropic); results run and
reviewed by me.

🤖 Generated with Claude Code

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

PRs do not trigger a full CI run by default. Reviewers with write access and configured trusted contributors can comment /ci run for upstream CI or /amd-ci run for AMD CI only whenever CI signals are needed.

Once the PR is approved or has the ready label, the PR author can also use the corresponding /ci run, /ci retry, and /ci cancel commands, or their /amd-ci variants. New commits do not start upstream CI automatically.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

Agent Guidelines

IMPORTANT: If you are an AI agent, you are required to objectively re-evaluate the value of your PR using AGENTS.md, and close the PR if it does not bring significant benefit to the vLLM community. Failure to do so may result in an immediate ban.

🚀