1. 涨价这件事真正被挤压的是哪部分预算DeepSeek API 在 2026 年这一轮调价圈子里讨论得很多但大部分讨论都跑偏了。大家盯着涨了多少倍这个数字吵却很少有人冷静下来算一笔账你每个月真正烧掉的 token到底有多少是非它不可的又有多少只是图省事顺手调过去的。我自己手上跑着几个小项目一个是文档批量摘要的流水线一个是给内部知识库做的问答机器人还有一个是代码补全的辅助工具。这三个场景对模型能力的要求完全不在一个档次上。文档摘要只要模型能稳定输出结构化文本就行知识库问答需要一定的推理和上下文理解代码补全则对指令跟随和长上下文有硬要求。涨价之前我图省事三个场景全走同一个接口涨价之后我把调用日志拉出来一看超过六成的 token 消耗在那些随便一个像样的模型都能干的任务上。这就是问题的核心。涨价不是让你把所有调用都换掉而是逼你把任务分层。贵的模型留给真正需要它的场景其余的全部下沉到更便宜的方案。我实测下来只要分层做得合理整体成本砍掉一半是完全可行的而且效果几乎没有可感知的下降。下面这几个方案是我在过去几周里逐个跑过、对比过、踩过坑之后留下来的。它们不是理论上更便宜而是我拿真实调用量验证过的。我会把每个方案适合什么场景、怎么接、坑在哪里都讲清楚。提示本文所有成本对比都基于我自己的调用结构摘要类占 60%、问答类占 30%、代码类占 10%你的比例不同结论会有差异但分层思路是通用的。2. 方案一GLM 系列承接摘要与批量文本任务2.1 为什么摘要类任务最适合第一个下沉摘要、分类、抽取、改写这类任务有个共同特点输入长、输出短、对推理深度要求低、对格式稳定性要求高。这类任务用旗舰模型跑本质上是在为用不上的推理能力付费。GLM 系列在这个位置上的性价比非常突出尤其是它的轻量档位处理长文本的吞吐和价格都很友好。我拿一批 3000 字左右的技术文档做对比测试同样的提示词模板同样的输出格式要求跑 500 篇。GLM 的输出在结构一致性上甚至比原来更稳因为它对严格按 JSON 输出这类指令的服从度很高很少出现多余的解释性文字。这一点对流水线特别重要输出里多一句废话下游解析就得多写一层容错。2.2 接入时最容易忽略的是上下文长度换算很多人换模型时只看单价不看上下文窗口结果跑长文档时被截断白白浪费一批调用。GLM 不同档位的上下文长度不一样你在做批量任务前一定要先确认你的单条输入峰值是多少 token。我的做法是先写一个统计脚本把待处理文本按字符数排序取 P95 分位作为设计上限而不是取最大值。因为极少数超长文本可以单独走贵模型没必要为了那 1% 把整个流水线的模型档位拉高。# 统计待处理文本的 token 分布确定模型档位 import tiktoken def estimate_tokens(texts, modelcl100k_base): enc tiktoken.get_encoding(model) counts [len(enc.encode(t)) for t in texts] counts.sort() p95 counts[int(len(counts) * 0.95)] return {max: counts[-1], p95: p95, avg: sum(counts) // len(counts)} # 用 P95 而不是 max 来选档位能省下大量成本这个脚本看起来简单但它决定了你后面所有的选型决策。先量化再选型别凭感觉。2.3 批量任务的并发与限流要提前压测换到新接口之后我踩的第一个坑就是并发。原来的接口我习惯了某个并发数换过去之后直接照搬结果触发限流一批任务卡在半路重试逻辑又没写好导致部分文档被处理了两次。正确的做法是先用小批量探明新接口的实际并发上限再设置一个留有余量的并发数并且给每个任务打上幂等标识。幂等这件事在批量任务里是刚需因为网络抖动、限流重试都会导致重复提交没有幂等标识你根本分不清哪些处理过了。项目建议做法踩坑后果并发数先压测取实测上限的 70%直接限流任务堆积重试指数退避 最大次数无限重试打爆配额幂等每条任务带唯一 ID重复处理成本翻倍超时按 P99 响应时间设长任务被误杀这张表是我用真金白银换来的尤其是幂等那一行别省。3. 方案二OpenRouter 做多模型路由与故障兜底3.1 单一供应商的风险在涨价期会被放大涨价这件事本身不可怕可怕的是你只有一个供应商它涨价你没有任何议价空间它限流你整个业务停摆。我之前的架构就是单点依赖涨价消息出来那天我第一反应不是算成本而是如果它明天再涨或者限流我怎么办。OpenRouter 这类聚合层的价值就在这里。它把多个模型供应商统一到一个接口后面你可以按任务类型路由到不同模型也可以在主模型不可用时自动切到备用模型。它解决的不是更便宜而是更稳和更灵活。3.2 路由策略要按任务价值分层而不是按价格排序我见过有人把路由策略写成永远选最便宜的结果关键任务被路由到能力不足的模型上输出质量崩了返工成本远超省下的那点钱。正确的分层逻辑应该是高价值任务对准确性敏感、返工成本高路由到能力强的模型价格次要中价值任务有格式要求、可容忍少量错误路由到性价比档位低价值任务批量、可重跑、错误可接受路由到最便宜的档位这个分层不是拍脑袋定的而是根据这个任务出错之后我要花多少时间补救来定的。补救成本高于模型差价的任务就不该省。3.3 配置里的模型名和参数要对齐别想当然接入聚合层最容易犯的错是以为模型名和原生接口一样。实际上聚合层有自己的命名规范参数支持程度也不完全一致。我有一次直接把原生接口的模型名填进去报了一晚上的 400排查半天才发现是名字对不上。# 路由配置示例按任务类型映射到不同模型 ROUTING { summarize: {model: glm-light, max_tokens: 1024}, qa: {model: mid-tier-model, max_tokens: 2048}, code: {model: strong-model, max_tokens: 4096}, } def route(task_type, payload): cfg ROUTING.get(task_type) if not cfg: raise ValueError(f未配置的任务类型: {task_type}) # 关键模型名必须用聚合层文档里的准确名称 return call_api(modelcfg[model], max_tokenscfg[max_tokens], **payload)注意聚合层的模型列表会变动上线前一定要拉一次最新的模型清单别把模型名硬编码在代码深处抽成配置项。3.4 故障切换要测不能只配自动切换这个功能配了不等于能用。我专门做过一次演练手动把主模型的 key 改错看系统会不会自动切到备用。第一次演练直接失败因为切换逻辑里有个异常没被捕获整个请求直接抛出去了。故障切换必须定期演练而且要覆盖主模型超时主模型返回错误码主模型限流三种情况。只配不测等于没配。4. 方案三本地小模型兜底高频低价值调用4.1 哪些调用根本不该出网有些调用频率极高、单次价值极低比如意图分类、敏感词初筛、简单的情感判断。这类任务每次调用可能就几百 token但架不住量大一天几万次下来也是一笔钱。这类任务最该做的不是换便宜接口而是直接搬到本地。我在一台普通的开发机上跑了一个小参数量的模型专门处理意图分类。实测下来单次推理延迟在几十毫秒级别准确率对这类粗分类任务完全够用。关键是它不产生任何按量费用跑多少都是电费。4.2 本地部署的硬件门槛没有想象中高很多人一听本地部署就摇头觉得要买显卡。实际上对于分类、抽取这类任务量化后的小模型在 CPU 上也能跑只是延迟高一点。如果你的调用不是强实时CPU 完全够用。我的配置是一台 16G 内存的机器模型做了 4bit 量化跑分类任务单条延迟 200ms 左右。对于后台批处理场景这个延迟完全可以接受。先别急着买硬件用手头的机器跑个 demo测出真实延迟再决定要不要升级。任务类型是否适合本地理由意图分类非常适合输出空间小容错高敏感词初筛适合只需召回后续可复核情感判断适合粗粒度即可长文摘要不适合上下文长本地吃力代码生成不适合对能力要求高4.3 本地模型和云端模型的衔接要设计好本地兜底不是让本地模型干所有活而是让它干它干得了的活干不了的转给云端。这个转交逻辑要设计清楚本地模型输出置信度低于阈值就转云端。这样既省了钱又不会因为本地模型能力不足而降低整体质量。def hybrid_infer(text, threshold0.7): local_result local_model.predict(text) if local_result[confidence] threshold: return local_result # 本地搞定零成本 # 置信度不够转云端 return cloud_model.predict(text)这个混合推理的模式是我目前最满意的一个改动。它把大量简单请求挡在了本地云端只处理真正需要它的部分。5. 方案四把 token 消耗本身降下来比换模型更根本5.1 提示词里的冗余是最大的隐形浪费换模型是节流但很多人忽略了提示词本身的浪费。我审计过自己的提示词发现系统提示里有一大段是几个月前加的早就没用了但每次调用都在传。这种冗余在单次调用里不起眼乘以调用量就是一笔可观的开支。我的做法是定期做一次提示词审计把系统提示、few-shot 示例、历史上下文全部拉出来逐段问这段删掉之后效果会掉吗。实测下来大部分提示词都能砍掉 20% 到 40% 的长度而不影响效果。5.2 上下文管理要主动不能无脑全传多轮对话场景里很多人图省事把整个历史都传进去。这是成本杀手。正确的做法是做上下文窗口管理保留最近 N 轮 关键信息摘要其余丢弃。我实现了一个简单的滑动窗口加摘要的机制最近 5 轮原文保留更早的对话压缩成一段摘要。这样既保留了上下文连贯性又把 token 消耗控制住了。def build_context(history, keep_recent5): if len(history) keep_recent: return history recent history[-keep_recent:] older history[:-keep_recent] summary summarize_history(older) # 压缩成一段 return [{role: system, content: summary}] recent5.3 缓存能省的钱比你想的多很多请求其实是重复的尤其是问答场景里相似问题反复出现。加一层语义缓存命中就直接返回不命中才调模型。我用一个轻量的向量库做相似度匹配阈值设得保守一点避免把不该命中的问题误判。实测下来在问答场景里缓存命中率能到 25% 左右这部分请求的成本直接归零。缓存这个事投入产出比极高值得优先做。6. 方案五按调用量做阶梯预算与告警6.1 没有预算约束的成本优化都是空谈前面四个方案都是怎么花得更少但如果没有一个预算约束机制你永远不知道自己有没有真的省下来。我给自己每个项目设了日预算和月预算超过阈值就告警超过硬上限就自动降级到便宜模型。这个机制的价值在于它把成本变成了一个可观测、可控制的指标而不是月底看账单时才发现超了。6.2 告警阈值要分层别只有一个总数只设一个总预算是不够的因为总量没超不代表结构健康。我设了三层告警总量告警日消耗超过预算 80% 时提醒单任务类型告警某个任务类型的消耗占比异常升高时提醒单次调用告警单次请求 token 超过阈值时记录用于排查异常请求第二层特别有用。有一次我发现摘要任务的消耗突然涨了排查发现是上游数据源格式变了导致输入文本变长。如果没有分类型告警这个问题要等到月底看账单才会发现。6.3 降级策略要平滑不能一刀切预算超了之后直接停服务是最蠢的做法。正确的降级是分级的先降非关键任务的模型档位再降并发最后才考虑限流。关键任务永远保留在能力足够的模型上。预算使用率动作 80%正常运行80% - 95%非关键任务降级到便宜模型95% - 100%降低并发暂停批量任务 100%仅保留关键任务其余排队这套机制跑下来我再也没有出现过月底账单吓一跳的情况。7. 实测对比五个方案组合起来到底省了多少7.1 我的真实调用结构前面讲了五个方案但单独用任何一个效果都有限真正省钱的是组合。我把自己的调用结构拆开看摘要与批量文本占总量 60%全部下沉到 GLM 轻量档问答占 30%走聚合层路由加语义缓存代码辅助占 10%保留在能力强的模型上意图分类等高频低价值调用全部本地化7.2 成本对比结果我拿涨价前后的一个月做了对比同样的业务量项目涨价前涨价后未优化优化后摘要类基准上涨约 2 倍降至基准的 0.4问答类基准上涨约 2 倍降至基准的 0.6代码类基准上涨约 2 倍基本持平高频低价值基准上涨约 2 倍接近 0综合100%约 200%约 55%综合下来优化后的总成本大约是涨价前的 55%比涨价后未优化的状态省了超过七成。这个结果比我最初预期的还要好主要贡献来自本地化和缓存这两块。7.3 效果有没有下降这是所有人最关心的问题。我的答案是在分层合理的前提下用户可感知的质量没有下降。摘要类任务的输出甚至更稳定了因为轻量模型在格式服从上更好。问答类因为加了缓存常见问题的响应还更快了。唯一需要留意的是代码辅助这部分我没动成本基本持平但也没必要动。真正会出问题的是把高价值任务也下沉到便宜模型上。分层的关键是任务价值和模型能力匹配而不是一味求便宜。8. 换方案过程中踩过的几个坑8.1 401 和 403 报错八成是 key 或权限问题换接口的时候最常见的报错就是 401 和 403。401 基本是 key 不对或者没带上403 往往是权限或者访问范围的问题。我遇到过 key 复制时多了个空格排查了半小时。遇到这类报错先检查 key 的完整性和权限配置别急着怀疑代码。8.2 token 失效和续签逻辑要单独测如果你的系统里有登录态或者临时凭证换接口之后一定要单独测 token 的获取、使用、续签、失效这条链路。我踩过一次坑token 过期后没有自动续签导致一批后台任务全部失败。这类问题在测试环境不容易暴露因为测试时 token 往往还没过期。8.3 上下文超限的报错要提前拦截不同模型的上下文上限不一样换模型之后很容易触发超限报错。我的做法是在请求发出前先做一次 token 估算超过目标模型上限的直接走截断或转其他模型不要等接口报错再处理那样既浪费一次调用又影响体验。8.4 模型名、参数名、返回结构都可能不一样这是最琐碎但也最容易出错的地方。不同供应商的模型名、参数名、返回字段结构都有差异。我的建议是在接入层做一层适配把差异隔离在适配层里业务代码只依赖统一接口。这样以后再加新供应商改动量很小。9. 给准备动手的人几句实在话如果你现在正因为涨价在纠结要不要换我的建议是先别急着换先做一次调用审计。把过去一个月的调用日志拉出来按任务类型分类算出每一类的 token 占比和成本占比。你会发现真正吃掉预算的往往不是你以为的那部分。审计做完之后按任务价值排序从最低价值的任务开始下沉。先做本地化和缓存这两块因为它们不依赖任何外部供应商做完就是净省。然后再考虑多模型路由和聚合层这部分能提升稳定性顺带省钱。最后提醒一句别为了省钱把关键任务的质量牺牲掉。省下来的钱如果要用返工和用户投诉来还那这笔账就是亏的。分层、缓存、本地化、预算约束这四件事做好成本自然就下来了而且质量守得住。我在实际操作中的体会是成本优化这件事没有一劳永逸的方案模型价格会变你的业务结构也会变。把审计和预算约束做成常规动作比一次性换个便宜模型有用得多。