mirror of
https://github.com/kvcache-ai/Mooncake.git
synced 2026-11-05 01:17:55 +00:00
[GH-ISSUE #180] Connection refused error when using mooncake store as kvcache store for XpYd disaggregation #87
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#87
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 @Second222None on GitHub (Mar 28, 2025).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/180
Mooncake is a nice work! However, we have the following problem when using the mooncake store as the kvcache store for XpYd disaggregation. Can anyone give some advice? Thanks in advance!
What's more,
Mooncake/mooncake-store/tests/stress_cluster_benchmark.pytest case passed and the configuration:@ShangmingCai commented on GitHub (Mar 28, 2025):
@alogfans Can you check this? I think it might be related to the etcd server or master server setup.
@xiaguan commented on GitHub (Mar 28, 2025):
The etcd and master services seem to be running fine.
The issue appears to be a failure to establish a TCP connection to the target host.
@ShangmingCai commented on GitHub (Mar 28, 2025):
@Second222None, can you provide the full log to show us whether the mooncake store connection is initialized successfully when initializing vLLM? Also, providing the master server log will help us to identify the root cause.
@Second222None commented on GitHub (Mar 31, 2025):
Sorry for late reply! The error occured in 1P2D scenario under LLMPerf test. For simplicity, we setup 1P1D( PD instances each run in a docker and mooncake store runs on the same host.) and collect the full log. Please find the attached full log.
decode1-202503302222.log
etcd-202503311320.log
mooncake_master-202503311320.log
prefill-202503302222.log
proxy-202503311325.log
We see another error(object_already_exist) and the performance number(TTFT) is not within our expectation. Any suggestion is welcome!
TTFT performance number(ms):
@ShangmingCai commented on GitHub (Mar 31, 2025):
@Second222None Thx for the logs.
I see some lines in the logs of decode node:
INFO 03-30 23:16:17 [metrics.py:481] Avg prompt throughput: 778.8 tokens/s, Avg generation throughput: 29.0 tokens/s, Running: 5 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 1.4%, CPU KV cache usage: 0.0%.It means that the decode instances failed to receive the kvcache, so they are running the prefill step by themselves, so the Avg prompt throughput is not zero.
If it runs successfully, you should be able to see this debug info:
DEBUG 03-31 15:49:48 [mooncake_store_connector.py:202] [rank0]: Successfully received all KVs and hidden states, skip model forwarding. (VllmWorkerProcess pid=1586499) DEBUG 03-31 15:49:48 [mooncake_store_connector.py:202] [rank1]: Successfully received all KVs and hidden states, skip model forwarding.Also, the TTFT is supposed to be larger than the vanilla vllm without kvcache transfer before we impl layer-wise async transfer. If you want to reduce TTFT, you should increase the prefill node, instead of the decode node. Increase the number of decode instances will show some performance improvement on TPOT and ITL.
@ShangmingCai commented on GitHub (Mar 31, 2025):
@xiaguan Any idea why all error code info is
object_already_exists?@xiaguan commented on GitHub (Mar 31, 2025):
It simply illustrates that some objects have been inserted multiple times, without compromising the program's correctness. Going forward, it might be more appropriate to classify this log as a debug message, so it doesn't appear by default.
@zhenwei-intel commented on GitHub (Mar 31, 2025):
Hi @ShangmingCai, @xiaguan
I also encountered the same problem. Can you help me explain
object_not_foundandobject_already_exists? And what their appearance represents?@ShangmingCai commented on GitHub (Mar 31, 2025):
@Second222None BTW, can you provide the full command to start all vllm instances? Also, did you install the latest MooncakeStore from the main branch source code, or are you using the release version?
@xiaguan commented on GitHub (Mar 31, 2025):
object_not_foundindicates that the object has never been put, meaning it wasn't found—this is consistent with the semantics of other databases.object_already_existssignifies to put the same object multiple times. Strictly speaking, this is not an error; We'll classify this log as a debug message later.@ShangmingCai commented on GitHub (Mar 31, 2025):
Do you use the same prompt to invoke requests multiple times?
@xiaguan Maybe there might exist some problems when multiple requests want to put the kvcache with the same key since they have the same prompt.
@ShangmingCai commented on GitHub (Mar 31, 2025):
@Second222None @zhenwei-intel Also, tcp is supposed to be slow. I think rdma is required if we want to minimize the communication overhead's impact on TTFT.
@zhenwei-intel commented on GitHub (Mar 31, 2025):
This error occurred this morning, but now I can't reproduce it:
TcpTransport: ASIO exception: connect: Connection refusedI launched a 1P1D setup on 2x V100 GPUs with the following commands:
benchmark scripts
mooncake json
Current issues:
mooncake_store_connector.py, afterself.kv_store.put(store_kvcache_key, kvcache_to_sent), I printed the key names and found duplicates:received all KVs@ShangmingCai commented on GitHub (Mar 31, 2025):
@zhenwei-intel
I think it could be related to concurrent duplicate requests with the same prompt. The hash is computed according to the token_ids, so when one instance hasn't finished putting a kvcache, another instance want to put a kvcache with the same key will report an error, right? @xiaguan
BTW, you don't need to setup
kv_rank,kv_parallel_size, andkv_buffer_sizeforMooncakeStoreConnector.@xiaguan commented on GitHub (Mar 31, 2025):
Yes. More precisely, each object can only be put once; subsequent puts will be skipped (since by design, if the key is the same, the value will be the same), and an
object_already_existmessage will be printed.@Second222None commented on GitHub (Mar 31, 2025):
According to the Mooncake Store doc, there is a TTL feature of get(). If put() skip the duplicate item, for same prompt, MooncakeStore doesn't ensure decoder can get the same kvcache multiple times. Am I right? How to turn off TTL feature.
@xiaguan commented on GitHub (Mar 31, 2025):
Yes, the master service has a TTL feature (disabled by default on the main branch). It deletes the object 1 second after receiving a GET request to free up space. This is mainly to address allocation failure issues and is not closely related to this issue. Apologies for the confusion caused — the documentation will be updated accordingly.
Trun off it
And yes, decode will only get the first successfully put value.
@Second222None commented on GitHub (Mar 31, 2025):
Another question. Does main branch has an eviction mechanism to delete the stale item?
@xiaguan commented on GitHub (Mar 31, 2025):
No. Except for the previously mentioned GC.
@ShangmingCai commented on GitHub (Mar 31, 2025):
@Second222None LRU-based GC will be supported in the future once we align with the v1 design.
@Huixxi commented on GitHub (Apr 1, 2025):
$ mooncake_master --port 50001
bash: mooncake_master: command not found
I met this problem after install mooncake follow this doc: https://github.com/kvcache-ai/Mooncake/blob/main/doc/en/build.md
@ShangmingCai commented on GitHub (Apr 1, 2025):
@Huixxi Can you try pulling the latest updates on the main branch? We are refactoring the compiling and building part now, so it is possible that your clone is in a stale state.
@Huixxi commented on GitHub (Apr 1, 2025):
Ok, thanks, but I eventually find it here Mooncake/build/mooncake-store/src/ 😅
@Huixxi commented on GitHub (Apr 2, 2025):
Could you please help with this issue ? https://github.com/kvcache-ai/Mooncake/issues/201
@Zhou-sx commented on GitHub (Apr 16, 2025):
I encountered the same problem, too. @zhenwei-intel @Second222None Have you solved this problem?
@ShangmingCai commented on GitHub (Apr 16, 2025):
@Zhou-sx Can you check whether your mooncake_master has port conflict?
lsof -i:50051, you should not open multiple mooncake_master , or set up to a port that has been used.@Zhou-sx commented on GitHub (Apr 16, 2025):
I used 50001. If i used conflict port, I will see infomation like these: Port 50001 is already in use. Please specify a different port using --port flag,but I am not.
And the problem appeared after running some steps. I wonder if there are some other problems.
@xiaguan commented on GitHub (Apr 16, 2025):
github.com/kvcache-ai/Mooncake@142e04e526/mooncake-integration/store/store_py.cpp (L101)If you are using the Python binding, mooncake store will randomly select a port for registration—please ensure that ports within this range are available. Alternatively, you can specify it directly by appending it to localhost, as in
localhost:12345.It would be even more helpful if you could provide detailed information about the error.
@Huixxi commented on GitHub (Apr 16, 2025):
emmm, FYI. I changed this port from 50001 to 5001
@Zhou-sx commented on GitHub (Apr 17, 2025):
I found that my Prefill node failed for some reason, so the Decode node encountered connect rejected when trying to retrieve the kv cache stored on the Prefell node.
@github-actions[bot] commented on GitHub (Jul 18, 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 25, 2026):
Closing due to 3 months of inactivity. If this is still relevant, please comment and we can reopen.