[Performance] RDT vs Direct YuanrongStore Backend Performance Analysis
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- python
- 领域
- backend, performance
调研方向
从 TransferQueue RDT 和 YuanrongStore 的 backend 路径开始，首先关注 RayStorageClient.get 和 yr.get，然后在 16 GB 下重现已报告的 TQ-RDT-YR 和 TQ-YR 对比。完成标准是确定为什么 TQ Client 的耗时在该大小下会急剧增加，并记录 batching 与按键传输是否是观察到的差异的原因。
由索引模型根据 Issue 内容生成。
描述
Background
Currently, TransferQueue supports multiple transmission backends, including:
-
RDT (Ray Direct Transport): The native distributed transmission mechanism of Ray, usually using NIXL as the underlying transmission between GPUs
-
YR (YuanrongStore): A high-performance data transmission system optimized for the NPU architecture, similar in function to NIXL but more suitable for the Ascend hardware
The purpose of this issue is to benchmark and analyze the performance overhead introduced by RDT (Ray Distributed Object Store) when using DS as the transmission backend. We conducted a comparative test between two scenarios on NPU cross-node environments:
-
TQ-RDT-YR: TransferQueue using RDT as the backend, where RDT uses YuanrongStore for data transmission.
-
TQ-YR: TransferQueue using YuanrongStore directly for data transmission.
Key Objectives
Evaluate the performance cost of the RDT layer.
Test Results
TQ-RDT-YR Get Cost
| seq_length | total_size | TQ CLIENT get (s) | Ray Storage Client get (s) | BandWidth (GB/s) | BW_RayStorageClient (GB/s) |
|---|---|---|---|---|---|
| 32 KB | 64MB | 0.86 | 0.85 | 0.07 | 0.07 |
| 128 KB | 256MB | 0.85 | 0.83 | 0.30 | 0.30 |
| 512 KB | 1 GB | 0.93 | 0.91 | 1.07 | 1.10 |
| 1 MB | 2 GB | 0.95 | 0.94 | 2.10 | 2.13 |
| 2 MB | 4 GB | 1.13 | 1.11 | 3.55 | 3.61 |
| 4 MB | 8 GB | 1.43 | 1.41 | 5.58 | 5.68 |
| 8 MB | 16 GB | 13.60 | 1.80 | 1.18 | 8.88 |
TQ-YR Get Cost
| seq_length | total_size | TQ CLIENT get (s) | Ray Storage Client get (s) | BandWidth (GB/s) | BW_RayStorageClient (GB/s) |
|---|---|---|---|---|---|
| 32 KB | 64MB | 0.14 | 0.12 | 0.46 | 0.52 |
| 128 KB | 256MB | 0.15 | 0.13 | 4.69 | 1.87 |
| 512 KB | 1 GB | 0.14 | 0.12 | 7.18 | 8.07 |
| 1 MB | 2 GB | 0.17 | 0.15 | 12.10 | 13.35 |
| 2 MB | 4 GB | 0.26 | 0.25 | 15.20 | 16.21 |
| 4 MB | 8 GB | 0.51 | 0.47 | 15.71 | 17.13 |
| 8 MB | 16 GB | 12.77 | 0.90 | 1.25 | 17.85 |
Proposed Analysis
Regarding the reason for the time difference in the RayStorageClient.get in the two scenarios, we speculate that it is because YRStore performs batch processing, getting all items together in one batch, while RayStore processes them individually. Each key is a separate reference, and even when calling yr.get, only one can be transferred at a time.
Remaining doubts
- When the total data volume reached 16GB, the time taken from the
TQ ClienttoRayStore/YRStoresuddenly increased significantly. Looking at the green section in the figure below, you can see that it suddenly expands significantly when the capacity reaches 16GB.
- 主要语言
- Python
- 星标
- 168
- 派生
- 56
- 平均合并
- 4 天 1 小时
- 30 天内合并 PR
- 15
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
Ascend/TransferQueue 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
Ascend/TransferQueue#194 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 55/100
Ascend/TransferQueue#195 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 30/100
Ascend/TransferQueue#188 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
Ascend/TransferQueue#180 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
Ascend/TransferQueue#173 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
查看 Ascend/TransferQueue 的全部 Issue
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 72/100
521xueweihan/HelloGitHub#4150 ·
-
难度 2/5 1-3 小时 新手友好度 74/100
aws-samples/sample-per-model-bedrock#595 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 85/100
维护者通常 1 天内回复
-
bug connectors
难度 1/5 1 小时以内 新手友好度 67/100
pyinfra-dev/pyinfra#2036 ·
维护者通常 9 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复