国内模型价格对比

手上要选一家国内大模型 API，官网价格页翻了一圈，却越看越糊：有的按输入输出分开报，有的把缓存价单列，有的标价看着低但长输出贵得离谱。这篇不替你下结论，只给一套能自己跑一遍的比价流程——先把口径对齐，再把你的真实用量代进去，最后知道什么情况下便宜的那家反而不划算。

手上要选一家国内大模型 API，官网价格页翻了一圈，却越看越糊：有的按输入输出分开报，有的把缓存价单列，有的标价看着低但长输出贵得离谱。这篇不替你下结论，只给一套能自己跑一遍的比价流程——先把口径对齐，再把你的真实用量代进去，最后知道什么情况下便宜的那家反而不划算。

适合谁看：正在给自家产品挑主力模型、或者准备从一家换到另一家的技术负责人。不适合谁：只是想给玩具项目随便找个免费额度跑一跑的人，那种场景看免费额度就够了，不需要做横向比价。下面全部是方法，数字请到站内对应页面核对当时的版本。

为什么国内模型的价格表很难直接比

最大的坑不是价格本身，而是每家的报价方式长得不一样。有的页面只给一个综合价，看着清爽，但你拆不出输入输出的占比；有的把输入、输出、缓存读、缓存写拆成四列，数字多了反而容易看错行。你要是直接拿两个不同口径的数字对比，得出的结论一定是错的。

• 报价单位与拆分方式不一致：综合价、拆分价、按档位价混在一起，先确认自己看的是哪一列
• 标价低的往往是短上下文的小档位，一旦把长文档或长对话丢进去，单价结构会变，不再是同一个商品
• 限速、并发上限、可用区这些非价格条款不写进单价，但会直接影响你能跑多快、要不要多开账号
• 有的页面把缓存价单独列出来，命中和不命中差很多，漏看这一列会严重低估或高估成本

比价前先对齐四个口径

动手做表之前，先把这四个问题在每家的价格页上找到答案，找不到就去站内价格变动追踪页和历史公告里翻。这一步花的时间，比后面反复返工便宜得多。四个口径没对齐，表做得再漂亮也是白做。

输入价与输出价

必须分开记。输出通常是成本大头，只看输入那一列会得出完全相反的结论。

缓存口径

是否单独计价、命中后怎么算、写入是否收费，写进对照表的备注列，别塞在脑子里。

价格形态

是否分时段价、是否阶梯价、批量与实时是不是同一个价，这决定你的用量曲线怎么落。

结算方式

结算币种、开票主体、能否对公。跨主体结算会多出汇率和手续费这两笔，属于隐性成本。

对齐口径时有一个常见误区：把「最便宜的那一档」当成「这家公司的价格」。一家厂商往往有多个档位，你真正会用到的通常只有一到两个，其余档位填进表里只会干扰判断。

搭一张能横向拉平的比价表

不要用记忆比价，也不要用别人整理的截图。自己搭一张表，列固定下来，每行只填一个模型档位。同一家的多个档位不要挤进一格，否则后面算任务成本时没法按行取数。具体单价请到站内官方 API 价格页核对当时的数字，这里不写死任何数值。

表填完之后做一次「减法」：把用不到的档位、跑不通合规要求的厂商、结算方式不匹配的主体，直接从候选里删掉。剩下三到五家再进入下一步，比一开始就在十几个选项里挑要清楚得多。

把单价换算成你的任务成本

单价不是成本，任务成本才是。你需要先估清一个典型任务的输入 token 量和输出 token 量，这两个数才是乘法的乘数。估不准就先拿一小批真实数据跑一遍，别拍脑袋。换算可以直接用站内的 token 单价换算和模型成本计算器，手算容易在单位上出错。

1. 抽一批真实样本从线上日志里抽一批真实请求，覆盖典型和极端两种长度，别只挑短的那批。
2. 量出输入输出 token分别统计每条的输入和输出 token 数，取中位数和偏高水平各记一个，后面算区间用。
3. 乘上加权重用候选模型的输入价乘输入量、输出价乘输出量，两者相加得到单任务成本，再乘上你的日均调用量。
4. 对照验证挑一家先小流量真跑，把实际账单和预估对齐，差得离谱的先回去查口径，不要先怀疑模型。

判断敏感点有个简单办法：算一下输出 token 占总量的大致比例。总结、生成、代码补全这类任务输出占比高，对输出价敏感；分类、抽取、检索问答这类任务输入占比高，对输入价和缓存命中率敏感。同一张表，两类任务算出来的「最划算」很可能不是同一家，这很正常，按任务分开选型即可。

便宜不等于划算：什么情况下要放弃最低价

单价最低的那家，在你自己的场景里未必最划算。下面这几种情况，便宜的那一档反而会把成本推上去，判断时要把它们单独拎出来看，而不是混进价格排序里。

• 需要一次做对的任务：返工重跑会把省下来的钱吐回去，还要搭上人工复核的时间
• 有严格延迟要求的场景：低价档位常配更窄的限速，排队等待也是成本，用户等不了
• 合规与数据要求：数据出境、发票主体、留存策略这些硬约束，价格再低也可能直接出局
• 长上下文或长输出任务：档位一变单价结构就变，原本便宜的可能不再便宜
• 稳定性要求高的链路：频繁超时和重试会放大实际消耗，账单上看得见

什么情况下这条建议不适用：如果你的场景本身就是容错很高的批量处理，错一条重跑一次几乎没代价，那价格权重可以放得很高，质量只要过最低线就行。先想清楚自己的返工成本，再决定要不要为质量多付一点。

小规模试跑：用一周真实流量验证

纸面比价永远有偏差，因为限速、重试、超时这些都会进账单。挑两到三家候选，各接一条真实业务链路，跑够一个完整周期，让工作日和周末的流量形态都覆盖到。这一步不用大动干戈，能拿到真实计费数据就够了。

1. 选链路选一条真实在跑、调用量适中、失败可回滚的链路，别拿核心链路做实验。
2. 双跑对比同一批输入分别打给候选模型，记录各自的输出质量和响应表现，人工抽查一批。
3. 记账记录实际计费 token、失败重试次数、超时比例，这三项都会体现在最终账单上。
4. 对账把实际消耗和前面的预估对齐，偏差大的先查口径差异，再看是不是触发了重试或缓存未命中。

试跑结束再决定主用哪家、备用哪家，不要一次全量切换。切换本身也有成本：改代码、改监控、改告警阈值，这些都算在迁移账上。

上线后的复核节奏

选定之后不是一劳永逸。价格会调整，限速策略会变，你的用量结构也在变。设一个固定的复核周期，按月拉一次用量和账单，和试跑阶段算出来的单任务成本对齐，发现持续偏离就去查原因。本站的价格变动追踪页会记录各家的调整，具体数字到那页核对当时的版本即可。

• 按月对账：实际单任务成本和预估差多少，差异来自哪一项
• 定期看价格变动：别等账单变了才发现，固定周期去站内价格变动追踪页复核
• 留一条可切换路径：主用模型涨价或限速收紧时，能在一周内切到备用
• 记录留档：每次复核的结论存下来，下次换模型时这份历史数据比任何榜单都准
• 关注用量结构变化：新功能上线可能让输出占比变高，原来的性价比结论可能失效

复核不等于频繁换模型。频繁切换本身的工程成本和稳定性风险，往往比价格波动带来的影响更大。真正该触发切换的是持续偏离的账单、明显收紧的限速、或者你的任务结构发生了实质变化，而不是一次两次的价格调整。