先对一组数。
DeepSeek 官网，deepseek-v4-pro 这一行，高峰时段输入 1.32 美元/百万 tokens，输出 3.96，缓存命中 0.044。
千帆和腾讯云的表上，同样是 V4-Pro，高峰输入 9 元、输出 27、缓存 0.3。
9 ÷ 1.32 = 6.818
27 ÷ 3.96 = 6.818
0.3 ÷ 0.044 = 6.818三档，同一个比值。空闲价 4.5 / 13.5 / 0.15 对 0.66 / 1.98 / 0.022，算出来还是 6.818。
所以第一句话可以说死：平台的挂牌价就是官网价乘汇率，没有第二套加价逻辑。
那账单上的 12 是从哪来的？
因为表上还有一行。那一行也叫 DeepSeek-V4-Pro，但版本不是 0813。
这篇讲清楚两件事：为什么同一个名字会出现两个价，以及什么时候那一行贵的反而更省。
一、同一个字符串，两个平台指的不是同一版
官网的 Models & Pricing 页，MODEL 列只有一个 deepseek-v4-pro，MODEL VERSION 写的是 DeepSeek-V4-Pro-0813。
千帆的 Model List 里，是两行：
| Model Name | Version | Endpoint ID | 默认 TPM |
|---|---|---|---|
| DeepSeek-V4 | DeepSeek-V4-Pro-0813 |
deepseek-v4-pro-0813 |
1,000,000 |
| DeepSeek-V4 | DeepSeek-V4-Pro |
deepseek-v4-pro |
150,000 |
注意 Model Name 那一列，两行都是 DeepSeek-V4。区分它们的是 Version，不是名字。
于是就有了一个很容易被忽略的错位：
- 官网的
deepseek-v4-pro，指向 0813 - 千帆的
deepseek-v4-pro，指向 旧版 V4-Pro
同一个字符串，在两个平台指的不是同一版。
这是第二句可以说死的话。
时间线在千帆的《模型更新记录》里写得很清楚：4 月 24 日上架 DeepSeek-V4-Pro，8 月 14 日上架 DeepSeek-V4-Pro-0813。两代并存，都还能调。
所以"不带日期就是最新版"这个直觉，在这张表上不成立。DeepSeek-V4-Pro 是一个版本名，它恰好不带日期而已。
价格页的第一列写的是 DeepSeek-V4-Pro，那是把版本名拿来当模型名用了。真正的模型名在 Model List 里是 DeepSeek-V4。这两张表对着看，才不会看错。
二、两行价，对应两个版本
千帆《模型服务计费》，原文单位是元/千tokens，下面换算成元/百万：
| 版本 | 高峰 8:00-22:00（输入/输出/缓存） | 空闲 22:00-次日 8:00 |
|---|---|---|
DeepSeek-V4-Pro-0813 |
9 / 27 / 0.3 | 4.5 / 13.5 / 0.15 |
DeepSeek-V4-Pro |
12 / 24 / 1 | 无时段字段，同左 |
腾讯 TokenHub 广州区，同样两行，数字一模一样。另外还各有一行带"原厂直供"标记的 0813，价格和普通 0813 相同。
两家对同一个版本报的价，一分不差。
这也解释了一件事：网上那些"哪家 DeepSeek 单价更低"的对比，如果是拿 A 家的 0813 去比 B 家的旧版，比出来的差额，其实是版本差，不是平台差。
旧版那三个数也能对上官网。12 ÷ 6.818 = 1.76，24 ÷ 6.818 = 3.52，1 ÷ 6.818 = 0.147。这是旧版当年在官网的美元价，按同一个汇率折过来。它对照的也是官网，只是对照的是旧版的历史价格。
千帆那张表还有两处要照实说明：旧版那一行的"模型版本"列，原文写的是
DeepSeek-V4-Pro），多一个右括号，疑为文档笔误，这里照录；另外表头标注"命中缓存限时价格生效日期：9月9日-10月30日"，缓存那一档是限时价，到期后要按订单页为准。
三、三个维度，差得不一样
把两行的数字逐项相减，会得到三个不同的结论。
输入：贵 33% 到 167%
- 对新版高峰价 9：12 ÷ 9 = 1.33，贵 33%
- 对新版空闲价 4.5：12 ÷ 4.5 = 2.67，贵 167%
差价大小取决于你什么时候跑。白天跑，差三分之一；夜里跑，差一倍半。
缓存：贵 3.3 倍到 6.7 倍
- 对高峰缓存 0.3：1 ÷ 0.3 = 3.33 倍
- 对空闲缓存 0.15：1 ÷ 0.15 = 6.67 倍
这是三个维度里倍数最大的。但倍数大不等于影响大------第五节会算给你看，拿这一项去判断该用哪一版，结论会反过来。
输出：高峰时段反而低 11%
这一项是反常识的。
- 对新版空闲价 13.5：24 ÷ 13.5 = 1.78，贵 78%
- 对新版高峰价 27：24 ÷ 27 = 0.89，低 11%
不是笔误。腾讯和千帆两张表上都是这么写的：0813 高峰输出 27，旧版输出 24。
原因是旧版那张表不分峰谷，它把高峰价和空闲价"平均"成了一个固定值。高峰时段新版涨到 27，旧版还停在 24，于是旧版反而低了。
四、把三项合起来，有一个临界点
单看某一项容易误判。真正该看的是总价。
设输入量为 I（百万 tokens），输出量为 O（百万 tokens），高峰时段，先不考虑缓存：
新版成本 = 9 × I + 27 × O
旧版成本 = 12 × I + 24 × O两者相等时：
9I + 27O = 12I + 24O
3O = 3I
I = O临界点就是输入量等于输出量。
- 输入大于输出（I > O）：新版更省
- 输入小于输出（I < O）：旧版更省
这不是理论。工单摘要、长文续写、代码生成这类任务，输出经常比输入长，正好落在 I < O 这一侧。
反过来，RAG 检索问答、长文档摘要、批量分类这类任务，输入的上下文远大于输出，I 可能是 O 的十倍以上，新版的优势就非常明显。
同样看空闲时段：
新版成本 = 4.5I + 13.5O
旧版成本 = 12I + 24O要让旧版更省，需要 7.5I + 10.5O < 0。I 和 O 都是正数，这个不等式无解。所以空闲时段旧版永远更贵，没有例外。
三种工况，算给你看
假设每月输入 1 亿 tokens、输出 2,000 万 tokens（I:O = 5:1）：
| 工况 | 新版成本 | 旧版成本 | 差额 |
|---|---|---|---|
| 全高峰，I:O = 5:1 | 1,440 元 | 1,680 元 | 旧版贵 16.7% |
| 全空闲，I:O = 5:1 | 720 元 | 1,680 元 | 旧版贵 133% |
| 全高峰，I:O = 1:2 | 6,300 元 | 6,000 元 | 旧版省 4.8% |
第三行就是"贵的那行反而更省"的场景：输出是输入的两倍，且全跑在高峰时段。
这三行是按官方单价直接算的，未计缓存命中与阶梯计价。你的比例不一样，结论要重算------计算方法下面给。
# 按官方单价估算两条版本线的月成本（元/百万 tokens）
def cost(in_m, out_m, is_old, peak=True):
if not is_old:
price_in, price_out = (9, 27) if peak else (4.5, 13.5)
else:
price_in, price_out = 12, 24 # 旧版不分峰谷
return in_m * price_in + out_m * price_out
# 输入 1 亿、输出 2000 万，高峰
print(cost(100, 20, False), cost(100, 20, True)) # 1440 1680
# 输入 1 亿、输出 2 亿，高峰
print(cost(100, 200, False), cost(100, 200, True)) # 6300 6000五、倍数大不等于影响大：缓存那一项最容易被高估
上一节算的是"完全没命中缓存"的情况。真实业务多少会命中一些，所以这一节要把缓存加进来。
设输入中有 h 比例的 token 命中缓存。上面那个 I:O = 5:1 的例子，把 h 从 0 拉到 90%：
| 缓存命中率 | 新版成本 | 旧版成本 | 旧版贵多少 |
|---|---|---|---|
| 0% | 1,440 元 | 1,680 元 | 16.7% |
| 30% | 1,179 元 | 1,350 元 | 14.5% |
| 50% | 1,005 元 | 1,130 元 | 12.4% |
| 70% | 831 元 | 910 元 | 9.5% |
| 90% | 657 元 | 690 元 | 5.0% |
| 99% | 578.7 元 | 591 元 | 2.1% |
缓存命中率越高，两版之间的差距反而越小。
这跟"缓存价差 6.7 倍"的直觉是反的。原因是绝对值：缓存差价 1 − 0.3 = 0.7 元/百万，而输入差价 12 − 9 = 3 元/百万。缓存那一项虽然倍数惊人，但每百万只差 0.7 元；输入那一项倍数温和，每百万差 3 元。
命中率越高，未命中的输入越少，输入差价的影响就越小；剩下那 0.7 元的缓存差价，摊到总账上很轻。
所以"缓存价差 6.7 倍"这句话本身没错，但它是倍数量级 ，不是金额量级。把它当成选型第一依据，会算错。
更麻烦的是，它还会移动临界点。同样是高峰时段，临界 I:O 随命中率漂移：
| 缓存命中率 | 反转所需的输出/输入比 |
|---|---|
| 0% | 1.00 倍 |
| 30% | 1.30 倍 |
| 50% | 1.62 倍 |
| 70% | 2.16 倍 |
| 90% | 3.23 倍 |
命中率 90% 时，输出要做到输入的 3.23 倍，旧版才开始省。所以"输出大于输入就该换旧版"这句话，只在没缓存的前提下成立。
六、把四个变量放一起：版本其实排第三
到这里可以做个排序了。以"0813 + 高峰 + 无缓存"为基准，I:O = 5:1、月输入 1 亿：
| 你改的动作 | 成本变化 | 量级 |
|---|---|---|
| 把 0813 换成旧版 | +16.7% | 版本 |
| 把高峰挪到空闲 | −50.0% | 时段 |
| 把缓存命中率做到 90% | −54.4% | 用量结构 |
| 输出占比从 20% 提到 200%（I:O 反转） | 旧版相对省 4.8% | 业务形态 |
三个百分比不能直接相加，它们是不同维度。但量级很清楚：
版本选错，账单差 16.7%；时段选错，差 50%。
这就是这篇有点别扭的地方------文章标题讲的是版本，但版本不是最大的变量。
那为什么还要先讲版本？因为它有三个别的变量没有的性质：
- 它不在你的监控里。 时段和缓存，账单上能看出曲线；版本写错了，账单只显示一个更高的单价，看起来像是"涨价了"。
- 它是改一次就长期生效的。 时段要改调度，缓存要改 prompt 结构，版本只要改一行字符串。
- 它是唯一一个"你以为你选对了"的。 同一个名字在两个平台指向不同版本，只看名字看不出来。
七、额度也分版本，规律不统一
价格之外，还有一层容易被忽略：默认限流。
千帆《模型列表》（更新 2026-09-07）里，四个 Endpoint 的默认额度是这样：
| Endpoint ID | 对应版本 | RPM | TPM |
|---|---|---|---|
deepseek-v4-pro-0813 |
V4-Pro-0813 | 60 | 1,000,000 |
deepseek-v4-pro |
V4-Pro | 60 | 150,000 |
deepseek-v4-flash-0731 |
V4-Flash-0731 | 60 | 150,000 |
deepseek-v4-flash |
V4-Flash | 60 | 150,000 |
V4-Pro 的两行，RPM 都是 60，TPM 一个是 100 万，一个是 15 万，差 6.7 倍。
这是两个版本各自的默认配额，不是同一版本的两套配置。旧版的额度低，是旧版的事，不能推成"新版一定高"。
比如 V4-Flash：0731 和旧版，TPM 都是 15 万。所以"带日期的额度一定更高"不能当规律用。它是逐版本配置的，只能查表，不能推。
对集成商来说，这一条比单价更容易出事。单价贵一点，账单上看得见；TPM 低了，表现是 429 和排队，日志里看不出来是额度问题。
八、还有第三种标记：原厂直供
腾讯那张表上，V4-Pro 的 0813 其实有两行：一行带"原厂直供"，一行不带。价格完全一样，都是 4.5/13.5/0.15 对 9/27/0.3。
但换成 V4-Flash，两行就不一样了：
| 表上的行名 | 空闲（输入/输出/缓存） | 高峰（输入/输出/缓存） |
|---|---|---|
| DeepSeek-V4-Flash 0731 正式版 原厂直供 | 1 / 4 / 0.02 | 2 / 8 / 0.04 |
| DeepSeek-V4-Flash 0731 正式版 | 1.5 / 4.5 / 0.05 | 3 / 9 / 0.1 |
同一版 0731，带"原厂直供"的输入价 1，不带的 1.5，差 33%。
所以"看名字判断价格"这件事，在这张表上是不成立的。 同一个模型可能有三行、四种标记，只有逐行对表才能确定。
价格页上还有一句关于生效时间的说明：
原厂直供模型 于北京时间 2026 年 8 月 29 日 00:00 起生效；其他 DeepSeek 模型（除 deepseek-v4-flash，deepseek-v4-pro 外） 于北京时间 2026 年 9 月 26 日 00:00 起生效。
括号里被排除的，正好是两个旧版 endpoint。这不难理解：新的峰谷价是给 0813 / 0731 这两代新版本定的，旧版继续按旧价走，所以旧版那两行没有时段字段。
不是"旧版被特殊照顾"，是旧版还没进这套价格体系。
九、价格对得上官网，时段不一定
即使你锁定了版本，还有一个变量：什么时候跑。
官网的规则是：
Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday, excluding Chinese public holidays. All other hours are off-peak, including weekends and Chinese public holidays in full.
换成北京时间，就是工作日 9:00--12:00、14:00--18:00，周末和法定节假日全天空闲。
腾讯的规则和这句完全对齐：
北京时间工作日（周一至周五)9:00--12:00、14:00--18:00 为高峰时段，其余为空闲时段；周末（周六、周日)：全天为空闲时段。
按这条算，一周高峰是 7 小时 × 5 天 = 35 小时。
千帆的规则不一样：高峰是"每日 8:00-22:00"，没有工作日/周末之分。一周 14 小时 × 7 天 = 98 小时。
98 ÷ 35 = 2.8 倍。
价格一分不差，时段口径却能差近三倍。 这是这篇最值得记住的一条：平台价对照官网，不代表计费规则也逐条对照官网。时段是平台自己划的。
判定口径上，腾讯写得很细：
单次请求的计费时段，以平台服务端接收到该请求的时间（北京时间）为准。请求接收时间处于高峰时段的，该次请求按高峰时段价格计费；处于空闲时段的，按空闲时段价格计费。请求的处理时长及返回时间不影响时段判定。
按接收时间算，不按返回时间算------意味着一个跑了三分钟的长请求，只要是在 11:59 发出去的，就按高峰计。
还有一条更要紧：峰谷只对 DeepSeek 系列生效。
同一张表上，GLM-5.3 是 8/28/2，Kimi-K2.6 是 6.5/27/1.1，Qwen3.5-Plus 是 0.8/4.8/0.08（≤128K 档），全都没有时段字段，从早到晚一个价。
所以"夜里跑能省一半"这句话，对 DeepSeek 成立，对 GLM 不成立。网上很多比价文把这条规则套到所有模型上，是错的。
十、怎么选：先查版本，再算 I:O，最后定时段
给一张判断表，不给"标准答案"。
| 你的情况 | 建议 | 依据 |
|---|---|---|
| 输入远大于输出（RAG、长文档） | 0813，并尽量错峰 | 输入价差最大到 167%，错峰再省一半 |
| 输出明显大于输入（写作、代码） | 可以试旧版，但先确认能力够用 | 无缓存时 I=O 即反转；命中率越高，需要输出占比越大 |
| 有回归测试、对输出格式敏感 | 锁 0813 | 行为可复现，不随上游升级漂移 |
| 跨平台迁移 | 逐平台核对 endpoint → version | 同名不同版，官网和千帆就不一致 |
| 需要稳定的额度上限 | 查 TPM 表，别猜 | 0813 是 100 万，旧版 15 万 |
| 有明确的下线窗口要求 | 优先新版 + 盯公告 | 旧版会先退役 |
最后一行不是假设。千帆的价格表上，Kimi-K2.6 那一行的版本列写的是"Kimi-K2.6（即将下线）"。旧版本会从表上消失，这件事在表上就有标记。
十一、三个最容易算错的地方
写完上面几节，回头看不难，但有三个坑几乎人人会踩。
坑一：拿不同版本比价，以为在比平台。
同一个版本，两家数字完全一样；不同版本，同一家能差 167%。跨平台比价如果不同时标注版本，比出来的结论是随机数。
坑二：把"峰谷"套到所有模型上。
峰谷只对 DeepSeek 系列生效。GLM-5.3、Kimi-K2.6、Qwen3.5-Plus 在两家表上都没有时段字段。给一个 GLM 项目做"夜间调度省钱"的方案，省不下来。
坑三：用平均单价估成本。
单价是分输入、输出、缓存三档的，而且输出价通常是输入价的 2--3 倍。用"每百万 tokens 多少钱"这种单一数字做预算，误差可能比版本差异大得多。
比如 0813 高峰：输入 9、输出 27，同一个版本两个数差 3 倍。如果你的业务输出占比高，按 9 元估出来的预算会低一大截。
十二、上线前，六件事逐条对一遍
不用改架构，半小时能做完。
- 查配置里写的是哪串。 全文搜
deepseek-v4-pro，看有没有尾缀-0813。 - 打印一次响应里的 model 字段。 返回体里通常带实际命中的版本标识，比配置文件可信。同名不同版这件事，只有返回体能证明。
- 到目标平台的 Model List 对一次表。 确认这个 endpoint 当前指向哪个 Version。换平台时这一步必做，因为同一个字符串在官网和千帆指的不是同一版。
- 算一下自己的 I:O。 从账单或日志里取一个月的输入、输出 token 数，相除。
- 量一下缓存命中率。 命中率高于 70% 时，两版的价差已经收窄到 10% 以内，不必为这一项纠结。
- 确认默认 TPM 够不够。 别等 429 了才去查额度表。RPM 相同不代表 TPM 相同。
十三、如果要从旧版换到 0813，按这个顺序改
先说明：以下是工程做法，官方没有规定迁移顺序，也没有承诺两版输出完全一致。所以每一步都要自己验。
第一步，先加日志，不改配置。
在调用处打两个字段：请求里写的 model 名，和响应里返回的版本标识。跑一天，确认两者是否一致。有些 SDK 或网关会在中间改写模型名，只看配置文件看不出来。
同时把 usage 里的输入、输出、缓存命中三个数记下来。没有这三个数，后面所有测算都是猜的------无论你用的是腾讯云 TokenHub 还是千帆，这一步都一样。
第二步，用同一批输入跑两遍。
从生产日志里抽 50 到 100 条真实请求，一条不动地分别打给两个版本，逐条 diff 输出。重点看三类差异：结构化字段是否还能解析、长文本是否被截断、同样的 prompt 是否给出了不同的拒答判断。
这一步不能省。两代版本指向的是不同的权重，输出风格本来就可能不一样。
第三步，按业务线灰度，不要按流量比例灰度。
按流量切（比如 10% 请求走新版）会出现"同一个用户在两个版本之间跳"的问题，尤其是多轮对话和有状态的场景。按业务线切------先切内部工具，再切一条低风险业务线------回滚时边界清楚。
第四步，把版本做成配置项，不要写死在代码里。
# 差的做法：字符串散落在各处
client.chat(model="deepseek-v4-pro-0813", ...)
# 好的做法：一个配置项，回滚只改一行
MODEL_ID = os.getenv("LLM_MODEL_ID", "deepseek-v4-pro-0813")
client.chat(model=MODEL_ID, ...)这一步的价值不在切换当天，在于出问题时能在五分钟内切回去，而不是重新发版。
第五步，观察七天再全量。
看三个指标：错误率、输出解析失败率、单位请求的 token 消耗。第三个最容易被忽略------不同版本的"话"可能变长变短，单价没变，账单也会变。
第六步，订上线公告。
锁版本的好处是行为稳定，代价是放弃了自动升级，所以必须自己盯着新版本发布。千帆的《模型更新记录》是按月列出的，每次上新都会写明模型名称和模型版本。把它加进订阅或者定期看一眼，比出事之后再翻日志省事得多。
十四、这篇没讲什么
没讲模型能力谁强------那是另一回事，和能力榜也没关系。
没讲怎么发第一个请求------官方文档比任何博客都全。
也没讲"哪家更划算"------因为同一个版本，两家的数字一样。真正不一样的是版本和时段口径，不是平台。
还有一个变量：地域。同一张腾讯的价格表上，广州区和新加坡区两栏的数字并不相同，同一行 GLM-5.3 在两边就是两组价。这个下次单独拆。
数据来源
本文涉及的技术口径：
- DeepSeek《Models & Pricing》，官网
api-docs.deepseek.com/quick_start/pricing - 腾讯云《大模型服务平台 TokenHub 模型价格》，页面标注最近更新 2026-10-17 16:42:58
- 百度智能云千帆《模型服务计费》，页面标注更新 2026-10-18
- 百度智能云千帆《Model List》，页面标注更新 2026-09-07
- 百度智能云千帆《模型更新记录》，页面标注更新 2026-10-18
文中单价均为官方页面直读。官网以美元计价，平台以人民币计价，两者比值 6.818，三档价格全部一致，未做四舍五入以外的处理。第三、四、五、六节的差额、临界点与敏感性表格，均为按官方单价的算术推导，非官方结论，假设（月输入 1 亿、输出 2,000 万，未计阶梯与量包）已在各节写明。限时价与量包未计入，实际费用请以订单页与账单为准。
你配置里写的 deepseek-v4-pro，在官网指向 0813，在千帆指向旧版。这个错位，你是从返回体的 version 字段发现的，还是从账单单价倒推出来的？
如果两个平台都跑过同一个 ID，输出有没有不一样？评论区说说。