API价格排行怎么看？主流服务商计费口径与价格对比

打开各家官方 API 价格页，数字摆在那里，但你会发现根本没法直接比：有的按输入输出分开列，有的把缓存读写单独计价，有的按次、按分钟、按字符算，还有的写着倍率和折扣。这篇不给你一个「谁最便宜」的结论，而是先把计费口径拆开，再告诉你价格排行该怎么读、哪些情况下排行榜会失灵。

打开各家官方 API 价格页，数字都摆在那里，但你会发现根本没法直接比。有的把输入输出分开列，有的把缓存读写单独计价，有的按次、按分钟、按字符算，还有的写着倍率和折扣。看着都是一行价格，落到你账上可能是完全不同的结构。

这篇不给「谁最便宜」的结论，那种结论换个月就过期，也没法适配你的用量结构。我们要做的是先把计费口径拆开，再告诉你价格排行该怎么读、哪些情况下排行榜会失灵。看完你应该能自己动手做一张只属于你团队的对比表。

为什么直接看价格排行容易踩坑

最容易踩的坑是把不同计价单位的东西放进同一列比较。按 token 的文本接口和按次的图像接口，单位就不在一个维度上；即便是同类文本接口，输入输出是否分开报价、缓存是否单列，也会让表面上的「单价」含义完全不同。排行本身没错，错的是我们默认所有数字可比。

• 计价单位不统一，输入、输出、缓存三项常被拆开或合并，直接横排就是错配
• 同一模型在官方、云市场、中转三种渠道的报价口径不同，混在一张表里比会失真
• 任务结构差异大，长输入短输出和短输入长输出会从同一份报价表得出相反结论
• 有的报价含税有的不含，外币结算还叠加汇率和手续费，这些都不写在单价里

判断标准其实就一条：这张表里的每一行，能不能被你自己的用量画像代入。代入不了，它对你就是一份宣传材料。真正的可比性来自口径对齐，而不是数字大小。

先分清四种计价单位：按 token、按次、按分钟、按字符

比价之前先把单位认准。文本模型主流是按 token，区分输入与输出，部分厂商把缓存读写单列出来；图像和部分工具型接口常按次计费，一次请求一个价，跟输入长度无关；语音合成、转写类接口多按分钟或字符，和文本模型之间不能直接换算。

1. 先记单位把上个月的调用记录拉出来，逐条标注它属于哪种计价单位，不要急着看钱。
2. 再记数量同一个单位下的调用量汇总，比如文本接口统计输入 token 和输出 token 各多少。
3. 最后才乘单价数量对齐之后再乘各家单价，这一步出来的数才是可比的。

这个顺序别反过来。先乘单价再归类，很容易把按次和按 token 混在一起，最后看着总额差不多，实际结构完全是两码事。

输入、输出、缓存读、缓存写：四项怎么分别看

文本接口的报价通常不只是一个数。输入和输出分开报价是常态，输出单价普遍高于输入；再往下还有缓存读和缓存写两项。做长文生成和做分类打标，成本结构完全不同，前者吃输出，后者吃输入。

缓存这块尤其容易算错。缓存写入通常有额外计费，只有命中缓存才有折扣。命中率低的场景根本拿不到折扣，却按折扣价做了预算，月底一看超了。看价格表时先确认「缓存」是默认开启还是需要显式参数，这直接决定你的预算模型成不成立。

一次典型请求的等效成本思路：；输入 token 数 × 输入单价；+ 输出 token 数 × 输出单价；+ 缓存写 token 数 × 缓存写单价；+ 缓存读 token 数 × 缓存读单价；= 这次请求的等效成本；把一天里同类请求的用量代进去，才是你真实的单位成本。

换算思路就这一段，关键是四项都别漏。很多人只算输入输出两项，结果缓存相关的费用在账单里冒出来，对不上预估。

倍率、折扣、阶梯价、赠送额度：哪些算进真实单价

价格表上还有一层「修饰」。倍率是把官方价乘以一个系数，比价前必须还原成实际单价，否则你比的是系数不是价格。阶梯价按用量段位变化，低用量和高用量的真实单价可能差出一个档，用哪一档取决于你的月用量落在哪。

• 倍率：先还原成实际单价，再拿去和别人比，不要直接比倍率数字
• 阶梯价：确认你落在哪一段，用量接近段位边界时按高一档估
• 折扣：看是否写明有效期与适用范围，没写清的先按不成立处理
• 赠送额度：有时限或范围限制，不能直接摊进长期单价
• 活动价：和常规价分开记，活动结束后预算要能兜住常规价

这几种修饰经常叠加出现，比如一个渠道既有倍率又有阶梯价，还带着赠送额度。这时候唯一的办法是把你自己的月用量代进去，算出加权后的等效单价，而不是看表上那个最显眼的数字。

读一份价格排行，按这个顺序看

拿到一份价格排行，别从最左边那列开始看。按固定顺序走一遍，能过滤掉大部分误导信息。

1. 确认口径看单位、是否含缓存、是否含税、按哪个地区或币种结算，这四项没对齐就先别比。
2. 对齐模型档位把用途相近的档位放一起，轻量档别去比旗舰档，能力差一档的价差没有意义。
3. 代入自己的用量画像输入输出比例、缓存命中率、并发量级，三个数代进去，表就变成你自己的了。
4. 回到当期数字到站内页面核对当时的报价，不要用记忆里的旧价，报价变动比你想象的频繁。

第四步最容易被跳过。很多人比价时脑子里记的还是上次看到的数字，结果口径对好了，数字是旧的。动态报价这件事没法靠记忆解决，只能每次现查。

官方价、云市场价、中转价：三套报价怎么对齐

官方价是基准尺子，但不同地区站点和结算币种会带来差异，别默认它们完全相同。云市场转售通常叠加了平台服务费，计费单位还可能被重新包装，比如按次数而不是按 token。中转报价常以倍率或分组形式呈现，同样需要还原到官方单价才能横向比。

统一做法是把三套报价全部折算成「每百万 token 的等效单价」再排。折算时把输入输出按你自己的比例加权，不是简单取平均。具体折算和当期数据，到站内页面核对当时的数字。

不过有一种情况折算会失真：涉及定制协议价、私有部署或打包套餐时，单价本身就不是线性关系，硬折算反而误导。这种时候应该按整包的实际使用量做一次性测算，而不是套用等效单价。

还有一点：中转渠道的稳定性会影响实际成本，因为你可能因为超时重试而多付。速度与可用性数据可以到站内页面用测速工具自己跑一轮，别只看报价。

比完价还不放心，再检查这 6 个成本变量

单价对齐之后，账单和预估还是可能对不上，问题往往出在这几个变量上。逐条过一遍，能解释掉大部分偏差。

• 失败重试带来的重复计费，有没有算进你的预估，超时重试是按调用次数付费的
• 上下文管理策略：是否每次都把完整历史发过去，这会直接放大输入成本
• 批处理与并发：批量任务是否有折扣通道，还是全按在线价走
• 缓存设计：提示词前缀是否稳定，前缀一变缓存就失效，折扣拿不到
• 限流与降级：被限速后改用更贵模型兜底，会把整体预算推高
• 汇率与结算手续费：以外币结算时这部分不体现在单价表里

这六条里，前两条通常影响最大。上下文策略尤其隐蔽，很多人以为是模型贵，其实是每次都把整段历史重发一遍，输入量翻了好几倍。改一下上下文裁剪策略，成本曲线立刻就变。

一份可执行的比价动作清单

概念讲完了，落到动作。下面这套流程按顺序做一遍，你手里就有了一张用得上、能定期更新的对比表。

1. 列任务列出你实际要跑的三类任务，各自记下典型输入输出长度，别用平均值糊弄。
2. 取数字按任务分别取两三家候选，去站内官方价格页抄当期数字，抄的时候带上口径备注。
3. 做对比表用同一口径折算成等效单价，做一张只属于你自己的对比表，输入输出按你的比例加权。
4. 小额实测跑一轮小额真实调用，把账单和预估对一次，偏差超过预期就回头看是不是口径错了。
5. 定复核节奏报价变动频繁，建议每隔一段时间重取一次数据，别让对比表过期。