零门槛，开发 vLLM+LMCache一台 MacBook 就够了
面向 New Contributor · 覆盖 Frontend / L1 Eviction / L2 Storage / Observability
如果你之前因为「手里没卡」而错过 LMCache，这份指南就是为你而写。LMCache 的多平台框架已经把 GPU 从大多数核心数据路径里解耦出来——也就是说，在一台普通的 MacBook（Apple Silicon）上或 ubuntu（大部分相似，本文不赘述，参考 .github/workflows/cpu_device.yml），你就能跑通完整的 vLLM + LMCache 端到端链路，动手改代码、跑单测、端到端验证不在话下。
本文包括：
① LMCache 解决什么问题；
② 你在 MacBook 上怎么搭工作台；
③ vLLM + LMCache 端到端怎么跑；
④ 内存不够怎么办、模型下不下来怎么办；
⑤ 你在四个方向上具体可以做什么。
图 1 · LMCache 的四个 hot zone，全部都可以在 CPU 笔记本上动手
◍ 一、LMCache 解决什么问题（60 秒原理）
大语言模型推理时，每个请求都会算出一段 KV cache，用来支撑后续 token 的生成。如果上下文有共享前缀（系统 prompt、文档检索、多轮对话…），原本要重新算一遍的 KV，其实可以从其它请求 / 其它机器 / 磁盘里直接复用。
LMCache 就是一个独立的 KV cache 引擎：它从推理引擎（vLLM、SGLang…）那里接收 KV、在内存（L1）里聚合、在外存（L2，磁盘 / Redis / 对象存储 / NIXL …）里持久化，并在新请求到来时把命中的 KV 高效送回推理引擎。对上层而言，它就是一段「缓存层 + 多机协同」的能力，复用率高的场景下能把首 token 延迟降一个数量级。
对你来说要记住的只有一句：LMCache 的核心数据结构是张量，搬运张量的方式被抽象成了「Transfer Context」，而 Transfer Context 既可以走 GPU IPC，也可以走 CPU 共享内存——这就是为什么 MacBook 也能跑全量链路。参考 https://blog.lmcache.ai/en/2026/06/15/understanding-lmcache-mp-mode-transfer-paths-a-beginners-guide/
◍ 二、为什么 MacBook 就能开发
LMCache 的代码库里有一层 Platform / Device 抽象，把「能不能用 CUDA」「torch 上有没有这个 op」之类的问题都收敛在了几个明确的入口里。对于绝大多数模块——Frontend / Eviction / Storage / Observability——实际处理张量的环节都在 Python 端，数据搬运又被 Transfer Context 屏蔽，所以你完全可以在没有 GPU 的笔记本上动手。
两类 Transfer Context
• EngineDrivenTransferContext：worker 端把张量 gather + send 整段给 LMCache server，server 端再 memcpy 到缓存池。子模式包括 SHM（通过 POSIX shm_open/mmap 零拷贝）和 pickle（通过 socket 传输序列化数据）。
• LMCacheDrivenTransferContext：LMCache server 端通过 IPC handle 直接访问 worker 端的张量内存。在 GPU 上 handle 是 CUDA IPC handle，在 CPU 上 handle 是 POSIX 共享内存段名，两端都通过 mmap 共享同一物理页，零拷贝。
在 vLLM 端通过 kv_connector_extra_config 里的 lmcache.mp.mp_transfer_mode 切换两条路径。本地开发推荐固定使用 engine_driven，这样你的本机链路与生产环境的 GPU 链路在数据路径上完全等价。
若想深入了解 LMCache 多平台架构，可以参考 .github/workflows/cpu_device.yml 和 .github/scripts/run-cpu-e2e-validation.sh，他们是 CI 中 CPU-only 端到端验证的权威参考，也是你本地环境可复现的最佳范例。
◍ 三、十分钟搭好你的 MacBook 工作台
3.1 准备一个独立的 Python 环境
vLLM 的 v1 KV connector API 要求 Python ≥ 3.11；本指南用 Python 3.12 实测通过，同时需要确保安装了 cmake 才能源码编译 vLLM ≥ 4.3.4。建议把 venv 与源码并排放，方便切换：
# We recommend putting everything under ~/projects-test/ mkdir -p ~/projects-test cd ~/projects-test # Create a shared venv (vLLM + LMCache will share it) python3 -m venv .venv-lmcache source .venv-lmcache/bin/activate pip install -U pip wheel setuptools
3.2 拉源码
cd ~/projects-test git clone https://github.com/vllm-project/vllm.git git clone https://github.com/LMCache/LMCache.git
3.3 安装 vLLM CPU 版（两种方式任选）
vLLM 的 PyPI wheel 是 CUDA 版，在 CPU-only 笔记本上 import 即失败。下面提供两种方式：源码编译（方案一，推荐，始终保持最新代码）和 预编译 vLLM CPU nightly wheel（方案二，省去 2~3 分钟编译时间）。日常开发推荐方案一，只想快速跑通端到端验证选方案二。
▎方案一：源码编译（推荐）
具体命令参考官方 Apple Silicon 安装指引：
# Official doc:
# https://docs.vllm.ai/en/stable/getting_started/installation/cpu/#apple-silicon
cd ~/projects-test/vllm
source ~/projects-test/.venv-lmcache/bin/activate
# 1) Install CPU deps (torch CPU, transformers, etc.)
pip install uv
VIRTUAL_ENV=~/projects-test/.venv-lmcache \
uv pip install -r requirements/cpu.txt \
--index-strategy unsafe-best-match
# 2) Build vLLM from source (needs setuptools_scm; Xcode 16 is fine)
pip install setuptools_scm setuptools_rust
VIRTUAL_ENV=~/projects-test/.venv-lmcache VLLM_TARGET_DEVICE=cpu \
uv pip install -e . --no-build-isolation
# 3) Sanity check - v1 KV connector API must be available
python -c \
'import vllm; print(vllm.__version__);
from vllm.distributed.kv_transfer.kv_connector.v1.base \
import KVConnectorBase_V1; print("v1 OK")'
实测：MacBook M-series + Xcode 16 + Python 3.12 上，从零到 import vllm 成功大约 2~3 分钟（torch 已下载好的情况下，vLLM 源码 build 约 40 秒）。
▎方案二：预编译 vLLM CPU wheel（使用 CI 脚本）
如果你不想等源码编译，可以直接用 LMCache CI 里验证过的 .github/scripts/install_vllm_cpu.sh 安装预编译的 vLLM CPU nightly wheel。脚本会自动安装 numpy<2、vllm-cpu-nightly（含 torch 2.11 CPU 版），并自动创建 dist-info 别名。
脚本支持两个环境变量来控制行为：
• PIP_BIN：指定 pip 命令路径，默认为 pip。可以设为 “uv pip” 使用 uv，或设为完整路径如 “~/projects-test/.venv-lmcache/bin/pip”。
• PIP_INSTALL_EXTRA_ARGS：传递给 pip install 的额外参数，默认为空。例如可以加 –index-url 来指定镜像源。
source ~/projects-test/.venv-lmcache/bin/activate # Simplest usage (uses pip from the activated venv): bash ~/projects-test/LMCache/.github/scripts/install_vllm_cpu.sh # Or explicitly point to the venv's pip: # PIP_BIN="~/projects-test/.venv-lmcache/bin/pip" \ # bash ~/projects-test/LMCache/.github/scripts/install_vllm_cpu.sh # If you need to pass extra pip args (e.g. mirror): # PIP_INSTALL_EXTRA_ARGS="-i https://mirrors.tencent.com/pypi/simple" \ # bash ~/projects-test/LMCache/.github/scripts/install_vllm_cpu.sh
脚本内部做了什么？① pip install numpy<2（vLLM CPU 的硬依赖）；② pip install vllm-cpu-nightly –extra-index-url https://download.pytorch.org/whl/cpu（因为 vllm-cpu-nightly 依赖 torch 2.11，只存在于 PyTorch CPU 索引，不加这个参数 pip 会找不到匹配的 torch 版本）；③ 自动创建 vllm-<ver>+cpu.dist-info 别名——因为 wheel 的 dist 元数据注册为 vllm-cpu-nightly 而非 vllm，vLLM 的 CLI 和内部调用会通过 importlib.metadata.version(“vllm”) 查找版本号，没有别名会直接报 PackageNotFoundError 导致 vllm serve 无法启动。+cpu local label 也是 CPU platform plugin 激活的条件——它会 grep dist metadata 里的 “cpu” 子串来判断当前是 CPU 环境。脚本是幂等的，重复运行只会刷新别名。
3.4 安装 LMCache（关键：NO_GPU_EXT=1）
在没有 NVIDIA / AMD / Intel 加速卡的笔记本上，默认的 pip install -e . 会去拉 cuda runtime、nixl、cupy 这些GPU vendor 依赖，并尝试编译 CUDA 扩展，直接报错。现在 setup.py/pyproject.toml 提供了三档开关，为 MacBook 场景专门设计：
• NO_GPU_EXT=1（MacBook 首选）：跳过所有 GPU 扩展 + cupy / nixl 等 GPU vendor 依赖，但保留 lmcache_fs / lmcache_redis 等纯 C++ 扩展。
• NO_NATIVE_EXT=1：连本地 C++ 扩展都不要，得到一个纯 Python 包。适合你只想跑 frontend / 算法相关测试、连 C++ 工具链都懒得装。
• NO_CUDA_EXT=1：Legacy 别名，等价于 NO_NATIVE_EXT，已 deprecated。你在老文档里看到这个的话，现在统一用 NO_GPU_EXT 或 NO_NATIVE_EXT。
MacBook 上只需要一条命令：
source ~/projects-test/.venv-lmcache/bin/activate # nvtx upstream sdist misses Cython as a build dep; # install it manually on macOS first pip install Cython openai # One-liner: install LMCache (skip GPU ext + GPU vendor deps) NO_GPU_EXT=1 pip install --no-build-isolation -e ~/projects-test/LMCache
为什么不是 NO_CUDA_EXT=1？因为这个是 legacy 别名，等同于 NO_NATIVE_EXT——它会跳掉所有 native 扩展，但 install_requires 里的 cupy / nixl 还是不跳，而 cupy-cuda12x 在 macOS arm64 根本没有 wheel，会让 pip resolver 直接不可解。NO_GPU_EXT=1 是为「无 GPU 但有 C++ 工具链」场景量身设计的，也同步跳掉 cuda_core.txt 的 cupy / nixl。
3.5 验证安装
source ~/projects-test/.venv-lmcache/bin/activate
python -c 'import lmcache; print(lmcache.__version__)'
python -c \
'from lmcache.integration.vllm.lmcache_mp_connector \
import LMCacheMPConnector; print("connector OK")'
看到 “StubCPUDevice” / “Skipping backend lmcache.c_ops” 即代表 CPU 后端已正确激活——你已经具备了开发 LMCache 的全部能力。
◍ 快速反馈：用 server_bench 独立验证 LMCache（无需 vLLM）
在切入完整的 vLLM + LMCache 端到端之前，有一个更轻量的验证方式：只启动 LMCache server，然后跑 lmcache bench server –mode cpu。它不需要 vLLM，不需要下载模型，只需要你已经装好了 LMCache。这是最快的「改代码 → 验证」闭环。
好处
• 极快反馈：从启动 server 到出结果不到 20 秒，适合调参迭代。
• 零依赖：不需要 vLLM、不需要模型文件、不需要 GPU。
• 聚焦 LMCache 本身：直接测试 store → retrieve 的 checksum 一致性，排除了 vLLM connector / KV tensor 序列化等外部变量。
• 两种 transfer mode 都覆盖：lmcache_driven 和 engine_driven，你可以分别验证两条数据路径的 store/retrieve 是否正确。
局限性
• 不涉及真实推理：bench 生成的是随机张量，不是真实 KV cache，无法验证 token 生成的一致性和语义正确性。
• 不走 KV connector：bench 直接通过 ZMQ/HTTP 和 server 通信，绕过了 vLLM 侧的 LMCacheMPConnector，因此不能用来验证 connector 集成。
• 不能测 cache hit 效果：server_bench 只做单次 store+retrieve 的 checksum 对比，没有连续请求、没有 cache hit/miss 逻辑。
跑一次只需三步
以下步骤参考了 CI 中的 .github/scripts/cpu_server_bench_test.sh，同时支持 engine_driven 和 lmcache_driven 两种模式。
# Step 1: start LMCache server (background) source ~/projects-test/.venv-lmcache/bin/activate lmcache server \ --port 5555 \ --http-port 8080 \ --l1-size-gb 1 \ --eviction-policy LRU & # Step 2: wait for healthcheck while ! curl -fsS http://127.0.0.1:8080/healthcheck 2>/dev/null; do sleep 1 done echo 'Server ready' # Step 3: run bench (lmcache_driven mode) lmcache bench server \ --rpc-url tcp://127.0.0.1:5555 \ --url http://127.0.0.1:8080 \ --mode cpu \ --transfer-mode lmcache_driven \ --num-tokens 512 \ --end 3 # Or with engine_driven mode: # lmcache bench server \ # --rpc-url tcp://127.0.0.1:5555 \ # --url http://127.0.0.1:8080 \ # --mode cpu \ # --transfer-mode engine_driven \ # --num-tokens 512 \ # --end 3 # Stop the server when done: # kill %1
成功标志：输出中出现 “CHECKSUM MATCH OK” × 3。如果出现 “CHECKSUM MISMATCH”，说明 store/retrieve 数据损坏，你的代码改动引入了 bug。这也是提 PR 前建议先跑一遍的最小健康检查。
◍ 四、第一段端到端：vLLM CPU + LMCache
把 vLLM 也接进来，你就有了一个完整的可调试推理 + KV cache 复用环境。vLLM 跑 CPU device，通过 KV connector 把 KV 经 SHM 句柄交给 LMCache server。
4.1 内存规划（必读，否则会 OOM）
这是 MacBook 上跑 vLLM + LMCache 最容易踩的坑。你需要同时给 vLLM 的 KV cache 池、LMCache 的 L1 缓存、以及 Python 进程本身预留内存。一台 16 GB MacBook 的建议配置：
• vLLM KV cache 池：由 VLLM_CPU_KVCACHE_SPACE 控制，建议 1 GB（opt-125m 完全够用）；另外用 –kv-cache-memory-bytes 更精确控制。
• LMCache L1 缓存：由 –l1-size-gb 控制，建议 1 GB。不要设太大，否则加上 vLLM 的内存，整机会不够。
• 如果你的 MacBook 只有 8 GB 内存，建议把 vLLM KV cache 设到 0.25 GB（VLLM_CPU_KVCACHE_SPACE=0.25），LMCache L1 设到 0.5 GB（–l1-size-gb 0.5），并用 –max-model-len 300 –max-num-seqs 1 限制序列长度和并发。
# Memory budget for a 16 GB MacBook (safe defaults): # vLLM KV pool: 1 GB (VLLM_CPU_KVCACHE_SPACE=1) # LMCache L1: 1 GB (--l1-size-gb 1) # torch + model weights: ~1.5 GB # Python runtime: ~0.5 GB # OS + apps: ~6 GB # ------------------------------------------ # Free headroom: ~6 GB # For an 8 GB MacBook, shrink everything: # VLLM_CPU_KVCACHE_SPACE=0.25 # --l1-size-gb 0.5 # --max-model-len 300 # --max-num-seqs 1
4.2 macOS arm64 特殊处理：绕开 OMP 死锁
这是在 Apple Silicon Mac 上跑 vLLM CPU 时特有的问题。如果不设这三个环境变量，vLLM 启动时会卡在 OpenMP 初始化阶段永远不返回。原因是 macOS 自带的 Accelerate framework 与外部 OpenMP runtime 冲突导致线程绑定死锁。解决方案是禁用 OMP 线程绑定，并强制单线程模式：
# === CRITICAL: avoid vLLM OMP deadlock on macOS arm64 === export VLLM_CPU_OMP_THREADS_BIND=nobind export OMP_NUM_THREADS=1 export KMP_BLOCKTIME=0 # ==========================================================
这三行只需要在启动 vLLM 的终端里 export，不影响 LMCache server。如果你用的是 Intel Mac 或 Linux，不需要这三行。不设也不会报错，只是多了几个无害的环境变量而已。
4.3 启动 LMCache server
下面这条命令启动 LMCache 的 ZMQ + HTTP 一体服务器。这是新的 CLI 入口（之前是 python -m lmcache.v1.multiprocess.http_server）。L1 1 GB、LRU 淘汰。ZMQ 监听 5555，HTTP frontend 监听 8080。启动成功的标志是日志中出现：”LMCache ZMQ cache server is running”。
# Terminal A: start LMCache server source ~/projects-test/.venv-lmcache/bin/activate lmcache server \ --port 5555 \ --http-port 8080 \ --l1-size-gb 1 \ --eviction-policy LRU
启动后你应该能看到：”accelerator available: False”、”TokenHasher initialized: chunk_size=256, hash_algorithm=blake3″、以及 “LMCache ZMQ cache server is running on tcp://localhost:5555″。HTTP 健康检查用 curl http://localhost:8080/healthcheck 验证。
4.4 启动 vLLM
把 KV connector 配到 lmcache_mp_connector，host 用 tcp://localhost、port 用 5555 与 server 对齐。关掉 vLLM 自带的 prefix caching（–disable-hybrid-kv-cache-manager / –no-enable-prefix-caching），把 KV 复用职责完全交给 LMCache。
# Terminal B: start vLLM (macOS arm64)
source ~/projects-test/.venv-lmcache/bin/activate
# === CRITICAL: avoid vLLM OMP deadlock on macOS arm64 ===
export VLLM_CPU_OMP_THREADS_BIND=nobind
export OMP_NUM_THREADS=1
export KMP_BLOCKTIME=0
# ==========================================================
# CPU device + gloo rendezvous
export VLLM_DEVICE=cpu
export VLLM_CPU_KVCACHE_SPACE=1
export VLLM_HOST_IP=127.0.0.1
export GLOO_SOCKET_IFNAME=lo0
# You can also set "lmcache.mp.mp_transfer_mode" to "engine_driven"
vllm serve facebook/opt-125m \
--port 18000 \
--dtype bfloat16 \
--disable-hybrid-kv-cache-manager \
--no-enable-prefix-caching \
--max-model-len 2048 \
--max-num-seqs 1 \
--kv-transfer-config '{
"kv_connector": "LMCacheMPConnector",
"kv_role": "kv_both",
"kv_connector_module_path":
"lmcache.integration.vllm.lmcache_mp_connector",
"kv_connector_extra_config": {
"lmcache.mp.host": "tcp://localhost",
"lmcache.mp.port": 5555,
"lmcache.mp.mp_transfer_mode": "lmcache_driven"
}
}'
4.5 发请求验证 cache hit
LMCache 的最小复用单元是 chunk（默认 256 token），因此 prompt 太短根本不会落进缓存。下面这段 Python 脚本会发两次相同的 ~640 token prompt，第一次冷启动会把 KV 写入 LMCache，第二次直接从 SHM 取回。
# Terminal C: verify cache hit
source ~/projects-test/.venv-lmcache/bin/activate
cat > /tmp/test_lmcache_e2e.py <<'EOF'
import time, requests
URL = 'http://localhost:18000/v1/completions'
words = ['the','quick','brown','fox','jumps',
'over','lazy','dog'] * 80 # ~640 tokens
prompt = ' '.join(words)
payload = dict(model='facebook/opt-125m', prompt=prompt,
max_tokens=8, temperature=0.0)
for i in (1, 2):
t0 = time.time()
r = requests.post(URL, json=payload, timeout=600)
print('round %d %d %.2fs' % (i, r.status_code, time.time()-t0),
r.json()['usage'])
EOF
python /tmp/test_lmcache_e2e.py
实测预期输出（M-series MacBook，opt-125m，bf16）：
round 1 200 0.71s {'prompt_tokens': 641, 'total_tokens': 649, ...}
round 2 200 0.25s {'prompt_tokens': 641, 'total_tokens': 649, ...}
在 Terminal A 的 LMCache server 日志里你会看到：
# First request: store LMCache INFO: Stored 512 tokens in 0.013 seconds # Second request: hit + retrieve LMCache INFO: Prefetch request completed (L1+L2): 2/2 prefix hits (2 L1, 0 L2) in 0.4 ms LMCache INFO: Retrieved 512 tokens in 0.007 seconds
这一刻你已经在 MacBook 上跑通了完整的： vLLM CPU worker → POSIX SHM → LMCache server (server-side memcpy) → L1 → 第二次请求命中并复用。 和 GPU 上 (cuda IPC handle) 唯一的差异只在 “如何拿到对端的 KV buffer”——业务逻辑、调度、淘汰、observability 完全等价。
图 2 · 你在 MacBook 上的零 GPU 开发闭环
◍ 五、模型下载不下来怎么办？
在一些网络环境中，Hugging Face Hub 可能访问不稳定，或下载速度较慢。下面按推荐顺序列出三种解决方案：
5.1 方案一：使用 HF 国内镜像（最方便）
设置 HF_ENDPOINT 环境变量，指向国内镜像站：
# Use HF mirror (hf-mirror.com is a popular option)
export HF_ENDPOINT=https://hf-mirror.com
# Then start vLLM as usual - it will download from the mirror
vllm serve facebook/opt-125m ...
# Or use snapshot_download manually to pre-download:
python -c "
from huggingface_hub import snapshot_download
snapshot_download('facebook/opt-125m')
"
如果 hf-mirror.com 也不行，可以尝试其他镜像：modelscope （https://modelscope.cn）或者公司内部的 HF 镜像。另外在 CI 中我们使用 .github/scripts/download_model.sh 来下载模型，它内置了重试 + 指数回退机制，可以直接拿来用：
# Use the same download script as CI (with retry) MODEL_ID=facebook/opt-125m \ bash ~/projects-test/LMCache/.github/scripts/download_model.sh
5.2 方案二：下载到本地后指定路径
如果你已经把模型下载到了本地，可以直接用本地路径代替 HuggingFace repo id：
# Download to local first (on a machine with good network) # pip install huggingface_hub # huggingface-cli download facebook/opt-125m \ # --local-dir ~/models/opt-125m # Then use the local path with vLLM: vllm serve ~/models/opt-125m \ --port 18000 \ --dtype bfloat16 \ ... # same args as section 4.4
本地路径支持绝对路径和相对路径，只要目录下有 config.json 和 pytorch_model.bin 等文件即可。这也是离线开发的推荐方式。
5.3 方案三：指定 HF cache 目录
如果你之前已经下载过模型，可以通过 HF_HOME 或软链接来复用缓存：
# Point HF cache to your existing model directory export HF_HOME=~/my_hf_cache # Or symlink the specific model into the default cache: mkdir -p ~/.cache/huggingface/hub ln -s ~/my_models/models--facebook--opt-125m \ ~/.cache/huggingface/hub/models--facebook--opt-125m
◍ 六、提交你的第一个 PR
• 先在 GitHub 上 Fork LMCache/LMCache，clone 你自己的 fork；
• 新建一个 feature 分支，遵循 conventional commit （feat / fix / refactor / docs / test 等前缀）；
• 本地装好 pre-commit：pip install pre-commit && pre-commit install，提交前会自动跑 ruff / mypy / 等格式化与静态检查；
• 至少跑一遍相关模块的单元测试——lmcache 仓库里大多数测试都不依赖 GPU。
• 在你的本地跑端到端验证——通过本文档，你完全可以在本地验证大部分功能。
• 把 PR 提到上游 main，描述里说清「问题 / 动机 / 方案 / 验证方式」，并附一段你在本机跑出的日志或 metrics 截图——这会让 reviewer 非常开心。
git commit 时记得加 -s/–signoff 参数，签上 Signed-off-by，这是项目要求。你可以用 git commit -s -m “…” 一次搞定。
◍ 七、写在最后
LMCache 是一个开源、开放、共建的项目。整个多平台抽象之所以存在，就是为了让没有加速卡的开发者、新硬件 vendor、不同推理引擎的使用者都能在同一套代码上协作。
你不需要先有一张 GPU 才能贡献——Frontend / L1 Eviction / L2 Storage / Observability 四个方向上随便挑一个，你的 MacBook 就足以支撑你写出第一份能合入 main 的代码。欢迎你来。
零 GPU 成本，零卡门槛，零等待。这是 LMCache 多平台改造想送给每一位社区贡献者的礼物。
◍ 附录：CI 脚本参考
以下是 LMCache 仓库中 CPU-only 测试相关的关键文件，它们是你本地排错的最佳参考：
• .github/workflows/cpu_device.yml —— CPU 设备测试的 CI workflow 定义，包含 macOS 和 Ubuntu 两个矩阵。
• .github/scripts/install_vllm_cpu.sh —— 安装 vLLM CPU nightly wheel，包含 dist-info alias 修复。
• .github/scripts/install_lmcache_cpu.sh —— NO_GPU_EXT=1 安装 LMCache editable 模式。
• .github/scripts/download_model.sh —— 下载 HF 模型，内置重试 + 指数回退。
• .github/scripts/cpu_device_test.sh —— 统一入口，支持 server_bench 和 vllm_e2e 两种模式。
• .github/scripts/run-cpu-e2e-validation.sh —— 完整的端到端验证脚本，含安装、启动、cache hit 验证、跨实例重启验证。
发表评论