Repository navigation
Optimize Triton decoding kernel for long context - #2394
Conversation
| o, | ||
| req_to_token, | ||
| b_req_idx, | ||
| b_start_loc, |
There was a problem hiding this comment.
remove this in the func signature of decode_attention_fwd?
There was a problem hiding this comment.
Sure. max_len_in_batch and triton_attention_reduce_in_fp32 may also need to be removed.
| forward_batch.batch_size, | ||
| self.num_head, | ||
| self.num_kv_splits, | ||
| self.v_head_dim + 1, |
There was a problem hiding this comment.
After this, we do not need to reduce the cuda graph max bs for deepseek models?
|
Hello, does issue #2271 still need further development? I saw this issue and would like to give it a try. However, I noticed that you are currently working on fixing it. Could you share the progress so far? Do you still need any help? @ispobock @merrymercy |
|
This issue didn't aim to solve the problem with speculative decoding using Triton, did it? |
Since #2394, _fwd_kernel_stage1 has reduced q*k in bf16, so every partial sum is rounded in a reduction order the compiler picks and may change between releases. test_grouped_decode_attention (atol=3e-2) fails on ~50% of seeds on both triton 3.7.1 and 3.8.0; the pinned seed 42 merely happened to pass on 3.7.1 and fails on 3.8.0 (pulled in by torch 2.14). This is a latent precision bug, not a triton regression, so fix the kernel rather than loosen the tolerance. Cast the bf16 product to fp32 before the reduction instead of upcasting the operands: same accuracy (0/100 seeds fail, worst normal-vs-grouped gap 0.055 -> 0.016) without materializing a fp32 [BLOCK_N, D] tile, so D=128 stays at 80 registers and short-sequence decode does not regress. The D=576 variant spills less and gets faster (749 -> 470 us at B=8, S=512, H=128 on H200).
Since #2394, _fwd_kernel_stage1 has reduced q*k in bf16, so every partial sum is rounded in a reduction order the compiler picks and may change between releases. test_grouped_decode_attention (atol=3e-2) fails on ~50% of seeds on both triton 3.7.1 and 3.8.0; the pinned seed 42 merely happened to pass on 3.7.1 and fails on 3.8.0 (pulled in by torch 2.14). This is a latent precision bug, not a triton regression, so fix the kernel rather than loosen the tolerance. Cast the bf16 product to fp32 before the reduction instead of upcasting the operands: same accuracy (0/100 seeds fail, worst normal-vs-grouped gap 0.055 -> 0.016) without materializing a fp32 [BLOCK_N, D] tile, so D=128 stays at 80 registers and short-sequence decode does not regress. The D=576 variant spills less and gets faster (749 -> 470 us at B=8, S=512, H=128 on H200).
Since #2394, _fwd_kernel_stage1 has reduced q*k in bf16, so every partial sum is rounded in a reduction order the compiler picks and may change between releases. test_grouped_decode_attention (atol=3e-2) fails on ~50% of seeds on both triton 3.7.1 and 3.8.0; the pinned seed 42 merely happened to pass on 3.7.1 and fails on 3.8.0 (pulled in by torch 2.14). This is a latent precision bug, not a triton regression, so fix the kernel rather than loosen the tolerance. Cast the bf16 product to fp32 before the reduction instead of upcasting the operands: same accuracy (0/100 seeds fail, worst normal-vs-grouped gap 0.055 -> 0.016) without materializing a fp32 [BLOCK_N, D] tile, so D=128 stays at 80 registers and short-sequence decode does not regress. The D=576 variant spills less and gets faster (749 -> 470 us at B=8, S=512, H=128 on H200).
Since #2394, _fwd_kernel_stage1 has reduced q*k in bf16, so every partial sum is rounded in a reduction order the compiler picks and may change between releases. test_grouped_decode_attention (atol=3e-2) fails on ~50% of seeds on both triton 3.7.1 and 3.8.0; the pinned seed 42 merely happened to pass on 3.7.1 and fails on 3.8.0 (pulled in by torch 2.14). This is a latent precision bug, not a triton regression, so fix the kernel rather than loosen the tolerance. Cast the bf16 product to fp32 before the reduction instead of upcasting the operands: same accuracy (0/100 seeds fail, worst normal-vs-grouped gap 0.055 -> 0.016) without materializing a fp32 [BLOCK_N, D] tile, so D=128 stays at 80 registers and short-sequence decode does not regress. The D=576 variant spills less and gets faster (749 -> 470 us at B=8, S=512, H=128 on H200).
Since #2394, _fwd_kernel_stage1 has reduced q*k in bf16, so every partial sum is rounded in a reduction order the compiler picks and may change between releases. test_grouped_decode_attention (atol=3e-2) fails on ~50% of seeds on both triton 3.7.1 and 3.8.0; the pinned seed 42 merely happened to pass on 3.7.1 and fails on 3.8.0 (pulled in by torch 2.14). This is a latent precision bug, not a triton regression, so fix the kernel rather than loosen the tolerance. Cast the bf16 product to fp32 before the reduction instead of upcasting the operands: same accuracy (0/100 seeds fail, worst normal-vs-grouped gap 0.055 -> 0.016) without materializing a fp32 [BLOCK_N, D] tile, so D=128 stays at 80 registers and short-sequence decode does not regress. The D=576 variant spills less and gets faster (749 -> 470 us at B=8, S=512, H=128 on H200).
Motivation
As mentioned in #2271, the original triton decoding kernel has significant performance degradation on long context. We refactored the kernel and adapted the flash decoding implementation from lightllm. Currently, the long context speed decay has been alleviated a lot.
Benchmark
Tested for input 128, output 2048.
Triton (this PR) num_kv_splits=8: 150->138
We can increase the
--triton-attention-num-kv-splitsto get better performance on long context.Triton (this PR) num_kv_splits=16: 150->144
Triton (main branch): 147->126
Flashinfer: 143->143