先给结论：悬停不是芯片还没造出来，而是算法一旦证明能用，机房里还留着一个数量级以上没吃满的算力。公开演示把可能性钉死后，项目会从百万级被推到十倍、百倍，窗口按月计。云上单价可比自建卡贵一个数量级，账上没花不等于硬件到顶。安全评估若只按当前账单做，测的是今天愿意花的钱，不是明天能动员的钱。

为什么「我们还没花那么多」不能当成能力上限

痛点是把支出当成能力。一次千亿参数级训练，算力加人力可以落在千万美元量级。大型科技公司一年的研发加资本开支是百亿美元量级。两者之间隔着两到三个数量级。中间不是物理定律，是有没有人相信「再乘一百仍然划算」。演示一出现，相信的人变多，预算委员会的问题从「可不可能」变成「哪个季度上机」。云合同还会把单价抬高：按平台租卡，每单位算力可以贵到自建卡的四十倍。用云账单外推「世界只能训这么大」，会把硬件地板错认成制度天花板。

悬停的经典图像是：你其实早就能建出远强于现网的系统，只是没人把它当成正经选项。直到有一次结果把选项打开，能力跳跃看起来像突然，其实是把已经闲着的资源一次接通。对安全评估，这意味着红线、能力测试、部署门槛如果默认「规模只在当前附近滑动」，会在接通发生时整体失效——不是模型偷学了新技能，是同一套算法突然跑在大一个数量级的机器上。

四步按「能动员的算力」而不是「已报销的算力」做门禁

1. 同时记三笔账：当前训练账单、自建加速卡的地板单价、公司或云厂商一年能调动的资本开支。第一笔是今天；后两笔才是悬停的高度。缺后两笔，就不要写「我们没有更大模型的能力」。
2. 把「算法解锁事件」写成触发器，不要写成年度规划。解锁可以是一次公开的规模跃迁、一次内部任务覆盖过半、一次单位成本跨过人力线。触发后，默认窗口是数月内出现十倍项目，而不是等下一次三年战略。
3. 安全评估按「当前规模的十倍到百倍」准备一套并行的测试，而不是等更大模型训完再发明测试。测的是同一算法家族在更长上下文、更多工具、更多并行副本下会不会跨过红线。现在做，贵在设计；事后做，贵在已经部署。
4. 把「说服持有预算的人」当成独立变量。悬停可以真实存在，同时百倍模型并不在下个月出现——因为委员会、芯片排队、数据管道都会拖。拖不是否定悬停，只说明高度和速度不是同一个数。计划要同时写：若下个月接通会怎样，若十八个月才接通会怎样。只写其中一条，会在另一条成真时没有动作。

现场有三条容易写进备忘录却很少进门禁的细节。其一，劳动力成本经常被算力数字盖住。一次训练里，人的工资可以和卡钱同量级。百倍项目不只是百倍卡，还是数据、评测、基础设施的编制。悬停高度要用「卡加人」一起估，否则会低估接通后的组织冲击。其二，张量核心和垄断云约会使「官方峰值」和「你能买到的有效峰值」差一截。做地板估算时用能实际买到的消费级或现货加速卡，不要用宣传幻灯片上的峰值。其三，算法改进本身也在造悬停：同一硬件上，更好的训练配方等于凭空多出来的卡。硬件悬停和算法悬停要分开记账，否则会把「配方进步」误写成「我们买了新集群」。

对已经在跑助手和智能体的团队，接通不一定表现为「突然冒出一个新模型名」。更常见的是：同样的基座，推理预算加两个数量级、工具从只读变成可执行、并行副本从一变成一百。对外还叫同一个版本，对内已经把闲置算力吃进去了。所以评估清单里要有「固定权重、只加推理和工具」这一档。这一档过不了，就不要假设「要等下一场训练才能跨红线」。

历史读法也要留余地。把悬停写成「几个月内必然出现百倍模型」，会被现实打脸——持有预算的人更新信念，比梯度更新慢。打脸的是速度预测，不是「账上还有一到两个数量级没动」这件事。正确的收缩是：高度仍按能动员的资本估，速度改成分布，不要改成零。速度变成零的写法，会在下一次解锁事件到来时，把同一套低估再犯一遍。

若只能改评估方案里的一项：给每个能力测试加一列「十倍推理预算或十倍并行副本后是否仍在红线内」。列是空的，就等于只测了当前账单，没测悬停。

结论：测能接通的规模，不要测已经报销的规模

悬停是闲置算力加一次算法解锁。云单价、委员会延迟、现网测试都可能把它藏起来，但它不会因为藏着就不存在。把门禁从「我们训过最大的那个」改成「我们能动员的十倍到百倍」，安全讨论才跟得上预算讨论。

你下次写能力评估，先补三行数：当前账单、自建地板、一年能调动的资本。三行写不全，就还不能说「没有更大的系统」。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源