fix(vllm): wait for engine health with no time limit (SGLang-style), gated by liveness

[aoshen02]

What

_wait_server_healthy hardcoded a 300s deadline. A large engine exceeds it while still loading weights + compiling + capturing CUDA graphs — a Qwen3-30B-A3B-FP8 dp=2 colocate engine hit TimeoutError: Timeout waiting for vLLM server healthy at 300s even though it became healthy seconds later.

Fix

Match slime's SGLang backend _wait_server_healthy: loop until /health returns 200, or — for a managed subprocess — until it dies (fail fast via process.is_alive()), with no overall deadline. The timeout_s parameter is removed entirely (cleaner). The per-probe timeout=3 on each /health GET is kept so a single stuck socket can't wedge the loop.

_wait_worker_process_alive (headless-worker stability check, different semantics) is unchanged.

Note on external mode

In external mode (process is None) there is no subprocess whose death signals failure, so a permanently-unreachable URL loops indefinitely — by design, since the external engine is caller-managed (this mirrors how SGLang's own health wait behaves). test_vllm_generate_endpoint.py updated to drop the now-removed timeout_s kwarg.

AI assistance (Claude Code) was used for this change.

[gemini-code-assist]

Code Review

This pull request increases the startup timeout for vLLM processes from 300 to 1200 seconds to accommodate large MoE engines. However, a critical issue was identified in _wait_worker_process_alive: because this function blocks until the timeout expires for a running process, increasing the timeout to 1200 seconds will cause healthy worker nodes to block startup for 20 minutes. It is recommended to keep a much smaller timeout (e.g., 10 seconds) for worker process verification.

[gemini-code-assist]

Critical Efficiency & Logic Issue: Healthy Workers Will Block Startup for 20 Minutes. In _wait_worker_process_alive, the loop continues as long as the process is alive. Because a healthy worker process stays alive indefinitely, this function has no success exit condition other than the timeout expiring. Consequently, any healthy worker node will always block and sleep for the entire timeout_s duration (now bumped to 1200 seconds / 20 minutes) before returning. Since _wait_worker_process_alive is called synchronously during the Ray Actor's init() on all non-head nodes, this change will introduce a mandatory 20-minute delay to the startup of any multi-node vLLM engine group. ### Suggested Fix: The head node's health check (_wait_server_healthy) already acts as the barrier for the entire distributed engine's readiness. Therefore, the worker nodes only need to verify that their subprocess does not crash immediately on startup. We should use a much smaller, dedicated timeout (e.g., 10 seconds) for _wait_worker_process_alive instead of sharing the 1200-second startup patience timeout.

Suggested change

	def _wait_worker_process_alive(process: multiprocessing.Process, timeout_s: float = 1200.0) -> None:
	def _wait_worker_process_alive(process: multiprocessing.Process, timeout_s: float = 10.0) -> None: