[qescccczmr]

Motivation

CUDA 13 images include FLA 0.5.2 but omit FlashKDA, so eligible GLM-5.3 KDA prefill calls cannot use its CUTLASS backend. Package FlashKDA through the existing third-party wheel pipeline used by DeepEP and DeepGEMM.

Modification

• Pin FlashKDA to d7e3b3a9f448500630fa60fb5200f4f9c9b1fc72 and build its wheel only for the cu130 target using pip wheel --no-build-isolation --no-deps. Explicitly compile all upstream-supported architectures for builders without a GPU; bound NVCC/build parallelism.
• Reuse pip install /wheels/*.whl, require the wheel for CUDA 13, and check its import and forward entry point.
• Set FLA_FLASH_KDA=0 in the CUDA 13 production and development image stages. FLA 0.5.2 checks package availability but does not reject unsupported GPU architectures, so enabling it remains explicit: docker run -e FLA_FLASH_KDA=1 ... on supported SM90+ hardware.
• Document activation, fallback and prefill verification in English and Chinese.

FlashKDA remains limited to CUDA 13. Generic runtime requirements and LMDeploy attention/decode implementations are unchanged. This PR is independent of #5071.

The Docker CI follow-up also resolves the latest router release through GitHub's release redirect instead of the rate-limited unauthenticated API, and installs the cuDSS ABI 0 runtime required by Jetson PyTorch wheels with its library directory registered for the dynamic linker.

Validation

• Initial FlashKDA changes passed all applicable pre-commit hooks, shell syntax and git diff --check.
• CI follow-up: five focused router download checks and shell syntax passed in an isolated container. Verified the NVIDIA ARM64 cuDSS package exports libcudss.so.0; the full Jetson runtime check is being rerun in CI.
• Exercised CUDA 13/CUDA 12.8 build selection and required-wheel checks, including missing-wheel rejection.
• Built the pinned wheel inside an isolated Python 3.12 / PyTorch 2.12.1+cu130 container with CUDA 13.0.88 and no visible build GPU. cuobjdump confirmed SM90a, SM100a, SM103a and SM120a cubins.
• Installed the wheel into an isolated directory. On H200, BF16 K=V=128 prefill at 256 and 8,192 tokens dispatched to the real FlashKDA forward function with FLA_FLASH_KDA=1; setting it to 0 selected Triton. Both output and FP32 recurrent state were finite. Relative RMS differences against Triton were approximately 0.00556–0.00563 (output) and 0.00453–0.00479 (state), for synthetic H=4 inputs.
• Full Docker image builds, other GPU architectures, model-quality evaluation and end-to-end serving benchmarks were not run. These operator checks do not establish model-quality equivalence or a serving speedup; the backend stays opt-in.

Checklist

• Pre-commit and focused build/dispatch checks completed.
• Installation documentation updated.
• Full image CI and broader hardware/model validation.

[RunningLeon]

why test docker ci failed ? can you fix it?

[yidingcheng0206]

In the current implementation branch, merely packaging flashKDA into the image only addresses the issue of the missing FlashKDA dependency in the image; it does not guarantee that kda prefill will use it.Please check