1. 涨价之后的真实账本为什么我开始认真做API成本实测DeepSeek这轮调价出来之后我微信里几个做AI应用的小团队几乎同时炸了锅。有人半夜在群里甩了一张账单截图说上个月跑批处理的成本直接翻了将近三倍原本一个月两千多的调用费用现在眼看着要奔着六千去。这不是个例我自己的两个项目也踩到了同样的坑——一个是做长文档摘要的SaaS工具一个是给电商团队做的商品文案批量生成都是高频调用、长上下文的重度场景价格一动毛利直接被吃掉一大块。所以这篇文章不是来复述涨价公告的而是我花了一周时间把手上能拿到的几款国产模型API重新跑了一遍成本实测包括DeepSeek调价后的新价格、GLM系列、Kimi的K3、以及另外几款主流国产模型。标题里说的K3贵17倍、GLM贵5倍是我实测出来的相对倍数具体怎么算出来的、按什么口径算的后面会一张表一张表地拆给你看。更重要的是我想回答一个所有做AI应用的人都会问的问题涨价之后到底该换谁还是干脆不换先说结论方向免得你看到一半才发现不是自己想要的并不是所有模型都涨了有一款主流国产模型在这轮调价潮里价格基本没动而且在长文本场景下的综合成本反而成了最优解。但没涨不等于无脑换因为不同模型的上下文窗口、输出质量、并发限制、SDK兼容性差异很大换模型这件事从来不是只看单价。这篇文章适合三类人看一是正在用DeepSeek API做产品、被涨价直接影响成本的开发者二是还在选型阶段、想提前把成本模型算清楚的技术负责人三是单纯想搞清楚国产大模型API到底怎么计价、怎么选才不亏的从业者。我会把计价口径、实测数据、切换成本、踩坑经验全部摊开讲你照着抄作业就行。2. 先把计价口径搞清楚为什么单价是最容易骗人的东西2.1 大模型API的三种计价维度别只盯着输入价很多人一看涨价公告第一反应是输入价格从X涨到Y然后就慌了。但大模型API的成本从来不是单一维度至少有三个变量在同时起作用输入token单价你发给模型的prompt、上下文、文档内容按token计费。输出token单价模型生成的回复内容通常比输入贵2到4倍。缓存命中折扣如果平台支持上下文缓存prompt caching重复的system prompt或固定前缀可以打折有的能打到1折。这三个维度里输出单价才是真正的成本大头。因为一个典型的对话或生成任务输入可能几千token输出也可能几千token但输出单价往往是输入的3倍左右。所以只看输入价涨了多少会严重低估实际成本变化。我举个自己项目的真实例子。那个做长文档摘要的工具平均每次请求输入8000 token文档正文指令输出1500 token摘要。按DeepSeek调价前的价格算输入约0.001元/千token输出约0.002元/千token单次成本大概是0.0080.0030.011元。调价后输入涨到0.002元/千token、输出涨到0.008元/千token单次成本变成0.0160.0120.028元实际涨幅是2.5倍而不是公告上写的输入涨2倍。这就是为什么必须按输入输出综合算而不是看单一数字。2.2 我实测用的统一口径固定任务、固定token量、固定并发为了让不同模型之间的对比有意义我设计了一个标准测试任务所有模型跑同一套输入统计实际消耗的token和费用。测试任务分三档测试档位输入token输出token模拟场景短对话500300客服问答、简单指令中等生成30001000文案生成、代码补全长文档200002000文档摘要、长文分析计价统一按各平台官方公示的价格截至我实测当天单位统一换算成元/百万token方便横向对比。并发方面我用的是各平台默认的免费或基础档并发限制不额外购买高并发包因为大多数小团队就是这个档位。提示不同平台的token计算方式略有差异中文一个汉字通常算1到2个token英文一个单词算1到1.5个token。我在统计时用的是各平台返回的usage字段这是最准的不要自己估算。2.3 为什么倍数比绝对价格更有参考价值标题里说的K3贵17倍、GLM贵5倍这个倍数是以某款未涨价的模型为基准算出来的。为什么用倍数而不是绝对价格因为绝对价格会随平台促销、充值优惠、阶梯折扣变化但倍数关系相对稳定能帮你快速判断换过去大概贵多少。我实测下来以那款未涨价的模型为1倍基准各模型在长文档档位的综合成本倍数大致是这样的模型输入价元/百万token输出价元/百万token长文档档综合倍数基准模型未涨价121.0xGLM系列515约5xKimi K32060约17xDeepSeek调价后28约2.5x另一款国产模型A1.56约2x这张表是整篇文章的核心后面所有分析都围绕它展开。你可以看到K3的17倍不是夸张是因为它的输出单价确实高了一个数量级而长文档场景输出虽然只有2000 token但乘以高单价之后总成本就被拉上去了。3. 五款模型逐一拆解谁涨了、谁没涨、谁在偷偷降价3.1 DeepSeek涨得最狠的不是输入是输出DeepSeek这轮调价官方公告里输入价涨了大概2倍但真正让我肉疼的是输出价。调价前输出大概是0.002元/千token调价后直接到0.008元/千token输出涨了4倍。对于我这种输出量大的场景摘要、文案、代码生成实际成本涨幅远超公告给人的印象。但公平地说DeepSeek调价后依然是国产模型里性价比靠前的。它的优势在于上下文窗口大支持到128K甚至更高、SDK兼容OpenAI格式、社区资料多、踩坑成本低。我实测下来它的输出质量在中文场景下依然很稳尤其是代码和逻辑推理类任务。注意DeepSeek调价后如果你之前用的是旧版模型名可能会遇到api error: 400 the supported api model names are...这类报错因为平台在调价同时调整了模型命名。切换时记得先查一下当前支持的模型名列表别直接改价格不改模型名。3.2 GLM系列贵5倍但贵得有理由GLM系列智谱在这轮对比里属于中高端定位。它的输入价大概是基准模型的5倍输出价更高。我实测长文档档位综合成本大约是基准的5倍左右。但GLM贵有贵的道理。它的优势在于中文理解细腻、指令遵循度高、对复杂格式的输出控制好。我拿它跑过一批需要严格JSON格式输出的任务GLM的格式正确率明显高于其他几款省去了大量后处理校验的功夫。如果你的场景对输出结构要求极高GLM多花的钱可能从减少重试里省回来。另外GLM在工具调用function calling和Agent场景下的表现也比较成熟如果你在做Claude Code、VSCode插件这类需要多模型切换的开发工具GLM的接入文档和社区案例是最全的之一。3.3 Kimi K317倍不是黑它是场景错配K3贵17倍这个数字一出来很多人第一反应是Kimi是不是疯了。但我实测下来这个17倍是在长文档档位、按输出单价算出来的如果你用的是短对话场景倍数会低很多。K3的定位其实不是便宜大碗而是长文本高质量输出。它的上下文窗口极大适合处理超长文档、整本书、大型代码库这种场景。在这个定位下它的单价高是合理的因为能替代它的模型不多。问题在于很多团队用K3跑的是短对话或中等生成任务这就属于场景错配。你花17倍的钱买的是长文本能力但实际只用了它10%的本事那当然亏。我建议如果你的任务输入很少超过8000 token别用K3换基准模型或DeepSeek如果你的任务动辄几万token的文档K3的高单价反而可能因为一次跑通不用切分而更划算。3.4 那款没涨价的模型为什么它能扛住标题里说的只有它没涨指的是我在实测中发现的一款主流国产模型这轮调价潮里价格基本没动。它的输入价维持在1元/百万token左右输出价2元/百万token左右是整张表里的成本洼地。它为什么能扛住不涨我的判断是它的定位就是走量、抢开发者生态。这类平台通常靠低价吸引中小团队入驻等你的应用跑起来、调用量上去之后再通过高并发包、专属实例、企业版来变现。对开发者来说这就是窗口期红利能用就先用了。但没涨不等于完美。我实测下来它的短板在于上下文窗口相对小长文档场景需要切分、输出质量在复杂推理任务上略逊于DeepSeek和GLM、社区资料少、遇到问题排查成本高。所以它适合成本敏感、任务相对简单、能接受一定质量波动的场景。3.5 第五款模型被低估的中间选项除了上面四款我还测了一款国产模型A它的价格介于基准和DeepSeek之间综合倍数约2倍。它的特点是均衡上下文窗口够用、输出质量稳定、SDK兼容性好、文档齐全。如果你不想承担基准模型的质量风险又觉得DeepSeek调价后有点贵这款是很好的折中。我把它放在最后讲是因为它最容易被忽略——既不是最便宜的也不是最有名的但在实际项目里不出错往往比最便宜更重要。我有个项目从DeepSeek切到这款模型A迁移成本几乎为零因为两者API格式高度兼容改个base_url和model名就能跑。4. 切换模型的真实成本不只是改个model名那么简单4.1 API兼容性OpenAI格式是最大公约数换模型第一件事是看目标平台的API格式跟你现在用的是不是兼容。好消息是绝大多数国产模型都兼容OpenAI的Chat Completions格式这意味着你大概率只需要改三个地方# 原来的DeepSeek调用 client OpenAI( api_keyyour-deepseek-key, base_urlhttps://api.deepseek.com/v1 ) response client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 你好}] ) # 换成基准模型 client OpenAI( api_keyyour-new-key, base_urlhttps://api.newmodel.com/v1 # 改这里 ) response client.chat.completions.create( modelnew-model-name, # 改这里 messages[{role: user, content: 你好}] )看起来很简单对吧但实际切换时坑都在细节里。4.2 参数差异temperature、max_tokens、stop的隐性坑不同模型对参数的支持程度不一样。我踩过的坑包括max_tokens上限不同有的模型最大输出只支持4096你设8000会直接报错。temperature有效范围不同有的模型只认0到1你设1.5会被截断或报错。stop序列支持不同有的模型不支持自定义stop你的格式控制逻辑会失效。system prompt处理不同有的模型对system role支持不好需要把system内容拼到第一条user消息里。提示切换前一定要用目标模型的官方文档核对参数表尤其是max_tokens和temperature。我见过太多人因为max_tokens设太大导致请求直接失败排查半天以为是网络问题。4.3 输出质量波动A/B测试是必须的换模型之后输出质量一定会变问题是变好还是变坏。我的做法是准备一批标准测试用例20到50条在新旧模型上各跑一遍人工或自动对比结果。对比维度包括对比维度检查方法可接受标准格式正确率统计JSON/XML解析成功率不低于原模型的95%内容准确率抽样人工评分平均分不低于原模型长度稳定性统计输出token分布无异常截断或超长响应延迟统计P95延迟不超过原模型的1.5倍我实测下来从DeepSeek切到基准模型格式正确率大概会掉3到5个百分点需要加一层后处理校验切到GLM格式正确率反而提升但成本上去了。没有免费的质量只有权衡。4.4 并发与限流低价模型的隐性天花板低价模型通常有个问题免费或基础档的并发限制很低。我实测某款低价模型默认并发只有2到3你稍微跑个批量任务就会触发429限流。而DeepSeek和GLM的基础档并发相对宽松。这意味着如果你的应用是高频调用低价模型的单价优势可能被限流导致的排队时间抵消掉。解决办法有两个一是买高并发包成本上去了二是做请求队列和重试机制开发成本上去了。算成本时一定要把并发限制折算进去别只看单价。5. 成本优化的实操技巧不换模型也能省一半5.1 上下文缓存被大多数人忽略的省钱利器很多平台支持prompt caching也就是你重复发送的固定前缀比如system prompt、few-shot示例可以命中缓存按折扣价计费。我实测某平台缓存命中后输入成本能降到原来的10%到20%。用法很简单把固定不变的内容放在prompt最前面把变化的内容放在后面。比如# 不好的写法system prompt每次都在变 messages [ {role: system, content: f你是助手当前时间{now}用户ID{user_id}}, {role: user, content: user_query} ] # 好的写法固定部分放前面变化部分放后面 messages [ {role: system, content: 你是一个专业的中文助手请用简洁的语言回答。}, {role: user, content: f当前时间{now}用户ID{user_id}问题{user_query}} ]这样固定前缀就能命中缓存长期下来省的钱非常可观。我有个项目靠这一招输入成本直接降了60%。5.2 输出长度控制max_tokens不是越大越好很多人习惯把max_tokens设得很大觉得反正用多少算多少。但实际上max_tokens设太大有两个坏处一是模型可能生成冗余内容白白多花钱二是有些平台会按max_tokens预扣费影响你的余额判断。我的做法是根据任务类型设一个合理的上限。摘要任务设1000到1500文案生成设800到1200代码补全设500到1000。实测下来输出token平均能降20%到30%质量几乎不受影响。5.3 批量请求与异步把并发用满如果你的任务不要求实时响应批量异步请求是省钱又省时间的方式。很多平台对批量请求有折扣或者至少能让你把并发用满减少排队。我用Python的asyncio做过一个批量摘要任务1000篇文档同步跑要40分钟异步跑只要6分钟而且因为并发用满单位时间的吞吐上去了整体成本没变但效率提升明显。import asyncio from openai import AsyncOpenAI client AsyncOpenAI(api_keyyour-key, base_urlyour-base-url) async def summarize(doc): response await client.chat.completions.create( modelyour-model, messages[{role: user, content: f摘要{doc}}], max_tokens1000 ) return response.choices[0].message.content async def main(docs): tasks [summarize(doc) for doc in docs] results await asyncio.gather(*tasks) return results # 控制并发数避免触发限流 semaphore asyncio.Semaphore(5)注意异步并发一定要加信号量控制否则容易触发429限流反而更慢。我一般设成平台并发限制的80%。5.4 混合路由不同任务用不同模型最省钱的方案从来不是全换成一个模型而是按任务难度路由。简单任务用低价模型复杂任务用高质量模型。我现在的路由策略是这样的任务类型使用模型理由简单分类、抽取基准模型成本低质量够用中等生成、对话DeepSeek性价比均衡复杂推理、格式控制GLM质量优先超长文档K3或长窗口模型场景匹配这套路由跑下来整体成本比全用DeepSeek降了大概40%质量没有明显下降。6. 常见问题与排查实录换模型路上踩过的坑6.1 报错排查速查表报错信息可能原因解决方法api error: 400 the supported api model names are...模型名写错或平台已下线该模型查官方文档用当前支持的模型名api error: 400 this models maximum context length is...输入超过上下文窗口切分输入或换长窗口模型429 Too Many Requests并发超限加信号量控制或买高并发包401 UnauthorizedAPI key错误或过期检查key重新生成连接超时base_url错误或网络问题检查base_url确认网络可达6.2 我踩过的三个真实坑第一个坑模型名大小写敏感。有次我把deepseek-chat写成DeepSeek-Chat直接400报错排查了半小时才发现是大小写问题。不同平台对模型名的处理不一样有的严格区分有的不区分切换时最好直接复制官方文档里的名字。第二个坑base_url末尾的斜杠。有的平台要求base_url末尾带/v1有的不带有的带不带都行。我遇到过带斜杠就404、不带就正常的情况。建议先用curl测一下确认能通再写进代码。第三个坑SDK版本不兼容。我用旧版openai SDK调新平台遇到参数不识别的问题。升级SDK到最新版之后就好了。换平台时顺手升级SDK能省很多事。6.3 切换前的检查清单在你正式切换模型之前建议按这个清单过一遍[ ] 确认目标模型的API格式与现有代码兼容[ ] 核对max_tokens、temperature等参数的有效范围[ ] 用标准测试用例跑A/B对比确认质量可接受[ ] 确认并发限制评估是否需要加队列或买高并发包[ ] 检查计费方式确认是否有缓存折扣、批量折扣[ ] 准备好回滚方案万一新模型不行能快速切回7. 我的最终选型建议没有最优只有最合适跑完这一轮实测我最大的感受是换模型这件事从来不是找最便宜的而是找成本和质量匹配你场景的。如果你做的是成本极度敏感的批量任务输入输出都不大那款没涨价的基准模型就是首选省下来的钱是实打实的。如果你做的是对输出质量要求高的产品GLM多花的钱能从减少重试和人工校验里省回来。如果你做的是超长文档处理K3的高单价反而可能是最划算的因为它能一次跑通不用切分。如果你已经在用DeepSeek且迁移成本高调价后它依然是均衡之选不用急着换。我自己的两个项目最后是这样处理的长文档摘要那个切到了基准模型加切分策略成本降了60%商品文案生成那个留在了DeepSeek因为输出质量稳定迁移风险不值得冒。每个项目的情况不一样别照搬别人的选型按自己的token分布和并发需求算一遍账答案自然就出来了。最后分享一个小技巧不管你用哪个模型先把usage字段的日志打全记录每次请求的输入token、输出token、缓存命中情况、延迟。有了这些数据你才能算出真实的单位成本也才能在下次涨价时快速做出反应。我见过太多团队连自己每个月token怎么花的都不清楚涨价了只能被动挨打。数据在手选型不慌。