企业官网建设流程全解析

简介：这份由浪潮信息发布的《2025年中国人工智能计算力发展评估报告》共45页，面向关注AI基础设施、算力规划与产业趋势的研究者、企业技术决策者和投资分析人员，帮助其系统理解全球及中国智能算力的演进路径与落地重点。压缩包内为1个PDF文件，约4.69MB，单文件即完整报告，便于检索、引用和离线阅读。报告从生成式人工智能与规模法则切入，梳理芯片与服务器、存储与网络、液冷数据中心、边缘计算、算法模型、算力服务及行业应用等关键环节，并给出智能算力规模、智算服务市场与液冷服务器市场的预测数据。第三、四章还包含行业与地域评估排名及IDC建议，涉及DeepSeek带来的算法效率变化、开源模型趋势、企业“扩容”与“提效”并行策略等具体议题。已有180人学习，适合用来快速搭建AI算力产业分析框架，或作为方案汇报、市场研究和选型论证的参考资料。

1. 算力账本：为什么算法效率提升十倍，算力反而更紧张

2024 到 2025 年，人工智能计算力这件事上出现过一次很典型的认知反转。某开源推理模型把同等能力的训练算力压到同类稠密模型的十分之一、推理阶段的缓存数据量压掉五十倍，按直觉，卡应该更好买了、机房应该更空了；实际结果是全球人工智能服务器市场规模和本土智能算力规模预测双双被上调。这份 45 页的评估报告给出的解释只有一句：规模法则没有失效，只是从预训练挪到了后训练和推理。它不是产品资料，而是一张把芯片、服务器、存储、网络、液冷、边缘、算法、算力服务放到同一张资产负债表上的行业基线图。搞懂这张图是怎么算出来的，比记住其中任何一个数字都有用。

2. 规模法则的迁移：预训练之后，算力被花到哪去了

2.1 从堆参数到堆思考：后训练与推理的算力账

规模法则的原始形式很朴素：损失函数随参数量、数据量、计算量呈幂律下降。这条曲线的直接推论是「堆就完了」，于是过去几年行业的主线是单集群越建越大、单模型参数越来越多。到 2024 年前后，这条曲线撞上两个硬约束：高质量语料接近枯竭，单次预训练的成本已经抬到让绝大多数机构无法重复验证的量级。扩展的方向于是从「预训练堆参数」转向「后训练堆采样」——用强化学习让模型在可验证的任务上反复尝试，再用奖励信号筛选轨迹。

这不只是「换个训练方法」，它改变了硬件负载的形态。预训练是一遍数据流过去，每个 token 一次前向一次反向，矩阵乘的规模足够大，加速卡的算力利用率可以推到相当高的水平，负载特征是「算力密集、延迟不敏感、可长周期并行」。强化学习后训练则是三个阶段的循环：自回归生成大量候选轨迹、对轨迹打分、只对少量样本做参数更新。生成阶段是访存瓶颈，打分阶段要跑另一套模型或规则校验，更新阶段的有效计算量很小。同样标称 1 EFLOPS 的算力，投在后训练阶段产生的有效进展，和投在预训练阶段并不等价，两个阶段的数字不能简单相加。

推理侧的变化更直接。思维链把「一次回答」变成「先写几百上千个中间 token 再给结论」，单次请求的输出 token 数被放大一个量级，而推理算力需求的基本公式是请求数乘以单请求输出 token 数再乘以每 token 成本。前两项被「让模型多想一会儿」推高，第三项被模型压缩和缓存优化压低，两者方向相反，谁跑得快决定了总算力是涨是跌。报告给出的答案是涨：效率提升降低了单位成本，单位成本下降打开了新场景，新场景带来的请求量增长超过了单请求成本的下降幅度。这就是杰文斯悖论在算力上的复现。

2.2 Prefill 与 Decode：一次推理为什么是两种负载

把一次大模型推理拆开看，它是两个物理特征完全不同的阶段。预填充（Prefill）阶段一次性处理整个输入序列，所有输入 token 并行参与注意力计算，QKV 都是大矩阵乘，加速卡能被真正打满，属于计算密集型。解码（Decode）阶段每次只处理一个新 token，但要读出全部模型权重和全部历史键值缓存（KV Cache），计算量小、访存量巨大，属于访存密集型。

用算术强度可以把这个差距量化。解码阶段每生成一个 token，需要把全部权重从显存读一遍，做大约两倍参数量次浮点运算，算术强度只有个位数 FLOP/Byte；而一张高端加速卡的算力与显存带宽之比，平衡点往往在数百 FLOP/Byte。这意味着解码阶段即使卡满载运行，算力利用率也只有个位数百分比——不是调度没做好，是物理上喂不饱。行业里常说的「推理集群 GPU 利用率低」，很大一部分来自这个结构性原因，而不是资源浪费。

# 估算单条请求的 KV Cache 显存占用 # 决定因素不是参数量，而是层数、KV 头数、head_dim、序列长度和精度 def kv_cache_bytes(layers, kv_heads, head_dim, seq_len, batch=1, dtype_bytes=2): # 每个 token 在每一层、每个 KV 头上要存一份 K 和一份 V，共 2 份 per_token = layers * kv_heads * head_dim * 2 * dtype_bytes return per_token * seq_len * batch # 传统多头注意力：32 层、32 个 KV 头、head_dim=128、8K 上下文、FP16 print(kv_cache_bytes(32, 32, 128, 8192) / 1024**3) # 约 4.0 GiB # 换成 8 个 KV 头的分组查询注意力，KV 头数压缩 4 倍 print(kv_cache_bytes(32, 8, 128, 8192) / 1024**3) # 约 1.0 GiB # 再叠加 FP8 存储（dtype_bytes=1），同等上下文只需 0.5 GiB print(kv_cache_bytes(32, 8, 128, 8192, dtype_bytes=1) / 1024**3)

这几个数字解释了「缓存数据量降低五十倍」是怎么来的：它不是某一个单点技术，而是分组查询注意力压缩 KV 头数、精度从 FP16 降到 FP8、配合更紧凑的层结构与按需分配策略叠加出来的结果。参数量决定的是权重占多少显存，缓存决定的是「同一张卡能同时服务多少并发请求」，后者才是推理成本的真正分母。这也能解释按 token 计费里为什么会出现「缓存命中价」和「缓存未命中价」相差数倍的定价：命中意味着跳过预填充阶段的重算，直接复用已经算好的 KV，省掉的是整段输入序列的前向计算。

正因为两个阶段的资源画像相反，实操中会把它们拆到不同的资源池里，各自按最合适的并行策略和卡型部署，中间通过网络传递 KV。这就是预填充-解码解耦（P-D 解耦）的动机。代价也很明确：KV 要在池子之间搬运，对互联带宽和延迟极其敏感，一旦网络成为瓶颈，解耦省下来的时间会被传输吃掉。报告把网络架构和存储并列成独立的支撑层，原因就在这里——它们不是配套设施，而是决定解耦能不能成立的前提。

2.3 杰文斯悖论的三条传导路径

效率提升为什么没有抑制算力需求，报告给了三条传导路径，值得逐条对照现实去看。

第一条是技术普惠。开源权重加轻量化部署把使用门槛拉低，中小团队和个人开发者也能跑起来，参与者数量级的增长直接换算成请求量。第二条是场景纵深。单位 token 成本降下来之后，原先算不过账的场景开始算得过账了——客服质检、合同比对、代码补全这类高频低价值任务，只有在成本足够低时才成立。第三条是算力泛在。同一个模型能力会同时铺到数据中心、边缘节点和端侧设备三层，三层的硬件形态完全不同，需求不是替代关系而是叠加关系。

本土市场的调研数据支撑了这个判断：42% 的企业已经在大模型上做初步测试和概念验证，41% 已经制定明确的支出计划，17% 已经把生成式能力引入生产环境。企业侧未来 18 个月的首要支出方向也印证了「先补硬件」的路径依赖。

把这张表和另一组「企业应用 AI 的挑战」排名放在一起看，逻辑会更清楚：缺乏高质量可用数据 66%、投入成本过高 52%、基础计算架构存在技术局限无法大规模应用 49%、缺乏成熟可用的模型 47%、缺乏开发人才 46%、计算资源配置不足 43%。排在最前面的不是「模型不够强」，而是数据、成本、架构这三类工程问题。硬件升级排到支出首位，本质是架构局限和算力配置不足这两个约束在推着企业先补底座。

提示：把「支出方向占比」当成「技术优先级」来读会跑偏。29% 的硬件支出占比反映的是当期采购结构，不代表硬件是最关键的瓶颈，它只是最容易在预算表上立项的那一项。

3. EFLOPS 的尺子：智能算力和通用算力为什么不能直接比

3.1 FP16 与 FP64：两套口径的由来

报告里有两个经常被并排引用、但其实不可比的数据：2025 年本土智能算力规模 1,037.3 EFLOPS，通用算力规模 85.8 EFLOPS，差了 12 倍。不少人顺手解读成「AI 加速卡的总算力是 CPU 的 12 倍」，这个结论从根上就错了。

两套数字用的是两把不同的尺子。智能算力按加速卡的 FP16（半精度）相当运算能力折算，因为训练和推理的主力精度就在半精度及以下，FP16、BF16、FP8、INT8 才是实际跑业务的精度。通用算力按 CPU 的 FP64（双精度）折算，因为科学计算、工程仿真、金融风控这类场景对双精度有硬要求。单张高端加速卡的 FP16 峰值可以是单颗服务器 CPU 的 FP64 峰值的上千倍，而加速卡的保有量远小于 CPU 核数，两个效应方向相反，最后落成 12 倍这个结果。这个倍数既不能说明硬件性能差距，也不能说明投资比例。

# 把「卡数 × 单卡某精度峰值」折算成 EFLOPS # 1 EFLOPS = 1000 PFLOPS = 1e6 TFLOPS def to_eflops(cards, peak_tflops_per_card): return cards * peak_tflops_per_card / 1e6 # 同一批 10 万张卡，按 FP16 峰值 1000 TFLOPS 折算 print(to_eflops(100_000, 1000)) # 100 EFLOPS（FP16 口径） # 同一批卡如果按 FP64 峰值 30 TFLOPS 折算 print(to_eflops(100_000, 30)) # 3 EFLOPS（FP64 口径）

同一堆硬件，换个精度口径，规模数字差三十多倍。这就是为什么跨报告比较算力规模之前，必须先对齐三件事：精度口径（FP16 还是 FP64）、是否含结构化稀疏（很多标称峰值是 2:4 稀疏后的值，稠密算力只有一半）、统计范围是加速卡还是整机。第三点尤其容易翻车——按卡统计和按服务器统计，中间隔着一台机器的 CPU、内存、存储和组装成本。

3.2 Scale-up 与 Scale-out：从 8 卡到十万卡的扩张边界

报告里有一组很具体的工程数字：配备 8 块高性能加速卡的服务器可以支撑两千亿参数级别的模型训练，插卡数量扩展到 72 块时能够支撑万亿参数级别。这两个数字划出了纵向扩展（Scale-up）的现实边界——互联域内能塞下多少张卡，取决于互联拓扑和交换芯片的端口密度。

纵向扩展的价值在于通信。张量并行和数据并行里的全归约操作，通信量随并行度增长，域内带宽不够就会让卡空等。把互联域从 8 卡扩到 72 卡，本质是把「跨机通信」降级成「机内通信」，这是万亿参数模型能训起来的前提。但纵向扩展有物理上限：单机柜的供电、散热、背板走线都有天花板，这也是后文液冷成为前置约束的原因之一。

横向扩展（Scale-out）解决的是总量问题，用更多节点拼出千卡、万卡甚至十万卡集群。这条路的瓶颈不在算力，在可靠性。节点数上去之后，集群级的平均无故障间隔会按节点数线性缩短。

# 集群级故障间隔随规模线性缩短 def cluster_mtbf(node_mtbf_hours, nodes): return node_mtbf_hours / nodes # 假设单节点平均 5 万小时出一次故障，这是相当乐观的估算 for n in (1_000, 10_000, 100_000): mtbf = cluster_mtbf(50_000, n) # 一个 30 天（720 小时）的训练任务，预期会遇到多少次节点故障 print(f"{n:>6} 节点：平均 {mtbf:.1f} 小时一次故障，720 小时内约 {720/mtbf:.0f} 次")

一万节点规模下，平均五小时左右就有一次节点故障；十万节点规模下，半小时一次。一个跑三十天的大模型训练任务，如果不做容错，几乎必然中断。这正是报告强调「高效监控体系」「故障点恢复管理」「智能显存分配」的原因：有效算力不等于峰值算力乘以卡数，还要再乘上可用性和利用率两个系数。十万卡集群的理论峰值可以很漂亮，有效算力可能只有一半多一点，差额全耗在故障恢复和作业重启上。

3.3 存储与网络：被低估的木桶短板

训练中断之后要恢复，恢复的起点是检查点。检查点的大小由参数量、权重精度和优化器状态共同决定，而优化器状态往往是权重本身的数倍。

# 训练检查点体积估算 def ckpt_tb(params_b, weight_bytes=2, opt_bytes=8): # 权重按 FP16（2 字节）；Adam 的一阶、二阶动量各按 FP32（4 字节）计 return params_b * 1e9 * (weight_bytes + opt_bytes) / 1e12 print(ckpt_tb(1000)) # 万亿参数：约 10 TB print(ckpt_tb(70)) # 700 亿参数：约 0.7 TB

万亿参数模型的一个检查点就是 10 TB 量级。如果集群平均五小时出一次故障，而检查点每 30 分钟落一次盘，那么存储侧要承受的是持续的 TB 级写入吞吐，并且必须做到原子切换——写一半崩了，恢复时读到损坏的检查点，整个作业白跑。这就把分布式存储和全闪存从「配套」变成了「必需」：机械盘的随机写和元数据操作延迟撑不住这个节奏，全闪存提供的不只是带宽，还有可预测的尾延迟。

网络侧的逻辑类似。横向扩展域内的全归约通信量随参数量和并行策略增长，以太网和硅光子被反复提及，指向的是同一个诉求：在成本可接受的前提下把域内带宽密度提上去。存储和网络在报告里被单独列成一节，和芯片服务器平级，这个结构安排本身就是一种判断——算力的短板已经不在计算单元上了。

4. 130kW 的机柜：液冷为什么从可选项变成前置约束

4.1 风冷的天花板在哪

单张加速卡的功耗区间在 250W 到 700W，一台 8 卡或 16 卡的高密度服务器，整机柜功率可以到 130kW 这个量级。风冷能不能扛住，答案藏在空气的物理属性里：空气的定压比热约 1.005 kJ/(kg·K)，密度在 35 摄氏度进风时约 1.165 kg/m³。想带走多少热量，就得推多少风量。

# 用空气带走热量所需的风量：Q = m * cp * ΔT cp_air = 1.005 # 空气定压比热，kJ/(kg·K) rho_air = 1.165 # 35℃ 进风时的空气密度，kg/m3 def airflow_m3_per_s(kw, delta_t): # kw 是机柜热负荷，delta_t 是允许的进出风温差 return kw / (cp_air * delta_t * rho_air) # 传统机柜 8kW，允许 15℃ 温升 print(round(airflow_m3_per_s(8, 15), 2)) # 约 0.46 m3/s # 高密度机柜 130kW，同样 15℃ 温升 print(round(airflow_m3_per_s(130, 15), 2)) # 约 7.4 m3/s

热负荷涨了 16 倍，风量也要涨 16 倍，而风扇功耗大致随风量的三次方增长，噪声、振动、机柜内回流和热点的控制难度同步上升。所以问题不是「风冷不能给 130kW 散热」，而是「风冷的边际成本曲线在超过某个功率密度之后陡到无法接受」。业内通常把 30 到 50kW 作为风冷经济性的分水岭，超过这个区间，继续用风冷意味着要为最后那点散热能力付出不成比例的代价。液冷之所以从「可选」变成「前置约束」，是因为它换掉了传热介质：液体的比热和密度比空气高两到三个数量级，同体积能带走的热量完全不是一个量级。

4.2 液冷三条路线与 PUE 的账

液冷不是单一技术，主流分三条路线，取舍点各不相同。

冷板式是在发热最集中的部件（加速卡、CPU）上贴冷板，热量通过冷板导入一次侧管路，其余部件仍靠风冷。它的优势是改造成本低、兼容现有服务器形态、运维习惯基本不变，代价是覆盖不全，一般只能带走整机六七成到八成的热量，剩下的还得靠风。浸没式把整台服务器泡在绝缘冷却液里，热量几乎全部由液体带走，散热能力最强，但服务器形态要重新设计，运维流程、漏液检测、介质回收都要重建。喷淋式介于两者之间，工程案例相对少。

判断该选哪条，最后都会落到 PUE 和总拥有成本这两笔账上。PUE 从 1.3 降到 1.15，看着只差 0.15，放到规模上完全不是小数。

# 1000 个 130kW 机柜的年度电耗差异 it_load_kw = 1000 * 130 # 130 MW 的 IT 负载 for pue in (1.30, 1.15): total_kw = it_load_kw * pue annual_mwh = total_kw * 8760 / 1000 print(f"PUE {pue}: 总功率 {total_kw/1000:.1f} MW，年耗电 {annual_mwh:,.0f} MWh") # PUE 1.30 与 1.15 之间的年耗电差额 diff = (it_load_kw * 1.30 - it_load_kw * 1.15) * 8760 / 1000 print(f"年耗电差 {diff:,.0f} MWh")

这十几万兆瓦时的差额，按工业电价折算就是每年数千万元级的运营成本差，还没算上电力配额和机房空间的机会成本。这个量级足以让液冷的增量投资在几年内回本，这也是液冷服务器市场被看好的根本原因——报告给出的预测是 2028 年本土液冷服务器市场规模达到 105 亿美元，五年年复合增长率 48.3%，同时到 2028 年会有六成数据中心采用微电网、定制硅芯片、液体冷却和加固结构这类组合方案来应对供电和可持续性约束。

注意：液冷方案的成本对比必须算全生命周期。除了冷量分配单元、管路、二次侧换热，还要算上机房承重改造、漏液检测与保压测试、运维人员培训、介质更换与回收，以及最容易被忽略的一项——漏液导致的硬件损坏风险准备金。只比「每千瓦散热成本」，结论会严重偏向液冷。

4.3 能耗曲线背后的绿色化约束

能耗数据的斜率比绝对值更值得关注。全球人工智能数据中心的 IT 能耗（含服务器、存储和网络）2024 年约 55.1 太瓦时，2025 年增至 77.7 太瓦时，是 2023 年的两倍，2027 年预计到 146.2 太瓦时，五年年复合增长率 44.8%，五年间实现六倍增长。同期全球数据中心总能耗从约 450.9 太瓦时涨到 704.7 太瓦时，年复合增速只有个位数。

两条曲线一对比，结论很清楚：AI 数据中心占全球数据中心总能耗的比重，从 2022 年的 7.6% 升到 2027 年的 18.0%。这意味着过去行业里通用的「平均 PUE」考核口径正在失效——一个园区里如果算力负载从 10% 涨到 60%，整体 PUE 会被高密度负载拉高，但这不是运维退步，是负载结构变了。想真正评估能效，必须按负载类型分开算，把训练集群、推理集群、通用计算分区拆开考核。

报告里还提到一个有意思的思路：从「储电能」转向「储算力」，把静态储备的电力转成驱动大模型的动态算力，让算力靠近电力源头。这个转向的机制本质是把电网的调峰压力转化成算力调度的灵活性问题——电力富余时多跑批处理训练，电力紧张时降频或迁移。代价也很明确：算力跟着电力走，就要接受网络时延、数据一致性和跨地域调度的复杂度。属于典型的「用软件复杂度换能源效率」。

5. 避坑：读算力报告和做容量规划时最容易翻车的五个地方

5.1 口径类坑：精度、单位、统计范围

坑一：拿 EFLOPS 跨精度横向比。现象是得出「智能算力是通用算力的 12 倍，所以 AI 芯片性能是 CPU 的 12 倍」这类结论，然后拿去支撑采购决策。原因在于两套数字的精度口径不同、参与统计的硬件形态不同、峰值算力的定义也不同，中间还隔着是否含稀疏、是标称峰值还是实测值这两道坎。解决办法是先把三件事对齐——精度口径、是否含结构化稀疏、统计对象是加速卡还是整机——对齐之后再比，往往会发现差距主要来自统计范围而非硬件能力。

坑二：把算力规模当成可用算力。现象是按 1,037.3 EFLOPS 规划业务容量，上线后发现排队严重、实际吞吐只有预期的几分之一。原因是规模数字是装机口径，包含了未上电的、闲置的、被其他业务占用的、以及因为故障在维修的部分，而且推理负载的波动极大，峰谷比可以到好几倍。解决办法是在容量模型里引入有效算力折算系数，按「峰值 × 可用性 × 利用率」三层折算，并且在推理场景下用 P95 延迟而不是平均延迟来定容量。

坑三：用训练算力推推理成本。现象是预算做出来和实际账单差一个数量级。原因是推理成本的主变量不是参数量，而是请求数乘以输出 token 数再乘以每 token 的访存量，其中输出 token 数受思维链影响可以放大十倍，访存量受 KV Cache 策略影响可以差几倍。解决办法是把推理成本拆成预填充和���码两段分别建模：预填充按输入 token 数乘以算力单价，解码按输出 token 数乘以显存带宽单价，两段之和才是真实成本。

5.2 架构类坑：把峰值当可用、把金额当出货

坑四：把服务器市场规模当成芯片市场规模。现象是根据服务器市场金额反推加速卡出货量，算出来的数字总是偏高。原因是服务器整机价格里包含 CPU、内存、本地存储、电源、机箱、组装和维保，加速卡只是其中一部分，而且整机均价跨度极大——同样是「AI 服务器」，8 卡高配和 2 卡入门机型的价格能差一个数量级。解决办法是分层拆解：先用整机金额除以区间均价得到台数区间，再按典型卡数配置折算卡数，最后用厂商口径的加速卡出货数据做交叉校验。

坑五：只看「生成式 AI 服务器占比」这个比例，忽略它是金额口径。现象是据此判断「2028 年还有六成服务器是非生成式」，进而认为通用服务器需求稳如泰山。原因是占比是按销售额算的，生成式机型单价高，金额占比会显著高于台数占比；同时非生成式部分里有大量是存储服务器、边缘节点和推理一体机，和训练集群不是一回事。解决办法是把金额占比和台数占比分开看，再叠加负载类型（训练、微调、推理、边缘）做二维拆解，否则很容易在容量规划上做出方向性误判。

这五个坑有个共同点：都不是技术难点，而是口径和边界没对齐。报告里的数字本身是自洽的，出问题的是读者把不同口径的数字放进了同一个算式。

6. 扩容与提效：模算效率才是那道分水岭

报告最终落到一对并行的策略上：扩容和提效。这两件事经常被对立起来讨论——有人说建那么多智算中心是浪费，有人说光靠算法优化就能省下硬件。两种说法都只说对了一半。

扩容解决的是供给总量和可获得性问题。智算中心的单期规划算力已经到千 P 级，部分运营方在推万卡以上的集群部署，适度超前规划的意义在于让研究和业务扩展有可用的底座，而不是等需求来了再现建。提效解决的是单位成本问题。模型剪枝、知识蒸馏、高效架构设计、分布式计算优化，这些手段能在保持能力的前提下压缩计算量和存储需求。一个具体的量级参考是某服务器厂商的混合专家模型，用 32 个专家配合基于注意力机制的门控网络，单 token 的训练和推理算力只需要某 700 亿参数稠密模型的十九分之一。

两者是乘法关系，不是替代关系。有效供给等于扩容带来的总装机量，乘以提效带来的单位算力产出。只扩容不提效，会造出一堆利用率上不去的机房；只提效不扩容，会在需求爆发时被供给卡住。报告里提到的「算法效率提升反而推高算力需求」正是这个乘法的结果：提效把单位成本打下来，成本下降把需求拉起来，需求增长的速度超过了单位成本的下降速度，总量还是涨。

判断一份行业报告的数字靠不靠谱，我习惯做一件事：挑几组首尾年份的数据反推年复合增长率，看能不能对上。

# 用首尾年份反推 CAGR，检查报告内部数字是否自洽 def cagr(begin, end, years): return (end / begin) ** (1 / years) - 1 # 智能算力：2023 年约 414.7 EFLOPS，2028 年 2,781.9 EFLOPS，跨 5 年 print(f"{cagr(414.7, 2781.9, 5):.1%}") # 约 46.3%，与报告的 46.2% 吻合 # 通用算力：2023 年约 59.3 EFLOPS，2028 年 140.1 EFLOPS print(f"{cagr(59.3, 140.1, 5):.1%}") # 约 18.8%，与报告的 18.8% 吻合

两个数字都能对上，说明这份报告的预测模型至少内部是自洽的，首尾年份和增速三者互相咬合。反过来，如果反推出来的增速和标注值差出一大截，通常意味着中间某年的统计口径调整过，或者预测采用了分段增速——这种时候引用数据就必须注明口径，否则拿去做容量规划会系统性跑偏。

真正需要留出判断空间的是「提效」这条线的不确定性。算法创新带来的效率提升是非线性的，可能某一年突然出现一个架构层面的突破，把单位算力产出抬高一个量级；也可能连续两年都在做微调，进展缓慢。扩容的确定性高，因为建设周期和资本开支是可规划的；提效的确定性低，因为它的上限取决于研究进展。一个务实的策略是把扩容当作下限保障，把提效当作上行期权，容量规划按扩容的确定性做，成本模型按提效的乐观值做敏感性分析，两头都留出缓冲。

从那以后我每次拿到这类评估报告，第一件事不是翻结论页，而是先挑三组首尾数字反推一遍增速、把口径注释逐条读完、再把金额占比和台数占比分开列一遍，

本文还有配套的精品资源，点击获取