[AMD][Bugfix] Fix vattn_asm HIP error 709 under CUDA graph capture on ROCm 10

[chuyeh]

Motivation

#37465 puts EAGLE verify / draft-extend / q_len-1 decode on the gfx950 vattn_asm kernel, launched through ctypes hipModuleLaunchKernel on the current torch stream. On ROCm 10 images, SGLANG_ASM_VERIFY_ATTN=1 fails during EAGLE verify HIP-graph capture:

RuntimeError: vattn_asm: hipModuleLaunchKernel failed: 709 (context is destroyed)

hipModuleLoad succeeded, so the kernel reports itself active, and the default stream (handle 0) still works. Only a torch stream fails — graph capture included, which is the path decode takes.

Root cause

ROCm 10 ships the HIP runtime (_rocm_sdk_core) and the toolchain (_rocm_sdk_devel) as separate wheels. Torch maps core's libamdhip64.so.7, which the unversioned CDLL("libamdhip64.so") does not match, so the loader takes devel's copy off LD_LIBRARY_PATH as a second HIP runtime: the module loads in devel while the stream belongs to core.

Unpatched, on MI355X:

Image	torch	HIP runtimes mapped	CDLL("libamdhip64.so") binds	Fix needed
rocm720	2.9.1	1	torch's, via the /opt/rocm symlink	no
rocm724	2.11.0	1	torch's, torch/lib/libamdhip64.so	no
rocm10	2.11.0	2	devel's, not torch's	yes

So the trigger is the SDK split, not torch 2.11 — rocm724 has torch 2.11 and one runtime — and the change is a no-op wherever the soname already resolves to torch's object. Same failure mode #30870 fixed for CUDA, where TileLang's libcudart_stub.so could win over the real runtime.

Modifications

• vattn_asm_gfx950/__init__.py: initialize CUDA so torch's HIP is mapped, then bind ctypes to it with the existing find_loaded_library() helper from Avoid TileLang CUDA runtime pollution #30870 rather than to the SONAME. Ten lines in one function; no new private API, no second /proc/self/maps parser.

No disambiguation between the two ROCm 10 copies is included, because none is needed: only torch's copy is ever mapped. After import torch, after CUDA init, and after importing aiter, unified_attention_3d_mtp and aiter_backend, /proc/self/maps holds exactly one libamdhip64:

maps after torch import: [.../_rocm_sdk_core/lib/libamdhip64.so.7]
maps after cuda init:    [.../_rocm_sdk_core/lib/libamdhip64.so.7]
maps after sglang+aiter: [.../_rocm_sdk_core/lib/libamdhip64.so.7]

The devel copy only enters the process if something explicitly dlopens it, which is precisely the bug being removed. Should a future image map both, find_loaded_library() is the single place to teach the preference, for CUDA and HIP at once.

Accuracy Tests

test/registered/amd/test_vattn_segplan_mi35x.py::TestVattnSegPlan::test_launches_on_a_side_stream_and_under_graph_capture (stage-b-test-1-gpu-small-amd-mi35x) launches the kernel on a torch side stream, then captures and replays it in a HIP graph, checking both against the file's existing fp32 reference. It lives with the other gfx950 asm kernel tests and reuses their fixtures.

Verified on MI355X (gfx950):

Image	Unpatched	This PR
v0.5.18-rocm10-mi35x-20260902	FAILED ... 709 (context is destroyed)	3 passed, 16 subtests passed
v0.5.19-rocm720-mi35x-20260913	passes	3 passed, 16 subtests passed
v0.5.18-rocm724-mi35x-20260825	passes	3 passed, 16 subtests passed

The ROCm 10 unpatched column is a negative control: reverting only _hip_lib() to CDLL("libamdhip64.so") makes the new test fail with exactly the reported 709, so the test guards the regression rather than merely passing. With the fix, ctypes binds /opt/venv/.../_rocm_sdk_core/lib/libamdhip64.so.7, the same runtime torch uses.

Speed Tests and Profiling

No speed change: one extra library-path lookup, once per process, at kernel load. This restores the assembly verify path under ROCm 10 HIP-graph capture; the kernel and launch geometry are untouched.

Checklist

• Format your code according to the Format code with pre-commit.
• Add unit tests according to the Run and add unit tests.
• Update documentation according to Write documentations. — no user-facing behaviour or interface changes.
• Provide accuracy and speed benchmark results according to Test the accuracy and Benchmark the speed.
• Follow the SGLang code style guidance.

Review and Merge Process

1. Ping Merge Oncalls to start the process. See the PR Merge Process.
2. Get approvals from CODEOWNERS and other reviewers.
3. Trigger CI tests with comments or contact authorized users to do so.
   • Common commands include /tag-and-rerun-ci, /tag-run-ci-label, /rerun-failed-ci
4. After green CI and required approvals, ask Merge Oncalls or people with Write permission to merge the PR.

---

CI States

Latest PR Test (Base): 🚫 Run #35178338784
Latest PR Test (Extra): ❌ Run #35178338599
Latest PR Test (AMD ROCm 10): ❌ Run #35178338783

[yichiche]

@zijiecode Can you help review this PR?

[zijiecode]

Protection for ROCm 10, LGTM.

[yichiche]

Fixed compatibility issue to support verify asm kernel on ROCm10. LGTM.