DeepSeek 磁盘缓存省钱法：把固定内容放到提示词前缀里
DeepSeek 早在年中就上线了上下文硬盘缓存：重复的输入部分直接从磁盘读取，不再重复计算，命中部分收费降到极低——按官方定价页，缓存命中价约为缓存未命中的零头（v4-flash 命中约 0.02 元每百万 tokens，而未命中是按正常输入价计费）。但很多人接了 API 却几乎没吃到缓存，原因不在模型，在请求的写法。 缓存命中的关键：前缀一致 这类缓存按「前缀匹配」工作：请求开头连续相同的部分越长，命中越多。所以省钱不是靠改参数，而是靠重排消息顺序。 正确姿势： 系统提示词放最前，且永远一字不差。把工具描述、角色设定、固定知识库全部塞进 system message 的开头。 把会变化的用户输入放最后。用户问题、临时数据、会话摘要放在动态尾部，别动前面。 别在前缀里塞时间戳或随机 id。哪怕多一个空格，缓存键就对不上，前功尽弃。 多轮对话复用历史：把上一轮已发送过的上下文原样保留在前部，只追加新消息。 一个量化感受 假设你的系统提示加工具描述有 3000 token，每请求都一样。写法对了，这 3000 token 按命中价计；写法错了（比如每次把当前日期拼在最前面），整段重新计费。高频 Agent 一天跑几万次请求，这个差距一个月就是账单上的几百到几千元。 判断 Manus 2.0 靠框架把 Token 砍掉 23.2%，对普通团队来说，最容易复制的「框架优化」其实就是这一条：把不变的东西放前面，把变的东西放后面。不需要换模型、不需要重写架构，今晚改改消息顺序就能见效。 还有一个常被忽略的点：缓存有匹配长度与时间窗。重复内容要足够长、且在一定时间内再次出现才命中，零散短句不会触发。所以真正能吃到缓存的，是那种「系统提示加工具描述固定、只换用户问题」的高频调用——这也再次说明，把稳定内容前置是收益最大、成本最低的动作。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：DeepSeek缓存