案例：Headroom 代理 vs DeepSeek Prefix Caching 冲突排查
日期: 2026-06-07 排查人: 大锤 → 老克 → Peter 系统链路: Hermes Agent → Headroom(localhost:8787) → DeepSeek V4 Flash API
背景
预期通过 Headroom 代理的上下文压缩功能降低 token 消耗和 API 费用。安装后使用一天，发现费用异常——单纯对话（无编码）的日消耗超过平时一整天（含高强度编码）的费用。
排查过程
第一轮：定价假设偏差
错误假设： DeepSeek V4 Flash 的缓存折扣为 50%（0.07/M）——来自第三方博客和 Headroom 内部计算。
事实： DeepSeek 官方定价显示缓存命中价仅 $0.0028/M，是全价的 2%，即 98% 折扣。一个定价假设的偏差导致整篇分析结论全歪。
教训： API 定价必须查官方文档，第三方估算值标注”需验证”。
第二轮：Headroom 压缩效果实测
| 指标 | 数值 |
|---|---|
| 请求总数 | 458 |
| 输入 tokens（压缩前） | 41,379,628 |
| 输入 tokens（压缩后发 API） | 24,568,077 |
| 压缩节省 | 16,811,551（40.6%） |
| 输出 tokens | 147,969 |
第三轮：缓存命中率分析
| 指标 | 数值 |
|---|---|
| 缓存读取 tokens | 20,012,544 |
| 缓存写入 tokens | 594,556 |
| 未缓存 tokens | 4,555,533 |
| Token 级缓存命中率 | 79.5% |
| 请求级缓存命中率 | 99.8% |
几乎每个请求都有部分缓存命中，但命中率不高。
第四轮：根因定位
矛盾链：
- Hermes CCR（对话压缩）在上下文达到 ~64K 时触发（今日 38 次）
- CCR 每次做三件事：重写消息结构、追加压缩提示到 system prompt、旋转 session_id
- Headroom 的
SessionTrackerStore用(model + system_prompt[:500])哈希标识会话 - CCR 改了这两者 → Headroom 认为新会话 → prefix freeze 重置
- DeepSeek 的前缀缓存从零开始积累
- 38 次 CCR = 38 次缓存硬重置
Headroom 统计盲区： tokens_lost_to_cache_bust = 0——它只跟踪自身 SmartCrusher 导致的缓存失效，不知道上游 CCR 的存在。
最终方案
拆掉 Headroom，Hermes 直连 DeepSeek API。
费用对比
| 时段 | 模式 | 费用 |
|---|---|---|
| 5月（2000+ 消息超长会话） | 直连 DeepSeek | ¥2-3/天 |
| 今天（191 轮对话） | 经 Headroom | ¥3.93/天 |
| 预判直连后 | 直连 DeepSeek | 更低 |
关键：直连时前缀稳定，缓存几乎全命中（0.14/M），得不偿失。
关键发现
- 多层优化工具可能互相抵消： CCR 压缩 → 打断缓存 → 成本反升
- 不要假设”多一层总是好的”： 引入优化工具前应设基准线，安装后对比验证
- API 定价以官方为准： 一次定价引用错误可让整篇分析结论全歪
- DeepSeek 缓存价值远超预期： $0.0028/M 的超低价意味着缓存稳定性比压缩更重要
方法论沉淀
引入优化工具前的验证清单
- 当前基准线已记录（token 数 + 费用）
- 只引入一个优化层（避免多变量干扰）
- 该工具会否与现有层冲突？（压缩 vs 缓存、路由 vs 限流等）
- 有明确的成功/失败判定标准
API 定价信息源分级
| 级别 | 来源 | 可信度 |
|---|---|---|
| A | 官方定价页面 | 高，直接使用 |
| B | 官方 SDK/API 响应 | 高，但需确认字段含义 |
| C | Headroom/OpenRouter 等代理计算 | 中，需交叉验证 |
| D | 第三方博客/评测 | 低，标注”需验证” |
后续跟踪
- Headroom 项目迭代中（PR #625 prefix stability pinning），日后若解决上游压缩破坏缓存问题，可重新评估
- 每月复核一次 DeepSeek 缓存命中率和费用趋势