祝融说。

在第二章中，我们已经为算力平台搭建了坚实的运营“骨架”——明确了组织架构和制度规范。然而，仅有高效的运营体系，如同拥有一套先进的交通管理系统，却无法决定应该修建多少车道、设计多高的时速限制。交通流量的预测与道路的规划建设，是决定整个交通系统能否承载城市发展的先决条件。同样地，算力规划与容量管理，正是决定算力平台能否支撑企业智能化转型宏图的“先手棋”和“生命线”。

本章将聚焦于“五位一体”总体建设思路中的规划维度。我们将深入探讨如何建立一套从需求洞察、科学预测到精准投资、弹性增长的全流程规划管理体系。

其核心目标是回答四个环环相扣的战略性问题：

1. 我们需要多少算力？（需求统筹）
2. 我们应该建设什么样的算力？（容量规划）
3. 我们应该如何建设和发展算力？（弹性扩容）
4. 我们如何对待已有的算力？（资源纳管）

解决好这四个问题，才能确保算力资源的投入既能满足当前和未来的业务需求，避免“资源饥饿”阻碍创新；又能最大限度地提升投资回报率（ROI），避免“过度投资”造成浪费。这是一门在不确定性中寻求最优解的科学与艺术。

需求统筹：从业务中来到业务中去

一切规划的起点，皆源于需求。算力的价值最终体现在对业务的支撑上，因此，算力规划必须深深植根于业务的土壤，遵循“从业务中来，到业务中去”的基本原则。需求统筹，正是将散落在企业各个角落的、模糊的、潜在的业务“想法”，系统性地转化为清晰的、量化的、可规划的算力“需求”的过程。这个过程如果做得粗糙，后续的规划便会成为“空中楼阁”。

需求统筹的挑战：为何“拍脑袋”不可取？

在缺乏系统性需求统筹机制的企业中，算力需求的提出和汇总往往面临诸多挑战：

需求的“碎片化”与“隐性化”：需求往往由各个业务部门或项目组独立提出，缺乏全局视角。A部门想做无人机巡检，B部门想做智能客服，C部门在探索营销数据挖掘。这些需求在提出时往往只关注自身的一亩三分地，难以形成对公司整体算力需求的完整拼图。更有大量的“隐性需求”——业务人员有痛点、有想法，但因为不了解AI技术能做什么、需要什么，而未能将其转化为明确的算力需求。

需求的“模糊性”与“不确定性”：业务部门在提出需求时，常常使用定性的描述，如“我需要很强的算力来训练一个大模型”，但对于模型的具体参数规模、训练数据量、训练周期等关键量化指标却难以提供。同时，AI项目本身具有很高的探索性和不确定性，初始阶段的需求估算可能与最终实际消耗存在巨大偏差。

需求的“潮汐性”与“周期性”：不同业务的算力需求在时间上存在显著的峰谷差异。例如，财务部门的AI应用可能在月末、季末出现高峰；科研项目则可能在项目启动初期集中进行大规模训练。如果只是简单地将各部门的峰值需求进行线性叠加，必然会导致规划结果的巨大冗余。

需求的“博弈性”：在资源有限的情况下，各部门为了确保自身项目顺利进行，往往会倾向于“夸大”需求，多报、早报，将算力需求作为一种部门间资源博弈的筹码。这为人为的“需求泡沫”埋下了隐患。

正是这些挑战，决定了需求统筹绝不能是一个简单的“收作业”式的汇总工作，而必须是一个主动的、深入的、结构化的管理过程。

构建常态化、结构化的需求统筹机制

为了应对上述挑战，我们建立了一套常态化、结构化的需求统筹机制，它由“两张表单、一次调研、一套流程”构成。

“两张表单”：实现需求的标准化采集

我们设计了两张标准化的线上表单，作为需求收集的统一入口，旨在引导和规范用户如何提出需求。

《中长期算力需求规划表》：

• 采集周期：每年两次（年中和年末），用于支撑年度规划和预算。
• 采集对象：面向各省公司、总部各部门的规划或技术负责人。
• 核心内容：要求填报未来1-3年内，本单位计划开展或深化的人工智能应用项目清单。对于每个项目，需提供：
• 业务背景：项目的业务目标、预期价值、所处阶段（探索、试点、推广）。
• 应用场景描述：具体是用于图像识别、自然语言处理、预测分析还是其他。
• 技术方案初步构想：计划采用的模型类型（如YOLO、BERT、Transformer）、大致的参数规模（如亿级、十亿级、百亿级）、训练数据来源与体量（TB级、PB级）。
• 算力需求估算：区分训练算力（预计需要的GPU卡数、训练时长、频次）和推理算力（预计的QPS峰值、服务数量）。表单中会提供不同场景的算力估算参考模板和辅助计算工具，帮助用户进行初步量化。
• 时间计划：项目预计的启动、上线时间。

《临时/紧急算力需求申请表》：

• 采集周期：按需、即时。
• 采集对象：面向所有项目负责人或开发者。
• 核心内容：聚焦于短期、具体的算力需求，其颗粒度更细。除了上述技术方案细节外，更强调：
  • 需求的紧迫性与理由。
  • 明确的资源需求清单：如“需要8张A100 GPU，独占使用7天，需要XX TB的高速存储空间”。
  • 明确的交付时间要求。

通过这两张表单，我们将原本模糊、定性的业务想法，引导、转化为结构化的、半量化的技术需求描述，为后续的分析和规划奠定了数据基础。

“一次调研”：从被动接收到主动挖掘

仅靠线上表单，仍然可能遗漏大量的“隐性需求”。因此，我们每年至少组织一次由总部智算运营团队牵头的、深入一线的“AI应用与算力需求”专项调研。

调研形式：采用“线上问卷普查 + 线下访谈深挖”相结合的方式。

调研内容： 普查现有应用：全面盘点各单位当前已上线或正在开发的人工智能应用现状，包括其技术架构、资源使用情况、遇到的瓶颈等。这不仅是为了收集需求，更是对现有算力使用情况的一次“摸底”，即“指导需求提报”的关键环节。我们会将各单位的《算力资源使用分析报告》（由运营平台生成）作为访谈的输入，与用户共同分析其资源利用率的合理性，纠正其在需求提报中的偏差。

挖掘潜在需求：与各核心业务部门（如调度、运检、营销、安监等）的业务专家进行深度访谈，向他们普及AI技术的最新能力和应用案例，共同探讨“AI能为我们解决什么新问题？”“哪些老大难的业务痛点，现在有了新的技术解法？”。这个过程是主动的“需求激发”，将业务痛点转化为未来的AI项目和算力需求。

收集反馈与建议：听取一线用户对现有算力平台和服务的意见和建议，作为平台优化和规划调整的重要参考。

“一套流程”：确保统筹工作的闭环与权威

• 定期发布与宣贯：总部定期（如每季度）发布《算力需求统筹工作通知》，明确本轮需求收集的时间、范围、要求和填报入口，形成稳定的工作节奏。

• 分级审核与汇总：省侧运营团队负责对本单位的需求进行初步的收集、审核和汇总，确保信息的准确性和完整性，然后统一上报至总部。

• 总部集中评审与确认：总部智算运营团队会同相关业务和技术专家，组织召开需求评审会，对上报的重大需求进行集中评审，评估其业务必要性、技术可行性和需求的合理性，剔除“水分”，识别重点。

• 形成统一需求清单：评审通过后，形成公司级的《算力需求资源汇总表》。这份清单不仅是算力总量规划的依据，更是后续资源分配优先级的参考。

• 反馈与沟通：将评审结果向各需求单位进行反馈，对于未获通过或被调整的需求，需给出明确的理由和建议。

通过这套“从业务中来”的系统性方法，我们得以描绘出一幅全面、真实、动态的公司AI应用“热力图”和算力需求“走势图”，为“到业务中去”的科学规划，提供了坚实可靠的输入。

容量规划：科学预测与精准投资

需求统筹回答了“我们需要什么”，而容量规划则要回答“我们应该建设什么”以及“需要投入多少”。这是一个将业务需求语言“翻译”成技术配置语言和财务预算语言的复杂过程。其核心挑战在于，如何在技术快速迭代、需求动态变化的不确定性中，做出相对最优的规划决策，实现技术先进性、业务匹配度和投资经济性的平衡。

容量规划的方法论：从需求到配置的“翻译”艺术

我们的容量规划并非简单的线性叠加，而是一套多维度、多层次的综合评估方法。

需求分类与优先级排序

首先，我们将统筹到的海量需求，依据其性质和成熟度进行分类和排序。

• 按业务关键性：分为核心关键业务（如电网安全稳定分析）、重要业务（如营销反窃电）、一般业务。
• 按项目成熟度：分为已上线推广应用、试点验证阶段应用、预研探索阶段应用。
• 按算力类型：明确区分训练算力和推理算力。通常，训练算力对单卡性能、并行计算效率要求高，可以容忍一定的排队；而推理算力对时延、并发处理能力要求高，需要保证服务的实时性。

基于上述分类，我们为每个需求赋予一个优先级。例如，一个已上线的、涉及电网安全的核心业务的推理算力扩容需求，其优先级必然高于一个处于预研阶段的非核心业务的训练算力需求。这个优先级排序，是后续资源倾斜和投资决策的基础。

算力基准测试与选型

“卡时”或“FLOPS”只是算力的理论峰值，不同架构、不同型号的GPU在运行真实AI任务时，其有效算力差异巨大。因此，在进行大规模采购和规划前，建立一套标准的算力基准测试体系至关重要。

• 建立典型模型库：我们会选取在公司内部应用最广泛、最具有代表性的几类AI模型（如输电领域的YOLOv5/v7、营销领域的BERT、调度领域的GNN等），构成我们的“基准模型库”。

• 进行横向性能评测：我们会定期获取业界主流GPU厂商的最新产品，在统一的软硬件环境下，使用基准模型库对这些GPU进行横向的性能评测，重点关注训练吞吐量、推理时延、能效比（性能/瓦特）等关键指标。

• 形成《算力选型指导白皮书》：基于评测结果，结合采购成本、供应链安全、生态成熟度等因素，我们会形成一份动态更新的《算力选型指导白皮书》，为总部及各单位的采购提供科学、客观的决策依据，避免盲目追新或被单一厂商绑定。

算力需求折算与量化

这是容量规划中最核心、技术性最强的一步。我们需要将上游的业务需求，精准地“翻译”为下游的软硬件配置清单。

训练算力折算：

• 公式化估算：我们建立了一套基于模型参数和训练数据量的估算模型。例如，对于类GPT的稠密Transformer模型，业界通行的经验估算（可追溯至OpenAI关于GPT-3训练算力的分析，即总算力约为6 × 模型参数量 × 训练数据Token数）给出了其训练所需总算力的量级。根据这个公式，结合目标训练周期，就可以倒推出所需的GPU卡数和型号（基于其有效FLOPS性能）。该公式为量级估算而非精确预测，对MoE等新架构需另行修正。
• 经验性对标：对于一些成熟的应用场景，我们会参考业界或内部已有的最佳实践。例如，“训练一个百亿参数的BERT模型，使用8张A100，大概需要XX天”。
• 预留冗余：考虑到算法优化、模型重试等不确定性，我们通常会在估算结果的基础上，增加15%-30%的冗余量。

推理算力折算：

• 压力测试法：这是最可靠的方法。我们会将被部署的模型在基准测试环境中进行压力测试，测量出在满足业务SLA（如P99时延<100ms）的前提下，单张GPU卡能承载的最大QPS。
• 需求与能力的匹配：根据业务部门提出的总QPS需求，除以单卡的QPS承载能力，即可得出所需的GPU卡数。同样，需要考虑高可用（如N+1冗余）和未来的业务增长，预留一定的容量Buffer。

配套资源折算：

• 存储规划：根据训练数据、模型文件、日志等的体量和性能要求，规划需要配置的高性能并行文件系统（用于训练）、对象存储（用于数据归档）和本地SSD（用于推理缓存）的容量和带宽。
• 网络规划：训练集群的网络（特别是多机多卡训练）是性能的关键。我们需要根据集群规模和GPU的通信带宽，规划计算网络（如InfiniBand或RoCE）的拓扑结构和带宽。同时，还需规划存储网络和管理网络。

形成标准化的规划产出

经过上述一系列科学的分析与折算，最终我们将形成两份核心的规划产出文件，用以指导总分部的投资和建设。

《算力规划标准》

这是一份纲领性的文件，它不涉及具体的软硬件清单，而是定义了公司在算力规划和建设中应遵循的原则、标准和方法。 技术路线原则：例如，坚持开放架构、拥抱云原生、训练与推理资源池物理隔离但逻辑统一等。

• 配置标准：定义不同规模、不同等级的智算中心的标准配置模型（如最小建设单元、GPU与CPU的配比、存算比、网络收敛比等），供各单位参考。
• 成本度量模型：定义公司统一的TCO（总体拥有成本）测算模型，包含硬件采购、软件许可、机房、电费、人力运维等全部成本要素。

《算力规划软硬件清单》及投资费用明细

这是一份具体的可执行清单，是年度预算和采购的直接依据。分单位、分项目列出：详细列出未来一个财年内，总部及各省公司，为了支撑哪些具体项目，需要新增或扩容的算力资源。

• 详细的软硬件配置：
• 计算服务器：型号、CPU配置、内存、本地存储、GPU型号与数量。
• 存储设备：类型（分布式文件存储/对象存储）、容量、带宽、IOPS。
• 网络设备：交换机型号、端口速率、数量。
• 配套软件：操作系统、虚拟化软件、容器平台、调度软件、AI框架、监控工具等的许可费用。
• 明确的投资费用明细：为每一项软硬件列出预估的采购单价、数量和总价，并汇总形成各单位乃至全公司的年度算力投资总预算。这份清单将作为向公司财经部门申请预算的核心材料。

通过这套从定性到定量、从业务到技术的科学规划方法，我们确保了每一笔算力投资都“师出有名、心中有数”，实现了“好钢用在刀刃上”的精准投资目标。

弹性扩容：适度超前与快速响应

市场和技术都在加速变化，任何一次性的、静态的规划都无法一劳永逸。弹性扩容，正是为应对这种不确定性而设计的动态调整机制。它追求的是一种平衡艺术：既要“适度超前”，为未来的业务爆发预留空间，避免在机会来临时因资源不足而错失良机；又要“快速响应”，在计划外的紧急需求出现时，能够有条不紊、高效地完成资源扩容。

“适度超前”的策略：建立资源水位警戒线

完全按需扩容（Just-in-Time）在硬件采购周期长、部署复杂的算力领域并不可行。我们必须建立一套基于资源水位的预警和扩容触发机制。

定义资源水位模型：我们将整个公司的逻辑算力资源池看作一个“水库”。“总容量”是水库的设计库容，“已分配容量”是当前的水位。我们定义了几个关键的警戒水位线：

• 安全水位（如70%）：当已分配容量达到总容量的70%时，系统触发“黄色预警”。此时，应启动下一轮的常规扩容规划和预算申请流程。
• 危险水位（如85%）：当水位达到85%时，系统触发“橙色预警”。此时，常规扩容流程必须加速，同时需要开始评估动用预留资源或采用临时性解决方案。
• 极限水位（如95%）：触发“红色预警”。表明资源即将耗尽，可能会影响新业务的受理。此时必须启动应急扩容预案。

总部算力资源储备：为了应对全网性的突发需求和战略性任务，总部智算中心在规划时，会有意识地储备一部分未分配的“战略预备队”算力资源。这部分资源平时不分配给日常业务，只在出现重大紧急情况时，由总部统一决策启用。

“快速响应”的机制：标准化流程与问题驱动

当扩容需求（无论是计划内的还是紧急的）明确后，必须有一套高效的机制来保障其快速、顺利地落地。

制定《算力扩容标准流程》：我们将扩容过程分解为一系列标准化的阶段和任务，并明确每个环节的责任部门、输入输出和时间节点。

• 阶段一：技术方案设计（算力运营团队、架构师）
• 阶段二：采购与招标（物资采购部门）
• 阶段三：机房准备与工勘（基础设施运维部门）
• 阶段四：设备到货与上架（厂商、运维团队）
• 阶段五：系统安装与部署（运维团队）
• 阶段六：联调与压力测试（运维团队、厂商）
• 阶段七：验收与资源入池（运营团队）

通过将流程标准化，可以实现多项任务的并行推进，并能清晰地跟踪整个扩容项目的进度。

编制《算力扩容指导手册》与典型方案：为了帮助缺乏经验的省公司能够高效率、高质量地完成扩容，总部牵头编制了《算力扩容指导手册》。手册中不仅包含了标准流程，还提供了针对不同规模（如一个机柜、一个集群）的典型扩容方案，包括推荐的硬件配置、网络拓扑图、部署脚本、测试用例等。这如同提供了“装修样板间”，各单位可以“拎包入住”或在此基础上稍作修改，大大降低了扩容的技术门槛和实施周期。

建立扩容问题协同解决机制：扩容过程中不可避免会遇到各种问题，如设备兼容性、软件Bug、性能不达标等。我们建立了以《扩容问题清单汇总表》为核心的协同机制。 问题驱动：所有在扩容中遇到的问题，都必须记录在该清单中，明确问题描述、责任方（厂商/内部团队）、优先级和期望解决时间。 定期“会诊”：总部智算运营团队定期（如每周）组织召开扩容协调会，邀请所有相关的内部团队和厂商参加，逐项过堂问题清单中的open items，协调资源，明确行动计划，推动问题解决。 闭环管理：问题解决后，需要在清单中记录解决方案和验证结果，形成闭环。这些记录也成为知识库的重要组成部分。

通过“适度超前”的预警机制和“快速响应”的标准化执行体系，我们将算力扩容从一种被动的、救火式的应急响应，转变为一种主动的、有计划的、可控的工程管理活动。

资源纳管：实现存量资产的统一与集约

在任何一家大型企业的智能化转型过程中，都不可避免地会存在大量的“历史遗留”算力资产。这些资产可能是在统一规划前，由不同部门、不同项目、在不同时期采购的，它们品牌各异、架构不同、标准不一，像散落的“珍珠”，无法形成合力。资源纳管，就是将这些散落的“珍珠”串联起来，进行统一的“盘点、评估、接入、改造”，最终融入一体化资源池的过程。这是一项复杂但价值巨大的“存量改革”工作。

存量之困：为何必须进行纳管？

• 资源浪费：存量资源往往与其原有的特定项目绑定，项目结束后或负载降低后，这些资源便被闲置，但其他部门却无法使用。
• 管理成本高：每一处存量资源都需要独立的运维团队、监控系统和管理流程，人力和管理成本居高不下。
• 技术孤岛：异构的技术栈使得应用和数据难以在不同资源池之间迁移和共享，阻碍了协同创新。
• 安全风险：缺乏统一的安全基线和管理策略，这些“游离”的资产可能成为企业信息安全的短板。

因此，对存量资源进行纳管，是实现“一体化”愿景、提升整体资源利用率、降低TCO的必然选择。

纳管之路：分步实施，从易到难

资源纳管是一项系统工程，不能一蹴而就。我们制定了“全面调研、制定标准、分批接入、持续优化”的四步走工作计划。

第一步：全面调研，摸清家底

我们首先需要对全公司的存量AI算力资源进行一次彻底的“人口普查”。

梳理现状：通过问卷、访谈、自动化扫描等多种手段，全面收集各单位存量资源的详细信息，包括：

• 硬件信息：服务器厂商型号、CPU/内存/磁盘配置、GPU型号/数量/显存。
• 软件信息：操作系统、虚拟化技术、容器平台、AI框架版本。
• 网络信息：网络架构、带宽。
• 管理信息：归属部门、运维负责人、承载的核心应用、当前负载情况。

形成《算力资源调研分析报告》：将调研数据进行汇总和分析，形成一份全局的存量资源视图。报告中会指出当前存量资源的总量、分布、利用率状况、技术架构的碎片化程度以及纳管将面临的主要挑战和机遇。

第二步：制定标准，明确路径

基于调研结果，我们需要制定清晰的《算力纳管标准及工作计划》。

定义纳管的技术标准：

• 最低硬件要求：定义能够被纳管的最低硬件配置标准，对于过于老旧、性能过低的设备，可能建议直接淘汰。
• 统一的操作系统与内核版本。
• 统一的容器化底座：明确要求所有被纳管的计算节点都必须安装统一版本的Docker/Containerd和Kubernetes Agent（Kubelet）。
• 统一的GPU驱动与设备插件：要求安装NVIDIA GPU Operator等统一的设备管理插件，以便K8s能够识别和调度GPU。

设计多种纳管模式：

• 完全纳管（Full Control）：对于符合标准的、负载较低的资源，可以进行重装和标准化改造，完全融入总部的统一Kubernetes集群，实现资源的统一调度。这是最理想的模式。
• 联邦纳管（Federation）：对于一些有特殊安全要求或无法完全标准化的存量集群，可以通过K8s Federation或类似技术，在保留其独立性的同时，实现逻辑上的统一管理和任务的跨集群分发。
• 监控纳管（Monitoring Only）：对于一些老旧或异构到无法改造的资源，最低限度是将其核心监控指标（如GPU利用率）统一接入总部的监控平台，至少实现“看得见”，为后续的淘汰和替换提供数据依据。

制定工作计划：根据各单位存量资源的状况和改造难度，制定一个分批次、分阶段的纳管工作计划，明确每个阶段的目标、责任单位和时间表，做到“成熟一批，纳管一批”。

第三步：分批接入，稳妥推进

按照工作计划，与各相关单位成立联合工作组，稳步推进纳管实施。

• 应用迁移评估：在纳管前，需要对承载在存量资源上的应用进行评估，制定详细的迁移或改造方案，确保业务的平稳过渡。
• 标准化改造：由总部提供标准化的部署脚本和工具，指导或协助各单位完成操作系统的重装、容器化底座的部署等改造工作。
• 接入验证：节点改造完成后，将其加入统一集群，并进行一系列的功能和性能验证测试，确保其符合预期。

第四步：持续优化，发挥价值

纳管不是终点，而是新生的开始。被纳管的资源融入统一资源池后，将与其他资源一样，接受统一的运营管理和调度，其使用效率和价值将得到极大提升。同时，我们也会持续跟踪这些被纳管节点的运行状况，并根据技术发展，对其进行持续的优化和升级。

本章小结

第三章完整地阐述了算力规划与容量管理的全貌。我们从需求统筹出发，通过系统化的机制确保规划的输入真实、全面；继而通过科学的容量规划方法，将业务需求精准地转化为技术配置和投资预算；然后，我们设计了弹性扩容体系，以应对未来的不确定性；最后，我们通过资源纳管，盘活了存量资产。这四个环节，共同构成了一个从战略到执行、从增量到存量的闭环管理体系，它确保了国家电网的算力“动脉”能够随着智能化业务的“心脏”而同步强健、协同脉动，为整个企业的数字化转型，提供了源源不断的核心动力。