开源落后闭源只剩四个月，这对你的采购意味着什么

4 个月。

据 Epoch AI 于 2026 年 5 月 29 日发布的数据，最强开源权重模型平均落后前沿闭源模型约 4 个月、8 个 ECI 点。

我们把这句话摊开看了很久，因为它做了一件此前没人做成的事：把一场一直靠感觉争论的比较，换成了一个带单位的数。落后的不是「一代」「一截」「明显一档」，是四个月。

一个带单位的数可以进采购流程，一个形容词不行。「哪个更强」这种问题永远吵不完，「等四个月对我值多少钱」是个可以在会上算完的问题。

这篇文章只做一件事：把这四个月换算成你能拿去做决定的东西。

一、先说清楚这个「四个月」是什么，以及不是什么

据 Epoch AI（2026 年 5 月 29 日）的这条数据，比较的两端是「最强开源权重模型」和「前沿闭源模型」，得到的结论是平均落后约 4 个月、8 个 ECI 点。

三个限定必须先写出来，否则后面全算错。

第一，是平均，不是保证。 「平均落后四个月」的意思是，把一段时间里的多个观测点平均之后落在四个月这个位置。它不承诺任何一个具体任务上都只差四个月，更不承诺你手上那件事只差四个月。有的任务上开源侧可能几乎没有差距，有的任务上差距会明显大于平均值。把平均值当保证用，是这条数据最容易被误用的方式。

第二，8 个 ECI 点这一侧，我们不往下用。 我们没有找到能把「8 个 ECI 点」换算成业务表现的公开口径——比如差 8 个点在客服工单上会多错几条、在合同抽取上会漏几项。既然换算不出来，本文就只用「4 个月」这一侧做判断，不替这 8 个点编一个业务含义。

第三，「开源权重」不等于「免费」，也不等于「你能自己跑」。 权重开源解决的是「模型能不能拿到手」，不解决算力、部署、运维、出问题谁兜底。这四件事的账在第四节单独算。

把这三条限定放进去之后，这条数据的正确读法只有一句：在任一时点上，前沿闭源模型能做到的事，开源权重模型平均要再过约四个月才能做到。

注意这句话里没有「开源追不上」，也没有「开源已经追平」。它说的是一个稳定存在、但已经很短的时间差。

四个月是什么概念？它比大多数公司做一次选型、走完采购流程、完成一轮对接的周期还要短。也就是说，等你把一个模型真正接进业务、跑通、让员工习惯，这个时间差已经过去了一轮。

这正是这条数据让采购逻辑发生变化的地方。当差距是「一代」的时候，你没得选，只能买最强的那个。当差距被量化成四个月的时候，它就变成了一个可以定价的东西——你可以选择付钱把这四个月买下来，也可以选择不付。

二、把四个月换成你自己的业务语言

「四个月值多少钱」这个问题，答案不在模型那边，在你的业务那边。

我们建议按一个很土但很好用的标准分：这件事晚四个月做，会不会有人替你做了。

不是「难不难」，不是「重不重要」，是「有没有人抢」。

第一类：等得起，而且等得起很多个四个月。

内部用的、批量的、结果有人复核的、不直接触达客户的任务，几乎全部落在这一类。工单归类、发票信息抽取、内部知识问答、把一堆散乱记录整理成表格、给库存单据做校验——这些事情的天花板从来不是模型能力，是你的流程有没有理顺、数据有没有整齐、复核环节有没有人接得住。

对这一类任务，四个月的能力差落进去基本看不见。你换一个落后四个月的模型，出错率的变化很可能被你自己流程里的噪声盖掉。而它们通常占了一家公司调用量的绝大部分。

第二类：等不起。

判断依据只有一条：你的差异化就建立在输出质量本身上，而且你的同行也在用同一批模型。

举个形状：如果你卖的是「我们出的方案比同行好」，而同行拿到的是前沿闭源模型、你拿到的是落后四个月的开源模型，那这四个月就是直接的竞争差。这类任务不多，但一家公司通常总有一两件。

第三类：不受影响，因为瓶颈根本不在模型上。

这一类比大多数人以为的要大。如果一件事现在做不成的原因是「没人整理数据」「没人定验收标准」「做完了没人用」，那么换任何模型都做不成，等四个月也做不成。为这类任务去争前沿模型，是把预算花在一个不是瓶颈的地方。

我们的看法是：先做这个分类，再谈选型。顺序反过来，最后必然变成全公司统一用最贵的那一档，然后为第一类任务的巨大调用量，付第二类任务的单价。

这个分类不需要任何技术背景，业务负责人自己就能做完，一张纸就够。做完之后你会得到三摞任务，其中第一摞通常最厚。

三、价格是这笔账的另一侧

能力差是四个月，价格差是多少？

我们只用各家官方定价页上的数，单位统一成「每百万 token 输入 / 输出」。

• →智谱 GLM-5.2：$1.4 / $4.4（据 Z.ai 官方定价文档）
• →DeepSeek V4 Pro：高峰 $1.32 / $3.96、低谷 $0.66 / $1.98，缓存命中价低至 $0.022（据 DeepSeek 官方定价页）
• →DeepSeek V4 Flash：高峰 $0.44 / $1.32、低谷 $0.22 / $0.66（据 DeepSeek 官方定价页）

DeepSeek 那两行是区间价而不是单价：2026 年 8 月 16 日 16:00（UTC）起它改成高峰 / 低谷两档计价，低谷价是高峰价的一半，高峰时段为世界协调时 01:00–04:00 与 06:00–10:00。所以「DeepSeek 多少钱」这个问题在这一家没有唯一答案，取决于你的活跑在几点。本文的账单演算取的是高峰价，夜里能跑的批量任务单价直接减半。

「每百万 token」这个单位对老板没有意义，得换成账单。

我们用一个可替换的假设口径：一个工单送进去 2,000 个 token，回来 500 个。这是假设，不是数据，你应该换成自己业务的真实值再算一遍。

1 万个工单就是输入 20 个百万、输出 5 个百万。账单 = 20 × 输入单价 + 5 × 输出单价。

如果这 1 万单是每月的量，一年 12 万单：GLM-5.2 一年 $600，V4 Flash 一年 $184.8（挪到低谷时段是 $92.4）。

再看缓存这一侧。V4 Pro 那 $46.2 里，输入端是 20 × $1.32 = $26.4。如果这 20 个百万 token 全部命中缓存，输入端变成 20 × $0.044 = $0.88，总账单降到约 $20.68。什么都没换，只是命中了缓存，账单从 $46.2 降到 $20.68。

$1.32 除以 $0.044 等于 30 倍。这是标准输入价和缓存命中价之间的倍数，高峰与低谷同比例，倍数不变。它成立的条件很具体：前缀重复——同一份长提示词、同一份产品手册、同一套规则文档被反复送进去。每次输入都完全不同的场景用不上这个价。

关于 GLM-5.2 还有一条，我们认为对采购的意义比价格更大。据 Z.ai 官方文档与钛媒体（2026 年 6 月 13 日）的报道，GLM-5.2 是 744B 参数、MIT 协议开源，并且全程在华为昇腾 910B 上训练完成。

MIT 协议和昇腾训练这两件事放在一起，指向的是同一个采购维度：供给不依赖单一来源。一个 MIT 协议开源的 744B 模型，意味着即使某家公司停掉 API，权重还在你手上；训练全程跑在国产卡上，意味着这条供给链上少一个卡脖子的位置。

这两件事不会让模型变得更强，但会让它变得更难被断掉。对一个已经把业务流程接上去的公司来说，「更难被断掉」和「更强」是两个都要算的账，而且前者往往被漏掉。

四、采购判断：三步，加三条硬指征

把上面两侧合起来，得到一个可以直接走的顺序。

第 1 步。先分等得起和等不起，这一步不看价格，也不看模型。

拿一张纸，把你公司里所有想交给模型做的事列出来，按第二节那个标准分成三摞：等得起的、等不起的、瓶颈不在模型上的。

第三摞先整个拿掉——那些事不是选型能解决的，先去解决数据和流程。剩下两摞才进入下一步。

这一步必须由业务方做，不能由技术方做。技术方分出来的一定是「难不难」，而你要的是「有没有人抢」。

第 2 步。看数据能不能出厂，这一步同样不看价格。

把两摞任务里涉及的数据过一遍，问一个问题：这些数据送到外部 API 上，有没有合同、法规或者客户约定不允许。

答案是「不允许」的那些任务，价格表对它们没有意义——它们只有一条路，就是权重开源的模型加自己的机器。这时候「落后四个月」不是一个选项，是一个前提，你只能接受它。

答案是「允许」的任务，才进入第三步。

第 3 步。最后才看价格，而且看的是账单不是单价。

用上面那个 2,000 / 500 的算法，换成你自己的真实值，把每一摞任务的月账单算出来。

算出来之后你多半会看到一个结构：等得起的那摞调用量最大、单位成本最低、总账单占比反而不高；等不起的那摞调用量很小，却可能吃掉大半预算。这个结构是健康的。真正要查的是有没有任务被无意识地从第一摞挪到了第二摞——那才是钱漏掉的地方。

三条必须用闭源前沿的硬指征。

不是所有任务都能靠等四个月解决。以下三种情况，我们的建议是不要省这笔钱：

第一，输出直接对外且不可撤回。对外报价单、合同条款、直接推送给客户的内容，出去之后没有第二双眼睛看。这一档的错误成本，通常一次就超过一整年的模型账单差。

第二，你的差异化就是输出质量，且同行拿的是前沿模型。这是第二节里的「等不起」，四个月在这里是实打实的竞争差。

第三，任务本身就在能力边界上。如果一件事你用当前最强的模型试过，也只是勉强做成，那么落后四个月的模型大概率做不成。这时候省下的不是钱，是把项目做失败。

除这三条之外的任务，我们没有找到必须付前沿溢价的理由。

代价：这套算法什么时候不成立

必须把开源侧的隐性成本写清楚，否则上面那张账单表是骗人的。

价格表上的 $1.4 / $4.4 是调用 API 的价格。如果你走的是「自己部署开源权重」这条路，这个价格根本不适用——你要付的是机器、电、部署的人、出故障时排查的人，以及一件最容易被漏掉的事：兜底没有人替你做。调 API 的时候，模型出问题是对方的事；自己部署之后，模型出问题是你的事，在半夜也是你的事。

一个 744B 的模型不是装一下就能跑的东西。在决定自建之前，先把「谁来运维」这个问题落到一个具体的人名上。落不到人名，就别走这条路，账单差再大也别走。

第二个代价是上面反复提过的：四个月是平均值，不是保证。你完全可能撞上一个差距远大于四个月的任务。所以这套判断的正确用法不是「等四个月就行了」，是「先按四个月估，然后在自己的真实样本上验一遍」。没验过就上量，等于拿平均值给自己的具体业务打包票。

第三种情况是整件事都不该做：如果你一个月的模型账单还没超过做这次分档的人力成本，就先别分。按上面的算法，月一万单全用中间档也就几十美元；为了省几十美元占住两个人一周，这笔账是亏的。先把量做起来，账单变成一个需要看的数字之后，这篇文章才有用。

同系列里还有一篇把各家官方价格拉成一张表、按任务分档对应模型的，分完摞之后可以接着看。