Configuration Reference#
This page documents every CLI argument accepted by the LMCache multiprocess server. Arguments are grouped by the config module that defines them.
Per-request LMCache configuration#
vLLM clients can attach request-scoped LMCache metadata through the top-level
kv_transfer_params field. When vLLM uses LMCacheMPConnector, entries
whose keys start with lmcache. are forwarded with the request across the
MP scheduler and worker IPC paths. Other kv_transfer_params entries are
reserved for the transfer layer and are not forwarded to LMCache.
For example:
curl -X POST http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen3-14B",
"prompt": "Explain KV cache reuse.",
"max_tokens": 32,
"kv_transfer_params": {
"lmcache.tag.tenant": "example-tenant",
"lmcache.ttl": 60
}
}'
The connector carries these values on lookup, prefetch, store, retrieve, and lookup-lock cleanup operations so server-side features can inspect the same request metadata throughout the request lifecycle.
Important
Forwarding a value does not by itself make the MP server act on it or make
it part of cache identity. The current MP server treats request configs as
metadata. Do not rely on lmcache.tag.*, lmcache.ttl,
lmcache.skip_save, or another request config for isolation, expiration,
or cache-control behavior in MP mode unless the selected server-side
feature explicitly documents support for it. The in-process
LMCacheConnectorV1 may interpret these values differently.
The MP server’s default --kv-load-policy acts on lmcache.skip_load: a
request that sets it to true gets a lookup miss and is recomputed by the
engine. Load policies receive the request configs as sent. The vLLM
LMCacheMPConnector, the unified SGLang MP connector, and the TensorRT-LLM MP
adapter add lmcache.hint.engine_computed_tokens, the tokens the engine
already holds in its own prefix cache, to their lookups. vLLM omits it on
eager-prefetch lookups, which run before vLLM checks its prefix cache.
MP Server#
Source: lmcache/v1/multiprocess/config.py
Argument |
Default |
Description |
|---|---|---|
|
|
Request transport exposed by the server. Choices: |
|
(unset, default UUID v4) |
Stable identity of this MP server. Used as the coordinator
membership key and projected onto the OTel
|
|
|
Host address to bind the selected request server. |
|
|
Port to bind the selected request server. |
|
|
Minimum chunk size for KV cache operations (in tokens). The vLLM MP connector may negotiate it upward to satisfy the model’s KV geometry; see Chunk-Size Negotiation. |
|
|
Engine block ID that denotes absent KV data. Keep the default for
vLLM-compatible layouts. Engines where block |
|
|
Base number of worker threads. Sets the default for both the GPU
(affinity) pool and the CPU (normal) pool. Can be overridden
per-pool with |
|
(inherits |
Worker threads for the GPU affinity pool (STORE/RETRIEVE). Requests from the same vLLM instance are always dispatched to the same thread, eliminating GPU transfer lock contention. |
|
(inherits |
Worker threads for the normal CPU pool (LOOKUP, etc.). |
|
|
gRPC request-dispatch threads. Used only with |
|
|
gRPC server implementation: |
|
|
Hash algorithm for token-based operations.
Choices: |
|
|
Cache engine backend type. |
|
|
Which worker → server transfer paths the server loads.
|
|
|
Assume engine workers and this server run in containers that share
no host IPC namespace ( |
|
|
Zero or more paths to runtime plugin scripts or directories to
launch alongside the server. Plugins are spawned by
|
|
|
JSON string of extra key-value config forwarded to runtime
plugins via |
|
|
Space-separated list of Python module names that scripts posted
to the HTTP |
|
|
Enable the |
|
|
SHM segment name for non-GPU KV transfer (only used when the
non-GPU path is loaded, i.e. |
|
|
CPU store-completion and eviction records retained for subscriptions
and reconnects. Workers receive pushes over ZMQ or gRPC and republish
them as KV events. |
|
|
Silence budget (seconds) after which a worker that has sent at
least one heartbeat PING but then gone quiet has its KV cache
registration reaped, freeing the leaked GPU context and CUDA IPC
handles. |
|
|
Silence budget (seconds) for a worker that registered but has never
sent a PING (still warming up, or died before its first request).
Must be >= |
|
|
Per-request choice between serving a lookup and letting the engine
recompute the prompt. The policy runs before the prefetch, so a
declined lookup fetches nothing from L2 and takes no locks; the engine
sees a miss. |
|
|
CacheBlend ( |
|
|
|
|
|
Split a hybrid model’s kernel groups into one object group per
cross-chunk attention window (full attention, each sliding-window
size, mamba/GDN) at KV-cache registration. Off by default; pass
|
Lookup Hash Logging#
Source: lmcache/v1/mp_observability/subscribers/logging/lookup_hash.py
When enabled, the server publishes chunk hashes computed during lookup()
as MP_LOOKUP events on the EventBus. The
LookupHashLoggingSubscriber writes these to rotating JSONL files for
offline analysis. Disabled by default. These arguments are part of the
Observability group.
Argument |
Default |
Description |
|---|---|---|
|
|
Directory to write lookup hash JSONL files. An empty string disables logging. |
|
|
Time interval in seconds before rotating to a new log file. |
|
|
Max file size in bytes before rotating even if the time interval has not elapsed. |
|
|
Max number of log files to keep. Oldest files are deleted when this limit is exceeded. |
HTTP Frontend#
Source: lmcache/v1/multiprocess/config.py
The HTTP frontend is included when running lmcache server.
Argument |
Default |
Description |
|---|---|---|
|
|
Host to bind the HTTP (FastAPI/uvicorn) server. |
|
|
Port to bind the HTTP server. |
|
unset |
Read a bearer API key from a file. Repeat the option to accept multiple
keys during rotation. |
P2P#
Source: lmcache/v1/multiprocess/config.py
These flags configure peer-to-peer KV cache sharing between MP servers
(see P2P KV Cache Sharing). They are registered by add_p2p_args() on the
lmcache server parser. P2P is enabled when --p2p-advertise-url
is set, which additionally requires a coordinator URL via
--coordinator-url (or LMCACHE_COORDINATOR_URL).
Argument |
Default |
Description |
|---|---|---|
|
|
Transfer-channel server |
|
|
Transfer-channel server |
|
|
Seconds before a peer lookup result counts as a miss. |
|
|
Seconds before a peer load counts as a failure. |
|
|
Transfer-channel implementation to use. |
L1 Memory Manager#
Source: lmcache/v1/distributed/config.py
Use repeatable --l1-manager '<JSON>' for tagged DRAM, Device-DAX, and
GDS managers. See Multiple L1 Managers for the schema, placement order, fixed
L2 affinity, and per-manager reporting. The flags below remain the legacy
single-L1 interface.
Argument |
Default |
Description |
|---|---|---|
|
required without |
Size of the L1 tier in GB. Sizes the pinned-DRAM L1 by default, or the
GDS slab file when |
|
|
Enable or disable lazy allocation for L1 memory.
Pass |
|
|
Initial allocation size (GB) when using lazy allocation. |
|
|
Alignment size in bytes (default 4 KB). |
|
|
Allocate the L1 pool from the 2 MiB hugepage pool instead of regular
pinned memory. It requires pre-allocated hugepages
( |
|
(not set) |
Optional |
|
|
ROCm only. |
Locked L1 on ROCm#
On ROCm, hipHostRegister does not page-lock memory: when the kernel
migrates a registered L1 page (memory compaction), the driver evicts all GPU
queues of the server until the mapping is restored, which stalls transfers for
seconds. --l1-mlock keeps the L1 as ordinary anonymous memory (O_DIRECT,
RDMA registration and memory-cgroup accounting are unchanged) and locks it.
Requirements, checked at startup:
the node sets
sysctl -w vm.compact_unevictable_allowed=0; otherwise compaction still moves locked pages;the server may lock the whole L1:
docker run --ulimit memlock=-1orCAP_IPC_LOCK.
Not covered: explicit page migration (move_pages, migrate_pages,
NUMA balancing), khugepaged when transparent huge pages are always
(use madvise or never), and host memory registered by other
processes such as vLLM. Device-DAX L1 is rejected.
GDS L1 Tier#
Source: lmcache/v1/distributed/config.py
Opt-in. Setting --gds-l1-path switches the L1 medium from pinned DRAM to
an NVMe slab file accessed via GPUDirect Storage DMA. The CPU pinned-DRAM tier
is then disabled, and --l1-size-gb sizes the slab. Disable byte-array L2
adapters when this is on (the GDS tier exposes no L1 memory buffer for them to
register).
The DMA path is selected automatically by platform: cuFile
(libcufile.so) on NVIDIA and hipFile (libhipfile.so,
ROCm/hipFile) on AMD ROCm. The same
flags apply to both; no configuration change is needed to switch vendors.
muFile (libmufile.so) is selected automatically on MUSA, or
explicitly with --gds-l1-backend mufile. It uses the SmartIO muFile
stream-ordered API and a filesystem slab, so the SmartIO runtime and its
MUSA-compatible libmufile.so must be installed on every worker.
uGDS (libugds.so) is a third, opt-in backend selected with
--gds-l1-backend ugds. It is a user-space GPUDirect Storage library that
builds NVMe commands and rings doorbells from user space, so its IO path issues
no syscall. LMCache can use uGDS on either NVIDIA CUDA or AMD ROCm. Each
deployment must use a libugds.so built for its active platform. Unlike
cuFile and hipFile, uGDS does not use a filesystem: the slab is mapped directly
onto a raw character device, and --gds-l1-path must name that device (for
example /dev/ugds_drv0) rather than a directory. The first
--l1-size-gb bytes of the device are the slab, so the device must be at
least that large and must not hold anything else.
Phoenix (libphoenix.so) is a fourth opt-in backend selected with
--gds-l1-backend phx. Phoenix (phxfs) provides a kernel-mediated
user-space NVMe-to-GPU DMA path with a very low software-stack overhead.
Like cuFile and hipFile it uses a filesystem slab: --gds-l1-path names
an NVMe directory, --gds-l1-use-direct-io applies, and the slab file
can share the disk with other data. Each GPU staging buffer is registered with
phxfs (phxfs_regmem, 64 KiB-aligned) and the slab is read and written
with stream-ordered submissions (phxfs_read_stream /
phxfs_write_stream) that keep the DMA ordered with the other work on
the stream. A libphoenix build without the stream-ordered API fails
to load. Follow the
Phoenix installation guide
to build libphoenix.so, load the phoenixfs kernel module, and
verify the installation.
Note
AMD hipFile requires ROCm >= 7.2.0. The zero-copy GPUDirect fast path
additionally needs a kernel built with CONFIG_PCI_P2PDMA,
amdgpu-dkms >= 30.20.1, and the slab on a local NVMe ext4/xfs
filesystem; where those are unavailable hipFile transparently falls back to
a host-bounce compatibility path (correct, but not zero-copy).
Note
uGDS requires its kernel module loaded and the NVMe device bound to it, and
a platform-matching libugds.so reachable through the loader
(LD_LIBRARY_PATH or ldconfig). Because the device is claimed by
ugds_drv rather than the kernel NVMe driver, it carries no filesystem
and cannot be shared with any other consumer while in use. Follow the
uGDS installation guide
to build and load the kernel module, bind the NVMe device, build
libugds.so, and verify the installation.
At startup LMCache queries the namespace capacity through
uGDSGetDeviceCapacity and rejects an aligned --l1-size-gb value larger
than the device. The installed libugds.so must provide this API; LMCache
fails closed with an upgrade message when an older library cannot report
capacity.
Warning
uGDS requires an entire dedicated SSD whose contents may be destroyed. Ensure the SSD is not used for any other purpose and that its contents are not critical.
Note
Phoenix requires the phoenixfs kernel module loaded and a
platform-matching libphoenix.so reachable through the loader
(ldconfig or LD_LIBRARY_PATH). It has been validated on NVIDIA
GPUs; other platforms require a matching libphoenix build and are not
yet tested.
Argument |
Default |
Description |
|---|---|---|
|
Not set |
NVMe directory for the GDS L1 slab, or the raw device path when
|
|
|
GDS implementation: |
|
|
Open the slab with |
L1 Manager TTLs#
Source: lmcache/v1/distributed/config.py
Argument |
Default |
Description |
|---|---|---|
|
|
Time-to-live for each object’s write lock (seconds). |
|
|
Time-to-live for each object’s read lock (seconds). |
Eviction Policy#
Source: lmcache/v1/distributed/config.py
Argument |
Default |
Description |
|---|---|---|
|
required |
Eviction policy.
Choices: |
|
|
Memory usage ratio (0.0–1.0) that triggers eviction. |
|
|
Fraction of allocated memory to evict when triggered (0.0–1.0). |
L2 Policies#
Source: lmcache/v1/distributed/config.py
Argument |
Default |
Description |
|---|---|---|
|
|
L2 store policy. Determines which adapters receive each key
and whether keys are deleted from L1 after L2 store.
The |
|
|
L2 prefetch policy. Determines which adapter loads each key
when multiple adapters have it.
The |
|
|
Maximum number of concurrent prefetch (L2 load) requests. Limits how many in-flight loads the PrefetchController may issue at once, preventing excessive L1 memory pressure. |
|
|
Interval in milliseconds for the periodic event notifier heartbeat. A native C++ background thread writes to all registered file descriptors at this interval, waking controller poll loops for L2 adapters that lack native async completion callbacks. |
L2 Adapters#
Source: lmcache/v1/distributed/l2_adapters/config.py
L2 adapters are configured via repeatable --l2-adapter <JSON> arguments.
Each JSON object must include a "type" field that selects the adapter type.
The optional "affinity_tag" field (default "_default") names the
host-backed L1 used for both stores and reloads; see Multiple L1 Managers.
The order of --l2-adapter arguments determines the adapter order (cascade).
Registered adapter types: nixl_store, nixl_store_dynamic, fs,
fs_native, mock, mooncake_store, aerospike, bigtable,
sagemaker-hyperpod, s3, hfbucket, resp, valkey,
plugin, native_plugin, raw_block, dax, fault_inject.
(A p2p type is also registered, but it is wired in dynamically by the
P2P subsystem rather than configured via --l2-adapter.)
Each adapter type’s required and optional fields, plus per-backend examples, are
documented on its own page under Secondary KV Storage
– including the adapters not detailed inline here (fs_native,
raw_block, dax, mooncake_store, aerospike, bigtable,
sagemaker-hyperpod, hfbucket, resp, valkey).
Multiple adapters (cascade)#
Pass --l2-adapter multiple times. Adapters are used in the order given:
--l2-adapter '{"type": "nixl_store", "backend": "POSIX", "backend_params": {"file_path": "/data/ssd/l2", "use_direct_io": "false"}, "pool_size": 64}' \
--l2-adapter '{"type": "nixl_store", "backend": "GDS", "backend_params": {"file_path": "/data/nvme/l2", "use_direct_io": "true"}, "pool_size": 128}'
Observability#
Source: lmcache/v1/mp_observability/config.py
See Observability for full details on the three modes (metrics, logging, tracing).
Argument |
Default |
Description |
|---|---|---|
|
off |
Master switch: disable the EventBus entirely. |
|
off |
Skip metrics subscribers (no Prometheus endpoint). |
|
off |
Skip gRPC Python runtime metrics while keeping LMCache metrics enabled.
By default, the MP server enables these metrics only for
|
|
off |
Skip logging subscribers. |
|
off |
Register tracing subscribers. Requires |
|
|
Max events in the EventBus queue before tail-drop. |
|
(none) |
OTLP gRPC endpoint for exporting metrics and traces. |
|
|
Port for the Prometheus |
|
|
Fraction of chunks/blocks in |
|
(none) |
Enable trace recording at the given level. |
|
(none) |
Path to write the trace file. If omitted while |
|
off |
Periodic INFO logs: per-GPU L0<->L1 transfer stats and L1 memory usage. See Logging. |
|
|
Seconds between extra-logging emissions. |
vLLM Client Configuration#
On the vLLM side, specify the LMCache server host and port via the
kv_connector_extra_config parameter. The URL scheme selects the request
transport: use tcp:// for ZMQ or grpc:// for gRPC, matching the
server’s --transport setting. A bare host is accepted and normalized to
tcp:// for backward compatibility:
vllm serve Qwen/Qwen3-14B \
--kv-transfer-config \
'{"kv_connector":"LMCacheMPConnector", "kv_role":"kv_both", "kv_connector_extra_config": {"lmcache.mp.host": "127.0.0.1", "lmcache.mp.port": 6000}}'
To target multiple LMCache servers from a single vLLM deployment, pass a
list (or comma-separated string) of server URLs via
lmcache.mp.server_urls. When set, server_urls takes precedence
over the single-server host / port keys; vLLM’s world size must
be divisible by the number of servers, and each worker connects only to
its locally-assigned server (global ranks are sliced into contiguous
blocks, one block per server). Multi-server mode currently supports
tensor parallelism only – pipeline parallelism (pp_size > 1) and
data parallelism (dp_size > 1) are rejected with a clear error.
vllm serve Qwen/Qwen3-14B \
--tensor-parallel-size 4 \
--kv-transfer-config \
'{"kv_connector":"LMCacheMPConnector", "kv_role":"kv_both", "kv_connector_extra_config": {"lmcache.mp.server_urls": "tcp://host1:6667,tcp://host2:6667"}}'
Decode context parallelism (DCP)#
--decode-context-parallel-size is supported. Under DCP, vLLM shards the
attention KV cache across ranks along the token axis, so each rank holds only
a strided 1/dcp slice and one block ID spans block_size * dcp tokens.
LMCache stores each rank’s opaque page as its own object and a chunk counts as
a hit only when every rank’s slice is present. Non-trivial
--cp-kv-cache-interleave-size values are supported when they evenly divide
every resolved attention cache block size. Because interleave changes the
token-to-slot byte layout, the connector automatically adds the DCP size and
interleave value to its internal cache namespace. This prevents pages written
by one interleave layout from being loaded by another. It does not change the
model name served by vLLM, but the decorated cache model name is visible in MP
metric labels so operators can distinguish incompatible cache layouts.
The vLLM MP connector automatically negotiates a compatible chunk size. For a
single attention group, the required alignment is
block_size * decode_context_parallel_size. For a hybrid model, it is the
least common multiple of every attention group’s DCP-scaled block span and
every recurrent-state group’s unscaled physical block span. The server treats
--chunk-size as a minimum and rounds it up to the smallest compatible
multiple; see Chunk-Size Negotiation.
The example model also needs a vLLM build that can run it under DCP:
Kimi-Linear DCP support landed after v0.27.1 (vLLM commit 63ac04a61e,
PR #50484). On stock v0.27.1 the command below fails at startup with
Kimi-K3 MultiHeadLatentAttention does not support context parallelism.
# block_size 1024 x dcp 2 -> a configured minimum of 256 negotiates to 2048
lmcache server --host localhost --port 6000 --chunk-size 256 \
--l1-size-gb 20 --eviction-policy LRU
vllm serve moonshotai/Kimi-Linear-48B-A3B-Instruct \
--trust-remote-code \
--tensor-parallel-size 2 \
--decode-context-parallel-size 2 \
--kv-transfer-config \
'{"kv_connector":"LMCacheMPConnector", "kv_role":"kv_both", "kv_connector_extra_config": {"lmcache.mp.host": "127.0.0.1", "lmcache.mp.port": 6000}}'
Pipeline parallelism and multiple LMCache servers may both be combined with DCP. These combinations are rejected at startup:
Rejected with DCP |
Reason |
|---|---|
|
Adds a second KV shard axis this connector does not map. |
Fewer than |
No server holds a complete set of shards, and lookup takes the minimum hit count across servers, so it reports no hits. |
An interleave value that is non-positive, larger than a resolved attention cache block, or does not evenly divide every resolved attention block is rejected at connector startup.
decode_context_parallel_size > tensor_parallel_size is rejected by vLLM
itself, so this connector does not re-check it.
LMCacheMPConnector reads the following keys from
kv_connector_extra_config:
Connector extra_config Keys#
All connector-level options are passed through
kv_connector_extra_config and use the lmcache.mp. prefix.
By default, MP caches only prompt tokens, avoiding new cache entries from sampled output when fixed prompts are replayed.
Set "lmcache.mp.save_decode_cache": true in kv_connector_extra_config
for resumable or streaming sessions, where generated tokens become part of a
growing prompt across turns within the same request. This setting is separate
from the in-process connector’s save_decode_cache YAML/environment setting.
Key |
Default |
Description |
|---|---|---|
|
|
Cache generated tokens in addition to prompt tokens. |
|
(unset) |
Multi-server deployment: list (or comma-separated string) of
|
|
|
Single-server deployment: request transport and host of the LMCache MP
server. Use |
|
|
Single-server deployment: port of the LMCache MP server. Must
match the server’s |
|
|
Timeout (seconds) for blocking message-queue requests, including
the initial chunk-size query and KV cache
registration/unregistration. If the server does not respond within
this window, the connector raises |
|
|
Interval (seconds) between periodic heartbeat pings sent from the connector to the server. |
|
|
Poll lookup-status replies without blocking the scheduler by default.
Set to |
|
|
Submit the LMCache lookup when a request enters vLLM’s waiting queue, allowing L2-to-L1 KV staging to overlap with scheduler queue wait. Resumable requests are skipped because their token IDs may be incomplete at enqueue time. |
|
|
Whether vLLM worker 0 should start a local |
|
|
Timeout (seconds) to wait for the auto-started server to respond to
ZMQ |
|
|
Extra command-line arguments passed to the auto-started MP HTTP server
process. Required server settings such as |
|
|
Routing mode for the worker -> server transfer context. One of
|
|
|
Assume the vLLM workers and the LMCache server run in containers
that share no host IPC namespace ( |
|
|
Set when the engine allocates its KV cache through the CUDA VMM
API (vLLM’s |
|
|
Buffer stores on the scheduler and submit them according to the selected lazy-offload policy. Requires vLLM prefix caching. See Lazy KV Cache Offload for behavior, limitations, and tuning guidance. |
|
|
Lazy drain policy. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To let vLLM worker 0 start a local MP server automatically:
vllm serve Qwen/Qwen3-14B \
--kv-transfer-config \
'{"kv_connector":"LMCacheMPConnector", "kv_role":"kv_both", "kv_connector_extra_config": {"lmcache.mp.autostart": true, "lmcache.mp.autostart.server_args": "--l1-size-gb 20 --eviction-policy LRU"}}'
Auto-start is a convenience for single-node, single-server deployments. The MP server is a child of vLLM worker 0, not an independently managed service.
Note
LMCache’s adapter shutdown does not explicitly terminate this child, but vLLM’s process-tree cleanup may terminate it. Its lifetime depends on the vLLM version and exit path; neither survival nor automatic cleanup is guaranteed. Stop any remaining auto-started server when it is no longer needed.
For servers that must survive vLLM restarts or be shared across vLLM instances, and for multi-node TP/PP deployments, start and manage the server separately. For example, run the server in a separate terminal or service manager and leave auto-start disabled in vLLM:
# Terminal 1: independently managed MP server
lmcache server --host 127.0.0.1 --port 5555 \
--http-host 127.0.0.1 --l1-size-gb 20 --eviction-policy LRU
# Terminal 2: connect-only vLLM instance
vllm serve Qwen/Qwen3-14B \
--kv-transfer-config '{
"kv_connector": "LMCacheMPConnector",
"kv_connector_module_path":
"lmcache.integration.vllm.lmcache_mp_connector",
"kv_role": "kv_both",
"kv_connector_extra_config": {
"lmcache.mp.host": "127.0.0.1",
"lmcache.mp.port": 5555,
"lmcache.mp.autostart": false
}
}'
Environment Variables#
Variable |
Description |
|---|---|
|
Log level for LMCache ( |
|
Set to a fixed value for reproducible hashing across processes
(relevant when using |
|
Set to |
|
Set to |
|
Seconds between continuous usage-telemetry flushes (default
|
Full Example#
lmcache server \
--host 0.0.0.0 \
--port 6555 \
--chunk-size 512 \
--max-workers 4 \
--max-gpu-workers 2 \
--hash-algorithm blake3 \
--engine-type default \
--lookup-hash-log-dir /data/lmcache/lookup_hashes \
--lookup-hash-log-rotation-interval 21600 \
--lookup-hash-log-rotation-max-size 104857600 \
--lookup-hash-log-max-files 100 \
--l1-size-gb 100 \
--l1-use-lazy \
--l1-init-size-gb 20 \
--l1-align-bytes 4096 \
--l1-write-ttl-seconds 600 \
--l1-read-ttl-seconds 300 \
--eviction-policy noop \
--l2-store-policy skip_l1 \
--eviction-trigger-watermark 0.9 \
--eviction-ratio 0.1 \
--l2-prefetch-policy default \
--l2-prefetch-max-in-flight 8 \
--periodic-notifier-interval-ms 5 \
--l2-adapter '{"type": "nixl_store", "backend": "POSIX", "backend_params": {"file_path": "/data/lmcache/l2", "use_direct_io": "false"}, "pool_size": 64}' \
--prometheus-port 9090 \
--metrics-sample-rate 0.01 \
--enable-tracing \
--otlp-endpoint http://localhost:4317
Anonymous Usage Statistics#
The MP server reports anonymous usage statistics: a one-time
environment/configuration snapshot at startup and interval counters
(tokens retrieved/stored, bytes stored, uptime) every
LMCACHE_USAGE_TRACK_INTERVAL seconds. No prompts, keys, KV-cache
data, model names, or --instance-id are ever sent, and reporting can
never affect serving. Opt out with LMCACHE_TRACK_USAGE=false or
DO_NOT_TRACK=1; see Usage Stats Collection for details.