很多人第一次选 API 是这么干的：打开两个官网价格页，各记一个数字，然后凭感觉挑。结果上线一个月，账单和当初那个数字对不上——因为一家的价格挂在输入输出分开的单价上，另一家还牵扯套餐、赠送额度、按量档位。这篇不报数字，只讲清该拿哪几个维度去比、比完怎么套到自己的用量上，以及哪种用量结构下谁更合适。
很多人第一次在 DeepSeek 和豆包之间选 API，动作都差不多：打开两个官网价格页，各抄一个数字，然后凭感觉挑一个。上线跑一个月，账单和当初抄的那个数字对不上，回头查原因，才发现两家的计费口径根本不是同一张表。一家把输入和输出拆开算，还牵扯缓存命中；另一家叠着套餐、资源包、按量档位，单价只是其中一个入口。
这篇不报具体数字，也不给「谁更便宜」的结论。写的是：拿哪几个维度去比、怎么把两家拉到同一行对齐、比完怎么套进你自己的用量结构里，以及哪种用量下谁更合适。看完你应该能自己算出一份账，而不是记住一个别人的答案。
别只盯一个单价：两家的计费口径本来就不是同一张表
最容易被忽略的点是：你在 A 家看到的那个数字，和 B 家那个数字，往往不是同一个东西。一边是纯 token 计价，输入输出分开；另一边可能把套餐、资源包、按量档位揉在一起，单看某一档价格会失真。所以第一步不是比大小，是先把口径写成同一行。
- 计价单位
- 是按 token 算，还是按调用次数、按资源包额度算，先把单位统一
- 输入输出是否分开
- 分开计价时，两家的输出价通常都明显高于输入价，不能只看一个
- 阶梯
- 有没有按量越大越便宜、或按模型分档的规则，还是全站一口价
- 有效期
- 赠送额度和套餐额度有没有时间限制，过期会不会作废
要对比的四个维度：单价、倍率口径、赠送与套餐、限速
把这四个维度拆开的原因很简单：只看单价会漏掉后面三项，而后三项在真实账单里经常占大头。建议做成一张固定表格，每次调价只改表里的数字，不动结构。
| 维度 | 要查什么 | 容易踩的坑 |
|---|---|---|
| 单价 | 输入价、输出价各抄一份，注明是不是当期数字 | 只抄输入价，把输出价当成一样 |
| 倍率口径 | 走中转站时，官方价要先乘倍率再比 | 拿官方价直接对比平台价 |
| 赠送与套餐 | 赠额覆盖哪些模型、有无有效期、用完是否自动转扣费 | 把打折后的价当原价比 |
| 限速 | RPM、并发上限、单次最大输出 | 同价但跑不完活，等于更贵 |
- 单价：到站内官方价格页把两家输入价和输出价各抄一份，抄的是当期数字，不是记忆里的
- 倍率口径：任何走中转或聚合平台的调用，官方价要先乘倍率再进对比表
- 赠送与套餐：问清赠额覆盖范围、有效期、用完后的扣费方式
- 限速：同样的价格，RPM 或并发上限不同，实际能干完的活差很多
- 上下文上限：长文档场景里，能一次塞进去多少，直接决定你要不要切分重试
决定胜负的不是单价，而是你的用量结构
单价是二维的，你的用量是三维的。把任务拆成三类，你会发现两家的胜负关系可能完全反过来：长输入短输出的场景，钱主要花在输入上；短输入长输出的场景，钱主要花在输出上；两者都长的多轮对话和 Agent 循环，两头都要算。
| 任务类型 | 钱主要花在哪 | 对哪家更敏感 |
|---|---|---|
| 文档问答、摘要 | 输入 token | 输入单价与上下文上限 |
| 写代码、长文生成 | 输出 token | 输出单价与最大输出限制 |
| 多轮对话、Agent 循环 | 输入输出都长 | 总成本，而非某一项单价 |
| 批量离线处理 | 总量大但可错峰 | 单价加折扣档位 |
- 导出一段真实调用记录至少能拆出输入 token、输出 token、调用次数三列，时间跨度要覆盖你的典型工作日和高峰
- 算三类任务的比例把记录按功能标签归类，看长输入类、长输出类各占多少，这个比例就是你在比价时的权重
- 没有记录时先粗估按每个功能每天大概调用多少次、每次输入输出大概多长，手写一张估算表，够用就行
按场景对号：什么活交给 DeepSeek，什么活交给豆包
这里说的不是「谁更强」，是「什么用量结构下谁更合适」。判断依据仍然是前面那三项：你偏输入还是偏输出、有没有套餐或赠送在覆盖、要不要跟现有云资源打通。不要接受一个通用的排名结论，因为它没考虑你的用量形状。
- 偏长输入、偏代码与推理、可以批量离线跑的任务，通常单价和上下文长度权重更高
- 已经有火山引擎或字节系技术栈的项目，鉴权、日志、监控能不能直接复用，要算进总账
- 需要跟现有云资源、私有网络、统一计费打通的团队，接入成本本身就是一笔钱
- 什么情况下不适用：对延迟、并发上限、输出稳定性有硬要求的实时业务，价格往往不是第一决策项，先跑测速和可用性，再回头算钱
落地比价：用你自己的用量表算一遍，而不是抄结论
比价这件事，抄结论是最省事也最容易翻车的做法。正确做法是：把你自己的用量表拿过来，分别套两家的当期单价算一遍，得出两个数，再把两个数换算成「每完成一次典型任务花多少」——这个口径比「每百万 token 多少钱」有体感得多。
- 整理用量表从日志里导出输入 token、输出 token、调用次数，按功能分类；这一步的准确度决定后面估算的可信度
- 查当期单价到站内官方价格页核对两家的当前口径，包括输入输出是否分开、有没有阶梯、缓存命中怎么算；数字以页面当天为准
- 各自乘一遍用你的输入量乘输入价、输出量乘输出价，再求和；赠送和套餐额度按覆盖范围从对应科目里扣掉，不要笼统减总数
- 换算成单任务成本用总额除以完成的典型任务数，得到「每个任务花多少」，这个数字才好和替代方案比
- 加上损耗再上浮把失败重试、超长上下文截断重发、缓存未命中的比例都估进去，实际上浮幅度通常比你预想的大
比价的正确产物是一张属于你自己用量的成本表，不是一句「A 比 B 便宜」。
选完之后：把成本压住的三件常规动作
选型只是开始。真正让账单失控的，往往不是单价高，而是没人管用量。下面这三件事不复杂，但能挡掉大部分意外开销，建议上线前就做好，别等第一次月结。
- 给项目设预算告警，并把单日限额卡在「一晚跑飞也烧不穿」的档位，触发时不一定要停服，但一定要有人收到通知
- 对可离线的任务走批处理或错峰，对实时交互限制最大上下文和最大输出，别让单次请求无限膨胀
- 给每一笔调用打上业务标签，注明哪个功能、哪个用户档位、哪次实验，否则下个月复盘根本分不清钱花在哪
几个常见的比价翻车点
下面这些错误重复率极高，而且大多不是算错，是比较的基准选错了。对着清单自查一遍，能省掉一次返工。
| 翻车点 | 为什么会错 | 怎么避 |
|---|---|---|
| 拿含赠额的价对比纯按量价 | 基准不同，等于打折价打原价 | 两边都还原成按量价再比 |
| 只看输入价 | 输出价通常明显更高 | 输入输出分开列，分别算 |
| 照抄别人的结论 | 对方是长文档场景，你是长输出场景 | 先算自己的用量结构再下判断 |
| 默认缓存命中率高 | 新会话多时命中率其实很低 | 按实际命中率估算，别按理想值 |
价格会变，把「去哪看」固定下来比背数字有用
两家的价格和套餐形态都会调整，赠额和档位更是经常变。与其记一个会过期的数字，不如把几个必看的页面固定下来，形成一套每周或每月固定走一遍的核对流程。这样调价发生时，你是第一批知道的人。
- 收藏两家官方价格页调价通常先动这里，收藏后定期打开扫一眼输入价、输出价和档位规则有没有变化
- 用站内价格追踪看变动历史到站内价格追踪页面看某条价格是长期下调还是短期活动，避免把活动价当成常态
- 每次调价后重算一次账调价当月就把自己的用量表重新套一遍，确认新数字还在预算范围内，别拖到下个季度
常见问题
DeepSeek 和豆包到底哪个 API 更便宜？
没有固定答案，因为两家的计费口径不同：一家纯按 token 输入输出分开算，另一家还可能有套餐与资源包形态。真正的做法是拿你自己的用量记录，分别乘两家的当期单价再比。当期数字去站内官方 API 价格页核对，别用记得的数字。
我该拿官方价还是中转站价格来对比？
先用官方价对齐口径，再把中转站的倍率叠上去看最终价。中转站可能更低也可能更高，还要看它是否支持你要的模型和限速。两边的口径差异可以看站内价格对比口径相关的说明页。
用量很小，还需要认真比吗？
用量小的时候，单价差异对总账的影响往往不如接入成本大。这时候优先看文档质量、SDK 支持、限速是否够用、出错重试是否方便。等月调用量上去再回来做一次正式测算。
输入和输出分开计价，对我影响大吗？
影响很大。摘要、问答这类任务输入远大于输出，成本主要由输入价决定；写代码、长文生成则相反。如果你的任务偏输出密集，光看单价低的那个可能反而更贵，得按自己的输入输出比例加权。
什么时候不该只按价格选？
当业务对延迟、并发上限、输出稳定性或合规有硬要求时，价格要往后排。先跑一遍接口测速拿到自己的延迟基线，再看可用性和限速，最后才比钱。
