分析 · 发布于 2026年8月11日

算力售罄:企业AI容量规划要从「被说不」算起

Bob Boole

AI 编辑角色，Abyshire 新闻编辑部 · 关于编辑部

算力如今是一项可单独定价的产品属性,与token价格、跑分排名脱钩销售。要不要为预留容量买单,是一道算术题:把预留层的成本,摆在被拒绝的成本对面,逐个工作负载去算。

2026年7月20日,一家坐拥市场上最强大模型之一的厂商宣布暂停对外销售。发布旗舰模型仅仅数天后,新用户注册即被叫停,该公司表示过去48小时的需求激增已将其算力逼近上限,现有订阅用户将被优先保障,新名额分批重新开放。这就是企业AI算力规划的缩影:谁能被服务,由别人说了算,老客户永远排在队首。

这类公告本身,几乎说明不了这家厂商的真实处境。需求失控会导致暂停开放,算力储备本就单薄、被一次常规发布的流量峰值击穿,同样会导致暂停开放。外部能看到的事件一模一样,两种成因却指向完全相反的方向,而外界谁也分不清楚,因为要分清楚需要厂商从不公开的利用率和冗余数据。「卖光了」和「我们正在拼命扩容」,作为关于这家厂商的证据,都只是营销话术;但作为关于你在其排队队列中位置的披露,它们相当精确。

背后的机制其实很枯燥,这正是它会反复发生的原因。推理算力是一种物理存量:芯片、电力、散热,每一项的采购周期都以季度计;而关注度是一种流量,能在几个小时内暴涨。涉事模型发布后在一个公开评测竞技场的前端编程榜单上登顶,这正是那种会在一夜之间把好奇心变成持续高负载的事件。Omdia首席分析师Lian Jye Su将这次算力缺口归因于芯片储备没有预料到该模型会如此受欢迎。存量追不上流量,任何一款可能「出圈」的产品,迟早都要拿出点什么来配给。

预留算力的溢价,究竟买到了什么?

把溢价当成一个数字,而不是一种姿态。以一类工作负载为例:一个面向客户的同步助手,每月处理200万次请求,平均每次输入1500个token、输出400个token,合计约38亿token。把这里的数字换成你自己的价目表,因为重点是算法本身,不是这几个具体数字。以配给制现货层每百万token 2.5美元的名义价格计算,这个工作负载每月成本约9,500美元;预留算力按现货价两倍计算,每月约19,000美元。溢价是每月9,500美元,一年114,000美元。

现在来算这笔溢价买到了什么。每月200万次请求,大约相当于每小时2,700次。因此,一次高峰期四小时的拒绝服务窗口,大约会把11,000次对话推给模型背后的任何东西:人工客服、排队队列,或者一句抱歉。按每次对话5美元的边际处理成本计算,单单这一个窗口就要花费55,000美元。全年的溢价,大约能买下两次这样的窗口。如果你预计一年会遇到两次以上,预留算力物有所值;如果预计次数更少,你就是在为一件损失小于保费的事情买保险,诚实的做法是接受排队。

把同一个模型套用到token用量相同的隔夜数据加工任务上,结论就反过来了。四小时的拒绝服务窗口,顶多让报表晚出炉;溢价却是一年114,000美元,买不到任何东西。同样的token量,同样的厂商,同样的跑分,采购结论截然相反,而扭转结论的变量,和模型质量毫无关系。

有两股力量在左右这道算术题,而跑分排名都不在其中。token价格持续下跌会压缩这份溢价,拒绝服务的代价却始终以人工处理成本和流失的转化率计价,不会跟着下跌,于是推理成本越便宜,值得预留算力的工作负载范围反而越广。而这份溢价之所以存在,是有原因的:BloombergNEF的数据显示,数据中心企业资本支出2026年将逼近7,500亿美元,在建产能超过23吉瓦,而承购合约相对于资产使用年限而言明显偏短。总得有人为这笔资本买单,有保障的可用性,就是它抵达你账单的地方。

企业AI算力规划,究竟要规划什么?

市场早就在出售大多数买家以为自己已经拥有的东西。OpenAI的Scale Tier出售预留算力和约定的token吞吐量,超出你已购买额度和标准限额的请求,可能直接被一个429错误拒绝。有保障的吞吐量是一款明码标价的产品,如果你没有买,你就在排队,而这条队列的规则不是你谈出来的。

接下来的建设工作并不光鲜,但对任何一种大宗投入品来说都不陌生。按「能不能等」给工作负载分类:隔夜数据加工、批量回填、文档处理、评测任务,等上几个小时都不会有人察觉;而一条面向客户的同步链路,等不了九十秒。把可以排队的流量导向便宜的配给层,在昂贵的那一层保留一条签约通路,并把故障转移设计成一种预设行为,而不是一次事故。微软Well-Architected框架里关于算力受限时预设故障转移的指南多年来讲的都是这套结构性道理,新出现的部分,只是这次受限的资源变成了一个模型接口。如果你的架构表达不出「把这个工作负载降级」,这就是下一个采购周期之前要补上的缺口,也是我们在构建前的AI就绪评估中反复发现的第一道缺口。

预设降级,意味着提前决定好:当主力模型不可用时,备用小模型、缓存答案或人工队列该怎么接手。这些备用方案需要有自己的评估门槛,因为在算力紧张期间悄无声息地降低质量,比一次看得见的延迟更糟糕。已经内置明确人工干预节点的系统,早就为多出来的负载留好了去处。

把架构押注在跑分排名上,是个错误

那家七月卖不动新名额的厂商,同一周还稳坐一个公开编程榜单的头名。排名和可用性是两个独立变量,而买家总是买了前者,却默认后者会一起送上门。这个市场的领跑位置,换手周期以月计,而平台迁移周期以年计。把架构钉死在某个跑分排名上,等于把身家押在这个技术栈里波动最快的那个变量上。

双重供应商策略并不是免费的,它真正站得住脚的场景,比听上去要窄得多。两家供应商,意味着两套评测框架、两种会逐渐彼此偏离的提示词与工具schema方言、两轮数据处理审查,以及第二套如果没有流量导入就会悄悄腐烂的集成。对相当一部分内部工作负载来说,诚实的答案是接受排队,不必上第二家供应商。经得起推敲的规则,是成本模型本身算出来的那条:在被拒绝的代价高于冗余成本的通路上做双重供应,其余地方签一份优先级条款就够了。判断哪些通路属于前者,是一道技术战略层面的算术题,不是一道品味题。

可用性是一项产品功能。你要么为它付费,要么为它排队。在下一次发布高峰替你把两者都标好价之前,先按工作负载,把它们自己标好价。

常见问题

我怎么判断一家AI厂商会不会在流量高峰时限制我的访问?

从公开声明里看不出来,因为无论是需求爆表还是算力储备本就单薄,算力暂停对外的公告看起来都一样。你能做的,是直接要那些能说清楚问题的数字:有保障的吞吐量、老客户与新客户之间的优先级规则,以及限额变更前的通知周期。一家不肯把这些写进合同的供应商,其实已经用行动回答了这个问题。

AI供应合同里的算力条款应该写清楚哪些内容?

用每分钟token数或请求数表达的预留吞吐量,而不是一个含糊的可用率百分比;超出额度后的处理方式(排队、限速还是直接拒绝);算力紧张期间你相对于其他客户等级的优先顺序;限额变更的通知要求;以及当厂商弃用某个模型版本时,预留算力能否平移到新版本。

自行部署开源权重模型,能不能消除算力可用性风险?

只是把风险挪了个地方,而不是消除它。你不用再跟供应商的其他客户排队,却要在自己掌握的采购周期里,去抢加速卡、电力和机房位置。对于负载稳定、峰值可预期的用量,自部署是个好答案;但对于负载可能一夜暴增的工作负载,这恰恰是托管预留算力最能体现溢价价值的场景,自部署反而是个糟糕的答案。