You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<!--
**Thanks for contributing to Awex.**
**If this is your first time opening a PR on Awex, you can refer to
[CONTRIBUTING.md](https://github.com/inclusionAI/asystem-awex/blob/main/CONTRIBUTING.md).**
Contribution Checklist
- The **Awex** community has requirements on the naming of pr titles.
You can also find instructions in
[CONTRIBUTING.md](https://github.com/inclusionAI/asystem-awex/blob/main/CONTRIBUTING.md).
-->
## What does this PR do?
<!-- Describe the details of this PR. -->
## Related issues
Closes#94
## Does this PR introduce any user-facing change?
<!--
If any user-facing interface changes, please [open an
issue](https://github.com/inclusionAI/asystem-awex/issues/new/choose)
describing the need to do so and update the document if necessary.
Delete section if not applicable.
-->
- [ ] Does this PR introduce any public API change?
- [ ] Does this PR introduce any binary protocol compatibility change?
Copy file name to clipboardExpand all lines: docs/README.md
+25-20Lines changed: 25 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,40 +23,44 @@ The core functional modules of weight exchange consist mainly of 5 parts:
23
23
-**RDMA weight transmission**: Uses NUMA affinity and RDMA communication for globally load-balanced transfer plan for weight updates;
24
24
25
25
### (1) Unified Training-Inference Weight Convert
26
+
26
27
Due to different computational workloads, training and inference engines generally adopt different parallelism strategies. Megatron training engine uses 5D parallelism strategy, DeepSpeed/FSDP uses Zero + DP data parallelism, while SGLang and VLLM inference engines mostly use DP + TP + EP. Additionally, different engines perform **fusion, transposition, and quantization** optimizations on weights after loading to adapt to high-performance operators.
27
28
28
29
To eliminate differences between different engines for subsequent weight exchange, Awex constructs a **unified weight convert layer** that performs the following converts:
29
30
30
-
+**Weight splitting**: Splits merged weights (such as FFN's gate/up) into independent weights, supporting cross-TP Resharding;
31
-
+**Weight name unification**: Converts all internal weights from all engines to the same namespace, establishing weight mapping relationships between training and inference engines;
32
-
+**Attention weight ReGroup**: On the training engine side, regroups and aligns QKV weights along the inference engine's TP/DPAttention parallelism strategy, avoiding shard explosion from fine-grained splitting;
33
-
+**Quantization, precision, and format conversion**: Automatically converts weights on the training side **according to the precision and format of the inference side**, and this low-precision conversion can also reduce the amount of transmitted data.
31
+
-**Weight splitting**: Splits merged weights (such as FFN's gate/up) into independent weights, supporting cross-TP Resharding;
32
+
-**Weight name unification**: Converts all internal weights from all engines to the same namespace, establishing weight mapping relationships between training and inference engines;
33
+
-**Attention weight ReGroup**: On the training engine side, regroups and aligns QKV weights along the inference engine's TP/DPAttention parallelism strategy, avoiding shard explosion from fine-grained splitting;
34
+
-**Quantization, precision, and format conversion**: Automatically converts weights on the training side **according to the precision and format of the inference side**, and this low-precision conversion can also reduce the amount of transmitted data.
34
35
35
36
The entire weight convert adaptation layer is implemented as a **pluggable structure** that can be fully customized at the engine layer, model weight convert, and sharding layer to meet the customization needs of complex scenarios.
36
37
37
38
### (2) Global Weight Metadata Management
39
+
38
40
Each training and inference process needs to **be aware of the weight metadata of all training and inference processes globally** for constructing subsequent weight transfer plan. Awex also performs **consistency validation of weight metadata between training and inference** at this step. The main workflow is as follows:
39
41
40
-
+ Each process in the training engine performs weight convert and obtains metadata for the converted shards
41
-
+ Through all_gather_object, each rank obtains global training shard metadata
42
-
+ Rank0 on the training side serializes global metadata and reports it to Meta Server
43
-
+ Inference instance 0 on the inference side performs similar work; other inference instances have identical metadata and don't need additional computation
44
-
+ All training and inference processes obtain global metadata from MetaServer
45
-
+ Training and inference engines each perform shard-level metadata consistency and compatibility validation
42
+
- Each process in the training engine performs weight convert and obtains metadata for the converted shards
43
+
- Through all_gather_object, each rank obtains global training shard metadata
44
+
- Rank0 on the training side serializes global metadata and reports it to Meta Server
45
+
- Inference instance 0 on the inference side performs similar work; other inference instances have identical metadata and don't need additional computation
46
+
- All training and inference processes obtain global metadata from MetaServer
47
+
- Training and inference engines each perform shard-level metadata consistency and compatibility validation
46
48
47
49
### (3) P2P Weight Transmission Execution Plan
50
+
48
51
After obtaining global weight metadata, Awex constructs a **deterministic point-to-point transmission plan** within each training and inference process.
49
52
50
53
**Core Strategy** (NCCL mode):
51
54
52
-
+ For each replica of the same tensor shard, assign training shards to inference shards through Round Robin to ensure uniform pulling;
53
-
+ For overlapping shard intervals, if perfectly aligned, directly map; otherwise, use two sends to different shards;
54
-
+ Pre-filter shards related to the current process to avoid constructing a global plan (shards can reach tens of millions for trillion-parameter models);
55
-
+ Ensure strict order consistency of NCCL send/recv;
55
+
- For each replica of the same tensor shard, assign training shards to inference shards through Round Robin to ensure uniform pulling;
56
+
- For overlapping shard intervals, if perfectly aligned, directly map; otherwise, use two sends to different shards;
57
+
- Pre-filter shards related to the current process to avoid constructing a global plan (shards can reach tens of millions for trillion-parameter models);
58
+
- Ensure strict order consistency of NCCL send/recv;
56
59
57
60
RDMA is more flexible than NCCL and uses a separate transmission plan, which we will expand on in subsequent articles.
58
61
59
62
### (4) NCCL Weight Transmission
63
+
60
64
Awex supports two transmission modes: NCCL (NVIDIA Collective Communications Library) and RDMA (Remote Direct Memory Access). NCCL mode is more user-friendly, while RDMA mode is more flexible with higher performance.
61
65
62
66
NCCL transmission mode primarily uses NCCL's send/recv interface for weight transmission. There are some implementation differences in Awex for separated and co-located modes, which we will detail here.
@@ -81,12 +85,13 @@ In this case, Awex uses **CUDA IPC to zero-copy map the training process's GPU m
81
85
82
86
In implementation, we have also made some **performance optimizations**:
83
87
84
-
+**Problem**: Each CUDA IPC Handle's Open/Close has significant overhead; MOE and other models may have thousands to tens of thousands of weight tensors per card requiring IPC serialization;
85
-
+**Solution**: Before IPC serialization, merge tensors by shape and dtype, reducing the count to dozens, greatly reducing CUDA IPC overhead;
88
+
-**Problem**: Each CUDA IPC Handle's Open/Close has significant overhead; MOE and other models may have thousands to tens of thousands of weight tensors per card requiring IPC serialization;
89
+
-**Solution**: Before IPC serialization, merge tensors by shape and dtype, reducing the count to dozens, greatly reducing CUDA IPC overhead;
86
90
87
91
(**Note**: CUDA IPC does not support CUDA virtual memory. Future plans include allocating additional physical memory space for weight merging and transmission when enabling virtual GPU memory in the training engine)
88
92
89
93
### (5) RDMA Weight Transmission
94
+
90
95
Although NCCL transmission mode can already significantly improve weight exchange performance, NCCL mode has two main limitations:
91
96
92
97
1.**NCCL versions on training and inference sides need to remain compatible**, otherwise NCCL transmission may hang, preventing independent updates and iterations of training and inference engines;
@@ -100,9 +105,9 @@ Considering these two reasons, we also developed an RDMA-based transmission impl
100
105
101
106
**RDMA Mode Advantages**:
102
107
103
-
+ Removes NCCL version binding, supports independent iteration of training and inference engines
104
-
+ More flexible transmission plan optimization space
105
-
+ Supports dynamic scaling of inference instances
106
-
+ Further performance improvement (1T model from 20 seconds to 6 seconds)
108
+
- Removes NCCL version binding, supports independent iteration of training and inference engines
109
+
- More flexible transmission plan optimization space
110
+
- Supports dynamic scaling of inference instances
111
+
- Further performance improvement (1T model from 20 seconds to 6 seconds)
107
112
108
113
RDMA mode implementation will be open-sourced soon. Stay tuned.
0 commit comments