[GH-ISSUE #434] Transfer engine line rate possibility #149

New issue

Closed

opened 2026-10-29 21:10:09 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-29 21:10:09 +00:00

Owner

Originally created by @YangZhou1997 on GitHub (May 30, 2025).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/434

Hi Mooncake maintainers,

I wonder what the obstacle is to achieving the network line rate for the transfer engine? Or are there some hidden costs when benchmarking the transfer engine performance? I am referring to this test number: https://github.com/kvcache-ai/Mooncake?tab=readme-ov-file#performance, where for 40GB data, Mooncake Transfer Engine delivers 190 GB/s out of the 400 GB/s (ie, 8×400 Gbps) network bandwidth.

Best,
Yang

Originally created by @YangZhou1997 on GitHub (May 30, 2025). Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/434 Hi Mooncake maintainers, I wonder what the obstacle is to achieving the network line rate for the transfer engine? Or are there some hidden costs when benchmarking the transfer engine performance? I am referring to this test number: https://github.com/kvcache-ai/Mooncake?tab=readme-ov-file#performance, where for 40GB data, Mooncake Transfer Engine delivers 190 GB/s out of the 400 GB/s (ie, 8×400 Gbps) network bandwidth. Best, Yang

bsakaguchi

2026-10-29 21:10:09 +00:00

closed this issue
added the
stale

auto-closed
labels

bsakaguchi commented

2026-10-29 21:10:10 +00:00

Author

Owner

@alogfans commented on GitHub (May 31, 2025):

The figure we reported is based on an earier version of Transfer Engine. In fact, we find that the software overhea (including splitting user request to 64-KB slices, dispatch them into different workers, polling for results and so on) is non-neglected. We will still work for utilizing more bandwidth under high-performance devices.

@alogfans commented on GitHub (May 31, 2025): The figure we reported is based on an earier version of Transfer Engine. In fact, we find that the software overhea (including splitting user request to 64-KB slices, dispatch them into different workers, polling for results and so on) is non-neglected. We will still work for utilizing more bandwidth under high-performance devices.

bsakaguchi commented

2026-10-29 21:10:10 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 8, 2026):

This issue has had no activity for 90 days and will be closed in 7 days if there is no further activity. Please comment or react if it should stay open.

@github-actions[bot] commented on GitHub (Jul 8, 2026): This issue has had no activity for 90 days and will be closed in 7 days if there is no further activity. Please comment or react if it should stay open.

bsakaguchi commented

2026-10-29 21:10:10 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 16, 2026):

Closing due to 3 months of inactivity. If this is still relevant, please comment and we can reopen.

@github-actions[bot] commented on GitHub (Jul 16, 2026): Closing due to 3 months of inactivity. If this is still relevant, please comment and we can reopen.

bsakaguchi referenced this issue

2026-10-29 21:26:43 +00:00

[PR #149] [CLOSED] [FEATURE] Support mounting multiple segments under the same segment_name #1355