nemo_automodel.components.moe.uccl_ep.buffer
nemo_automodel.components.moe.uccl_ep.buffer
UCCLBuffer: a DeepEP-compatible Buffer backed by UCCL-EP.
This module re-exports the canonical Buffer implementation under the UCCLBuffer alias expected by nemo_automodel, with automatic intranode detection.
Module Contents
Classes
API
The core expert-parallel (EP) communication buffers for Mixture of Experts (MoE) model, which supports:
- high-throughput intranode all-to-all (dispatch and combine, using NVLink)
- high-throughput internode all-to-all (dispatch and combine, using RDMA and NVLink)
- low-latency all-to-all (dispatch and combine, using RDMA)
the number of ranks in the group.
the SMs used in high-throughput kernels.
the local rank number.
the C++ runtime.
Return the current CUDA stream pointer for low-latency runtime calls.
Capture a CUDA event on the current stream, i.e. torch.cuda.current_stream().
Returns: EventOverlap
the captured event.
As low-latency kernels require part of the buffer to be zero-initialized, so it is vital to clean the buffer if the buffer is dirty at some time. For example, after running the normal dispatch/combine, you must run this function before executing any low-latency kernel.
Parameters:
the maximum number of tokens to dispatch, all the ranks must hold the same value.
the hidden dimension of each token.
the number of all experts.
Combine (reduce) tokens (addition without weights) from different ranks, both intranode and internode settings are supported. Intranode kernels require all the ranks should be visible via NVLink. Internode kernels require the ranks in a node should be visible via NVLink, while the ranks with the same GPU index should be visible via RDMA.
Parameters:
[num_tokens, hidden] with torch.bfloat16, the tokens to send for reducing to its original ranks.
a must-set communication handle, you can obtain this from the dispatch function.
[num_tokens, num_topk] with torch.float, the tokens’ top-k weights for reducing to its original ranks.
the performance tuning config.
the event to wait before actually executing the kernel.
the current stream will not wait for the communication kernels to be finished if set.
control whether all the allocated tensors’ ownership to be on the communication stream.
Returns: torch.Tensor
the reduced token from its dispatched ranks.
Destroy the cpp runtime and release resources.
Dispatch tokens to different ranks, both intranode and internode settings are supported. Intranode kernels require all the ranks should be visible via NVLink. Internode kernels require the ranks in a node should be visible via NVLink, while the ranks with the same GPU index should be visible via RDMA.
Parameters:
torch.Tensor or tuple of torch.Tensor, for the first type, the shape must be [num_tokens, hidden],
and type must be torch.bfloat16; for the second type, the first element of the tuple must be shaped as
[num_tokens, hidden] with type torch.float8_e4m3fn, the second must be [num_tokens, hidden // 128]
(requiring divisible) with type torch.float.
an optional communication handle, if set, the CPU will reuse the layout information to save some time.
[num_ranks] with torch.int, the number of tokens to be sent to each rank.
[num_rdma_ranks] with torch.int, the number of tokens to be sent to each RDMA
rank (with the same GPU index), return None for intranode settings.
[num_tokens, num_ranks] with torch.bool, whether a token be sent to a rank.
[num_experts] with torch.int, the number of tokens to be sent to each expert.
[num_tokens, num_topk] with torch.int64, the expert indices selected by each token,
-1 means no selections.
[num_tokens, num_topk] with torch.float, the expert weights of each token to dispatch.
align the number of tokens received by each local expert to this variable.
the worst number of tokens to receive, if specified, there will be no CPU sync, and it will be CUDA-graph compatible. Please also notice that this flag is for intranode only.
the performance tuning config.
the event to wait before actually executing the kernel.
the current stream will not wait for the communication kernels to be finished if set.
control whether all the allocated tensors’ ownership to be on the communication stream.
Returns: Union[Tuple[torch.Tensor, torch.Tensor], torch.Tensor]
received tokens, the same type and tuple as the input x, but the number of tokens equals to the
received token count.
Get a recommended combine config.
Argument
num_ranks: the number of ranks.
Returns: Config
the recommended config.
Get the communication stream.
Returns: torch.Stream
the communication stream.
Get a recommended dispatch config.
Argument
num_ranks: the number of ranks.
Returns: Config
the recommended config.
Calculate the layout required for later communication.
Parameters:
[num_tokens, num_topk], dtype must be torch.int64, the expert indices selected by each token,
-1 means no selections.
the number of experts.
the event to wait before actually executing the kernel.
the current stream will not wait for the communication kernels to be finished if set.
control whether all the allocated tensors’ ownership to be on the communication stream.
Returns: torch.Tensor
[num_ranks] with torch.int, the number of tokens to be sent to each rank.
Get the raw buffer (slice supported) as a PyTorch tensor.
Argument:
dtype: the data type (PyTorch dtype) for the tensor.
size: the slice size (by elements) to get from the buffer.
offset: the offset of the beginning element.
use_rdma_buffer: whether to return the RDMA buffer.
Get a minimum size requirement for the RDMA buffer. The size calculation will be done with BF16.
Parameters:
the maximum number of tokens to dispatch, all the ranks must hold the same value.
the hidden dimension of each token.
the number of EP group ranks.
the number of all experts.
Returns: int
the RDMA buffer size recommended.
Get the raw registered RDMA buffer tensor for next low-latency combine, so that the next combine kernel can skip the copying.
Parameters:
the communication handle given by the dispatch function.
Returns:
the raw RDMA low-latency buffer as a BF16 PyTorch tensor with shape
[num_local_experts, num_ranks * num_max_dispatch_tokens_per_rank, hidden], you should fill this buffer
by yourself.
Internode combine implementation, for more details, please refer to the combine docs.
Normally, you should not directly call this function.
Internode dispatch implementation, for more details, please refer to the dispatch docs.
Normally, you should not directly call this function.
A low-latency implementation for combining tokens (reduce with weights) with IBGDA. This kernel requires all the ranks (no matter intranode or internode) should be visible via RDMA (specifically, IBGDA must be enabled). Warning: as there are only two buffers, and the returned tensors reuse the buffer, you cannot hold more than 2 low-latency kernels’ result tensors at a single moment.
Parameters:
[num_local_experts, num_max_dispatch_tokens_per_rank * num_ranks, hidden] with torch.bfloat16,
the local calculated tokens to be sent to this original rank and reduced.
[num_combined_tokens, num_topk] with torch.int64, the expert indices selected by the dispatched
tokens. -1 indices (not selecting any expert) are supported. Note that, num_combined_tokens equals
to the number of dispatched tokens.
[num_combined_tokens, num_topk] with torch.float, the expert weights selected by the dispatched
tokens. The received tokens will be reduced with the weights in this tensor.
the communication handle given by the dispatch function.
whether to use an internal “LogFMT with dynamic per-64-channel cast” format (10 bits).
whether the tensor is already copied into the RDMA buffer, should be cooperative
with get_next_low_latency_combine_buffer.
the current stream will not wait for the communication kernels to be finished if set.
return a receiving hook if set. If set, the kernel will just do the RDMA request issues, but without actually receiving the data. You must call the received hook to make sure the data’s arrival. If you do not set this flag, the kernel will ensure the data’s arrival.
the in-place output tensor, if set, the kernel will write the result to this tensor and return it directly.
a cumulative time spent waiting to receive each token tensor for statistics,
which should have shape [num_ranks, num_ranks] and be typed as torch.int64.
This is useful for detecting and pre-cisely localizing slow anomalies.
Returns: torch.Tensor
the reduced token tensor, with shape [num_combined_tokens, hidden] and type torch.bfloat16.
A low-latency implementation for dispatching with IBGDA. This kernel requires all the ranks (no matter intranode or internode) should be visible via RDMA (specifically, IBGDA must be enabled). Warning: as there are only two buffers, and the returned tensors reuse the buffer, you cannot hold more than 2 low-latency kernels’ result tensors at a single moment.
Parameters:
torch.Tensor with torch.bfloat16, shaped as [num_tokens, hidden], only several hidden shapes are
supported. The number of tokens to be dispatched must be less than num_max_dispatch_tokens_per_rank.
torch.Tensor with torch.int64, shaped as [num_tokens, num_topk], only several top-k shapes
are supported. -1 indices (not selecting any expert) are supported.
the maximum number of tokens to dispatch, all the ranks must hold the same value.
the number of all experts.
a cumulative expert count tensor for statistics, which should have shape
[num_local_experts] and be typed as torch.int. This is useful for online service EP load balance
monitoring.
a cumulative time spent waiting to receive each token tensor for statistics,
which should have shape [num_ranks, num_ranks] and be typed as torch.int64.
This is useful for detecting and pre-cisely localizing slow anomalies.
whether to enable FP8 casting, with this, the received data will be a tuple of FP8 tensor and scaling factors.
whether round the scaling factors into power of 2.
whether use UE8M0 as scaling factor format (available only with round_scale=True).
the current stream will not wait for the communication kernels to be finished if set.
return a receiving hook if set. If set, the kernel will just do the RDMA request issues, but without actually receiving the data. You must call the received hook to make sure the data’s arrival. If you do not set this flag, the kernel will ensure the data’s arrival.
Returns: Tuple[torch.Tensor, torch.Tensor]
a tensor or tuple with received tokens for each expert.
With use_fp8=True: the first element is a torch.Tensor shaped as
[num_local_experts, num_max_dispatch_tokens_per_rank * num_ranks, hidden] with torch.float8_e4m3fn.
The second tensor is the corresponding scales for the first element with shape
[num_local_experts, num_max_dispatch_tokens_per_rank * num_ranks, hidden // 128] with torch.float,
if use_ue8m0=False. With use_ue8m0=True, the second one is packed and shaped as
[num_local_experts, num_max_dispatch_tokens_per_rank * num_ranks, hidden // 512] with type torch.int.
Notice that, the last-two-dimension of the scaling tensors are in column-major for TMA compatibility.
With use_fp8=False, the result would be a tensor shaped as
[num_local_experts, num_max_dispatch_tokens_per_rank * num_ranks, hidden] with torch.bfloat16.
Moreover, not all tokens are valid, only some of the num_max_dispatch_tokens_per_rank * num_ranks are,
as we do not synchronize CPU received count with GPU (also not incompatible with CUDA graph if synced).
Reset the RDMA buffer, this is useful when you want to reuse the RDMA buffer for another run.
Set the number of SMs to use in high-throughput kernels.
Parameters:
the new number to be set.
A wrapper class to manage CUDA events, also for better overlapping convenience.
Utility for overlapping and Python with syntax.
You can overlap the kernels on the current stream with the following example:
Utility for overlapping and Python with syntax.
Please follow the example in the __enter__ function.
The current stream torch.cuda.current_stream() waits for the event to be finished.
Bases: Buffer
Buffer subclass that auto-detects intranode mode.
When all EP ranks fit on a single node (group_size <= LOCAL_WORLD_SIZE), RDMA is disabled and only NVLink is used, avoiding RDMA MR registration failures on single-node setups.