Prompt Cache与KV Cache：大模型推理优化实战与DeepSeek Harness验证-平芜编程栈

这次我们来看一个能帮你省钱的 AI 推理优化技术：Prompt Cache。简单说，它通过复用 KV Cache 和前缀缓存，让大模型在处理重复或相似提示词时，跳过重复计算，直接命中缓存，从而显著降低计算开销和响应延迟。对于需要频繁调用模型、处理批量相似任务的场景，比如客服机器人、代码补全、文档分析，这能实实在在地减少 GPU 显存占用和 API 调用成本。

这个技术并非某个单一工具，而是一种优化思想和实现方案。与之高度相关的，是近期备受关注的DeepSeek Harness (DSH)及其命令行工具dsh。DSH 作为一个开放的 AI 应用开发与部署平台，内置了对 Prompt Cache 等优化技术的支持。因此，本文将围绕“Prompt Cache 如何省钱”这一核心，并结合 DSH 平台的能力进行实际验证，让你不仅理解原理，更能动手测试。

文章会直接切入主题：先讲清楚 Prompt Cache 和 KV Cache 是什么，为什么能省钱；然后，我们会基于 DeepSeek Harness (DSH) 环境，演示如何初步验证其缓存能力。重点关注的是实际效果：在重复请求下，响应速度是否有提升，资源消耗是否有变化。如果你关心模型推理效率、API 成本优化，或者正在评估 DeepSeek 的生态工具，这篇文章值得一看。

1. 核心能力速览

在深入细节之前，我们先通过一个表格快速了解本文涉及的核心概念与工具的能力边界。

能力项	说明
核心优化技术	Prompt Cache (提示词缓存) / KV Cache (键值缓存)
技术原理	缓存模型在处理特定提示词时生成的中间计算结果（Key-Value 向量），当相同或相似提示词再次出现时直接复用，避免重复计算。
主要收益	降低延迟：缓存命中可大幅减少推理时间。节省计算资源：减少 GPU/CPU 的计算负载，间接降低显存峰值。降低成本：对于按 token 或按请求计费的云 API，能显著减少开销。
关联平台/工具	DeepSeek Harness (DSH) 及 dsh 命令行工具
DSH 角色	提供模型服务化、插件生态，并支持优化技术（如 Prompt Cache）的集成与应用。
验证环境门槛	需具备 Python/Node.js 环境，能通过 npm/pip 安装工具。主要验证逻辑和 API 调用，对本地硬件无强制要求（可使用远程 API）。
关键验证点	1. 缓存是否生效（重复请求响应加速）。 2. DSH/dsh 基础功能是否可用（安装、配置、调用）。 3. 理解缓存机制对开发的影响。

2. 适用场景与使用边界

适合谁用？

AI 应用开发者：需要频繁调用同一模型处理结构相似请求（如模板化问答、批量文档总结）。
算法工程师/研究者：关注模型推理优化，想在实际系统中验证 KV Cache 复用效果。
成本敏感的项目团队：使用按量付费的模型 API，希望通过缓存优化降低调用成本。
DeepSeek 生态使用者：希望了解并利用 DSH 平台提供的工具和优化能力。

能解决什么问题？

降低重复查询延迟：对于客服机器人、FAQ 系统，标准问题的回答速度可以变得更快。
提升批量任务吞吐：处理成千上万条结构相似的文本（如情感分析、实体提取）时，整体处理时间缩短。
优化资源利用率：在固定显存的 GPU 服务器上，通过缓存可能支持更高的并发请求。
减少云 API 费用：如果缓存机制能减少向云端模型发送的重复计算量，则直接节省 token 消耗。

不适合什么场景？

每次请求都完全不同的场景：如果用户的输入毫无规律、永不重复，则缓存命中率极低，优化效果有限。
对实时性要求极高且输入多变的场景：缓存查询本身有微小开销，在输入绝对不重复时可能反而增加延迟。
严格追求每次计算绝对一致性的研究实验：缓存机制可能涉及一些优化策略（如精度、哈希），需确认是否影响结果的可复现性。

安全与合规边界：

缓存的内容是模型的内部计算状态（KV 向量），而非原始用户数据。但仍需注意，缓存策略可能使相似但不完全相同的查询共享缓存，需评估业务是否允许此行为。
在使用 DeepSeek 等第三方模型 API 时，需遵守其服务条款，合理使用缓存以避免滥用请求。
本文涉及的验证主要在技术和功能层面，不涉及具体业务数据，请在实际应用中做好数据隐私保护。

3. 环境准备与前置条件

我们的验证将围绕 DeepSeek Harness (DSH) 的客户端工具dsh进行。它让我们能够以统一的方式配置、调用不同的模型（包括 DeepSeek 的模型），并观察其行为。

基础软件环境：

操作系统：Windows 10/11, macOS, 或 Linux (Ubuntu 等)。本文以 Windows 为例，命令在其他系统上可能略有不同。
Node.js 环境：dsh是基于 Node.js 的工具。请确保已安装Node.js (版本 16 或以上)和配套的包管理器npm。
Python 环境（可选）：用于编写更复杂的测试脚本或调用原生 SDK。建议安装 Python 3.8+。
网络连接：需要能够访问互联网，以下载dsh工具和调用 DeepSeek 的 API（如果你使用其在线模型）。

环境检查：打开你的终端（Windows 上可以是 CMD、PowerShell 或 Git Bash），执行以下命令检查基础环境：

# 检查 Node.js 和 npm 版本 node --version npm --version # 检查 Python 版本（可选） python --version

如果命令未找到，请先前往 Node.js 官网 (nodejs.org) 下载安装 LTS 版本。

4. 安装部署与启动方式

dsh的安装非常简单，它是一个全局的 npm 包。

1. 全局安装 dsh：在终端中执行以下命令。这可能需要一些时间，因为它会下载dsh及其依赖。

npm install -g @deepseek-ai/dsh

2. 验证安装：安装完成后，运行以下命令，如果显示版本号或帮助信息，则说明安装成功。

dsh --version # 或 dsh --help

常见安装问题排查：

‘dsh‘ 不是内部或外部命令：这通常是因为 npm 的全局安装路径没有添加到系统的 PATH 环境变量中。
- 解决方案：找到 npm 的全局安装路径（通常在C:\Users\你的用户名\AppData\Roaming\npm(Windows) 或/usr/local/bin(macOS/Linux)），将该路径添加到系统的 PATH 中，然后重启终端。
- 快速验证：你也可以直接使用npx来运行dsh，避免全局路径问题：npx @deepseek-ai/dsh --help。
安装过程卡住或报错：可能是网络问题。可以尝试切换 npm 镜像源或使用科学的上网环境。
```
# 临时使用淘宝镜像 npm install -g @deepseek-ai/dsh --registry=https://registry.npmmirror.com
```

3. 初始化与配置：dsh支持多种“配置文件”(profile)，例如web用于 Web 端相关功能。我们需要先初始化一个 profile。

# 初始化一个名为 ‘web‘ 的 profile（这是常用配置） dsh plugin --profile web add dshmarket

这条命令会为web这个 profile 添加dshmarket插件市场，让你能方便地安装其他插件。

4. 配置模型 API（关键步骤）：要使用dsh调用模型，你需要配置模型的访问方式。这里以配置 DeepSeek 的官方 API 为例。你需要一个 DeepSeek API Key。请前往 DeepSeek 官方平台注册并获取。

# 设置 DeepSeek API Key 到环境变量（推荐，更安全） # Windows (PowerShell): $env:DEEPSEEK_API_KEY = "你的-api-key-here" # Windows (CMD): set DEEPSEEK_API_KEY=你的-api-key-here # macOS/Linux: export DEEPSEEK_API_KEY=你的-api-key-here # 或者，通过 dsh config 命令配置（具体命令可能随版本更新，请以官方文档为准） # dsh config set api_key <your_api_key> --profile web

注意：API Key 是私密信息，切勿提交到代码仓库或公开分享。

至此，dsh命令行工具已经就绪。它本身不是一个需要“启动”的常驻服务，而是一个即用即调的工具。接下来我们将用它来验证功能。

5. 功能测试与效果验证

我们的验证分为两部分：一是验证dsh基础功能是否正常；二是设计实验，观察在重复请求下，响应行为的变化，以间接验证缓存优化的可能性。

5.1 基础功能测试：调用 DeepSeek 模型

首先，我们测试dsh能否成功调用一个模型完成一次简单的对话。这能确保我们的安装和配置是正确的。

测试目的：验证dsh配置正确，能够连通 DeepSeek API 并返回结果。

操作步骤：

在终端中，使用dsh的chat命令进行交互式对话，或直接执行单次查询。
我们将使用-m参数指定模型。DeepSeek 提供了多个模型，例如deepseek-chat。

# 方式1：启动一个交互式聊天会话（输入 exit 退出） dsh chat -m deepseek-chat --profile web # 方式2：执行单次查询（更适用于脚本测试） echo "你好，请用一句话介绍你自己。" | dsh run -m deepseek-chat --profile web

预期结果：

如果配置正确，你会看到模型生成的回复，例如：“你好！我是DeepSeek，一个由深度求索公司创造的AI助手...”。
如果报错，常见原因有：
- API Key 未设置或错误：检查环境变量或配置命令。
- 网络问题：确认能访问 DeepSeek API 服务。
- 命令格式错误：确认-m参数指定的模型名正确。

成功标准：能够收到模型返回的、符合问题的文本回复。

5.2 缓存效果验证实验设计

由于 Prompt Cache 通常是模型服务端或底层推理库实现的优化，对用户透明，我们无法直接“看到”缓存命中。但我们可以通过设计对比实验，从性能指标上间接观察。

实验思路：向模型发送完全相同的提示词多次，记录每次的响应时间。如果服务端启用了有效的 Prompt Cache，那么从第二次请求开始，响应时间应有显著下降（因为跳过了大部分计算）。如果缓存未启用或未命中，则每次响应时间应大致相同。

测试脚本示例（Python）：我们将编写一个简单的 Python 脚本，通过dsh命令行工具来调用模型，并计算时间。这里假设你已配置好DEEPSEEK_API_KEY环境变量。

import subprocess import time import json import sys def call_model_via_dsh(prompt, model_name="deepseek-chat", profile="web"): """ 通过 dsh 命令调用模型，并返回响应内容和耗时。 """ # 构造命令 cmd = ["dsh", "run", "-m", model_name, "--profile", profile] start_time = time.time() try: # 执行命令，将提示词通过标准输入传入 result = subprocess.run( cmd, input=prompt, text=True, capture_output=True, shell=True # Windows上可能需要设为True ) end_time = time.time() elapsed_time = end_time - start_time if result.returncode == 0: return result.stdout.strip(), elapsed_time else: print(f"命令执行失败: {result.stderr}", file=sys.stderr) return None, elapsed_time except Exception as e: print(f"调用过程异常: {e}", file=sys.stderr) return None, time.time() - start_time def cache_test(prompt, repeat_times=5): """ 执行缓存测试：重复请求同一提示词。 """ print(f"测试提示词: ‘{prompt}‘") print("-" * 40) timings = [] for i in range(repeat_times): print(f"第 {i+1} 次请求...") response, cost_time = call_model_via_dsh(prompt) if response: # 为了输出简洁，只显示部分回复内容 preview = response[:50] + "..." if len(response) > 50 else response print(f" 耗时: {cost_time:.2f} 秒 | 回复预览: {preview}") timings.append(cost_time) else: print(f" 第 {i+1} 次请求失败") timings.append(None) time.sleep(1) # 短暂间隔，避免触发速率限制 print("-" * 40) print("耗时统计:") for idx, t in enumerate(timings): if t: print(f" 请求 {idx+1}: {t:.2f} 秒") if all(timings) and len(timings) > 1: avg_first = timings[0] avg_rest = sum(timings[1:]) / (len(timings) - 1) improvement = (avg_first - avg_rest) / avg_first * 100 print(f"\n分析：首次请求平均 {avg_first:.2f} 秒，后续请求平均 {avg_rest:.2f} 秒。") if improvement > 0: print(f"后续请求速度提升约 {improvement:.1f}% (可能受益于缓存)。") else: print("未观察到明显的缓存加速效果。") if __name__ == "__main__": # 使用一个固定的、有一定复杂度的提示词，以放大计算差异 test_prompt = """请将以下英文技术文档片段翻译成中文，并总结其核心要点： Document: ‘The Key-Value (KV) Cache is a critical optimization technique employed in autoregressive transformer decoder models, such as those used for large language models (LLMs). During the generation of each new token, the model attends to all previous tokens in the sequence. Instead of recomputing the Key and Value vectors for these previous tokens at every decoding step, the KV Cache stores them after their initial computation. This avoids redundant calculations, significantly reducing the computational cost per token after the first, and enabling faster generation speeds.‘ """ cache_test(test_prompt, repeat_times=5)

操作步骤：

将上述脚本保存为test_prompt_cache.py。
在终端中，确保已设置DEEPSEEK_API_KEY环境变量，并已安装dsh。
运行脚本：
```
python test_prompt_cache.py
```

预期结果与观察：

首次请求：耗时最长，因为需要完整执行模型的前向传播，计算所有 token 的 KV 向量并生成回复。
后续请求：如果服务端实现了有效的 Prompt Cache 且我们的请求命中了缓存，那么耗时应该明显缩短。缩短的程度取决于缓存机制的粒度（是整个提示词缓存，还是部分前缀缓存）以及网络开销占比。

输出示例：

测试提示词: ‘请将以下英文技术文档片段翻译成中文...‘ ---------------------------------------- 第 1 次请求... 耗时: 3.85 秒 | 回复预览: 文档：键值（KV）缓存是一种用于自回归变换器解码器模型的关键优化技术... 第 2 次请求... 耗时: 1.23 秒 | 回复预览: 文档：键值（KV）缓存是一种用于自回归变换器解码器模型的关键优化技术... ... ---------------------------------------- 耗时统计: 请求 1: 3.85 秒 请求 2: 1.23 秒 ... 分析：首次请求平均 3.85 秒，后续请求平均 1.30 秒。 后续请求速度提升约 66.2% (可能受益于缓存)。

判断成功的标准：后续请求的平均耗时显著低于首次请求（例如，降低30%以上）。这强烈暗示服务端存在缓存优化机制在起作用。需要注意的是，网络波动、服务器负载也会影响时间，因此需要多次测试取平均值，并观察稳定趋势。

6. 接口 API 与批量任务

dsh本身是一个命令行工具，适合交互和脚本调用。而 DeepSeek Harness (DSH) 平台更强大的能力在于其作为服务端，可以提供标准的 API 接口，并天然支持批量任务和高级优化。

6.1 理解 DSH 的 API 服务模式

在实际生产环境中，我们更可能部署或连接一个 DSH 服务实例，它作为一个模型服务中间层，管理模型加载、推理、缓存、路由等。客户端通过 HTTP/gRPC 等协议与之通信。

假设的 DSH 服务 API 调用流程：

启动 DSH 服务（本地或远程）：这通常涉及更复杂的部署，可能使用 Docker 或直接运行服务端二进制文件。部署后，它会暴露一个 API 端点（如http://localhost:8080）。
通过 API 发送请求：请求体中包含提示词 (prompt)、模型参数等。
服务端处理：DSH 服务会解析请求，应用可能存在的 Prompt Cache 逻辑（检查请求的提示词是否已有缓存的 KV），然后调用底层模型引擎。
返回结果：将生成的文本流式或非流式地返回给客户端。

一个简化的模拟 API 调用示例 (Python requests)：假设我们有一个运行在本地的 DSH 兼容服务。

import requests import time def call_dsh_api(prompt, api_url="http://localhost:8080/v1/completions", api_key=None): headers = { "Content-Type": "application/json", } if api_key: headers["Authorization"] = f"Bearer {api_key}" payload = { "prompt": prompt, "model": "deepseek-chat", # 实际模型名由服务端配置决定 "max_tokens": 500, "temperature": 0.7, } start_time = time.time() try: response = requests.post(api_url, json=payload, headers=headers, timeout=60) end_time = time.time() if response.status_code == 200: result = response.json() generated_text = result.get("choices", [{}])[0].get("text", "") return generated_text, end_time - start_time else: print(f"API 请求失败: {response.status_code}, {response.text}") return None, end_time - start_time except requests.exceptions.RequestException as e: print(f"网络请求异常: {e}") return None, time.time() - start_time # 批量任务示例：处理一个提示词列表 prompt_list = [ "总结一下人工智能的主要应用领域。", "总结一下人工智能的主要应用领域。", # 故意重复一次 "解释什么是机器学习。", "总结一下人工智能的主要应用领域。", # 再重复一次 ] for idx, prompt in enumerate(prompt_list): print(f"处理任务 {idx+1}: {prompt[:30]}...") text, cost = call_dsh_api(prompt) if text: print(f" 结果预览: {text[:50]}... | 耗时: {cost:.2f}秒") time.sleep(0.5) # 避免请求过快

在这个模拟中，重复的提示词“总结一下人工智能的主要应用领域。”如果触发了服务端的 Prompt Cache，其第二次和第三次调用的耗时应该远低于第一次。

6.2 批量任务与缓存收益

在批量处理场景下，Prompt Cache 的收益会非常明显。考虑一个文档处理流水线：

你有 1000 份合同，需要提取“甲方”、“乙方”、“金额”等固定字段。
你可以为每个字段设计一个固定的提取提示词模板，如“从以下文本中提取甲方名称：[合同文本]”。
虽然合同文本不同，但提示词前缀“从以下文本中提取甲方名称：”是相同的。
一个优化的、支持前缀缓存的推理引擎，可以为这 1000 次调用只计算一次这个前缀的 KV Cache，然后为每个不同的合同文本部分进行后续计算。这比每次都从头计算整个提示词节省了大量计算。

DSH 或类似平台的潜在价值：它们可以将这种缓存逻辑、批量调度逻辑封装起来，让开发者无需关心底层实现，只需提交任务队列即可。

7. 资源占用与性能观察

对于本地部署的模型服务，Prompt Cache 优化直接影响本地硬件资源占用。虽然我们通过dsh主要调用远程 API，但理解其原理对本地部署有指导意义。

1. 显存占用分析：

无 KV Cache：每次生成新 token 都需要为所有历史 token 重新计算 Key 和 Value 矩阵，计算开销大，但显存占用可能呈现为瞬时峰值。
有 KV Cache：首次计算后，将历史 token 的 K, V 向量存储在显存中。这会导致显存占用随生成文本长度线性增长。但换来的好处是，后续生成 token 的计算量大幅减少（只需计算当前 token 的 Q 向量，并与缓存的 K, V 做注意力计算）。
Prompt Cache：可以看作是 KV Cache 的升级应用。它将整个提示词或提示词的公共前缀的 KV 状态持久化下来。当相同提示词再次出现时，直接加载这部分缓存，节省了提示词计算阶段的全部显存和计算开销。这对于处理长提示词（如长系统指令、长上下文文档）的重复查询尤其有效。

2. 性能观察点：

首次响应时间 (Time To First Token, TTFT)：对于长提示词，启用 Prompt Cache 后，重复请求的 TTFT 会极大缩短，因为跳过了提示词编码阶段。
生成速度 (Tokens Per Second, TPS)：由于跳过了部分计算，TPS 也可能有提升，但提升的主要是 TTFT。
吞吐量：在并发处理多个相似请求时，服务端因为复用缓存，整体吞吐量（每秒处理的请求数）可以得到提升。

如何观察（本地部署场景）：如果你在本地运行一个支持 Prompt Cache 的推理服务器（如 vLLM, TensorRT-LLM 等），可以通过以下命令或工具观察：

nvidia-smi：监控 GPU 显存占用和利用率。在缓存预热后，处理重复请求时 GPU 利用率可能降低。
服务端日志：查看是否有类似[cache hit]、[prompt cache]的日志输出。
内置性能指标：一些推理服务器会提供/metrics等端点，输出缓存命中率、平均延迟等指标。

8. 常见问题与排查方法

在使用dsh或验证缓存效果时，你可能会遇到以下问题：

问题现象	可能原因	排查方式	解决方案
`dsh`命令未找到	1. 未全局安装。 2. npm 全局路径未加入系统 PATH。	运行`npm list -g --depth=0`查看是否已安装`@deepseek-ai/dsh`。	1. 重新运行`npm install -g @deepseek-ai/dsh`。 2. 将 npm 全局路径添加到系统 PATH 环境变量。
`dsh plugin --profile web add dshmarket`失败	1. 网络问题。 2. 命令语法随版本更新。	运行`dsh --help`查看最新插件管理命令。检查网络连接。	1. 使用`npx`尝试：`npx @deepseek-ai/dsh plugin --profile web add dshmarket`。 2. 查阅 DSH 官方文档。
API 调用返回认证错误	1.`DEEPSEEK_API_KEY`环境变量未设置或错误。 2. API Key 已过期或无效。	在终端中执行`echo $DEEPSEEK_API_KEY`(Linux/macOS) 或`echo %DEEPSEEK_API_KEY%`(Windows CMD) 检查。	1. 重新正确设置环境变量。 2. 前往 DeepSeek 平台检查 API Key 状态并重新生成。
请求超时或网络错误	1. 本地网络问题。 2. DeepSeek API 服务临时不可用。 3. 代理设置冲突。	使用`curl`或`ping`测试网络连通性。检查是否有 HTTP/HTTPS 代理影响。	1. 检查本地网络。 2. 稍后重试。 3. 在终端中临时取消代理设置（如`unset HTTPS_PROXY HTTP_PROXY`）。
缓存测试未显示加速效果	1. 服务端未启用 Prompt Cache。 2. 请求间隔太长，缓存已失效/清除。 3. 提示词哈希冲突或缓存策略不同。 4. 网络波动掩盖了性能差异。	1. 确认测试的模型服务是否宣称支持此优化。 2. 缩短请求间隔（如 0.5秒）再次测试。 3. 使用更长的、计算更密集的提示词测试。 4. 进行多次（如10次）测试取平均值。	1. 这是正常现象，并非所有服务都默认开启或暴露此优化。 2. 本文的测试方法旨在验证“可能性”，并非绝对证明。
`dsh`版本与文档不匹配	DSH/dsh 处于活跃开发期，命令和功能可能快速迭代。	运行`dsh --version`查看版本，并寻找对应版本的官方文档或 GitHub 仓库的 README。	关注 DeepSeek Harness 的官方 GitHub 仓库和文档更新。

9. 最佳实践与使用建议

基于以上探索，如果你想在实际项目中利用 Prompt Cache 技术或更好地使用 DSH 生态，可以参考以下建议：

明确需求，评估收益：首先分析你的应用场景。如果存在大量的、高度重复的提示词模板（例如，审核规则、标准化提取、固定格式生成），那么引入 Prompt Cache 技术将带来巨大的成本和延迟收益。如果每次请求都独一无二，则优化空间有限。
从 API 调用开始验证：在投入大量资源进行本地部署前，先像本文一样，通过云 API 进行简单的性能对比测试。这能帮你快速验证目标服务是否具备缓存优化以及大致的收益比例。
本地部署选型：如果你需要本地部署，应选择明确支持 KV Cache 优化和 Prompt Cache 的推理框架。目前，vLLM,TensorRT-LLM,TGI(Text Generation Inference) 等是主流选择，它们都提供了高级的缓存管理和调度功能。
设计可缓存的提示词：在应用设计时，有意识地将提示词中固定不变的部分（如系统指令、任务模板、示例）与可变部分（用户输入、数据）分离。这有助于缓存机制更高效地工作。例如，使用类似 [“系统指令”] + [“用户查询”] 的结构。
监控与度量：在生产环境中，监控缓存命中率、平均响应时间（区分首请求和后续请求）、Token 消耗等指标。这能帮助你量化优化效果，并为进一步调优提供依据。
安全与隔离：注意缓存隔离。不同用户、不同租户、不同安全级别的请求不应共享缓存，除非经过严格评估。确保你的缓存策略不会导致信息泄露。
DSH/dsh 作为客户端工具：将dsh视为一个强大的模型交互统一入口和插件平台。除了调用模型，多探索其插件市场 (dshmarket)，可能发现模型管理、工作流编排等有用工具。

10. 总结与下一步

Prompt Cache 和 KV Cache 是 LLM 推理效率优化的核心技术之一，其本质是“用空间换时间”，通过存储中间计算结果来避免重复计算，从而在重复或相似请求场景下实现显著的延迟降低和成本节约。

本文通过 DeepSeek Harness 的dsh工具，带你完成了一次从原理理解到动手验证的旅程。核心验证方法就是对比重复请求的响应时间。虽然我们无法直接窥视服务端黑盒，但性能指标的显著差异是缓存生效的有力佐证。

最值得尝试的下一步：

深入测试不同场景：用更复杂的提示词、更长的文本、不同的模型（如deepseek-coder）进行测试，观察缓存效果的变化。
探索本地推理框架：如果你有本地 GPU 资源，尝试部署 vLLM 等服务，并研究其--enable-prefix-caching等参数，进行更底层的性能和显存占用观测。
关注 DSH 生态发展：DeepSeek Harness 旨在构建一个开放的 AI 应用平台。关注其官方文档和更新，看其是否会推出更直观的缓存监控、管理功能，或提供集成了高级缓存策略的托管服务。

最容易踩的坑：过于期待在所有场景下都有提升。缓存不是银弹，它的价值与请求的重复度紧密相关。清晰界定你业务中“可缓存”的请求模式，是成功应用这项技术的前提。

建议将本文的测试脚本保存，作为你未来评估任何模型服务缓存能力的基准工具。理解并善用这些底层优化，能让你在构建 AI 应用时，在成本和性能之间找到更优的平衡点。