mirror of
https://github.com/kvcache-ai/Mooncake.git
synced 2026-11-05 01:17:55 +00:00
[PR #1226] [MERGED] Add Local Cache Mechanism for Mooncake Store Client #2088
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#2088
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?
📋 Pull Request Information
Original PR: https://github.com/kvcache-ai/Mooncake/pull/1226
Author: @Shichang-Zhang
Created: 12/17/2025
Status: ✅ Merged
Merged: 2/11/2026
Merged by: @stmatengss
Base:
main← Head:upstream-zsc-working📝 Commits (10+)
36ee91bfeat(Store): add local hot cache for client4158e59feat(Store): add client local hot cache log to show performance9d4aa0dfix: local hot cache initialize buge9686edfix(Store): Mooncake put slice is max 16MB, so make local hot cache block 16MB6453b95feat(Store): move local hot cache initialization to Client::Create6768f3cfeat(Store): local hot cache remove unused small block implementation8848351feat(Store): add client local hot cache unit test602801efix(Store): modify client local hot cache suit with v0.3.79d57b16feat(Store): change local hot cache unit tes19cca30fix: initialize local hot cache with negative value📊 Changes
9 files changed (+1871 additions, -10 deletions)
View changed files
📝
mooncake-integration/store/store_py.cpp(+0 -1)📝
mooncake-store/include/client_service.h(+65 -0)➕
mooncake-store/include/local_hot_cache.h(+199 -0)📝
mooncake-store/src/CMakeLists.txt(+1 -0)📝
mooncake-store/src/client_service.cpp(+251 -6)➕
mooncake-store/src/local_hot_cache.cpp(+355 -0)📝
mooncake-store/src/transfer_task.cpp(+35 -3)📝
mooncake-store/tests/CMakeLists.txt(+1 -0)➕
mooncake-store/tests/client_local_hot_cache_test.cpp(+964 -0)📄 Description
Description
This PR introduces the client hot cache feature mentioned in Issue 1062.
This feature is enabled by setting the environment variable
LOCAL_HOT_CACHE_SIZE(in bytes). The mooncake store client will allocate memory blocks for caching hot data on a per-request basis. The block size is configurable via the environment variableLOCAL_HOT_BLOCK_SIZE(in bytes), with a default value of 16MB. Memory allocation follows the configured block size unit. IfLOCAL_HOT_CACHE_SIZEis set to less than the block size (either the default 16MB or the value specified byLOCAL_HOT_BLOCK_SIZE), zero, negative, or other invalid inputs (such as non-numeric strings), the client hot cache feature will be disabled.For the standalone client scenario, the feature should be disabled since all things are in local storage.
For the architecture of multiple clients and a master, the feature is recommended for use. Users should adjust the LOCAL_HOT_CACHE_SIZE value based on their actual deployment context to strike an optimal balance: the performance gain from reduced cross-node data transfer outweighs the overhead of additional local cache memory.
Type of Change
How Has This Been Tested?
Run unit test for the feature
mooncake-store/tests/client_local_hot_cache_test.cpp.Performance Test
Software
Hardware
Mooncake Performance Test
Environment
We run the test on a Kubernetes cluster that involves two Atlas 800I A2 machines.
Method
Start master-service pod as Mooncake Master and redis pod as the metadata server.
Start a Mooncake Client pod on node 1.
Call
MooncakeDistributedStore:Putinterface to store data (e.g., 1GB) on Mooncake Client 1.3.1 Store 10 keys with corresponding data (e.g., 1GB total) in Mooncake.
3.2 All data slices are stored on node 1 since only one client exists.
Start another Mooncake Client pod with local hot cache (e.g., 1GB) enabled on node 2.
Call
MooncakeDistributedStore:Get/BatchGetinterface from Mooncake Client 2 to retrieve the stored data.5.1 All data slices are on node 1, so all slices requested by Mooncake Client 2 will be transferred remotely.
5.2 Use TCP protocol to increase network transmission latency.
5.3 After retrieving data from remote node 1, the slices are stored in the local hot cache.
Record the latency of the Get/BatchGet calls.
Repeatedly call
MooncakeDistributedStore:Get/BatchGetinterface from Mooncake Client 2 and record the latency.7.1 These requests result in cache hits.
Result
Note: The latency is measured for each key request, for
BatchGetinterface, first round latency is the average latency of first 2 key.End to End Inference Performance Test
Environment
We run the test on a Kubernetes cluster that involves three Atlas 800I A2 machines. We deployed the inference service with vLLM v0 and Mooncake.
Method
Start master-service pod as Mooncake Master and redis pod as the metadata server.
Start 5 prefill pods and 5 decode pods running vLLM and Mooncake Client. Each client offers 30GB store memory.
2.1 Deploy 10 Mooncake Clients to increase the probability of remote slice data transmission.
2.2 Use TCP protocol and deploy across three machines to increase network transmission latency.
2.3 Prefill instances do not enable the local hot cache feature, while decode instances enable it.
Start proxy server pod for routing inference requests
3.1 Use the example proxy server from vLLM.
Start EvalScope script
4.1 Send 1000 inference requests at concurrency 5 or 10, with a fraction of exact duplicate requests to simulate hotspot/cache hits. Average input length is 4096 tokens and output length is fixed at 256 tokens.
4.2 Use a random dataset to vary prefix lengths, controlling prefix sharing across requests and thus the number of hot slices (and hit rate).
4.3 EvalScope summarizes and logs key performance metrics such as throughput, latency (p50/p95/p99), and success/error rates.
Test Script
Note: This is the start command of the prefill pod. So
POD_IPis the node address of this pod.Note: This is the start command of the decode pod. So
POD_IPis the node address of this pod.Result
Checklist
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.