Repository navigation
[Model][GLM-5.3-Flash] Warm up the DCP top-k merge kernels for the kpool indexer - #60032
Conversation
CI selector (shadow): 5 test steps (25 jobs) instead of 34 (47 jobs)Shadow mode: this changes nothing about what CI runs. It shows what the evidence-based selector would pick for this PR, next to today's rules. How it works. Feedback welcome: reply here if it would skip a step this change needs, or runs something unrelated.
Selector would run (5)
Would skip (today's rules run them) (32)
Would add (today's rules do not run them) (3)
AMD mirrors: would skip (32)
AMD mirrors: would add (0)none 1 changed files · base |
…ool indexer Under DCP the kpool indexer merges per-rank top-k with the CuteDSL/Triton DCP merge kernels, but only SparseAttnIndexer registered them for JIT warmup, so GLM-5.x compiled PackDCPTopkCandidatesKernel during inference. Register them from SparseAttnIndexerKpool as well. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: NickLucche <nicolo.lucchesi@mistral.ai>
f75c346 to
984782e
Compare
Cover the warmup registration added to SparseAttnIndexerKpool.__init__: both DCP top-k merge kernels are registered under DCP with JIT warmup enabled, and neither is registered without DCP or with warmup disabled. Generated with Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai> Signed-off-by: NickLucche <nicolo.lucchesi@mistral.ai>
LopezCastroRoberto
left a comment
There was a problem hiding this comment.
Thanks for catching this. I think we can drop the test and simplify the condition to current_platform.is_cuda() and has_cutedsl(). The registry already handles enable_jit_warmup, and DCP is guaranteed by the surrounding branch.
Address review feedback: drop the unit test and reduce the warmup condition to `current_platform.is_cuda() and has_cutedsl()`. The JIT warmup registry only compiles registered kernels when `enable_jit_warmup` is on (kernel_warmup gates registry.warmup()), and DCP > 1 is guaranteed by the surrounding branch, so the extra checks are redundant. Generated with Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai> Signed-off-by: NickLucche <nicolo.lucchesi@mistral.ai>
|
Thanks for reviewing @LopezCastroRoberto , addressed! |
LopezCastroRoberto
left a comment
There was a problem hiding this comment.
Gotcha! Sorry for the block @NickLucche. LGTM, thanks!
|
/ci run |
|
✅ Triggered Buildkite CI #93544 for commit |
Purpose
Follow-up to #59211 (now merged; this branch is rebased on main).
Under DCP, the GLM-5.x kpool indexer merges the per-rank top-k with
_merge_dcp_topk_global, which runsPackDCPTopkCandidatesKernelandStableTopKFromGatheredCandidatesKernel. OnlySparseAttnIndexer.__init__registers these kernels for JIT warmup, so with the kpool indexer they were compiled on the first long-context request:This PR registers them from
SparseAttnIndexerKpool.__init__under the same conditions: DCP > 1, JIT warmup enabled, CUDA, and CuteDSL available. #59211 already makes the warmup keys use pool-level top-k and interleave for kpool models.Test Plan
zai-org/GLM-5.3-Flashon 8×H100 withvllm serve, bf16 KV cache, no MTP. TP8 + DCP8 with--cp-kv-cache-interleave-size 4, compared with TP8. GSM8K (1319 questions) at 5, 25, 50 and 100 shots, i.e. prompts from about 650 to about 17k tokens. Checked the server log for JIT monitor warnings.Test Result
PackDCPTopkCandidatesKernelno longer compiles during inference under DCP8. Without this change, it compiled during inference in the same setup. The other JIT warnings in the log (fused_moe_kernel, kpool compress kernels) also appear without DCP and are unrelated.The E2E runs used the same local SM90 FlashMLA bf16 DCP change as #59211, which Hopper needs for DCP at head_dim 512.
Duplicate check
I searched open PRs for kpool /
SparseAttnIndexerKpool/PackDCPTopkCandidateswarmup and found none. #54345 deals with prefill metadata JIT, not the DCP top-k merge kernels.AI assistance
This PR was written with AI assistance (Claude). I reviewed the change and ran the tests above.
🤖 Generated with Claude Code