Skip to content

[CUDA] Support bfloat16 in AllReduce, AllGather and AllToAll - #31571

Merged
tianleiwu merged 1 commit into
mainfrom
tlwu/bf16_collective_ops
Aug 3, 2026
Merged

[CUDA] Support bfloat16 in AllReduce, AllGather and AllToAll#31571
tianleiwu merged 1 commit into
mainfrom
tlwu/bf16_collective_ops

Conversation

@tianleiwu

Copy link
Copy Markdown
Contributor

Description

Adds bfloat16 support to the CUDA collective ops AllReduce, AllGather and AllToAll.

Three things blocked bf16 today:

  1. GetNcclDataType had no BFloat16 case, so any bf16 tensor reaching a collective failed at runtime with Tensor type not supported in NCCL. Now mapped to ncclBfloat16.
  2. The AllReduce CUDA kernel used DataTypeImpl::AllIEEEFloatTensorTypes(), which excludes BFloat16 because bf16 is not an IEEE format. Replaced with an explicit float / double / MLFloat16 / BFloat16 list.
  3. The op schemas did not list tensor(bfloat16). Added to all three. Note that the AllGather and AllToAll kernels already register DataTypeImpl::AllTensorTypes(), so for those two the schema was the only thing rejecting bf16 — no kernel change was needed.

Motivation and Context

bf16 is the native dtype of most current LLMs, so a tensor-parallel graph built from one is bf16 end to end. Hitting an fp32-or-fp16-only AllReduce at every layer boundary forces either a cast pair around each collective (extra kernels and bandwidth on the critical path, twice per layer) or exporting the whole model in fp16.

This came up while bringing up a tensor-parallel + expert-parallel DeepSeek-V4 export on 8×H200, where each of the 43 layers issues two AllReduce on bf16 activations.

Testing

Validated end to end rather than by unit test, since the distributed collective tests require a multi-GPU host and are opt-in:

  • 8-rank TP=8 / EP=8 inference of a 284B bf16 model, 2 × bf16 AllReduce per layer × 43 layers, producing correct token sequences.
  • A full 800-sample MMLU-Pro run over that deployment.

Happy to add a bf16 case to the existing distributed collective test if reviewers would like it in this PR.

Note for reviewers

ncclBfloat16 requires NCCL ≥ 2.10 (mid-2021). CMake currently only version-checks NCCL for the USE_NCCL_P2P define (≥ 2.7) and does not enforce a floor, so in principle a build against NCCL 2.7–2.9 would now fail to compile this file. Every CUDA 12/13 toolchain ships far newer NCCL, so I left it unguarded rather than adding #if NCCL_VERSION_CODE >= NCCL_VERSION(2,10,0) clutter — but let me know if you would prefer the guard or a hard CMake floor.

GetNcclDataType had no mapping for BFloat16, so any bf16 tensor reaching a
collective failed with "Tensor type not supported in NCCL". The AllReduce
kernel additionally used AllIEEEFloatTensorTypes(), which excludes BFloat16
since it is not an IEEE format, and the three op schemas did not list
tensor(bfloat16).

Map BFloat16 to ncclBfloat16, spell out the AllReduce kernel type constraint
as float/double/float16/bfloat16, and add tensor(bfloat16) to the AllReduce,
AllGather and AllToAll schemas. The AllGather and AllToAll kernels already
register AllTensorTypes(), so the schema was the only thing blocking bf16
there.
@tianleiwu
tianleiwu enabled auto-merge (squash) August 3, 2026 18:54
@tianleiwu
tianleiwu merged commit b2fe8b0 into main Aug 3, 2026
87 checks passed
@tianleiwu
tianleiwu deleted the tlwu/bf16_collective_ops branch August 3, 2026 19:27
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