很多人卡在这一步：手上有个真实任务，一边是 Claude 的接口，一边是 DeepSeek 的接口，两边报价单看着都不复杂，可就是算不出到底选谁。问题多半不在数字，而在口径——输入输出怎么分、缓存算不算、重试和长上下文怎么摊。这篇不讲结论，只给你一套能自己跑一遍的对比流程，以及什么情况下这套算法不适用。
很多人卡在这一步：手上有个真实任务，一边是 Claude 的接口，一边是 DeepSeek 的接口，两边报价单看着都不复杂，可就是算不出到底选谁。问题多半不在数字，而在口径——输入输出怎么分、缓存算不算、重试和长上下文怎么摊。这篇不讲结论，只给你一套能自己跑一遍的对比流程，以及什么情况下这套算法不适用。
先明确一件事：这篇文章里不会出现任何具体单价。价格会变，额度会变，活动也会变，写死的数字过两周就可能误导你。所有需要看数字的地方，我都会告诉你去哪个站内页面核对当天的版本。你要带走的是比价方法，不是一串会过期的报价。
为什么这两家的价格单没法直接对
两家计价项并不完全重合。输入、输出、缓存读写、推理型模型的思考 token 是否单列，各家口径都不太一样。你拿 A 家的「每百万 token 输入价」直接去比 B 家的同名项，很可能比的是两个不同东西，算出来的结论自然不可靠。
- 计价项不重合：有的把缓存读写单列，有的合并在输入里；
- 同一任务消耗的 token 数不同：提示词越啰嗦、模型越爱展开，差距越被放大；
- 所以正确的顺序是先固定任务、再比钱，而不是先比单价。单价去站内官方 API 资料库核对当天的数字，别背。
第一步：把两边的计价项拉成同一张表
这一步的目标是消除口径差。你不需要看懂全部计费规则，只需要把两边能对上的项对齐，对不上的先标记出来。到站内官方 API 资料库分别翻一遍 DeepSeek 和 Anthropic 的规格与计费说明，然后把它们填进同一张表里。
| 计价项 | 要记录什么 | 对不上时怎么办 |
|---|---|---|
| 普通输入 | 每单位输入的计费方式 | 标注口径不明，留余量 |
| 缓存命中输入 | 是否单列、如何命中 | 按你的真实命中率估 |
| 输出 | 是否含思考 token | 推理任务单独测 |
| 额外计费项 | 长上下文加价、工具轮次 | 逐项列进出预算 |
表格填不满是正常的。遇到对不上的项，不要硬凑成一个数，直接在备注里写「口径不明」，然后在后面的测算里给这部分留出 10% 到 20% 的余量。比价最怕的不是算不准，而是用一个错口径算出一个看起来很精确的结论。
第二步：拿你自己的任务量一遍 token
两边官网的单价只是原料，真正决定账单的是你的任务消耗多少 token。挑三个真实任务，各跑十次以上，分别记录输入和输出的 token 数。不要只记总数，输入和输出在这两家的价差结构里权重不一样，混在一起会把结论带偏。
- 选任务挑短问答（几百字内）、中等改代码或写文档、长文摘要或长上下文检索各一个，覆盖你的主要使用场景。
- 跑样本每个任务跑十次以上，记录每次的输入、输出 token 数，取平均值和最坏值。
- 换钱用站内 token 价格计算器把输入输出分别换算成花费，别只看总数。最坏值才是你账单上会看到的那个数，平均值只用来做趋势。
如果任务里带固定前缀（比如系统提示、知识库片段），把这些前缀单独标出来，下一步算缓存时会用到。没有固定前缀的任务，缓存这一项可以直接跳过。
第三步：把缓存、重试和倍率算进去
固定前缀越多，缓存命中的比例越高，两边受益幅度不一样。你要按自己的真实命中率算，而不是按官方宣传的最高命中率算。一个简单的估法是：数一下你的请求里有多少比例的内容是每次都一样的前缀，这个比例大致就是你的命中率上限。
- 失败重试、超时重发、流式断流重连都会真实扣费，按 5% 到 15% 的额外量预留比较稳；
- 走中转站的话还有倍率和分组差异，同一模型不同渠道不是一个价，不能忽略；
- 把缓存收益和重试损耗写在同一条测算里，避免只算省的不算多花的。
第四步：分场景看谁更划算，而不是评一个总冠军
不存在「谁绝对更便宜」这回事，只有「在你的任务上谁更划算」。把任务按特征分成几类，分别代入你刚才算出的 token 数据，结论会清楚很多。下面的对照表给你一个判断顺序，具体数值仍然要去站内核对当天版本。
| 任务特征 | 关键计价项 | 判断顺序 |
|---|---|---|
| 高频短请求、批量分类抽取 | 输入价为主 | 先比普通输入，再算缓存 |
| 长文理解、多轮改代码 | 输出价 + 缓存命中 | 先看输出单价，再看命中率 |
| 推理型任务 | 思考 token 是否单列 | 单独测，别套用普通任务结论 |
推理型任务要特别小心：思考过程本身可能要算钱，单价上的优势很容易被吃掉。这类任务不要用前面的平均值直接外推，必须自己单独跑一批样本，把思考部分的消耗也量出来。
什么情况下上面的算法不成立
这套方法有边界，用错了地方反而浪费时间。下面三种情况，价格对比的意义会明显下降，你需要换一套判断标准。
- 两边效果差一个档时，价格对比没有意义——省下的钱不够你人工返工的时间；
- 任务量极小（一天几十次调用）时，讨论单价没意义，先看哪个接入更快、文档更顺；
- 任务对延迟、并发稳定性有硬要求时，先量延迟基线再谈价格。
还有一种情况：你的任务是实验性质、随时可能砍掉。这时候不值得花半天做精细测算，直接各接一个最小版本跑两天，用真实体感做决定更快。
下单前再核一遍，别用一个月前的数
价格和额度会变，测算表也有保质期。签约或大额充值前，到站内价格追踪页和对应官方页再确认一次当天数字。如果走中转站，把倍率、分组、充值门槛一起记进去，单看模型单价会算错。
- 核对当天价格到价格追踪页和官方 API 资料库确认当前计价项，别用旧截图。
- 修正假设把当月真实账单和你的测算表对一次，偏差超过两成的假设要改。
- 记录渠道信息走中转站的话，把渠道倍率、分组、起充门槛一起写进备注。
一页清单：照着做一遍就能出结论
把上面四步压成一张可执行清单，做一遍基本就能出结论。做完如果还是拿不定主意，说明你的任务本身差异不大，那就选接入更省事的那一边，把精力留给产品本身。
- 固定三个真实任务 → 各跑十次 → 记录输入输出 token 平均值与最坏值；
- 查两边官方计价页 → 拉成同一张四行表 → 标出口径不明项；
- 套上你的缓存命中率和重试余量 → 换算成月花费；
- 到站内模型成本计算器复核，最后用一次真实小额调用验证。
比价的目的不是找出最便宜的那家，而是让你知道在什么条件下该换、什么条件下不值得换。下一步把你算出的月花费和渠道倍率，拿到站内工具与价格追踪页复核一遍，再决定要不要换接口。→
常见问题
只看官方挂出来的单价，能不能直接判断哪家便宜？
不能。单价只覆盖输入输出两项，缓存读写、思考 token、长上下文的计费方式各家并不一样，而且同一个任务在两边消耗的 token 数通常不同。正确做法是固定你自己的任务，分别量出真实用量再换算，否则比出来的是一个和你账单无关的数字。
我的请求量很小，还需要做这套对比吗？
量小的时候，价格差异往往抵不过接入成本和调试时间。这时优先级是：文档是否清楚、有无免费额度可试、报错好不好排查。等调用量涨到每月账单能明显感知的时候，再回来做这套测算，性价比更高。
走中转站的价格会不会让这个对比失去意义？
中转站会叠加倍率和分组差异，同一个模型在不同渠道不是一个价，但对比框架不变：先算官方口径下的基线，再按渠道倍率折算，同时把充值门槛、余额有效期、跑路风险一起纳入成本。只看折后单价不看这些，容易得出偏乐观的结论。
两边效果差距大的时候，价格对比还有用吗？
如果任务上效果差一个明显档次，价格就不是主要变量了，省下的接口费很可能被人工返工吃掉。这种情况应该先解决效果问题，比如换提示词、加检索、拆任务，等两边都能稳定产出合格结果后，再回来比成本。
