[PR #643] Support RDMA bandwidth calculation for heterogeneous GPU server configurations #682

Open
opened 2026-10-27 21:05:14 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/deepseek-ai/DeepEP/pull/643
Author: @alpha-baby
Created: 5/25/2026
Status: 🔄 Open

Base: main ← Head: fujh/enhance_get_rdma_gbs


📝 Commits (3)

  • f352c7b enhance get_rdma_gbs in difference arch GPU server
  • cb0f37e fix code format
  • 28efbac Fix setup lint errors

📊 Changes

2 files changed (+87 additions, -35 deletions)

View changed files

📝 deep_ep/utils/envs.py (+60 -6)
📝 setup.py (+27 -29)

📄 Description

Problem Background

The existing implementation of get_rdma_gbs() returned only the bandwidth of a single RDMA NIC. This leads to inaccurate bandwidth calculations in the following heterogeneous server configurations:

  1. GPU-NIC Mismatch: Some server configurations have multiple GPUs sharing fewer RDMA NICs (e.g., 8 GPUs sharing 4 RDMA NICs instead of 1:1 ratio)
  2. NIC Bonding Configuration: Certain network architectures use 802.3ad LACP bonding to aggregate multiple physical NICs into a single logical interface thx @michaelchen1996 RP:https://github.com/deepseek-ai/DeepEP/pull/618

Key Behavioral Changes

Before:

return rate / 8  # Returns single NIC bandwidth only

After:

nic_count = _get_active_rdma_nic_count(output, nic_name)
# Detects bonding and multiplies by slave count...
gpu_count = _get_local_gpu_count()
return rate * nic_count / gpu_count / 8  # Returns per-GPU allocated bandwidth

Compatibility

  • For standard 1 GPU : 1 NIC configurations, the calculation result remains the same as before
  • For multi-GPU shared NIC scenarios, now correctly reflects the actual RDMA bandwidth available to each GPU
  • Function signature remains unchanged, fully backward compatible

🔄 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/643 **Author:** [@alpha-baby](https://github.com/alpha-baby) **Created:** 5/25/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fujh/enhance_get_rdma_gbs` --- ### 📝 Commits (3) - [`f352c7b`](https://github.com/deepseek-ai/DeepEP/commit/f352c7b046742772fdd0dc6c20e98d8dfb119151) enhance get_rdma_gbs in difference arch GPU server - [`cb0f37e`](https://github.com/deepseek-ai/DeepEP/commit/cb0f37ec46cd8e41d93d38490137ae08dea2bbd8) fix code format - [`28efbac`](https://github.com/deepseek-ai/DeepEP/commit/28efbacdfb65da9699bf109c1049157fb60287b0) Fix setup lint errors ### 📊 Changes **2 files changed** (+87 additions, -35 deletions) <details> <summary>View changed files</summary> 📝 `deep_ep/utils/envs.py` (+60 -6) 📝 `setup.py` (+27 -29) </details> ### 📄 Description ## Problem Background The existing implementation of `get_rdma_gbs()` returned only the bandwidth of a single RDMA NIC. This leads to inaccurate bandwidth calculations in the following heterogeneous server configurations: 1. **GPU-NIC Mismatch**: Some server configurations have multiple GPUs sharing fewer RDMA NICs (e.g., 8 GPUs sharing 4 RDMA NICs instead of 1:1 ratio) 2. **NIC Bonding Configuration**: Certain network architectures use 802.3ad LACP bonding to aggregate multiple physical NICs into a single logical interface thx @michaelchen1996 RP:https://github.com/deepseek-ai/DeepEP/pull/618 ## Key Behavioral Changes **Before:** ```python return rate / 8 # Returns single NIC bandwidth only ``` **After:** ```python nic_count = _get_active_rdma_nic_count(output, nic_name) # Detects bonding and multiplies by slave count... gpu_count = _get_local_gpu_count() return rate * nic_count / gpu_count / 8 # Returns per-GPU allocated bandwidth ``` ## Compatibility - For standard 1 GPU : 1 NIC configurations, the calculation result remains the same as before - For multi-GPU shared NIC scenarios, now correctly reflects the actual RDMA bandwidth available to each GPU - Function signature remains unchanged, fully backward compatible --- <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 labels
pull-request
No milestone
No project
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#682
No description provided.