同一个任务在不同厂商要花多少钱？一个能自己套的实算模板
跨厂商比成本，唯一靠谱的做法是用同一个任务、同一批样本，分别代入各家的真实单价算总账。不是比谁的输入价低——那个数字单独看没有意义。
这篇给一个能直接套用的实算模板。为了不写没核实过的价格，示例里只用能在厂商官方定价页逐字查到的单价（详见价格对比表，每行都带官方链接和核对日期）；你套用时把自己核到的单价填进去即可。
第一步：把任务定义清楚
「做客服问答要多少钱」这个问题没法算，因为它没定义单次请求长什么样。可算的任务定义至少包含四项：
- 单次输入构成：system prompt 多长、带几轮历史、有没有检索片段、工具定义多大
- 单次输出长度：期望值和上限
- 调用频次：日请求数，以及是否有峰值时段
- 质量要求：能不能用轻量档模型，还是必须旗舰
举个例子，把任务定义成这样：客服问答，system prompt 约 800 token，带最近 3 轮历史约 1200 token，检索片段约 1500 token，用户问题约 100 token，期望回答 300 token、上限 600 token，日请求 5000 次。
这样定义之后，单次输入 = 800 + 1200 + 1500 + 100 ≈ 3600 token，单次输出取期望值 300 token。
第二步：把 token 数量出来，别拍脑袋
上面那些数字不能靠估，要实测。把真实的 system prompt、真实的历史、真实的检索片段拼成一个完整请求体，粘进 token 计算器，得到的才是可用的输入长度。
输出侧从日志统计历史平均长度；没有日志就跑几十条样本，取平均值和 P90。
第三步：算月用量
月输入 = 3600 × 5000 × 30 ≈ 5.4 亿 token 月输出 = 300 × 5000 × 30 = 4500 万 token
注意这里的输入输出比接近 12:1，属于典型的输入敏感型任务。这个比例会直接决定谁更划算——输入敏感型任务里，输入单价的权重远高于输出单价。
第四步：代入各家单价对比
把月输入和月输出填进月成本估算器，它会按各模型单价算出月成本并排序。
本站表内目前只收录了能追溯到官方定价页的条目（DeepSeek 与 Google Gemini 两家，核对于 2026-08-06）。这不是说别家不值得用，而是别家的定价页当天没能逐字核到，宁可空着也不写第三方转述价。你自己套模板时，把你核到的单价补上就行。
对比时记得同时看两件事：
- 排序：谁最便宜
- 差距：第一名和第二名差多少。差百分之几就没必要为此换厂商，换模型的迁移成本（prompt 重调、格式重验、效果重测）很可能超过省下的钱。
第五步：把折扣和分档修正回去
上一步得到的是标准档估算，还要做三处修正：
缓存修正：这个任务里 system prompt（800）和工具定义是固定的，检索片段和用户问题是变化的。把固定部分放在请求前缀，命中缓存后这部分按折扣价计。固定部分占输入的比例越高，修正幅度越大。
分档修正：3600 token 的输入在多数厂商都落在基础档，但如果你的检索片段经常更长，要按实际档位重算。
重试修正：按你的限流额度和历史重试率加一个系数。
修正完的数字才是能拿去排预算的。
换个场景，结论会翻过来
上面的客服问答是输入敏感型（输入输出比约 12:1）。换成输出敏感型，排序可能完全不同。
比如内容生成任务：system prompt 约 600 token，用户给的要点约 200 token，期望输出 1500 token。单次输入 800、输出 1500，输入输出比约 0.5:1——输出的权重是输入的三倍。
同样日 5000 次，月输入约 1.2 亿 token、月输出约 2.25 亿 token。这时候输入价再低也救不了输出价高的模型，排序会和客服场景反过来。
所以「哪家最便宜」这个问题本身就是错的，正确的问法是「在我的输入输出比下，哪家最便宜」。这也是为什么本站的估算器要你分别填输入和输出，而不是给一个总量——总量算不出排序。
如果你的团队同时有这两类任务，结论很可能是分开选型：客服链路用一家，生成链路用另一家，中间做一层统一封装隔离差异。做法见多家 API 统一封装。
换厂商的迁移成本清单
算出便宜多少之后，还要减去迁移成本才是净收益。这些项经常被漏：
- prompt 重调：不同模型对指令的响应习惯不同，原来稳定的 prompt 换家后可能需要重写，这是最大的一块工时。
- 输出格式重验：结构化输出的稳定性因家而异，解析层可能要加容错。
- 效果回归：整批样本重跑一遍，人工复核。
- 限流与重试策略重调：新厂商的 RPM/TPM 上限不同，并发参数要重设。
- 报错码映射：错误语义不一致，监控和告警规则要跟着改。
- 合规与数据条款复核：涉及企业数据时这一项不能省。
一个粗略的判断标准：如果预计节省不到总成本的两成，多半不值得迁；超过三成，且上面的清单能在两三周内完成，通常划算。
第六步：别忘了效果这一票
成本算完只解决了一半问题。剩下两三个候选之间，拿你自己的二三十条真实样本盲评一遍——公开榜单和你的具体场景经常对不上，尤其是中文长文、垂直术语、严格输出格式这几类任务。
如果便宜的那家需要更长的 prompt 去兜效果、或者失败率更高需要重试，省下的单价会被吐回去。总账要算到「达到同等效果所需的总 token」，而不是名义单价。
别只算模型调用，配套成本也要进表
做跨厂商对比时，只比 token 单价会漏掉几项实际会付的钱：
embedding 成本。检索方案要把文档向量化，文档更新还要重建。单价通常远低于生成模型，但文档量大时不是零。
网关或中转的加价。走聚合平台的话，多数会在原厂价上加一层。方便是真方便，加价也是真加价，比价时要用加价后的实际单价，而不是原厂刊例价。
存储与检索服务。自建向量库有服务器成本，托管服务有订阅费，都要摊进单位成本里。
监控与日志。把每次调用的 token、耗时、命中情况记下来是必要的，但海量日志本身也有存储成本。
这些项单独看都不大，加起来对总成本的影响可能有几个百分点。在两家差距本来就不大的时候，它们足以改变结论。
模板汇总
想看各家单价的横向情况，去价格对比表；想把候选并排看参数，用模型横向对比；想按厂商了解计费口径，读国产大模型 API 价格对比。