Skip to content

(WIP) perf(comm): add two-stage producer-direct reduction - #1141

Draft
panditsa wants to merge 1 commit into
lightseekorg:sanket/wip-k3-small-m-moefrom
panditsa:sanket/wip-k3-iris-producer-direct
Draft

(WIP) perf(comm): add two-stage producer-direct reduction#1141
panditsa wants to merge 1 commit into
lightseekorg:sanket/wip-k3-small-m-moefrom
panditsa:sanket/wip-k3-iris-producer-direct

Conversation

@panditsa

@panditsa panditsa commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Summary

  • keep one-stage Iris reduction for small producer-direct payloads
  • switch world-size 4/8 payloads above the dtype-aware threshold to reduce-scatter plus all-gather
  • retain BF16, FP16, and FP32 packing behind the existing symmetric-output API

Performance

Exact parent 2ebd8f81 → head 60babeb9, world-size 8 BF16 producer-direct reduction under CUDA-graph replay, critical-rank p50:

Payload M Parent Head Reduction
AttnRes [M,7168] 2 9.26 µs 7.96 µs 14.0%
AttnRes [M,7168] 4 10.68 µs 8.70 µs 18.6%
AttnRes [M,7168] 8 14.52 µs 10.25 µs 29.4%
AttnRes [M,7168] 16 21.04 µs 10.47 µs 50.2%
Joint MoE [M,3584]+[M,7168] 2 9.31 µs 8.30 µs 10.8%
Joint MoE [M,3584]+[M,7168] 4 11.93 µs 9.68 µs 18.9%
Joint MoE [M,3584]+[M,7168] 8 16.88 µs 10.41 µs 38.3%
Joint MoE [M,3584]+[M,7168] 16 26.99 µs 10.75 µs 60.2%

M=2/4 remain on the one-stage path; M=8/16 cross the world-size-8 BF16 two-stage threshold.

Tests

  • threshold, world-size 4/8, noncontiguous subgroup, large-payload, dtype, and repeated graph-replay coverage: 7 passed
  • benchmark validates exact reduced values before timing each eager/captured operation

Stack

Use a reduce-scatter/all-gather Iris path for larger symmetric outputs while retaining the one-stage path for small payloads.

Signed-off-by: Sanket Pandit <sanket.pandit@amd.com>
@panditsa
panditsa force-pushed the sanket/wip-k3-iris-producer-direct branch from 60babeb to 10863f1 Compare August 19, 2026 20:21
@panditsa
panditsa force-pushed the sanket/wip-k3-small-m-moe branch from 2ebd8f8 to 377b289 Compare August 19, 2026 20:25
@jhinpan

jhinpan commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

@panditsa I am validating the #1132 M=8 path on current main (9196fa27) and want to coordinate rather than duplicate this stack.

Exact 131072/1024 TP8/EP8 forced-acceptance=1 now measures 36.80 ms/round versus 17.06 ms ordinary decode (2.157x); forced DSpark is token-identical to ordinary greedy on both a 4K/1K repeated prompt and an exact 131K/128 natural prompt. An all-rank first-64 trace reproduces 5,888 MoE reductions and 11,968 AttnRes kernels. The important caveat for this PR is producer skew: summed attention/MoE Iris durations range from 0.666/0.496 s on rank 5 to 2.624/1.382 s on rank 7, so I will judge #1141 on unprofiled wall time, not isolated reduction latency.

Unless you prefer a different arrangement, I plan to benchmark these existing changes independently on current main: #1141, the M=8 add3 portion of #1135, #1142 plus the communication-only gate from #1146, and #1140's router-warp line. I will not use #1145 or open overlapping kernel PRs; I will post exact results back to the owning PRs first.

@jhinpan

jhinpan commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

Exact #1132 result on 9196fa27: this commit applied standalone did not reach a benchmarkable serving state. The engine became ready, but 1-token health requests took about 4.5–5.5 s and SMG's TokenSpeed gRPC probe repeatedly timed out, so the worker never registered. I stopped the run rather than publish an isolated-kernel extrapolation.

The same #1141 code inside #1141 + #1142 + #1146 does register and completes; that full stack improves forced 131K/1K TPOT from 36.80 to 36.25 ms (-1.49%, three runs). This suggests the downstream state/orchestration changes are required for an E2E-valid use of the two-stage path.

@panditsa

Copy link
Copy Markdown
Contributor Author

@panditsa I am validating the #1132 M=8 path on current main (9196fa27) and want to coordinate rather than duplicate this stack.

Exact 131072/1024 TP8/EP8 forced-acceptance=1 now measures 36.80 ms/round versus 17.06 ms ordinary decode (2.157x); forced DSpark is token-identical to ordinary greedy on both a 4K/1K repeated prompt and an exact 131K/128 natural prompt. An all-rank first-64 trace reproduces 5,888 MoE reductions and 11,968 AttnRes kernels. The important caveat for this PR is producer skew: summed attention/MoE Iris durations range from 0.666/0.496 s on rank 5 to 2.624/1.382 s on rank 7, so I will judge #1141 on unprofiled wall time, not isolated reduction latency.

Unless you prefer a different arrangement, I plan to benchmark these existing changes independently on current main: #1141, the M=8 add3 portion of #1135, #1142 plus the communication-only gate from #1146, and #1140's router-warp line. I will not use #1145 or open overlapping kernel PRs; I will post exact results back to the owning PRs first.

These optimizations help with 4K/1K scenarios but I have not been using/looking at dspark and 131072/1024 performance. Feel free to continue with your investigations. I am glad these PRs are at least getting us to serving state :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants