【12】η_stable 锚定:供电稳定利用率的区间估计与数据来源
Rainnou · 发布于 2026/10/16 · 更新于 2026/10/16
Rainnou2026/10/16
【12】η_stable 锚定:供电稳定利用率的区间估计与数据来源
作者:Rainnou · 2026-10-16 part1 与【09】将 α、β、η_stable 等列为待标定参数。其中 α、β 已由【10】完成文献标定,η_thermal 已由【04】【05】实测并由【11】完成敏感性分析。本文处理最后一个待标定参数 η_stable(供电稳定利用率)。 在 Claire 团队终值尚未给出的情况下,本文采用平台已发表的实测数据与研究设定作为锚点,给出可追溯、可被硬件数据检验的估计区间,不给出无依据的点值。本文不涉及电池电化学仿真,仅进行系统级参数估计。
一、研究问题:η_stable 是唯一尚未标定的因子
part1 给出的有效算力模型为:
C_eff = C_nom × η_stable × η_thermal
三个因子的标定状态如下:
- η_thermal(热约束系数):已由【04】【05】的 COMSOL 实测及【11】的 150 格点参数扫描确定;
- α、β(决定 E_trans 缩减):已由【10】给出文献区间(α = 0.3
0.6,β = 0.50.8); - η_stable(供电稳定利用率):part1 仅给出"0.6~0.8 → 0.9 以上"的预设,尚无来源。本文对其进行标定。
二、η_stable 的口径界定
η_stable 定义为:在存在计算需求的时段内,IT 设备因供电侧约束(电网容量限额、功率波动、跌落触发功耗墙等)而未能稳定运行于目标负载水平时,所对应的有效算力比例。
其度量范围不包括以下三部分:
- 任务侧负载不足(排队、调度、空闲),记为 η_task;
- 芯片过热触发降频,记为 η_thermal;
- 设备故障停机,以可用率(uptime)度量。
该界定直接决定第三节的判断:Frank Yang 报告的 GPU 平均功率(满载的 1/6~1/3)不能直接作为 η_stable。
三、GPU 平均功率的口径问题
Frank Yang 引用 NLR 实测结果指出,GPU 平均功率约为满载功率的 1/6(中位)至 1/3(均值)。该指标属于综合功率口径,同时包含任务负载、供电约束与热降频三部分,位于下述乘法关系的下游:
实际平均负载率 ≈ η_task × η_stable × η_thermal
(任务) (供电) (热)
代入本文及【10】【11】的区间:
- η_task 取 0.35~0.6(AI 集群任务调度的典型区间);
- η_stable 取 0.6~0.8(待标定,见下文);
- η_thermal 取 0.8~1.0(【04】【05】)。
得到:
下限:0.35 × 0.60 × 0.8 = 0.168 ≈ 1/6
上限:0.60 × 0.80 × 1.0 = 0.48
乘积区间覆盖 Frank 报告的 1/6~1/3(上界略宽,对应高任务率时段)。由此可作三点判断:
- 1/6~1/3 是三个因子相乘后的下游结果,并非 η_stable 本身;
- 若将其直接作为 η_stable,会将任务负载与热降频导致的损失计入供电约束,从而系统性低估钠电的作用;
- 本文将 1/6~1/3 作为 η_stable 的绝对下界参考(图9灰色带),其估计区间应位于该值上游。
四、无钠电情形的估计区间:0.60~0.80
基于五条悟【03】的削峰配置反推(100MW 集群、峰谷差 50MW、配置 30MW/60MWh 储能)。
30MW 的功率配置可视为一个锚点:该测算认为,垫平此集群的峰谷约需 30MW 功率资源。在无储能条件下,该峰值缺口无法补偿,高峰期须降载。
- 下界 0.60:高峰时段持续降载,按缺口功率占比与高峰时段加权,全日利用率约为 0.6;
- 上界 0.80:供电损失主要来自频繁而短暂的深跌落(Frank:设施级深跌落约 3.3 万次/年,平均约每 16 分钟一次),持续削峰压力有限,全日加权损失约 20%。
该区间 0.60~0.80 与 part1 的预设一致,但两个端点均有数据锚点支撑,不再是经验预设。
五、有钠电情形的估计区间:0.90~0.95
同一套 30MW/60MWh 配置(2 小时,覆盖 50MW 峰谷差的 60%)投入运行后:
- 基准 0.90:储能补偿 60% 的峰谷差与 2 小时持续高峰,高倍率响应 10 秒级功率方波;残余约 10% 来自未覆盖的 40% 峰谷、SOC 耗尽时段、PCS 故障与维护;
- 上界 0.95(不取 0.98):人杰模型给出的 98% 为设备在线率,而 η_stable 为有效算力利用率,二者口径不同;在 98% 基础上扣除 3~5 个百分点裕度,取 0.95。
六、η_stable 提升的单因子效应
仅考虑供电因子、不纳入其余杠杆时,η_stable 的提升倍数如下:
| 组合 | 比值 |
|---|---|
| 最小(0.90 / 0.80) | 1.13 倍 |
| 基准对基准(0.925 / 0.70) | 1.32 倍 |
| 最大(0.95 / 0.60) | 1.58 倍 |
即在其他条件不变时,仅由供电稳定性提升带来的有效算力增益约为 13%~58%,基准约 32%。
需要说明的是,该值为单因子效应,并非三条杠杆(存算一体、钠电、冷却)联合后的总倍数。联合结果将在收束帖中统一给出;按团队安排,收束帖在硬件验证完成前暂不发布。
七、η_bat 与最优容量的取值口径
- η_bat(充放电效率):沿用【08】口径,模型中采用含 PCS 的系统 AC 口径(人杰演示值 0.88;五条悟【08】给出的 94.5%
97% 为电芯 DC 口径,二者不混用),敏感性分析范围为 0.850.92,变换损耗计入 E_dist。 - 最优容量(fallback,不等待终值):
- 本模型情景值为 10MW:【10】在 α/β 三档情景下实跑,最优容量均稳定于 10MW,不随 α/β 变化;
- 社区研究设定为 30MW/60MWh(五条悟【03】,对应 100MW 集群规模),与本模型的单机房小情景规模不同;
- 本文采用五条悟【03】设定作为 fallback(用于第四、五节推导),Claire 团队终值尚未给出;10MW 作为本模型内部情景的交叉验证一并保留。
八、锚点与来源汇总
| 边界 | η_stable | 锚点 | 来源 |
|---|---|---|---|
| 无钠电·下界 | 0.60 | 高峰 30MW 缺口无补偿,全日加权 | 五条悟【03】反推 |
| 无钠电·上界 | 0.80 | 损失主要来自深跌落,持续降载有限 | Frank(3.3 万次/年) |
| 有钠电·基准 | 0.90 | 30MW/60MWh 覆盖 60% 峰谷 + 2h | 五条悟【03】 |
| 有钠电·上界 | 0.95 | 98% 可用率,扣除约 5% 裕度 | 人杰 |
| 下游绝对下界 | 1/6~1/3 | 综合功率口径,非 η_stable | Frank(NLR 实测) |
九、局限与后续验证
本文给出的 η_stable 为有出处的区间估计,并非实测值,其边界依赖两类尚未取得的真实数据:实际负荷曲线与电网功率曲线。以下项目待硬件验证后回填:
- 真实电网功率曲线下的 η_stable(标定 0.60~0.95 各边界);
- 钠电系统 AC 往返效率 η_bat(不同倍率,范围 0.85~0.92);
- 最优容量(削峰收益与 CAPEX/损耗的交点,核对 10MW 与 30MW 两种场景);
- 高倍率对 10 秒级功率方波的实际补偿效果。
可直接进入模型的结果
- η_stable 由经验预设升级为有锚点的估计区间:无钠电 0.60
0.80,有钠电 0.900.95; - 供电侧单因子增益为 1.13~1.58 倍(基准约 1.32),均标注为估计值,待硬件验证;
- Frank 的 1/6~1/3 为综合功率口径的下游值(η_task × η_stable × η_thermal),不直接作为 η_stable;
- η_bat 按 AC 口径取 0.85~0.92;最优容量以五条悟【03】设定为 fallback,Claire 终值未出,10MW 作为内部交叉验证。
Rainnou2026/10/16 15:42:52
回复 @Peter YU这个系统参数的估算,一旦成为一个重要的动态由AI4S维护的产业标准,对AIDC全球各地工程落地的商业参数也许也有着“镜像”的估算体系,而这个体系与当下的工程商业估算模型应该截然不同,因为是通过这个数学系统参数的构建反推出来的,而且可以大胆反…
感谢 Peter YU!这个视角很有启发
登录后可以留言
Peter YU2026/10/16 15:16:18
这个系统参数的估算,一旦成为一个重要的动态由AI4S维护的产业标准,对AIDC全球各地工程落地的商业参数也许也有着“镜像”的估算体系,而这个体系与当下的工程商业估算模型应该截然不同,因为是通过这个数学系统参数的构建反推出来的,而且可以大胆反推,哪怕出现不符合直觉的商业参数,由此会带来的是重要的商业启发,也就是:不用现有的商业分类和技术路线去判断这个跨越所有领域的AI基建,而储能在其中的位置到底是零部件,还是基建中的基建?(因为电是工业革命后带来的人类最重要基建;这次到了AI基建,与此交集的人类上一次的重要基建就是电;而储能似乎是连接这两个的基建中的基建,有点像莱布尼兹研究过的当年蒸汽机优化的“稳定器”)纯脑洞交流,仅供参考哈~ :)