[GH-ISSUE #152] illegal memory on low_latency_dispatch when test dataset

bsakaguchi commented

2026-10-26 09:55:01 +00:00

Owner

Originally created by @hpz4311 on GitHub (May 10, 2025).
Original GitHub issue: https://github.com/deepseek-ai/DeepEP/issues/152

你好，deepep的作者们，我成功在h20上把deepep集成到我们的项目中，目前internode, intranode的dispatch 和combine kernel都能正常运行，但是在实际运行low_latency_dispatch kernel时, 会在成功运行一些数据之后报错illegal memory, 如下图

我们直接调用了c++接口，对于你们的代码我只做了下面的修改，把low_latency_mode 下的dispatch 和combine 的kNumWrapGroups和 kNumWrapPerGroup 变量改成了8 和 4，防止h20报sm不足的错误。以及在初始化时设置了相关环境变量

排查过程中我尝试在internode_ll.cu 的dispatch kernel中加了一些打印，我发现出错时rdma_recv_count 获取到的值是异常值，之前的代码中应该是使用该地址进行nvshmem通信，我怀疑是rank之间进行rdma_recv_count 通信时发生了异常。
我在单机8卡和多机多卡上都会碰到这个问题，我可以确定我传入的数据是对的，因为出错的数据单独跑都能正常运行，只有在运行数据集时会发生错误，一般跑几条数据就会报错。会不会是实际运行过程中每次num_max_dispatch_token_per_rank 不同导致的。
:单机8卡机时我的local_experts_per_rank = 33 [256 /8 + 1]

请问有什么排查的思路吗，这个问题已经困扰我好几天了，十分感谢。

Originally created by @hpz4311 on GitHub (May 10, 2025). Original GitHub issue: https://github.com/deepseek-ai/DeepEP/issues/152 你好，deepep的作者们，我成功在h20上把deepep集成到我们的项目中，目前internode, intranode的dispatch 和combine kernel都能正常运行，但是在实际运行low_latency_dispatch kernel时, 会在成功运行一些数据之后报错illegal memory, 如下图 ![Image](https://github.com/user-attachments/assets/a0c7e1e9-2817-41d0-966a-ace690b6353f) 我们直接调用了c++接口，对于你们的代码我只做了下面的修改，把low_latency_mode 下的dispatch 和combine 的kNumWrapGroups和 kNumWrapPerGroup 变量改成了8 和 4，防止h20报sm不足的错误。以及在初始化时设置了相关环境变量 ![Image](https://github.com/user-attachments/assets/69e21997-19e3-4240-bcf6-8fd68406223d) ![Image](https://github.com/user-attachments/assets/452badd6-c55a-4b0d-9182-0d7e88825100) 排查过程中我尝试在internode_ll.cu 的dispatch kernel中加了一些打印，我发现出错时rdma_recv_count 获取到的值是异常值，之前的代码中应该是使用该地址进行nvshmem通信，我怀疑是rank之间进行rdma_recv_count 通信时发生了异常。我在单机8卡和多机多卡上都会碰到这个问题，我可以确定我传入的数据是对的，因为出错的数据单独跑都能正常运行，只有在运行数据集时会发生错误，一般跑几条数据就会报错。会不会是实际运行过程中每次num_max_dispatch_token_per_rank 不同导致的。 :单机8卡机时我的local_experts_per_rank = 33 [256 /8 + 1] ![Image](https://github.com/user-attachments/assets/852ee56b-cc47-4baa-a19d-9d1bef84cc9d) ![Image](https://github.com/user-attachments/assets/598046f7-0cb8-4a07-984a-eb1676f498bb) 请问有什么排查的思路吗，这个问题已经困扰我好几天了，十分感谢。

bsakaguchi commented

2026-10-26 09:55:02 +00:00

Author

Owner

@LyricZhao commented on GitHub (May 12, 2025):

要不要先排除下环境的影响，用 Python 的脚本运行 test 之类的会有类似的问题吗？

还有就是你有没有 normal kernel 和 low-latency kernel 混合调用，如果混合调用了这个 buffer 是需要在中间被清零的（有一个专门的函数用来做这个）；你可以在每次 launch 之前都检查下 rdma_recv_count 位置是不是都被清零的？（检查的方式是先 barrier 一下，然后检查，然后再 barrier 一下）。甚至也有可能别的 kernel 写越界了。

这里的逻辑是，最开始是 0，直到别的 rank 发过来让它不是 0 之后就知道真值了。

@LyricZhao commented on GitHub (May 12, 2025): 要不要先排除下环境的影响，用 Python 的脚本运行 test 之类的会有类似的问题吗？还有就是你有没有 normal kernel 和 low-latency kernel 混合调用，如果混合调用了这个 buffer 是需要在中间被清零的（有一个专门的函数用来做这个）；你可以在每次 launch 之前都检查下 `rdma_recv_count` 位置是不是都被清零的？（检查的方式是先 barrier 一下，然后检查，然后再 barrier 一下）。甚至也有可能别的 kernel 写越界了。这里的逻辑是，最开始是 0，直到别的 rank 发过来让它不是 0 之后就知道真值了。

bsakaguchi commented

2026-10-26 09:55:02 +00:00

Author

Owner

@yuan-luo commented on GitHub (May 13, 2025):

有没有可能是 kNumWrapGroups 和 kNumWrapPerGroup 变量改反了？
我们是H20上改成：kNumWarpsPerGroup = 8，kNumWarpGroups = 4

sed -i 's/constexpr int kNumWarpsPerGroup = 10;/constexpr int kNumWarpsPerGroup = 8;/g' ./csrc/kernels/internode_ll.cu
sed -i 's/constexpr int kNumWarpGroups = 3;/constexpr int kNumWarpGroups = 4;/g' ./csrc/kernels/internode_ll.cu

@yuan-luo commented on GitHub (May 13, 2025): 有没有可能是 _kNumWrapGroups_ 和 _kNumWrapPerGroup_ 变量改反了？我们是H20上改成：kNumWarpsPerGroup = 8，kNumWarpGroups = 4 ``` sed -i 's/constexpr int kNumWarpsPerGroup = 10;/constexpr int kNumWarpsPerGroup = 8;/g' ./csrc/kernels/internode_ll.cu sed -i 's/constexpr int kNumWarpGroups = 3;/constexpr int kNumWarpGroups = 4;/g' ./csrc/kernels/internode_ll.cu ```

bsakaguchi commented

2026-10-26 09:55:02 +00:00

Author

Owner

@LyricZhao commented on GitHub (May 13, 2025):

这两个值基本都可以随意变，改错了应该不会 illegal memory access；一般来说，groups 的数量少（2-4 这个范围），一个 group 里面的 warps 数量多（8-12）；乘积 <=32

@LyricZhao commented on GitHub (May 13, 2025): 这两个值基本都可以随意变，改错了应该不会 illegal memory access；一般来说，groups 的数量少（2-4 这个范围），一个 group 里面的 warps 数量多（8-12）；乘积 <=32

bsakaguchi commented

2026-10-26 09:55:03 +00:00

Author

Owner

@hpz4311 commented on GitHub (May 13, 2025):

要不要先排除下环境的影响，用 Python 的脚本运行 test 之类的会有类似的问题吗？

还有就是你有没有 normal kernel 和 low-latency kernel 混合调用，如果混合调用了这个 buffer 是需要在中间被清零的（有一个专门的函数用来做这个）；你可以在每次 launch 之前都检查下 rdma_recv_count 位置是不是都被清零的？（检查的方式是先 barrier 一下，然后检查，然后再 barrier 一下）。甚至也有可能别的 kernel 写越界了。

这里的逻辑是，最开始是 0，直到别的 rank 发过来让它不是 0 之后就知道真值了。

感谢回复，确实有可能是我的其他kernel越界了，不过我暂时没有定位到。听从你的建议，我在每次decode 第一次调用low_latency_dispatch 之前都调用了一下clear_low_latency_buffer(理论上是不需要此操作，因为我没有混合调用normal和ll kernel)，目前测试正常。

@hpz4311 commented on GitHub (May 13, 2025): > 要不要先排除下环境的影响，用 Python 的脚本运行 test 之类的会有类似的问题吗？ > > 还有就是你有没有 normal kernel 和 low-latency kernel 混合调用，如果混合调用了这个 buffer 是需要在中间被清零的（有一个专门的函数用来做这个）；你可以在每次 launch 之前都检查下 `rdma_recv_count` 位置是不是都被清零的？（检查的方式是先 barrier 一下，然后检查，然后再 barrier 一下）。甚至也有可能别的 kernel 写越界了。 > > 这里的逻辑是，最开始是 0，直到别的 rank 发过来让它不是 0 之后就知道真值了。感谢回复，确实有可能是我的其他kernel越界了，不过我暂时没有定位到。听从你的建议，我在每次decode 第一次调用low_latency_dispatch 之前都调用了一下clear_low_latency_buffer(理论上是不需要此操作，因为我没有混合调用normal和ll kernel)，目前测试正常。

bsakaguchi commented

2026-10-26 09:55:04 +00:00

Author

Owner

@LyricZhao commented on GitHub (May 13, 2025):

你可以用 compute-sanitizer + PYTORCH_NO_CUDA_MEMORY_CACHING=1 看看 memcheck 下别的 kernel 有没写越界，现在核心问题就是 buffer 被改了。

@LyricZhao commented on GitHub (May 13, 2025): 你可以用 compute-sanitizer + PYTORCH_NO_CUDA_MEMORY_CACHING=1 看看 memcheck 下别的 kernel 有没写越界，现在核心问题就是 buffer 被改了。

bsakaguchi commented

2026-10-26 09:55:04 +00:00

Author

Owner

@hpz4311 commented on GitHub (May 13, 2025):

你可以用 compute-sanitizer + PYTORCH_NO_CUDA_MEMORY_CACHING=1 看看 memcheck 下别的 kernel 有没写越界，现在核心问题就是 buffer 被改了。

是的，这个问题我还在定位，我尝试下你的方法

@hpz4311 commented on GitHub (May 13, 2025): > 你可以用 compute-sanitizer + PYTORCH_NO_CUDA_MEMORY_CACHING=1 看看 memcheck 下别的 kernel 有没写越界，现在核心问题就是 buffer 被改了。是的，这个问题我还在定位，我尝试下你的方法

bsakaguchi referenced this issue

2026-10-27 21:05:30 +00:00

[PR #695] Fix LL dispatch RC QP assert for all-P2P topologies #712

Rows
Columns

[GH-ISSUE #152] illegal memory on low_latency_dispatch when test dataset #134