mirror of
https://github.com/kvcache-ai/Mooncake.git
synced 2026-11-05 01:17:55 +00:00
[GH-ISSUE #887] [Bug]: Specified the topology.json, but it doesn't seem to take effect. #277
Labels
No labels
ascend
auto-closed
bug
bug
CI/Build
Common
documentation
enhancement
feature request
good first issue
help wanted
high priority
MetaX
nightly-failure
pull-request
PyTorch Backend
question
RFC
Roadmap
stale
Store
Tests
Transfer Engine
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
kvcache-ai/Mooncake#277
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lirong-lirong on GitHub (Sep 25, 2025).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/887
Bug Report
I specified the topology.json, but it doesn't seem to take effect.
I'm using Mooncake Store to transfer tensors between two GPUs, and there appears to be a system issue where NICs can only access GPU memory within the same PIX domain (PIX = Connection traversing at most a single PCIe bridge). For example, mlx5_bond_0 can only access cuda:0, and attempting to access cuda:1's memory results in errors. There are related issues in the community (https://github.com/kvcache-ai/Mooncake/issues/851, https://github.com/kvcache-ai/Mooncake/issues/284).
To work around this problem, I specified the topology.json via environment variables.
Here is my topology.json:
Here is my code:
The execution log shows:
According to the logs, the topology.json doesn't seem to be taking effect. Based on the topology.json configuration, it should use mlx_bond_1 to access the memory of cuda:1, but it actually used mlx_bond_4 instead. This behavior persists regardless of whether automatic topology discovery is enabled or disabled. Am I using it incorrectly?
In fact, by disabling automatic topology discovery and forcibly specifying the NIC, the program can execute successfully.
Before submitting...
@xiaguan commented on GitHub (Sep 25, 2025):
Thanks for reporting the issue!
You can check the topology info actually stored by the Transfer Engine by printing the topology info from the HTTP metadata. We'll improve the logging around topology discovery.
@lirong-lirong commented on GitHub (Sep 25, 2025):
@xiaguan
Thanks for your response!
I'm not sure how to retrieve the topology information from the HTTP server - when I tried curling the HTTP server, it returned a 404 error.
However, I used the transfer_engine_topology_dumpscript to get the topology discovery results from the Transfer Engine:
I checked the script and found that it doesn't consider the MC_CUSTOM_TOPO_JSONenvironment variable, so I wrote a simple test script:
The topology result is:
As you can see, the topology looks correct.
I also noticed some discussions in the issues and recompiled Mooncake with -DUSE_CUDA=ON. After recompilation, the automatic topology discovery in Mooncake Store works normally, and my test code can also run successfully.
After examining the code, I believe the issue might lie in the
store.register_bufferinterface. When this Python interface calls the underlying C++RegisterLocalMemoryfunction to register memory, it first usesgetMemoryLocationtodetect the memory location. IfUSE_CUDAis not enabled, it skips the CUDA-related detection logic and directly proceeds to the NUMA node detection for CPU memory, incorrectly identifying GPU memory as Host memory.Thank you very much for your reply!
By the way, I'd like to ask: do the developers have plans to provide CUDA-enabled pip packages? Currently, the precompiled packages available via pip have CUDA disabled by default, which prevents them from correctly identifying GPU memory locations. In some specific environments where NICs can only access GPU memory within the same PIX domain due to hardware or driver limitations, this leads to various
local protection errors(#851, #284). Providing CUDA-enabled pip packages might help reduce some of these issues.@xiaguan commented on GitHub (Sep 25, 2025):
Great insight—you nailed the reason!
Good suggestion. We could take care of it.
In fact, we already have a CUDA pip package (for aarch64, it's manually built and uploaded). For x86_64 (the most commonly used arch), we need to figure out how to package CUDA—specifically, which version to use and how to do it.
I'll give it a try. Could you tell me your CUDA version?
@lirong-lirong commented on GitHub (Sep 25, 2025):
The container image I'm using is based on CUDA 12.8.1. The test was conducted on host machines with different CUDA versions - some running 12.8 and others 12.2.