Purpose

This PR adds Mooncake DummyClient support to MooncakeStoreConnector.

MooncakeStoreConnector was introduced in #40900 as a store-backed KV connector
using MooncakeDistributedStore for shared KV-cache offload and hash-based
prefix cache reuse. This PR extends that connector with a DummyClient mode so a
vLLM worker can connect to a colocated real Mooncake client process instead of
each vLLM process owning its own Mooncake/RDMA resources.

The deployment goal is to let multiple vLLM instances on the same host share one
real Mooncake client / RDMA resource owner, while the vLLM workers access the
store through DummyClient.

Main changes:

• Add DummyClient config fields to MooncakeStoreConfig:
  • enable_dummy_client
  • real_client_address
  • environment overrides:
    • MOONCAKE_ENABLE_DUMMY_CLIENT
    • MOONCAKE_REAL_CLIENT_ADDRESS
• Add a DummyClient initialization path in MooncakeStoreWorker using
  store.setup_dummy(...).
• Keep the existing RealClient path using store.setup(...).
• Add a host-SHM staging ring for DummyClient mode. DummyClient only accepts
  buffers allocated from its shared-memory pool, so direct GPU KV-cache pointer
  registration is not valid. This PR stages GPU KV blocks through DummyClient
  SHM before calling Mooncake store APIs.
• Optimize the staging path with cudaHostRegister and async CUDA copy paths
  where available, with a safe fallback if pinning or async setup fails.
• Preserve upstream kv_cache_config behavior in
  MooncakeStoreWorker.__init__(vllm_config, kv_cache_config), including
  resolve_kv_cache_block_sizes(...), _kv_cache_config, _kv_cache_groups,
  MooncakeStoreCoordinator, and per-group token database setup.
• Add/update focused unit coverage for DummyClient config and staging-ring
  behavior.

DummyClient data path:

vLLM GPU KV cache
        |
        | cudaMemcpyAsync
        v
DummyClient SHM staging ring
        |
        | Mooncake store batch_put / batch_get
        v
Real Mooncake client process
        |
        v
Mooncake distributed store

Test Plan

Unit and lint checks:

git diff --check
ruff check \
  vllm/distributed/kv_transfer/kv_connector/v1/mooncake/store/worker.py \
  vllm/distributed/kv_transfer/kv_connector/v1/mooncake/store/scheduler.py
.venv/bin/python -m pytest tests/v1/kv_connector/unit/test_mooncake_store_worker.py -q

Functional benchmark:

• Compare RealClient, DummyClient sync staging, and DummyClient async+pinned
  staging.
• Benchmark workload:
  • Model: Llama-3.1-8B-Instruct
  • TP: 1
  • Backend: FlashInfer
  • Input/output: 8000 / 200
  • Conversations: 50
  • Turns: 3
  • Concurrency: 16
  • Prefix setup: 10% global prefix + 80% conversation prefix

Test Result

Unit and lint results:

git diff --check
-> passed

ruff check \
  vllm/distributed/kv_transfer/kv_connector/v1/mooncake/store/worker.py \
  vllm/distributed/kv_transfer/kv_connector/v1/mooncake/store/scheduler.py
-> passed

.venv/bin/python -m pytest tests/v1/kv_connector/unit/test_mooncake_store_worker.py -q
-> 10 passed

Performance report summary as follows:

Staging copy microbenchmark:

End-to-end benchmark:

After SHM pinning and async copy optimization, DummyClient mode is within about
3.8% throughput of RealClient mode on this workload, with p99 TTFT within about
2.4%.

Known benchmark limitation: this workload had
external_prefix_cache_hit_rate = 0.0%, so the benchmark primarily measures
DummyClient overhead, not the benefit from external KV-cache hits. Additional
follow-up benchmarking should use a smaller GPU cache or larger working set to
force external Mooncake hits.