缓存策略探测实验方案架构设计

执行摘要本方案将缓存策略探测设计为五阶段递进式实验流水线Phase 0 → 4核心思路是不要默认信任cached_tokens——先用 Phase 1 验证这个字段是否在说真话用决策树而非线性流程——每个阶段根据上一阶段的结论自动分叉到对应的下一阶段双信源三角验证——cached_tokens 响应延迟互为校验隔离优先于效率——探针污染是 test-V4 最大的方法论失败本次方案将隔离性作为首要设计约束接受无法完全区分作为合法结论——有些缓存机制的外部黑盒不可区分方案明确标记这些盲区关键决策Phase 1 的结果决定整个实验是否值得继续。如果cached_tokens被证伪实验必须切换到延迟为主信源模式。1. 假设空间目录在开始实验前穷举所有可能的缓存实现方式。这是决策树的叶节点集合——所有分支最终都会收敛到这些假设之一。1.1 缓存机制假设空间编号假设核心特征可探测性test-V4 支持证据H0无缓存cached_tokens始终为 0重复请求延迟无下降⭐⭐⭐ 高❌ 矛盾所有报告显示cached_tokens 0H1固定响应字段cached_tokens f(prompt_tokens)是纯公式与实际缓存无关⭐⭐⭐ 高✅ 强证据cached prompt - 1跨所有场景恒定H2内容哈希全局缓存对整个请求内容序列化后做哈希哈希匹配则全量命中⭐⭐ 中✅ 支持Report D 中 v4-pro 的cached_tokens固定 806H3前缀匹配上下文缓存标准 Prompt Caching从第一个 token 开始匹配到分叉点⭐⭐⭐ 高❌ 矛盾different_system场景本应零命中却显示高命中H4采样哈希缓存对内容做局部采样哈希如每隔 N 个 token 采样近似匹配⭐ 低部分兼容现有数据H5语义向量缓存对内容做 embedding相似度 阈值即命中⭐ 低部分兼容现有数据H6时间窗口缓存在固定时间窗口内如 5 分钟同一 API key 的所有请求共享缓存⭐⭐ 中无直接证据H7会话级缓存缓存绑定到特定会话/连接跨会话不共享⭐⭐ 中无直接证据H8混合策略上述 2 种机制的组合如前缀匹配 时间窗口⭐ 低可能性存在1.2 假设的 Bayesian 先验基于现有 4 份报告基于 test-V4 的 4 份测试报告我们对各假设的初始信念P(H1: 固定响应字段) 0.45 ← 最强先验exact minus 1 模式 P(H2: 内容哈希缓存) 0.30 ← Report D 固定 806 支持 P(H0: 无缓存) 0.05 ← 与 cached_tokens 0 矛盾 P(H3: 前缀缓存) 0.10 ← different_system 假阳性矛盾 P(H4-H8: 其他) 0.10 ← 均匀分配重要这些先验只是实验设计的起点不应影响实验结果的客观判断。1.3 不可区分假设对某些假设对在黑盒测试中无法区分。方案必须承认这些盲区假设对不可区分原因解决方案H4 采样哈希 vs H5 语义向量两者都可能对相似但不相同的内容产生命中需要白盒信息或大量采样测试H2 内容哈希 vs H1 固定响应如果 API 确实缓存了所有内容因为语料库有限H2 的观测可能与 H1 相同Phase 0 的语料空间独立性测试H6 时间窗口 vs H7 会话级两者都在短时间内产生缓存命中需要跨 API key / 跨 IP 测试2. 阶段架构总览Phase 0: 信号源盘点 (前置1 小时) ↓ Phase 1: 信号真实性验证 (关键分叉2-4 小时) ↓ ├─ 信号可信 ──→ Phase 2: 机制区分 (核心4-8 小时) │ ↓ │ Phase 3: 边界映射 (细化4-8 小时) │ ↓ │ Phase 4: 鲁棒性测试 (收尾2-4 小时) │ └─ 信号不可信 ──→ 切换到延迟信源 → Phase 2-4 (同上仅信源不同)总耗时估算15-25 小时含 API 调用冷却等待时间Phase 0: 信号源盘点目标在写一行测试代码之前明确所有可用的观测信号产出信号清单 信噪比预估信号类型获取方式预期信噪比优先级cached_tokens直接API 响应的usage.prompt_tokens_details.cached_tokens未知待验证P0prompt_tokens直接API 响应的usage.prompt_tokens高基础计数P0总响应延迟间接客户端 RTT 计时中受网络抖动影响P0首 token 延迟 (TTFT)间接流式模式首个 chunk 到达时间中-高更能反映计算时间P1响应 body 一致性间接对比相同 prompt 的响应内容是否逐字相同中受 temperature 影响P1API 计费报告间接从 API 供应商 dashboard 获取实际扣费高如果可获取P1速率限制头间接响应头中的X-RateLimit-*或类似字段低大多数代理不暴露P2关键决策点如果 Phase 1 发现cached_tokens不可信我们必须切换到延迟和计费作为主信源。如果所有间接信源也都不可靠则实验终止——结论是该 API 的缓存行为无法从外部探测。Phase 1: 信号真实性验证目标回答一个问题——cached_tokens是在报告真实的缓存命中还是在执行一个固定公式核心思路构造两组请求如果cached_tokens是真实测量它们应该有显著差异如果它是固定公式它们将相同。1.1 独立性探针H0 vs H1 区分测试逻辑发送两组「内容词汇完全不重叠」的请求。第一组主题 A如中国古代史第二组主题 B如量子计算如果cached_tokens是真实的第二组请求的缓存命中应为 0因为内容完全不相关。如果cached_tokens仍然为非零固定值如prompt_tokens - 1则 H1 成立。判定规则if 所有请求的 cached_tokens 0含内容完全不相关的请求: → H1 或 H8固定响应或内容无关缓存 → 切换到延迟信源 elif 仅相同/相似内容出现 cached_tokens 0: → 信号可能真实 → 继续 1.21.2 一致性探针验证信号与物理缓存的相关性测试逻辑发送完全相同的一对请求间隔足够的时间确保第一次的副作用写入完成。如果cached_tokens真实第二次请求应显示大量缓存命中。同时测量两次请求的延迟差。判定规则if cached_tokens(2nd) cached_tokens(1st) AND latency(2nd) latency(1st): → 信号与物理缓存行为一致 → ✅ 信号可信使用 cached_tokens 作为主信源 elif cached_tokens(2nd) cached_tokens(1st) AND latency(2nd) latency(1st): → 物理缓存存在但字段不反映它 → ⚠️ 信号不可信切换到延迟信源但实验可继续 elif cached_tokens(2nd) cached_tokens(1st) AND latency(2nd) ≈ latency(1st): → 无缓存 → ❌ 终止H0 成立1.3 跨端点对照探针测试逻辑在两个被测端点上同时运行 1.1 和 1.2。如果两个端点行为不同说明至少有一个端点的cached_tokens语义不同。关键约束需确认是否有官方 DeepSeek APIapi.deepseek.com作为基准对照。如果官方 API 的cached_tokens行为是已知的标准前缀缓存则可以作为校准基准。Phase 2: 缓存机制区分前置条件Phase 1 确认至少有一个可信信源cached_tokens或延迟目标从 8 个假设中确定最可能的缓存机制2.1 内容哈希 vs 前缀缓存区分H2 vs H3这是整个实验中最关键的一次区分。两种机制在大多数场景下表现相似相同内容都命中但有一个根本差异对顺序重排的响应不同。决定性探针顺序重排测试构造两个 system promptPrompt A段落 1 段落 2 段落 3原始顺序Prompt B段落 3 段落 2 段落 1反转顺序预期 - 前缀缓存A 和 B 的第一个 token 就不同 → 缓存命中 0 - 内容哈希缓存A 和 B 的内容完全相同 → 缓存命中 100% - 固定响应公式A 和 B 的 cached_tokens f(prompt_tokens) → 完全相同决策逻辑if 重排后缓存命中 ≈ 0 → H3前缀缓存→ 进入 Phase 3b if 重排后缓存命中 ≈ 100% → H2内容哈希→ 进入 Phase 3a if 重排后缓存命中 ≈ f(prompt_tokens) 不变 → H1固定响应→ 回退 Phase 12.2 前缀缓存分叉点探针H3 确认测试逻辑构造一系列 prompt 对前缀共享比例从 0% 逐步增加到 100%以 token 为单位非字符。共享比例: 0% → 25% → 50% → 75% → 90% → 100% 预期 H3: cached ≈ 共享前缀的 token 数 预期 H2: cached 00%或 100%100%中间值全为 0 预期 H4: cached ≈ f(共享比例)但可能非线性2.3 时间与会话维度探测H6 vs H7测试逻辑使用不同 API key 在短时间内发送相同请求使用相同 API key 在 TTL 后发送相同请求if 跨 key 仍然命中 → H2 或 H6全局/时间窗口缓存 if 仅同 key 命中 → H7会话级缓存Phase 3: 边界映射根据 Phase 2 的结论进入不同的子阶段Phase 3a: 内容哈希缓存边界映射探针维度测试内容关键问题哈希敏感度改变单个字符、空白符、换行符、标点哈希是否对微小变化敏感是否是标准化哈希忽略空白序列化格式敏感度JSON key 顺序变化、messages 数组顺序哈希输入是原始 JSON 还是规范化后的表示内容长度边界从 1 token 逐步增加到 10000 tokens是否存在最小/最大缓存长度超大内容是否绕开缓存哈希碰撞概率大量不同内容1000 种的缓存命中模式是否存在可检测的碰撞模式Phase 3b: 前缀缓存边界映射探针维度测试内容关键问题分叉点精度前缀共享比例0%, 10%, 20%, …, 100%分叉点检测精度是 token 级还是字符级中断规则在共享前缀中间插入一个不同 token后面又恢复相同缓存是否在第一个差异处断开不可恢复还是可以跳过差异Breakpoint 行为构造多个分叉点前缀 A 共享中间 B 分叉后缀 C 又共享缓存能否在分叉后重新匹配最小匹配长度前缀长度从 1 token 逐步增加最短多少 token 的前缀可以触发缓存Phase 3c: TTL 衰减曲线所有机制适用测试逻辑写入缓存发送一个播种请求在时间点 t [1s, 5s, 10s, 30s, 60s, 120s, 300s, 600s, 1800s, 3600s] 发送相同请求记录每个时间点的缓存命中率拟合衰减曲线关键约束每个时间点的探测请求本身会刷新缓存。因此每对播种→探测必须是独立的内容用唯一 UUID 区分。正确设计隔离 播种_A → 等待 10s → 探测_A (测 TTL10s 的衰减) 播种_B → 等待 30s → 探测_B (测 TTL30s 的衰减独立于 A) 错误设计污染 播种_A → 等待 10s → 探测_A → 等待 20s → 探测_A ↑ 第一次探测_A 已经刷新了缓存第二次测的是 20s 而非 30sPhase 4: 鲁棒性测试维度测试内容关键问题并发写入同时发送 5/10/20 个不同的播种请求然后检测每个的缓存是否独立存在缓存是否支持并发写入是否有 race condition缓存容量持续发送大量不同的内容100 个唯一 prompt然后回头检测最早的内容是否被逐出LRUFIFO随机逐出容量上限大载荷单个 prompt 的 token 数达到 8K/16K/32K大内容是否绕过缓存跨模型隔离在端点 A声称 deepseek-v3.2和端点 Bdeepseek-v4-pro上发送相同内容缓存是按模型隔离的还是全局共享的异常恢复发送一个导致 4xx/5xx 的请求后检测之前的缓存是否仍然存在错误响应是否触发缓存清空3. 实验矩阵设计3.1 矩阵维度维度类型水平数水平定义D1: 内容相似度自变量操纵6完全相同 / 前缀共享 / 后缀共享 / 顺序重排 / 部分重叠 / 完全不相关D2: 请求序列位置自变量操纵3首次请求播种/ 二次请求探测/ 第 N 次请求D3: 时间间隔自变量操纵8-100s, 1s, 5s, 10s, 30s, 60s, 120s, 300s, 600s, 1800sD4: 内容大小自变量操纵3小型 ~200 tokens / 中型 ~1000 tokens / 大型 ~5000 tokensD5: 修改粒度自变量操纵4替换 1 字符 / 替换 1 token / 替换 1 段落 / 替换全部D6: API 端点分组变量2-3算优优 / 移动云 / 官方 DeepSeek对照D7: 迭代次数控制变量≥5每个条件重复至少 5 次基于 test-V4 审查建议3.2 矩阵压缩策略全因子实验的组合数是 6×3×10×3×4×3×5 32,400 个条件——不可行。压缩策略不是所有维度组合都有意义。按阶段裁剪阶段活跃维度典型组合数说明Phase 1D1(2) × D2(2) × D6(2) × D7(≥5)~40仅需完全不同 vs 完全相同Phase 2D1(3) × D2(2) × D6(2) × D7(≥5)~60重排、前缀共享、完全不同Phase 3aD1(2) × D4(3) × D5(4) × D6(1) × D7(≥5)~120针对内容哈希的精细探测Phase 3bD1(2) × D4(3) × D5(2) × D6(1) × D7(≥5)~60针对前缀缓存的精细探测Phase 3cD3(10) × D6(2) × D7(≥3)~60TTL 曲线Phase 4视前序结果定制~50-100针对性鲁棒性测试总计约 390-440 次 API 调用可管理3.3 随机化与阻塞Phase 内随机化同一 Phase 内的条件顺序应随机化Fisher-Yates shufflePhase 间隔离每个 Phase 使用独立的内容域避免 Phase 间缓存污染端点间对照算优优和移动云的测试应交替进行而非先完成一个再另一个以消除时间趋势混淆4. 探针污染防护策略这是 test-V4 最严重的架构缺陷。本次方案将污染防护从建议提升为架构约束。4.1 污染类型与对策污染类型机制test-V4 表现本方案对策跨场景污染前序场景将内容写入缓存后序场景误中different_system假阳性P0 行动项 #4内容域隔离 Phase 隔离跨迭代污染同一场景的迭代 1 写入缓存迭代 2-5 全部命中所有迭代显示相同cached_tokens每次迭代使用独立内容域跨时间点污染TTL 测试的探测请求刷新缓存TTL 测试逻辑缺陷P0 行动项 #7每个时间点使用独立播种-探测对跨端点污染端点 A 的缓存通过某种后端共享影响端点 B未知如果两个端点行为完全一致需怀疑是否为同一后端4.2 内容域隔离架构核心思想每个独立的测试单元使用完全不重叠的语料空间。内容域分配 Domain_Phase1_A: 语料集 {动物学, 植物学, 矿物学} Domain_Phase1_B: 语料集 {量子物理, 相对论, 弦理论} Domain_Phase2: 语料集 {法国历史, 英国历史, 德国历史} Domain_Phase3a: 语料集 {操作系统, 编译器, 数据库} Domain_Phase3b: 语料集 {油画技法, 雕塑技法, 版画技法} Domain_Phase3c_T1-T10: 语料集 {10 个独立的虚构公司简介} Domain_Phase4: 语料集 {奥运会历史, 世界杯历史, ...}关键原则每个 Phase 使用独立的语料领域词汇零重叠每个 TTL 时间点使用独立的内容用 UUID 标记阴性对照必须在每个 Phase 开始时首先执行语料库本身不应在 API 的全局缓存中预先存在使用随机生成的合成内容更好4.3 会话隔离检查清单在每次 Phase 切换时执行□ 当前使用的 API key 是否与上一 Phase 相同 → 如果相同是否有证据表明上一 Phase 的内容已从缓存中逐出 → 如果不确定等待 ≥ 推测 TTL × 2 的时间 □ 当前 Phase 的语料域是否与所有前序 Phase 的语料域零词汇重叠 → 用自动化脚本验证集合交集检测 □ 当前 Phase 的阴性对照是否在序列第一位 → 确保阴性对照结果不被任何前序操作污染5. 风险、局限性与盲区5.1 可探测性边界以下情况黑盒测试无法得出确定结论盲区原因影响缓解措施多层缓存API 代理后可能有多层缓存CDN → 代理 → 模型服务探针只能看到最终聚合效果可能将多层聚合误判为单一机制通过不同时间尺度秒级 vs 分钟级的测试间接推断层次动态切换策略API 提供商可能根据负载动态调整缓存策略不同时间的测试结果可能不一致在多个时间段重复核心探针早/中/晚各一次私有缓存键缓存键可能包含探针无法控制的字段如 IP、User-Agent、请求头顺序跨客户端测试结果不一致在探针文档中明确声明所有请求头的取值缓存预热API 可能对热门内容做预先缓存基于日志分析第一次请求就出现缓存命中使用足够冷门的合成内容概率性缓存缓存可能只有一定概率生效如仅在负载高时启用结果有随机性增大迭代次数n ≥ 10报告置信区间5.2 如果cached_tokens完全虚假这是本方案的最坏情况。如果 Phase 1 判定cached_tokens不可信即 H1 成立后续所有实验必须切换到双信源模式主信源响应延迟需在相同网络条件下多次测量取中位数辅助信源API 计费仪表盘如果可以获取实际扣费数据延迟测量的挑战网络抖动噪声需要足够大的迭代次数建议 n ≥ 10和异常值过滤IQR 方法模型推理时间方差首 token 延迟TTFT比总延迟更有区分力因为缓存应主要减少计算时间需要非缓存场景的基线延迟作为对照可接受的结论范围缩小可以确认“物理缓存是否存在”通过延迟下降判断可以确认“缓存是否对内容敏感”通过不同内容的延迟对比无法确认“缓存的精确命中率”——延迟下降只能告诉你有缓存但不能精确量化命中了多少 token5.3 探针自身的伦理边界API 的速率限制Phase 3c 和 Phase 4 可能触发速率限制。需要在方案中预留冷却期。不要对生产 API 进行 DoS 级别的并发测试Phase 4 的并发写入应限制在 20 个并发以内如果 API 返回 429应自动退避而非重试6. 后续执行方案从实验到测试工具6.1 结论到工具架构的映射假设 Phase 4 完成后得出了确定的缓存模型以下是各结论对应的测试工具架构原则场景 A确认为「内容哈希全局缓存」测试工具的核心变更 ✗ 删除所有基于前缀共享比例的测试场景prefix_sweep, prefix_truncation, partial_overlap——这些场景对内容哈希缓存无区分力 ✓ 新增内容复用率监测器——在对话历史中追踪内容块的重复出现频率 ✓ 重构cached_tokens 的语义从前缀命中 token 数改为内容复用 token 数 ✓ 架构调整测试场景从 6 个减少到 3 个核心场景 - identical阳性对照 - content_reordered敏感度测试顺序重排是否影响命中 - content_modified敏感度测试微小修改是否影响命中 ✓ 监控指标变更从cache hit rate by prefix overlap改为 cache hit rate by content similarity场景 B确认为「前缀匹配上下文缓存」测试工具的核心变更 ✓ 保留前缀类测试场景prefix_sweep, prefix_truncation——但需用 tiktoken 精确计算 token 级分叉点 ✗ 删除current 的字符级切分方式 ✓ 新增分叉点精度测试token-level bifurcation point detection ✓ 新增前缀缓存的中断与恢复测试breakpoint and reattach ✓ 监控指标精确到 token 的缓存命中率与预期前缀共享比例对比场景 C确认为「无缓存」H0或「固定响应」H1测试工具的核心变更 ✗ 整个缓存测试工具废止——如果无缓存就没有可测的东西 ✓ 替代方案将工具重定位为API 行为一致性验证器 - 验证 usage 字段的公式化关系 - 监测不同 API 版本间的字段语义变化 - 作为持续监控工具在 API 升级后自动检测缓存行为是否发生变化6.2 测试工具架构设计原则独立于缓存结论无论最终确认的是哪种缓存机制重构后的测试工具应遵循信源可切换支持cached_tokens、延迟、计费三种信源通过配置项切换探针隔离优先每个探针单元使用独立的内容域探针执行顺序可随机化统计报告所有测量附带 95% CI 和效应量不再依赖 n2 和固定阈值自检机制在每次测试运行的开头自动执行 Phase 1 级信号验证如果信号模式异常则自动终止并报告多端点支持同时测试多个端点自动执行对照分析双模运行支持探测模式反向工程缓存机制和监控模式持续验证缓存行为是否变化7. 交付物清单本方案产生交付物负责方状态缓存策略探测实验方案架构本文档gstack-product-reviewer✅ 已完成决策树可视化内嵌 SVGgstack-product-reviewer✅ 已完成需要后续产生交付物负责方依赖Phase 1-4 的具体探针测试用例参数化规格gstack-investigator本文档 Phase 架构判定标准与统计显著性要求含自动化判定逻辑gstack-qa-lead本文档假设空间 investigator 探针设计综合执行脚本整合三方输出team-lead以上全部缺陷对应关系缺陷缺陷描述本方案如何解决逻辑缺陷CORPUS 重叠导致不同 system prompt 内容相同Phase 架构 内容域隔离每个 Phase 使用独立语料域零词汇重叠功能缺陷prefix_sweep 重复 API 调用不在本方案范围implementation detail但架构上要求每个探针是纯函数方法论失效exact minus 1 模式未被检测Phase 1 信号真实性验证自动检测固定公式模式并终止缓存污染场景顺序固定后序被污染Phase 间隔离 阴性对照优先 内容域隔离场景构造UUID 前缀不足以区分内容哈希Phase 2 顺序重排探针用完全反转的内容区分哈希缓存场景构造字符级切分 ≠ token 级切分Phase 3b 要求 token 级精确切分使用 tiktokenTTL 污染探测请求刷新缓存Phase 3c每个时间点使用独立的播种-探测对判定逻辑固定阈值、n2、错误处理不在本方案范围qa-lead 负责判定标准