feat(ffn): add deterministic distributed Triton FFN for ROCm - #325
Open
frank-2077 wants to merge 21 commits into
Open
feat(ffn): add deterministic distributed Triton FFN for ROCm#325frank-2077 wants to merge 21 commits into
frank-2077 wants to merge 21 commits into
Conversation
frank-2077
requested review from
Flink-ddd,
KJLdefeated,
bitborne and
inaniloquentee
as code owners
August 20, 2026 15:23
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
Flink-ddd
changed the base branch from
codex/ws2-rocm-strict-attention
to
main
August 21, 2026 15:37
frank-2077
changed the base branch from
main
to
codex/ws2-rocm-strict-attention
August 21, 2026 15:40
zhangj1an
added a commit
that referenced
this pull request
Aug 29, 2026
Applies the PR #325 / #328 measurement matrix and presentation to the strict ROCm Attention path: their timing and accuracy helpers, their spawned distributed world, and their figure style, so the three reports read side by side. Operator-only, no checkpoint; Qwen3-8B shapes (Hq=32, Hkv=8, D=128). Headline: the Triton core is bit-identical to _C.deterministic_attention_* on all eight (dtype, sequence) cases -- out, lse, dQ, dK and dV, zero mismatched elements. TP-degree invariance reproduces PR #319 on independent inputs and shows why the per-KV-group launch schedule is load-bearing. Raw AITER is non-invariant at 5 of 12 (S, TP) points, up to 7.8e-03 out max-abs, and which points fail is shape-dependent: S=512 and S=4096/TP=2 both look clean. The per-KV-group schedule is bitwise at 12/12. Distributed CP runs the real AG/RS schedule -- all-gather Q/K/V and position ids, strict core on the full sequence, reduce-scatter (out, lse) -- and is bitwise against CP=1 on all six topologies including the 8-rank TP=2/CP=2 x2-replica case. Three things the numbers say that were not obvious: - the strict production core is faster than SDPA at S=4096 forward (0.81x), so the bitwise arrangements cost almost nothing on the production path; - AITER's backward peaks at 16.6 GiB at S=4096, 4x the materializing reference core; - both deterministic cores are closer to an FP64 oracle than SDPA or AITER. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01824WkgMDxtBKD4Ex2NkfYA
zhangj1an
added a commit
that referenced
this pull request
Aug 29, 2026
Three gaps, all found by comparing against what PR #325 actually plots and by walking the code paths an H100 run would take. Charts. PR #325's most distinctive figure is a mismatch heatmap (topology x tensor category, annotated, RdYlGn), and we had no equivalent even though the data was already collected. exactness_matrix.png adds it: Triton-vs-reference on the left, CP-topology-vs-CP=1 on the right. Cells that were never measured (fp16 gradients) render as "n/m" on grey rather than 0, which would read as measured-and-equal. The distributed chart also had no baseline, so it could not show what the transport costs; it is now grouped bars against CP=1, which puts AG/RS at 2.2-3.3x. Host support. Timing falls back to wall clock and peak memory to an RSS high-water delta from /proc when there is no device, and NativeAttentionOp joins as pytorch-native -- the one non-SDPA path that also runs on the host. --device selects, and the GPU-only sections are skipped rather than failed. CUDA support, which the H100 run would otherwise have hit head-on. AITER does not exist there, so strict-fa4 (StrictFlashAttention4Core) is the production core on CUDA; TritonDeterministicAttentionOp raises on CUDA by design, so it is now built with require_bitwise_libm=BITWISE_LIBM_PARITY and measured without claiming parity; and the distributed case had StrictRocmAiterCKAttentionCore and the RCCL transport hard-coded, which would have failed every CP topology on an H100 -- it now dispatches on torch.version.hip. reference-hip is renamed reference-native, since on CUDA that same .cu is not a HIP build. --compare-with LABEL=PATH merges another platform's results.json into the report, so mi300x, cpu and h100 runs land in one table with a Platform column; a missing row means the backend cannot exist there, not that it failed. Verified on ROCm after the refactor: all six CP topologies still bitwise against CP=1 with transport reported as rccl_ag_rs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01824WkgMDxtBKD4Ex2NkfYA
Port the HIP IPC fixed-tree transport and packed reduce-scatter path from PR RL-Align#357, with RCCL fallback and focused ROCm coverage.
Record the PR RL-Align#357 collective measurements, preserve the four-way same-topology comparison, and publish the refreshed MI300X artifacts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a ROCm-native deterministic distributed Qwen3 FFN implemented in
Triton. It supports FFN forward/backward across tensor parallelism (TP), context
parallelism (CP), and sequence parallelism (SP), with fixed-order RCCL tensor
transport.
Note
Validation is operator-only. It uses seeded tensors and does not load or
benchmark a model, checkpoint, tokenizer, dataset, or serving engine.
Comparison contract
The three experiments are intentionally independent:
dHidden, anddWeights; acceptance is 0Qwen3MLPat TP=1Qwen3MLPat TP=1 in FP32Native ROCm/RCCL is not used as a numerical-accuracy reference in this report.
Design
kernels; there is no CUDA-generated HIP source in this PR.
GEMM and preserve BF16 stage boundaries in forward and backward.
BF16 rank reduction tree.
tree matches CP=1.
corresponding backward paths.
Operator test matrix
Weights use Hugging Face
[out, in]layout. No model-level benchmark and noseparate gate/up/down projection benchmark is included.
(M,H,I)=(1/8/32,4096,12288), BF16Qwen3MLPTP1; forward and forward+backward(M,H,I)=(32,4096,12288), BF16(M,H,I)=(8,4096,12288)Qwen3MLPTP1 FP16 vs the same operator in FP32ROCm environment
08f47d97d0443c5998b8da6b41a22fdf3848da8fe64ababCorrectness results
dHiddenvs Triton TP1dWeightsvs Triton TP1Commands used:
Performance results
All speed numbers compare complete FFN calls. The official baseline is upstream
Transformers
Qwen3MLPwith unsharded weights and input at TP=1. Distributedtiming uses synchronized wall time and the slowest rank per sample. These rows
compare speed only.
9.03-22.86x7.38-11.56x8.76-15.79x7.45-14.06xThe separate dtype observation runs only official
Qwen3MLPTP1:6.544e-4(0.06544%)2.046e-63.742e-7Full combined report ·
Raw JSON
Communication overlap assessment
The reported implementation serializes dependencies; the measurements do not
claim communication/computation overlap.
TP reduction consumes the down-projection output. These are hard dependencies.
dHiddenare independent untiltheir final ordered addition. A future implementation can reduce one on a
second stream while computing the other.
BF16 stage boundaries, and gate-then-up addition order. It is accepted only if
every TP1 mismatch column remains zero.
Communication implementation provenance
The ROCm deterministic communication operator used by this PR is adopted from PR #357. The current path uses the optimized HIP IPC fixed-tree implementation with RCCL fallback, including the packed
reduce_scatter_manypath for the independent sequence-parallel FFN backward lanes.The checked benchmark report records this implementation provenance and keeps the main performance figure as a four-way same-topology comparison without adding a PR-specific series.