[docs] debug guide: tell a cold Triton compile from a colocate hang (en + zh)

[David553]

Why

#1487 — a colocate run finishes its rollout, prints Timer actor_train start, and then only SGLang health checks; several people in that thread report the same, and "turning colocate off helps". We hit the identical shape on Miles, a slime fork that shares slime's reloadable_process_group and sleep() / wake_up() path; what it turned out to be is written up in #1487 (comment).

developer_guide/debug.md currently says nothing about colocate offload, process-group rebuild, py-spy, watchdog timeouts, or Triton's per-container cache, so the natural next step for anyone hitting this is to raise the NCCL timeout and re-run — which on releases before v0.3.1 did nothing (see below).

What

A new section in docs/en/developer_guide/debug.md and docs/zh/developer_guide/debug.md, placed before the INT4 section, with:

• the py-spy check (one rank per node / pipeline stage);
• the two stack shapes that explain most of these hangs: one pipeline stage inside the Triton compiler (fla/ops/gated_delta_rule on GDN models) while the next waits in recv_forward → _communicate_shapes → torch.cuda.synchronize; and, on releases before Support reloading the default process group #2208 / v0.3.1, the rebuilt process groups silently falling back to the default 10-minute timeout regardless of --distributed-timeout-minutes;
• the three ways out (warm the Triton cache before a multi-node launch, share TRITON_CACHE_DIR, size the timeout to cover the first step);
• how to recognize a real collective mismatch instead, and what to attach to an issue.

Where the numbers come from

2 × 8 H20, Qwen3.6-35B-A3B, TP2 / PP2 / EP8, colocate, on the slime fork: cold first actor_train 639 s and the preceding log-prob pass 394 s; the same passes 60 s and 13 s once ~/.triton/cache was warm. py-spy on all 16 ranks during the stall showed 8/8 stage-0 ranks in triton/backends/nvidia/compiler.py:make_llir and 8/8 stage-1 ranks in recv_forward. The timeout claim was verified with a two-process probe against reload_process_groups() before and after #2208: _get_backend(device).options._timeout goes 2:00:00 → 0:10:00 on the old code and stays 2:00:00 after.

Docs only; en and zh updated together.

🤖 Generated with Claude Code