DeepSeek 调价的消息出来之后我身边几个技术群都在讨论要不要赶紧换服务商。我拦住了我们团队里准备动手的同事不是因为懒得改代码而是因为在这种时刻换恰恰是最不该先做的事。这篇文章我想从成本工程的视角把这件事拆开讲清楚为什么涨价之后最便宜的方案不是换服务商以及你真正应该优先调整的五个环节。如果你正在用 DeepSeek 的 API或者在用 Codex、Harness 这类工具接了大模型做智能体应用这篇文章大概率能帮你省回远超涨价带来的那部分成本。1. 为什么涨价就换往往是最贵的应对方式1.1 换服务商的第一步不是改 base_url而是重写钱很多团队接到涨价消息时第一反应是搜一圈同类服务比单价然后准备迁移。但迁移从来不是改一行 base_url 的事。以我自己的项目为例我们半年多前接 DeepSeek API 时做过的适配工作包括工具调用格式的调试、上下文缓存策略的验证、对 long context 对话的截断逻辑、各类超时和重试参数的调优。如果换一家服务商这些适配几乎全部要重新做一遍。这还没算伤害更大的隐性成本你的业务代码里可能写死了很多依赖当前服务商特性的逻辑比如特殊的 tool_calls 消息格式、并行工具调用的返回值、system prompt 里为了适配模型行为而调了很久的措辞。换个服务商轻则参数对齐花费两三天重则某些能力根本不兼容得重新设计交互流程。团队验证的时间、线上故障的风险都是钱。对大多数体量不大的项目来说这部分迁移成本可能比一年涨价的差额还高。1.2 缓存冷启动你之前积累的折扣会一夜归零这是很多人忽略的一点。DeepSeek API 对输入前缀是有缓存机制的固定 system prompt、稳定的工具定义、重复出现的 prompt 片段在命中缓存时实际计费会显著低于全价输入。我们当初做过的优化有相当一部分就是围绕提高缓存命中率展开的。一旦你迁移到新服务商缓存冷启动是必然的。新服务商即使声称支持 prompt 缓存缓存 key 的生成规则、缓存上下文的过期时间、命中后价格打折力度都不同。迁移初期几天到一周你的全部请求大概率都是未命中状态输入部分全额计费。你以为换了个更便宜的单价实际上账单可能比涨价之后还难看。更麻烦的是缓存没有稳定建立起来之前线上行为表现也会不一样反馈到响应质量上会让你误判新服务商不行然后又开始折腾下一家。这就是典型的为了省一块钱花掉了三块钱。1.3 新的便宜供应商不一定真的便宜还有个反直觉的点低价服务商的价格曲线往往更陡。拿看似低单价的模型做深度使用后发现它对上下文窗口、并发量、长输入的处理限制更多有些会高频要求重试、截断或更换模型规格。这些限制最终都会翻译成额外的 token 消耗和一次次的失败重试账单反而上去了。所以我的原则一直很简单先把自己这侧的调用效率做起来再去谈供应商价格。2. 打开账单看看你的钱到底花在哪些 token 上2.1 计价的基本盘缓存价低于输入价输入价低于输出价要省钱首先得知道账单里每一项都是什么。大多数 LLM API 按 token 计费时至少会分成三档计费项相对价格水平主要产生来源输入 token未命中缓存中等偏高system prompt、工具定义、对话历史、用户输入输入 token命中缓存明显更低固定 system prompt、稳定工具定义、重复前缀输出 token显著更高模型生成正文、工具调用参数、长回复很多人只盯着输出贵却忽视了输入量对总账单的影响。系统提示词、工具描述、多轮历史是每回合都要重发的一个 1000 token 的 system prompt 3000 token 的工具 schema一轮对话跑下来就是 4000 token 的固定成本跑 20 轮这 4000 token 被重复计费了 20 次。如果缓存命中率低输入部分的分量甚至可能超过输出部分。只有把这三档价格结构摸清你才知道该优化的重点在哪。2.2 实际跑一个 20 轮工具调用的 token 增长拿一个典型的 agent 任务来演算。假设 system prompt 固定 2k token工具描述 3k token每轮对话加工具返回结果 2k token。第 1 次请求输入是 231 6k 左右第 10 次请求输入是 2310*2 25k第 20 次请求输入变成 45k。把这 20 次的输入累计下来总共超过 500k token而全部输出可能只有 4k token。这时候你会发现如果你没有吃缓存输入 token 的成本才是大头。反过来如果系统提示和工具描述稳定那 2k3k 的固定前缀基本能命中缓存真正按全价计算的只有每轮新增的那 2k 对话内容。缓存命中的价值就这么直接——它不是省一两成而是能把不断重复的固定成本从全价里摘出去。这也是我后面会说固定前缀优先于一切花活的原因。2.3 输出 token 是涨价的放大器长回复和失败重试最烧钱输出 token 贵不仅是单价贵还因为它常常是失控的。同一个任务模型用 100 token 就能回答但如果你 prompt 里没有明确约束它可能输出 800 token 的解释和格式描述。在 agent 场景里更麻烦工具调用返回参数模型如果生成一段冗长的 summary 而不是一个简洁 JSON这部分就是按最贵档计费的纯浪费。再叠加失败重试情况更糟。一次工具调用序列如果因为参数格式非法、消息顺序不对而失败重试等于把输入历史重新计费一次并额外生成一份新输出。我看到过不少线上应用在深夜的日志里刷几百条 retry 记录每条都是一次全价请求。这才是涨价后账单突然变难看的关键——不是单价涨了而是你原有的调用方式在疯狂放大单价波动。3. 不换服务商先把这三块省回来3.1 固定前缀用工程纪律喂饱缓存缓存命中是成本优化里性价比最高的因素之一而它只奖励那些开头稳定的请求。要做到稳定有三条具体纪律第一条把所有固定内容放在 messages 列表最前面。system prompt、few-shot 示例、长期工具定义都应该是稳定字符串不要往里塞时间戳、会话编号、动态变量。动态信息全部放到 user message或者作为 system 的追加消息放后面。第二条工具 schema 尽量做到按需注入。你的工具列表里如果既有 50 个工具每个工具描述 200 token那每次请求就是 10k token 的固定成本。多数业务真正用到的可能只有三五个工具。给需要的场景准备对应工具子集注入到请求里既降低输入量也更容易命中缓存。第三条不要在代码里拼 prompt 时引入随机性。比如有的同学喜欢把你是一个聪明助手 当前日期拼成一个字符串当 system prompt结果每小时的日期变化都导致前缀变化缓存直接被拆掉。日期这类信息放在 user 消息里就足够了。# 稳定前缀 动态内容分离 messages [ {role: system, content: STABLE_SYSTEM_PROMPT}, # 保持数月不变 {role: system, content: get_dynamic_side_info()}, # 可选动态项放后面 {role: user, content: current_input}, ]这条看起来简单但我在实际项目里见过的违反案例太多了。有人用字符串模板渲染 system prompt把 team_id 和日期都塞进去结果所有请求全部缓存未命中成本比优化后贵好几倍。固定前缀的改动应该走代码 review而不是随手写。3.2 上下文压缩把堆木头改成叠罗汉多轮对话和 agent 任务里最常见的问题就是历史记录只增不减。对话越跑越长每次请求携带的历史 token 越来越多人话叫堆木头——下面压着沉积上面还在不断加。换种思路把旧对话压缩成摘要保留最近关键轮次原文整体请求体量就下来了。我给团队搭过一套简单的压缩策略设定一个窗口宽度比如 10 轮。前 20 轮对话中最早的 10 轮被摘要化中间 10 轮保留关键结果最近 10 轮保留完整原文。每次请求的输入从全部历史平铺变成摘要 最近窗口。做过一次数据统计同样的 50 轮任务平铺时每次请求要带 70k token压缩后只需要 12k token 左右成本大概降了七成。代价是模型能看到的细节变少所以关键状态我会额外抽出来写到工作区文件里需要时再注入。这种叠罗汉策略也适用于多智能体编排。多个 agent 协同工作时不要让每个子 agent 都继承完整的全局历史而是共享一个精简后的工作区状态真正需要细节时再按需读取。子任务接收的上下文越小输入成本和出错率都越低。3.3 重试策略一次重试等于两次计费别让重试成为主流程看到这里你可能已经意识到成本优化里最容易被忽略的是请求失败带来的级联消耗。一次超时重发等于把已经请求的内容再请求一遍一次 tool call 结果校验失败等于让模型重新生成一次参数。如果请求里还带着几十轮历史那重试一次的成本是很可观的。我的建议是给所有外部 API 调用加三层约束设置重试次数上限默认不超过 2 次且只对明确可重试的错误类型重试比如超时、429 限流。区分错误类别对校验失败消息顺序非法这类错误直接停止链路不要走重试逻辑。客户端和服务端都做限流排队避免瞬时高并发导致接口被限流后反复重试。手段本身都不复杂但确实能实打实地把账单压下来。重试带来的主要浪费不在那一次失败请求而在于失败打断了你对 token 消耗节奏的控制。4. Agent 与 Harness 场景最容易烧钱的隐形角落4.1 工具调用把单次请求变成连环计费如果你只是做简单的问答成本优化相对容易。但如果你的场景是接 Codex、Claude Code、DeepSeek Harness 这类 agent 工具那成本模型就完全不一样了。工具调用天生是连环的模型发一个 tool_call你执行完把结果塞回去模型再发下一个 tool_call每一轮都会把新的 tool call 和 tool result 追加进上下文。这意味着工具的 schema、上一步的结果、agent 自己的临时输出全部都要重复计费。工具描述越长、工具列表越大每轮请求的基座就越高。并且很多时候模型会尝试调用多个工具却只拿到一个结果剩下的调用结果没能正确返回就会报错或重试。这类场景下我最先做的是给工具列表做减法。每个任务只注入当前步骤可能用到的 2-3 个工具而不是把无关的长工具描述全塞进去。同时把所有工具描述压缩成统一格式功能名、核心参数、返回值结构。描述越长模型越容易在参数里塞多余字段生成的输出 token 也跟着膨胀。4.2 多智能体编排时的三块护栏在多个智能体协作的架构里上下文共享方式直接决定成本。我梳理了三块必须提前设好的护栏第一每个子任务必须限制模型规格和最大轮数。不要所有子任务都调最强模型也不要让一个简单的搜索资料子任务循环 20 轮。设置 max_steps 是硬约束宁可任务失败重来也不能让它无上限烧 token。第二公共上下文保持精简。多个智能体之间不要互相传递完整对话历史而是共享一个高度压缩的工作区状态。每个子 agent 启动时只需要读自己的工作区片段不需要知道全局过程。第三对工具返回结果做提炼。工具结果如果是大段日志或长文本不要让模型把整个返回都带进下一步思考。先用一个轻量步骤把结果提炼成一两行关键信息再注入上下文。这里的逻辑是信息密度越高需要的 token 越少生成质量反而更可控。4.3 messages tool calls need immediate results 报错的成本黑洞如果你在用 Harness 或者 Codex 接 DeepSeek大概率遇到过类似 messages tool calls need immediate results 的报错。这个报错的技术含义是当一条消息里包含 tool_calls 时API 要求下一条消息必须立即是对这些 tool calls 的执行结果中间不允许插入其他消息。很多 agent 框架在处理多个并行 tool call 时会把结果延迟到后面的消息里补上这就会触发报错。结果是什么框架开始重试而且往往重试时会把整个历史重新发送一遍。一次工具调用序列出现几次这个错误token 消耗就成倍增长。你甚至可以把这个错误当成漏钱信号——每次日志里出现它都意味着一整段上下文被无效重放。解决办法很直接不要让 tool call 等待后续消息取到结果后立刻追加为下一条 assistant/system 消息不要让一个消息同时包含多个 tool_calls拆成单调用会增加轮数但能避免结果乱序和报错如果框架对消息顺序管理有 bug升级到支持严格顺序的版本比自己去 hack 更稳。这属于典型的调对了比降价更省钱。4.4 IDE 接入 Codex/Claude Code 的省钱设置现在有很多人把 DeepSeek 接进 IDE 的 Codex 或 Claude Code 插件里。接上确实方便但默认配置下它会把整个代码库的索引或者当前打开文件片段持续作为上下文重发。我见过一个项目因为 IDE 插件默认把多文件组合成 system prompt导致每次请求输入 token 都在十万级然后又被缓存机制反复虐了一遍。这类场景的省钱动作一般是关掉不必要的全局索引只在具体任务里按需引入相关文件切换供应商时重开会话避免上个模型的长上下文被全部发给新模型。如果你用 CCSwitch 这类切换工具也要注意它在切换过程会不会清掉旧上下文别让上一次对话的历史在切换后继续占用输入量。5. 本地部署和 vLLM另一种不换服务商的长期账本5.1 vLLM 部署 DeepSeek 的成本模型本地部署也是热搜里绕不开的关键词。vLLM 部署 DeepSeek 确实可行但先要算清楚一笔账本地部署不是把 API 换成免费而是把按 token 计费变成固定硬件摊销加运维成本。假设你的业务一个月消耗 500 万输出 token、2000 万输入 tokenAPI 成本是一个显而易见的数字。本地部署需要显卡、显存、散热、电费和运维人力。一台能跑得上主流尺寸开源模型的机器月折旧和电费轻松上千。如果你的 API 月消耗连一千都不到那本地部署算总账反而是亏的。真正适合本地部署的条件有两个一是模型调用量稳定且持续走高二是你能接受固定硬件成本和一定的运维负担。只要其中一条不满足API 仍然更省钱。5.2 量化、蒸馏小模型和混合路由让每个流量走到合适的地方关注DeepSeek 17b这类词的人实际上是在找更轻量的本地部署方案。我的建议是不要试图用本地小模型完全替代 API而是把它放到调用链路的前端做路由守门。简单任务比如意图判断、代码片段补全、固定模板生成优先走本地小模型复杂推理、长篇文档理解、需要强工具调用的任务再走 DeepSeek API。这种混合路由才是最便宜方案的真正含义。它不是选一个绝对低价的服务商而是让不同价值的请求按不同成本路径流动。你也无需追求本地模型在所有任务上对标 API只需要它有足够高的拦截能力把大多数简单流量留在本地就够了。5.3 什么时候不要省这个钱没有运维团队、调用峰谷差异极大、数据领域对实时性要求极高这三种情况下本地部署大概率会变成新的成本黑洞。省了 token 钱赔上人力和稳定性不值。干脆承认 API 是更平滑的方案然后集中精力做好前面几节的调用优化。6. 我的决策路径你可以直接复制6.1 三条路线的对照路线启动成本边际成本变化适合场景换服务商中高需要重新适配和验证边际单价可能变化但缓存冷启动阶段实际成本偏高现有服务商稳定性或可用性出严重问题优化现有调用低主要是梳理配置和代码明显下降缓存命中率和上下文压缩会持续起作用绝大多数用 OpenAI 兼容 API 的项目本地部署 混合路由高需要硬件和运维投入稳定后边际成本低长期高调用量、有明显技术运维能力的团队表格不是一个精确决策器但它能帮你把当下的心情从赶紧换拉回到先看成本模型。6.2 从易到难的执行顺序如果让我给个通用顺序大概率是这样冻结 system prompt 前缀和工具 schema提高缓存命中率。这是零代码侵入、当天就能生效的改动。给所有 agent 任务设置 max_steps 和最大 token 预算精简工具列表修复 tool_calls 消息顺序问题。对长对话启用摘要压缩和上下文裁剪。当 API 月度成本连续三个月高过本地硬件折旧时再引入本地部署加混合路由。最后这一步不需要一开始就做它应该是你优化完前几步之后的自然判断。大多数团队在执行完 1-3 之后月度成本已经下降了相当可观的比例涨不涨价对你的影响就没那么大了。6.3 记账别凭感觉顺便提一个长期受益的习惯给每个业务线单独记录 token 消耗和成本分布。只记总额是不够的要区分输入、输出、缓存命中占比、重试占比、单次平均 token。有了这些维度你才能在每次调价时快速判断真实的薄弱环节到底是服务商贵了还是我们调得烂。我每次做完这种复盘都会发现最后真正解决问题的手段永远是把自己这边的调用效率提上去而不是焦虑地搜索下一家供应商。最后再分享一个小技巧把涨价当成一次定期的成本巡检信号。不要只在涨价时算账而是每个月花半小时看一眼缓存命中和重试日志这两个指标。哪怕只是把这两个指标维持住你的 API 账单都会比大多数裸调用的项目低一截。工具和模型的榜单永远在变但链路管理做得好的人在哪都不容易吃亏。