一、涨价已经落地，账单的差距藏在 30 倍里
8 月 17 日零点，DeepSeek 新价格正式生效，全系切入峰谷计价。知乎社区的情绪很直接：那位曾经把 API 打到白菜价的"价格屠夫"，创始人梁文锋从被尊称"梁圣"，到被调侃成"梁子"“梁文谷”——高峰时段贵到用不起。
这不是 DeepSeek 一家的动作。智谱年内三连涨，Kimi K3 输出价涨超 3 倍，MiniMax 直接翻倍，国产大模型正在集体从价格战退回价值战。烧钱换份额的阶段过去了，接下来拼的是每一块钱 token 花得值不值。
具体涨了多少？旗舰 V4-Pro 高峰时段每百万 tokens 输出价 27 元，此前是 6 元，一口气涨了 350%，高峰时段定义为工作日 9–12 点、14–18 点。知乎8 月 23 日后规则放宽，周六周日全天按低谷价计费，非实时任务有了明确的便宜窗口。
但真正决定账单数量级的，是缓存。V4-Pro 缓存命中输入价 0.15 元/百万 tokens，未命中 4.5 元，相差 30 倍。知乎同样是输入，命中与否差出一个数量级。也就是说：会不会组织前缀、会不会让缓存命中，比会不会砍需求更影响这个月的账单。
二、LangChain 7 月悄悄上线的显式缓存，正好踩在这个点上
涨价公告刷屏的时候，很多人才回头发现：LangChain 在 2026 年 7 月上旬已经密集发版，1.3.13 联合 langchain-openai 1.3.5 把显式 Prompt caching 做成了标准参数，核心变化是让开发者能按自己的策略管理 prompt 缓存，不再依赖服务端自动猜测。微信公众号
之前的自动缓存有两个说不清的地方：写入时机由服务端决定，你不知道哪段内容进了缓存；多副本部署时同一前缀可能被路由到不同推理节点，命中率靠运气。对客服机器人、代码补全这类高频重复场景，这两种不确定性意味着成本与延迟仍有至少 20%–40% 的优化空间。微信公众号
这次更新新增三个可观测的控制接口，目标都是让开发者拿回缓存的主控权。微信公众号拆开看：
prompt_cache_key：传入自定义字符串，把请求优先路由到同一 key 对应的推理节点，适合按租户、场景、客户 ID 分片，解决"命中率靠运气"的问题。
prompt_cache_options：implicit 模式保留自动断点并允许显式标记，explicit 模式只用你指定的断点，ttl 可以把缓存有效期精确到分钟级。
prompt_cache_breakpoint：在消息内容块上精确标记缓存写入点，支持显式断点的模型每请求最多 4 个显式断点加 1 个隐式断点。
三个控制点可以独立用，也可以组合。翻译成一句话：以前是"希望服务端帮我缓存"，现在是"我指定哪一段必须缓存"。
三、先泼三盆冷水，再谈怎么上
第一，这套字段走的是 OpenAI 协议。如果你的生产流量是通过 OpenAI 兼容接口接国产模型，显式缓存字段是否被识别、是否真的计费生效，必须用自己的流量实测，别把升级当生效。旧模型遇到新字段会静默忽略，不报错，这恰恰是最容易误判的地方。
第二，不管走不走显式字段，把不变的内容钉成固定前缀，是所有模型通用的工程纪律。系统提示、工具描述、few-shot 示例、知识库文档块，放在请求最开头并且保持逐字节稳定，后续每轮只传差异。知乎这一步零成本，今天就能做。
第三，别指望缓存解决一切。每次请求都在变的 system prompt、随手改写的工具描述，缓存了也是白缓存。显式缓存的收益前提是结构稳定，它奖励的是有纪律的请求设计，不是无脑重试。
四、光靠缓存不够，LangChain 降本是一套组合拳
1. 钉前缀，吃透缓存。这是地基，上面所有的收益都建立在前缀稳定上。用 prompt_cache_breakpoint 把系统指令和 few-shot 圈进缓存区，用 prompt_cache_key 给多租户流量分片。
2. 压缩上下文，别让历史无限膨胀。用 trim_messages 控制进入模型的消息量，长对话交给 1.0 引入的中间件机制处理——SummarizationMiddleware 这类中间件可以灵活拦截和修改 Agent 行为，把旧对话滚动成摘要而不是原样背着。微信公众号
3. 模型分级，粗活别上贵模型。init_chat_model 一个入口切不同厂商和档位，把任务分层：分类、抽取、初稿、格式化走便宜的 Flash 档，多步推理、复杂评审才上 Pro。V4 系列有 Flash 和 Pro 两档，Flash 便宜、快，写邮件、做分类、出初稿、跑简单抽取这类"粗活"交给它。知乎
4. 错峰批跑，把非实时任务挪出高峰。数据清洗、RAG 建索引、批量摘要、定时报告，本来就不需要秒级响应。用 batch、ainvoke 加 max_concurrency 并发控制，统一排到低谷窗口，高峰价是低谷的两倍，错峰本身就近乎砍半。
5. 改造前先估算账单。langchain-core 1.4.0 起，count_tokens_approximately 支持多模态消息的 token 估算，改造前后各算一遍，能直接量化每条优化动作的含金量，避免凭感觉降本。
6. 顺手把迁移做掉。1.0 已经承诺 2.0 之前不会有破坏性变化。微信公众号现在动缓存参数、接中间件，不用担心下个版本白改。
五、按场景对号入座
场景 | 成本痛点 | 优先动作 |
|---|---|---|
客服多轮对话 | 系统提示与人设大段重复 | prompt_cache_key 按租户分片，系统提示钉成固定前缀 |
RAG 知识库问答 | 长文档上下文反复编码 | 文档块前置为稳定前缀，显式断点圈住检索区 |
代码补全 | 高频、强实时，没法错峰 | 吃透缓存命中率，补全走小模型档位 |
Agent 编排 / 批处理 | 单任务内 LLM 调用次数多 | 错峰批跑 + 模型分级 + trim_messages |
RAG 场景值得单独说一句：同一份长文档反复提问时，前缀缓存把首 token 时间从 22.4 秒压到 0.56 秒，答案逐 token 不变。知乎对"加载一次文档、反复提问"的业务，缓存收益直接决定体验，也直接决定账单。
六、接下来值得盯的三个信号
一是 DeepSeek 的峰谷窗口和缓存政策还会不会调——8 月 23 日刚放宽过一次周末规则，说明计价表本身还在动，别把任何一档价格当长期常量写进成本模型。
二是国产模型在 OpenAI 兼容层上会不会跟进显式缓存字段。一旦有厂商把缓存控制做成标准参数，多厂商之间的降本空间会重新拉开，届时 init_chat_model 这类统一入口的切换价值会更大。
三是本地兜底路线的性价比。这一周社区在密集验证消费级显卡跑开源 27B 级别模型，如果轻任务本地化的成本真的压过云端，云端涨价对你的杀伤力会再降一档。
定价权不在自己手里，但 token 怎么花是工程问题，工程问题就有工程解法。今天最值得做的一件事：把线上请求的前缀结构审一遍，看看 30 倍的差距里，自己站在哪一边。
