Skip to content

[cuda backend] optimized L_kv threshold for sdpa implementation selection. #20142

Open
Gasoonjia wants to merge 2 commits into
g4-opt-coalesced-scalefrom
g4-opt-sliding-splitk
Open

[cuda backend] optimized L_kv threshold for sdpa implementation selection. #20142
Gasoonjia wants to merge 2 commits into
g4-opt-coalesced-scalefrom
g4-opt-sliding-splitk

Conversation

@Gasoonjia

Copy link
Copy Markdown
Contributor

Our triton/replacement_pass.py adopted a suboptimal threshold to choose between splited_sdpa and regular_sdpa due to misbenchmarking: the benchmark script was a. didn't take cuda graph optimization into account, and b. overfitted into qwen sdpa configuration.

This PR updates benchmarking script to cover gemma4 case as well as other representative case. Based on the results shows as below we take L_kv == 256 as the threshold. With the update, the sliding-window decode attention in gemma4-31b can be benefit from split-sdpa performance gain and decode perf raised from 38.5 tok/s to 43.98 token/s, beats llama.cpp.

gemma sliding (D=256, CTA=16) [B=1 H_q=32 H_kv=16 D=256]

L_kv ET Triton (GQA) (us) ET Split-K (GQA) (us)
64 6.5 7.0
128 9.7 9.0
256 16.1 12.7
512 27.6 13.1
1024 50.8 15.8
2048 102.6 26.0
4096 200.8 54.8
8192 395.2 96.0
16384 784.8 180.2

qwen (D=256, CTA=2) [B=1 H_q=16 H_kv=2 D=256]

L_kv ET Triton (GQA) (us) ET Split-K (GQA) (us)
64 6.4 7.2
128 9.8 9.0
256 15.5 12.4
512 27.0 12.6
1024 49.8 12.7
2048 95.6 13.2
4096 186.6 14.2
8192 370.2 20.6
16384 767.2 33.2

head_dim=128 (D=128, CTA=16) [B=1 H_q=32 H_kv=16 D=128]

L_kv ET Triton (GQA) (us) ET Split-K (GQA) (us)
64 4.5 5.8
128 6.8 7.2
256 11.2 9.5
512 18.6 9.9
1024 33.1 10.5
2048 62.4 13.9
4096 125.8 22.2
8192 247.8 55.5
16384 490.5 98.1

Next

Instead of hard coded the threshold, we should choose the operator base on the actual performance during export. Other refactor is on the way.

Gasoonjia added 2 commits June 9, 2026 00:19
…ied) + benchmark rework

Summary:
At decode (L_q==1) the standard pack-GQA SDPA kernel's grid collapses to
CTA = batch * n_kv_heads, which under-occupies the SMs; split-K flash-decoding
partitions the KV sequence across many more CTAs to fill the GPU. In
ReplaceEdgeOpWithTritonOpPass._pick_sdpa_kernel, route decode to split-K when
L_q==1 and L_kv >= 256 (power-of-2 head dim required; prefill and non-pow2 head
dims keep the standard kernel).

The 256 crossover was measured under CUDA-graph timing (capture+replay, faithful
to the deployed --cuda_graph runtime). The earlier 2048 boundary was overfit to
a plain (non-cuda-graph) microbenchmark, which charged split-K a ~140us per-call
partial-buffer alloc + extra-launch overhead that the graph runtime eliminates;
under faithful timing split-K wins ~1.2-20x from L_kv ~= 256 upward.

benchmark_sdpa.py reworked: deleted run_sweep and all CSV/sentinel machinery;
run_benchmark now compares all six backends (ET-standard, ET-split-K, PyTorch,
Flash, Efficient, Math) with the PyTorch correctness check, across several
decode configs (gemma D256/CTA16, qwen D256/CTA2, D128/CTA16) over the L_kv
range, with a cuda-graph on/off toggle (--mode {cudagraph,plain,both}) timing
every backend through a small self-contained cuda-graph primitive; terminal-only
output. Each reported cell is the mean+/-std over the last 6 of 10 runs (first 4
discarded as warmup; N_RUNS=10, N_WARMUP=4).

Test Plan:
Exercised against the repo (PYTHONPATH) since the conda env's installed
executorch is stale; a lib reinstall is required for the routing to take effect
in a real export.

backends/cuda/tests/test_sdpa_splitk_replacement.py
  - L_kv=128 -> standard; L_kv=256 -> split-K; L_kv=4096 -> split-K;
    non-pow2 D=96 -> standard.
backends/cuda/tests/test_triton_sdpa_splitk.py (14) and
backends/cuda/tests/test_triton_sdpa_nan.py (3) pass. 21 tests total.

gemma4_31b long-context decode (2401-tok prompt, 256 new tokens, temp 0,
--cuda_graph, 10 runs middle-6) with split-K routing: decode 37.91 -> 43.98
tok/s (+16.0%); prefill within noise.

python backends/cuda/benchmarks/benchmark_sdpa.py --mode cudagraph (gemma
D256/CTA16, mean+/-std us): L_kv=2048 ET-std 102.4+/-0.0 / ET-split-K 24.6+/-0.2 /
PyTorch 475.1+/-0.3 / Flash 56.5+/-0.0; L_kv=16384 ET-std 785.5+/-0.0 /
ET-split-K 179.8+/-0.1 / PyTorch 3447+/-2.6. Plain-timing mode shows split-K's
per-call overhead (the artifact behind the old 2048).
@pytorch-bot

pytorch-bot Bot commented Jun 9, 2026

Copy link
Copy Markdown

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20142

Note: Links to docs will display an error until the docs builds have been completed.

❌ 3 New Failures, 2 Pending

As of commit 32e87c2 with merge base a79f3e4 (image):

NEW FAILURES - The following jobs have failed:

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jun 9, 2026
@Gasoonjia Gasoonjia marked this pull request as ready for review June 9, 2026 07:29
@Gasoonjia Gasoonjia changed the title [cuda backend] [cuda backend] optimized L_kv threshold for sdpa implementation selection. Jun 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant