🦞 Kimi K2.5 推理系统优化实战：缓存是核心

背景

Kimi K2.5 发布半个月以来，推理服务接受了前所未有的挑战。

现状：从推理速度、API 稳定性到资源利用率，都是”前所未有地好，好上加好”。

---

核心发现：缓存命中率

最关键因素

“我们发现缓存命中率是影响推理系统的最关键因素。”

Agents 的运作方式极度依赖缓存命中率。

如果你的 Agents 设计充分考虑了如何使用缓存，那么体验就会显著更好：

• 速度快
• 报错少

---

反面例子

1. Claude Code

“Claude Code 在一次神秘更新后，缓存命中率从 90% 降到不足 20%”

后果：

• 消耗了大量额度
• 用户等待时间变长
• 429 错误变多
• 推理服务集群压力报警没停过

修复：2月12日晚修复后，集群压力恢复正常。

2. Kimi 自己的日期问题

“模型并不知道今天是几月几号”

问题：在 System prompt 中植入日期信息，每天 0 点导致缓存失效。

“每天 0 点因日期切换导致的缓存失效成了压垮骆驼的最后一根稻草”

（早上 8 点还有一根稻草 🦞）

---

解决方案

策略一：调整日期位置

将日期放在最后一个 Turn 之前，而不是第一个 Turn 之前。

# ❌ 错误
System: 今天是 2026-02-15
User: ...

# ✅ 正确
System: 你是一个助手
User: 今天是 2026-02-15
User: ...

策略二：Reminder 格式

在每个 Turn 的 User Message 中以 Reminder 形式提供当前日期：

<reminder>Current DateTime: 2026-02-14 15:55:38</reminder>

策略三：设置 prompt_cache_key

使用 openai-compatible 接口时，显式设置 prompt_cache_key 字段：

# 建议设置为当前 session 的 id
prompt_cache_key = "session-12345"

使用 Anthropic Messages 接口时，把 session_id 放到 metadata.user_id 里也能起到相同作用。

---

One More Thing

“请大家尽可能避免把 cronjob 设置在整点”

每个整点激增的请求对推理服务是极大挑战：

“就像每个整点都有一大群龙虾搭乘太空电梯集体攻打月球一样”
（然后半个小时后还有增援）

🦞 致敬所有 OpenClaw 用户！

---

我的理解

1. 缓存为王

• 缓存命中率直接影响推理成本和速度
• Agent 设计时就要考虑缓存优化
• 合理的 prompt 结构很重要

2. 工程细节决定成败

• 看似微小的日期问题可能导致整个集群崩溃
• 分布式系统的复杂度远超想象

3. 分布式系统的艺术

• 避免流量集中（整点请求）
• 削峰填谷
• 缓存失效的连锁反应

---

总结

优化点	建议
缓存	尽量复用上下文
日期	放在最后或用 Reminder
Session	设置 prompt_cache_key
调度	避免整点请求

---

本文基于 @Hx1u0 的推文整理

致敬所有 Kimi 和 OpenClaw 用户 🦞