我使用GLM、Kimi、Opus和GPT测试了DeepSeek Harness，以查看提示缓存是否仍能与其他模型一起工作

简而言之：是的，至少对于GLM和Kimi。在实际的DeepSeek Harness会话中，GLM在工具循环内达到了97%的缓存重用率，下一轮达到了99.6%。Kimi两轮都达到了99%。Opus在此次测试中没有显示缓存活动，而GPT测试无法完成，因为我使用的第三方路由没有正确处理当前的DSH请求。我想测试DeepSeek Harness是否能在使用其他模型替代DeepSeek时保持高缓存命中率。DSH在每个请求上发送一个大的重复前缀：系统提示、25个工具定义、对话历史和先前工具结果。新消息附加到末尾。如果上游模型/提供商支持前缀缓存，那么大部分上下文应该可以重用。在测试DSH之前，我通过同一个第三方网关GMI Cloud发送了300多个直接API请求。GLM有16/21的前缀命中。Kimi有13/21，大约62%。我还针对账单导出检查了80个请求，每个请求都与报告的令牌使用量和公布价格完全匹配，因此我将cached_tokens作为DSH测试的主要信号。然后，我通过透明的日志代理运行正常的DSH网络会话。代理调用工具，读取一个长文件，并继续相同的对话。代理只记录实际请求和使用情况。GLM工作得非常好。第一次工具调用后，7924个输入令牌中有7680个被缓存：97%。在下一个对话轮次，18383个令牌中有18304个被缓存：99.6%。因此，一旦对话运行起来，几乎整个现有系统提示、工具定义和历史记录都在被重用。这也与直接API结果一致，GLM在前缀缓存方面一直是最可靠的模型。Kimi是一个更大的变化。它的直接API前缀测试只有13/21，大约62%，并且一些请求变得更快而没有报告缓存令牌。在DSH内部，工具循环请求报告了7424/7498个缓存令牌，99%。下一个轮次报告了17152/17325，也是99%。甚至第一个主要请求已经有5632个缓存令牌占7498个，尽管我没有事先手动用Kimi预热那个DSH系统提示+工具前缀。我没有足够的数据来说明为什么会这样，但实际结果是清楚的：Kimi在DSH中正常工作，并且后续请求保持约99%的缓存重用。这是直接API测试和实际DSH测试之间的最大区别：Kimi从大约62%的前缀命中率提高到实际工作负载中的大约99%。Opus可以在DSH中运行，但第二个请求有超过25k令牌的上下文，仍然报告零缓存令牌。上游Opus路由在当天的直接测试中也没有显示缓存活动，所以我无法从中得出更广泛的结论。我无法完成GPT测试。我使用的第三方GPT路由没有正确处理当前的DSH请求/配置，因此本次测试没有有用的GPT缓存结果。我还验证了另一件事：DSH Web UI中显示的缓存百分比与代理记录的cached_tokens匹配。因此，当提供商正确报告缓存使用情况时，DSH自己的缓存显示足以监控它。这里有用的结果是DSH的追加式请求模式也适用于其他模型。GLM和Kimi都处理了实际的工具调用和多轮历史，并且都达到了大约97–99.6%的前缀缓存重用。