很多人第一次比 Claude 和 DeepSeek 的价，是拿两边的「每百万 token 输入价」直接相减，结果一上量发现账单对不上。问题不在算错，而在两家的档位划分、缓存口径、输出与长上下文的计价方式根本不同。这篇不报具体数字，只给一套能自己跑通的对照方法和排查顺序，让结论经得起复核。
很多人第一次比 Claude 和 DeepSeek 的价，是拿两边的「每百万 token 输入价」直接相减，觉得数字低的那家就是便宜。结果一上量，账单对不上，回头翻明细才发现问题不在算错，而在两家对输入、输出、缓存、长上下文的档位切法根本不是一个切法。拿不同口径的两个数相减，本身就没意义。
这篇不报具体数字，价格时刻在动，写死的数很快过期。这里只给一套能自己跑通的对照方法：先对齐口径，再摆档位和缓存，然后把单价换算成「干一件活多少钱」，最后给一份下单前的排查清单。照着做完，结论至少经得起自己复核。
先对齐口径，再谈谁便宜
比价的第一步不是看谁便宜，是先确认你在对比「哪一档」。两家都把输入和输出拆开计价，但档位划分不一样：一家最核心的区分是缓存命中与未命中，另一家在此基础上还可能叠加长上下文或思考模式的独立档位。你拿 A 家的缓存命中价去比 B 家的普通输入价，比出来的结论是假的。
还有一个容易忽视的点：单价只对同一种 token 有效。缓存写入价、缓存读取价、输出价之间经常差出好几倍，只比其中一个，等于没比。折扣、赠送额度、阶梯价这些也要单独列一栏，别混进单价表里一起算，混进去之后你根本说不清哪部分差异来自档位、哪部分来自促销。
- 先确认计价单位：是按百万 token 还是别的单位，两家写法规不规整
- 把输入、输出、缓存写、缓存读四类价格分别列开，不要合并成一行
- 折扣与免费额度单列一栏，标注有效范围和是否与付费额度同价
- 具体数值到 Anthropic 官方 API 资料页（/official-api/providers/anthropic） 和 DeepSeek 官方 API 资料页（/official-api/providers/deepseek） 核对当期口径
- 不适用的情况：如果用量几乎全是短输入短输出，缓存和长上下文档位根本用不上，比价表可以只保留输入与输出两列
上下文档位与缓存价怎么摆到一张表里
档位对齐之后，下一步是把它们摆进同一张表，用你真实的请求长度去切分。别用官网示例的长度，那个长度往往和你线上差很远。按短问答、几千字文档、几万字长文各切一档，看两家的请求分别落在哪个计价区间，超出某个长度后是不是整段请求都按更高档计。
缓存这块要分清「写」和「读」。第一次把内容灌进去，通常按缓存写入价；后续命中同一段前缀，才按缓存读取价走。只有反复引用同一段前缀的场景，才吃得到读价的红利。如果每次请求的前缀都在变，缓存基本用不上，这时候纠结缓存价没意义。
| 对比维度 | 要填什么 | 填的时候注意 |
|---|---|---|
| 输入长度档 | 短问答 / 中等文档 / 长文各一段 | 按你真实请求分布切，别抄官网示例 |
| 缓存写价 | 首次灌入前缀时的价格 | 和读价分开填，别合并 |
| 缓存读价 | 命中同一前缀时的价格 | 只有复用前缀的场景才适用 |
| 输出价 | 生成内容的计价 | 输出通常比输入贵，别只看输入 |
| 特殊档 | 长上下文 / 思考模式等附加档 | 确认是否整段请求换档 |
这张表填完，两家的差异会自然浮出来。名词拿不准的，可以到 基础术语词典（/ai-dict/category/basics） 查一下缓存命中、上下文窗口这些词的确切含义，避免因为理解偏差填错档。
- 第一步：切档把你最近一周的请求按输入长度分三档，统计各档占比，别凭印象
- 第二步：填表对照上面那张表，两家各填一遍，缺的格子去站内资料页补
- 第三步：标记适用性在每格旁标注「本场景是否用得到」，用不到的格子直接划掉，别强行比
把单价换算成「干一件活多少钱」
单价本身没法指导选型，因为用户买的不是 token，是任务结果。换算方法很简单：挑一个你天天跑的真实任务，拆出固定前缀、可变输入、输出三部分的 token 量，再套各自档位的价格算一遍。同一个任务在两家各算一次，得到的「每件活成本」才是有可比性的数。
固定前缀越长、复用次数越多的任务，缓存收益越大，这类任务更适合愿意在缓存编排上花力气的那一方。一次性任务则要看谁的输入输出档更贴合，缓存那部分权重可以调低。算完之后建议反向验证一次：用站内工具把结果对一遍，对不上通常说明有档位漏算了。
| 任务类型 | 成本大头 | 比价时重点看 |
|---|---|---|
| 短问答、高频调用 | 输入档 + 输出档 | 两家的档位切点是否贴合你的长度 |
| 长文摘要、批量处理 | 长上下文档 + 输出 | 换档阈值在哪，是否整段换档 |
| 固定前缀的重复任务 | 缓存写价 + 缓存读价 | 前缀复用次数够不够摊平写价 |
| 质量敏感型生成 | 输出档 + 返工成本 | 别只看价，返工一次可能吃掉全部差价 |
验证环节可以用 token 价格计算器（/tools/token-price-calculator） 和 模型成本计算器（/tools/model-cost-calculator） 各跑一遍，两个工具结果对不上，或者说和手算差得远，那就是某类 token 没算进档位里。对上了再往下走。
下单前的比价清单与常见坑
前面几步做完，结论基本成型，但下单前还有几个坑要排。最常见的两个：一是拿订阅套餐折算出来的单价比，和按量价比，这两者不是一回事，混着比会得出反直觉的结论；二是只看官网示例的长度，而自己线上请求的分布和示例差很远，算出来的成本偏差会放大。
- 确认计价单位，两家是否一致
- 确认缓存读价与写价是否分开列
- 确认长上下文或思考模式是否触发换档
- 确认有没有地区、渠道或合作方差价
- 确认免费额度与付费额度是否同价
- 确认价格调整有没有主动通知机制
最后一条尤其要注意：价格和档位调整通常不会主动通知到你邮箱，定期回看 价格追踪页（/price-watch） 的记录，比事后对账发现超支要省事得多。如果手上要接多家 API 做冗余，可以顺便看看 站点导航（/sites） 里各家中转与官方渠道的差异，把渠道因素也纳入比价。
下一步把上面那张四列表用你自己的真实请求填一遍，填不出来的格子说明口径还没对齐；对照站内价格追踪记录再核一次当期数字，比价结论才算落地。→常见问题
Claude 和 DeepSeek 谁更便宜，能给个结论吗？
没有脱离场景的结论。输入短、输出大、又不做缓存复用的任务，和长文档反复引用同一段前缀的任务，排序可能反过来。先按你的真实请求分布切成几档，套各自档位算一遍，再定。当期单价到站内官方 API 页面看，别用记忆里的数字。
缓存价是不是一定比普通输入便宜？
不一定，要看是缓存写还是缓存读。写进去那一次通常不便宜，甚至可能比普通输入贵；只有后续多次命中的读取才体现出优势。所以判据是这个前缀会被复用几次，复用次数少的话，做缓存编排反而更亏。
长上下文档位怎么判断我会不会踩到？
看你的典型请求长度分布，而不是看单次极限。把近一段时间的输入长度拉出来看分位数，如果大部分请求都落在某一档之上，那整条链路的单价预期都要按这一档重算，而不是按最低档估。
