deepseek-ai/DeepEP
1
0
Fork 0
mirror of https://github.com/deepseek-ai/DeepEP.git synced 2026-11-05 00:47:32 +00:00
Code Issues 308 Projects Packages Wiki Activity

[PR #440] Fix racing condition in large batch size #571

New issue
Open
opened 2026-10-27 21:04:10 +00:00 by bsakaguchi · 0 comments
bsakaguchi commented 2026-10-27 21:04:10 +00:00
Owner
Copy link

📋 Pull Request Information

Original PR: https://github.com/deepseek-ai/DeepEP/pull/440
Author: @fzyzcjy
Created: 10/2/2025
Status: 🔄 Open

Base: main ← Head: patch-10

📝 Commits (1)

📊 Changes

1 file changed (+1 additions, -1 deletions)

View changed files

📝 csrc/kernels/configs.cuh (+1 -1)

📄 Description

In internode_ll.cu, the logic is:

                lane_id == 0 ? atomic_add_release_global(atomic_finish_counter_per_expert + dst_expert_idx, 1) : 0;
...
                atomic_add_release_global(atomic_finish_counter_per_expert + i, FINISHED_SUM_TAG);
...
                atomic_add_release_global(atomic_finish_counter_per_expert + i, FINISHED_SUM_TAG - sum);
...
        while (ld_acquire_global(atomic_finish_counter_per_expert + responsible_expert_idx) != FINISHED_SUM_TAG * 2);

In my naive understanding, if the batch size is >1024 (which is possible since a extreme case can have bs 1400), then it is possible that after sending the first 1024 tokens, we already reach the last while condition (since FINISHED_SUM_TAG=1024), and we send signals prematurely, causing bugs.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/deepseek-ai/DeepEP/pull/440 **Author:** [@fzyzcjy](https://github.com/fzyzcjy) **Created:** 10/2/2025 **Status:** 🔄 Open **Base:** `main` ← **Head:** `patch-10` --- ### 📝 Commits (1) - [`f00ce65`](https://github.com/deepseek-ai/DeepEP/commit/f00ce65a0a6bd3571077ae53d95721e2dde54686) Update configs.cuh ### 📊 Changes **1 file changed** (+1 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `csrc/kernels/configs.cuh` (+1 -1) </details> ### 📄 Description In internode_ll.cu, the logic is: ``` lane_id == 0 ? atomic_add_release_global(atomic_finish_counter_per_expert + dst_expert_idx, 1) : 0; ... atomic_add_release_global(atomic_finish_counter_per_expert + i, FINISHED_SUM_TAG); ... atomic_add_release_global(atomic_finish_counter_per_expert + i, FINISHED_SUM_TAG - sum); ... while (ld_acquire_global(atomic_finish_counter_per_expert + responsible_expert_idx) != FINISHED_SUM_TAG * 2); ``` In my naive understanding, if the batch size is >1024 (which is possible since a extreme case can have bs 1400), then it is possible that after sending the first 1024 tokens, we already reach the last while condition (since FINISHED_SUM_TAG=1024), and we send signals prematurely, causing bugs. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
hybrid-ep
chore/remove-clang-format-yapf
v2.5
nvDev
try-fix-cu128
mori-ep
antgroup-opt
compat-old-torch
add-linter
eager-rdma
v1.2.1
Labels
Clear labels   
pull-request
Mirrored from GitHub Pull Request

No labels
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
deepseek-ai/DeepEP#571
No description provided.