祝融说。

在第一章中，我们擘画了“一体化、高效率、易使用”的宏伟愿景，并提出了“五位一体”的总体建设思路。蓝图虽美，非行不至。本章将聚焦于“五位一体”中的基石——管理，深入探讨如何将顶层设计转化为可执行、可落地的运营体系。如果说算力平台是高速驰骋的“赛车”，那么运营体系就是确保赛车手、维修团队、赛事规则、后勤保障协调一致的“车队管理系统”。没有这套系统，再强悍的性能也无法转化为持续的胜利。

算力运营体系的构建，我们遵循两大核心原则：组织保障与制度先行。组织保障，回答的是“谁来干”的问题，通过构建科学的组织架构和团队，确保事有人管、责有人负；制度先行，回答的是“怎么干”的问题，通过制定明确的标准、规范和流程，为纷繁复杂的运营活动提供统一的行为准则。这两者如车之两轮、鸟之双翼，共同构成了算力平台从“建起来”到“管起来、转起来”的关键一跃。

组织保障：“总部+省侧”两级一体化运营模式

面对国家电网这样地域广阔、层级众多、业务多元的巨型企业，设计一个既能保证战略统一，又能兼顾一线灵活性；既能集中力量办大事，又能快速响应局部需求的运营组织模式，是所有工作的前提。照搬互联网公司的集中式精英团队模式，难以适应电网的条块结构和业务特点；放任各省公司“各自为政”，又会重蹈“协同孤岛”的覆辙。

经过反复论证和实践检验，我们最终确立了“总部+省侧”两级一体化运营模式。这个模式的核心思想，是在集团层面实现“统一领导、统一规划、统一标准”，同时在省级层面保证“贴近业务、快速响应、属地服务”。它不是简单的上下级关系，而是一个分工明确、能力互补、高效协同的有机生态系统。

总部智算运营团队：平台的“大脑”与“赋能中心”

总部智算运营团队，是整个算力运营体系的“大脑”和“心脏”，其定位并非事无巨细的“超级管理员”，而是规则的制定者、能力的输出者、战略的推动者和最终责任的承担者。其核心职责可以概括为“定战略、建平台、立标准、强赋能、兜底线”。

战略与规划中心 (定战略)

• 算力战略规划：负责研究分析内外部技术发展趋势和业务发展需求，牵头制定公司中长期的人工智能算力发展战略和技术路线图。
• 年度规划与预算：负责统筹汇总各单位的年度算力需求，编制公司年度的算力建设计划、扩容方案和投资预算，并对执行情况进行监督。
• 资源统筹调度：在全局视角下，对公司范围内的算力资源进行统一视图管理和宏观调度，特别是在面临重大、紧急、跨区域的算力需求时，负责制定并执行资源协同保障方案。

平台建设与技术管理中心 (建平台)

• 技术架构与选型：负责AI算力平台的总体技术架构设计，制定硬件选型、软件栈、网络架构等技术标准，确保平台的技术先进性和统一性。
• 核心平台研发与运维：负责统一的算力管理与调度平台（PaaS层）的规划、研发、迭代和运维工作。这是实现“一体化”愿景的技术核心。
• 技术创新与预研：组织力量对大模型、异构计算、算力网络等前沿技术进行跟踪、研究和试点验证，为平台的持续演进储备技术能力。

标准与流程中心 (立标准)

• 制度规范制定：这是总部团队的核心职责之一。牵头编制本书后续将详述的所有运营管理制度、标准和规范，包括但不限于《算力需求测算标准》、《算力资源分配回收办法》、《算力使用评价标准》、《服务等级协议(SLA)》等，并负责其宣贯、解释和持续修订。
• 流程设计与固化：设计标准化的运营管理流程，并推动在统一的IT服务管理系统（ITSM）中进行线上化、自动化固化，提升运营效率。

能力建设与赋能中心 (强赋能)

• 知识库建设：负责构建和维护公司级的算力运营知识库，沉淀最佳实践、技术文档、解决方案和故障处理经验，并向省侧团队和最终用户开放。
• 培训与认证：建立面向省侧运营团队和用户的培训与认证体系，定期组织技术交流、技能培训和上岗认证，持续提升全员的算力应用水平。
• 高阶技术支持 (L3 Support)：作为技术支持的最高响应级别，负责处理省侧团队无法解决的、复杂的、深层次的技术难题，如平台核心组件的Bug修复、重大性能瓶颈的诊断与优化等。

运营监控与治理中心 (兜底线)

• 全局运营监控：负责构建和运营公司级的算力资源监控“驾驶舱”，对全网的资源水位、利用率、健康度、服务SLA等核心指标进行7x24小时的实时监控和态势感知。
• 运营分析与报告：定期（按月、季、年）对全局运营数据进行深度分析，编制运营分析报告，识别共性问题、发现效率瓶颈、预警潜在风险，并向管理层和各单位进行“晾晒”，为持续的运营优化和治理决策提供数据支撑。
• 审计与合规：负责对各单位的算力使用情况进行合规性审计，确保所有行为都遵循已发布的标准和规范，防止资源滥用和违规操作。

为了履行上述职责，总部智算运营团队内部通常会设立不同的岗位角色，例如：

• 运营经理：负责整体协调和流程管理
• 平台架构师：负责技术规划和平台建设
• 产品经理：负责运营平台的需求与迭代
• 高级运维工程师：负责核心平台的稳定
• 数据分析师：负责运营数据的监控与分析
• 技术支持专家：负责高阶问题解决

这是一个精干、专业、高水平的复合型团队。

省侧智算运营团队：贴近一线的“前台”与“本地专家”

如果说总部团队是“大脑”，那么省侧智算运营团队就是连接大脑与身体各部位的“神经末梢”和“执行单元”。他们的最大优势是“贴近”，贴近一线的业务场景、贴近本地的用户、贴近具体的应用需求。其定位是本地算力服务的提供者、用户需求的代言人、总部标准在属地的落地执行者。其核心职责可以概括为“接需求、保落地、做服务、报问题、搞创新”。

本地需求管理中心 (接需求)

• 需求受理与初审：作为本地用户算力需求的统一入口，负责接收、响应各类算力申请。依据总部制定的标准，对需求的完整性、合规性及初步的合理性进行审核，驳回不合规申请，辅导用户完善申请材料。
• 需求澄清与沟通：主动与本地业务部门和开发团队沟通，深入理解其应用场景和技术细节，协助他们更精准地进行算力需求测算，充当业务语言和技术语言之间的“翻译官”。

资源落地与属地运维 (保落地)

• 本地资源管理：负责本省范围内算力基础设施的日常运维管理，包括硬件的监控、维护、故障处理等，确保本地资源池的稳定可用。
• 资源分配与执行：根据总部审批通过（或在本地权限范围内审批）的分配指令，在算力平台上为用户开通账号、配置资源、授予权限，完成资源交付的“最后一公里”。
• 标准落地执行：负责将总部发布的各项运营标准、规范和流程，在本地进行宣贯、培训和监督执行，确保全网运营步调一致。

一线技术支持与用户服务 (做服务)

• 基础技术支持 (L1/L2 Support)：作为用户问题的第一响应人，负责解决大部分日常使用中遇到的问题，如环境配置、软件安装、任务提交、权限申请、基础性能问题诊断等。他们通过电话、即时通讯、工单系统等多种渠道，为用户提供及时、有效的帮助。

• 用户培训与推广：负责在本地组织开展平台使用、AI基础知识等培训活动，推广总部的优秀案例和最佳实践，提升本地用户的应用水平。

• 用户关系管理：定期与核心用户群体进行座谈和回访，收集他们对平台的反馈、意见和建议，建立良好的合作关系。

问题上报与信息反馈 (报问题)

• 问题升级：对于超出自身能力范围（如平台级Bug、需要跨省资源协调等）的L3级别问题，负责在工单系统中进行准确描述和记录，并及时升级至总部团队，同时跟踪问题的解决进度，并向用户反馈。
• 需求与经验反馈：系统性地收集和整理本地用户的共性需求和痛点，以及在运营中总结的经验教训，定期向总部团队反馈，作为平台迭代优化和标准修订的重要输入。

属地应用创新孵化 (搞创新)

• 场景挖掘与合作：发挥贴近业务的优势，主动挖掘具有本地特色的AI应用场景，并与业务部门合作，利用算力平台进行应用的孵化和试点验证。
• 本地生态连接：可以与本地的高校、科研院所、科技企业建立联系，探索产学研合作，为本地的AI创新引入外部智慧。

省侧团队的人员构成更侧重于运维和支持能力，通常包括属地运营经理、运维工程师、技术支持工程师等角色。他们是保证总部战略和平台能力能够真正惠及一线，并产生业务价值的关键枢纽。

两级协同机制：确保一体化高效运转的“齿轮”

确立了总部和省侧的职责分工后，必须建立一套清晰、高效的协同机制，确保两级团队之间能够像精密咬合的齿轮一样顺畅运转。

• 统一的IT服务管理平台(ITSM)：这是协同的“载体”。所有的服务请求、事件报告、问题升级、变更发布，都必须通过统一的ITSM平台进行流转。这确保了所有工作都有记录、可跟踪、可度量。
• 清晰的工单流转与SLA：定义不同类型、不同优先级的工单在两级团队之间的流转路径和升级规则，并为每个环节设置明确的服务等级协议（SLA），如响应时间、解决时间等。
• 定期的沟通与例会机制：建立周/月度的运营例会制度，两级团队共同复盘近期的运营情况、讨论重大问题、同步关键信息。此外，还应建立针对重大故障或项目的即时沟通群组。
• 知识库的共建共享：总部牵头建设知识库，省侧团队既是知识的消费者，也是重要的贡献者。他们在一线解决问题的经验，经过提炼和审核后，应及时沉淀到知识库中，供全网共享。
• 统一的考核与激励体系：总部的考核侧重于平台的整体运营效率、技术先进性和战略目标的达成；省侧的考核则更侧重于本地用户的满意度、服务响应及时率和标准的落地执行情况。通过合理的指标设计，引导两级团队目标一致、同向发力。

通过这种“总部大脑+省侧触角”的组织模式和协同机制，我们成功地解决了在大型集团企业中普遍存在的“总部管得太死，一线没有活力”或“地方各自为政，集团一盘散沙”的两难困境，为构建一个既有秩序又有活力、既能统一指挥又能灵活作战的算力运营体系，提供了坚实的组织保障。

制度先行：算力运营标准与规范编制

如果说组织保障解决了“谁来干”的问题，那么制度建设则从根本上回答了“怎么干”和“干得好不好”的问题。制度是运营体系的“法律”和“度量衡”，它将模糊的管理理念转化为清晰的、可执行的行动指南，是实现算力运营从“人治”走向“法治”，从“粗放”走向“精益”的必由之路。我们围绕算力运营的全链条，重点构建了三大核心制度模块：评价标准、管理流程、人员与厂商管理。

算力使用评价标准（训练与推理）

要提升算力使用效率，首先必须能够科学地评价其使用效率。评价标准是“指挥棒”，它向所有用户清晰地传递了什么样的算力使用行为是被鼓励的，什么样的行为是需要改进的。我们深知训练和推理场景的特点截然不同，因此为其分别设计了多维度的评价体系。

训练算力使用评价标准

训练任务的特点是资源消耗大、周期性强、目标是产出高质量的模型。因此，评价标准不仅要看“用了多少”，更要看“用得好不好”、“产出如何”。

核心指标一：资源使用率

• GPU平均利用率：这是衡量计算资源是否被充分利用的最核心指标。在整个训练任务周期内，所有分配的GPU卡的算术平均利用率。低于某个阈值（如60%）则说明存在明显的I/O瓶颈、CPU瓶颈或代码效率问题，需要优化。
• GPU显存利用率：衡量显存资源的使用情况。显存利用率过低说明Batch Size设置过小或模型本身较小，造成显存浪费；过高则有OOM（Out of Memory）的风险。
• 多机通信效率（针对分布式训练）：通过NCCL All-Reduce等典型通信操作的带宽测试，评估多节点间的网络通信效率，反映了集群的横向扩展能力和训练框架的并行效率。

核心指标二：运行稳定性

• 任务成功率：提交的训练任务中，成功运行至结束的比例。高失败率可能意味着环境问题、代码Bug或资源配置不当。
• 平均无故障运行时间（MTBF）：衡量训练任务在无人为干预的情况下，能够持续稳定运行的平均时长。
• 重算率：由于硬件故障、驱逐等原因导致任务中断，需要从检查点恢复并重新计算的计算量占总计算量的比例。这个指标直接反映了平台稳定性和容错能力对训练效率的影响。

核心指标三：资源分配率

• 申请-实际使用比：用户申请的算力时长（如1000卡时）与实际任务运行消耗的算力时长的比率。这个指标用于评估用户需求预测的准确性，约束“过度申请、长期占用”的行为。
• 排队等待时间：任务从提交到开始运行的平均等待时间。这是衡量平台资源是否充足、调度策略是否合理的重要用户体验指标。

核心指标四：模型性能

• 模型收敛速度：达到目标精度（如Top-1 Accuracy）所需的训练时长或迭代步数。在同等条件下，收敛越快，说明算法和训练策略越高效，对算力的利用也越经济。
• 吞吐量：单位时间内能够处理的样本数量（如samples/sec）。这是衡量端到端训练效率的综合性指标。
• 最终模型精度：在满足业务要求的前提下，模型的各项核心指标（如准确率、召回率、mAP等）。这是评价算力投入最终产出的“金标准”。

通过这四个维度的综合评价，我们可以清晰地描绘出一个训练任务的“健康画像”，并为用户提供针对性的优化建议，例如：“您的GPU利用率较低，请检查数据加载流程”或“您的模型收敛速度慢于基线，建议尝试调整学习率策略”。

推理算力使用评价标准

推理任务的特点是7x24小时在线、实时响应、面向最终用户或业务系统。因此，其评价标准更侧重于服务的质量、效率和用户的体验。

核心指标一：资源利用率

• GPU/显存日均峰值利用率：由于推理负载通常有潮汐效应，我们更关注其在业务高峰期的资源使用情况。如果峰值利用率长期过低（如低于30%），则说明资源分配过多，存在缩容空间；如果峰值利用率长期过高（如高于80%），则说明存在性能瓶颈或容量风险，需要扩容。
• 分配率（分配-实际需求比）：与训练场景类似，用于评估为推理服务预留的资源与其真实负载的匹配程度，避免资源浪费。

核心指标二：服务访问量

• QPS/RPS（每秒查询/请求数）：衡量推理服务的处理能力和实际承载的业务量。这是评估一个推理服务价值和影响力的直接指标。
• 调用成功率：API调用请求中，成功返回结果的比例。高失败率直接影响业务连续性。

核心指标三：用户评价

• 平均时延（Latency）：从收到请求到返回结果的平均耗时。这是用户体验最关键的指标，特别是P95/P99时延，更能反映服务在极端情况下的表现。
• 吞吐量（Throughput）：在给定并发压力下，服务单位时间内能成功处理的最大请求数。
• 用户满意度/NPS：通过定期的问卷调查或服务评价功能，直接收集最终用户对推理服务效果和稳定性的主观评价。

核心指标四：成本效益

• 单位请求成本：处理单次推理请求所消耗的算力资源成本。这个指标可以横向对比不同模型、不同部署方案的经济性。
• 业务价值贡献：将推理服务的调用量与其所支撑的业务指标（如缺陷识别率提升、客服人力节省、交易成功率提升等）进行关联分析，量化其为业务带来的实际价值。

通过对训练和推理算力建立这样一套科学、量化的评价标准，我们成功地将算力使用从一个“模糊地带”转变为一个可以精确度量、持续优化的管理科学，为实现“高效率”愿景提供了核心抓手。

核心运营管理流程设计

制度的生命力在于执行，而流程则是制度执行的“轨道”。我们借鉴ITIL（信息技术基础架构库）等业界成熟的管理框架，设计了一系列标准化的核心运营管理流程，并致力于将其在ITSM平台中线上化、自动化，确保运营活动的高效、规范和可追溯。

算力资源全生命周期管理流程

这是算力运营最核心的流程，覆盖了从“出生”到“消亡”的每一个环节。

• 需求申请与测算流程：用户通过统一门户提交《算力需求申请单》，模板中包含了模型类型、参数规模、数据量、期望时长等标准化测算字段。流程驱动申请单流转至需求方主管审批，再到算力运营团队进行专业评估和测算复核。
• 资源分配与开通流程：审批通过后，流程自动触发资源分配任务。对于标准化需求，可通过与底层平台的API对接，实现资源的自动化开通和信息的自动回填。
• 动态调整流程：用户可通过变更请求流程，申请临时增加或减少资源。流程中需明确调整的理由、时长和审批权限，确保调整的合理性和可控性。
• 到期自动回收：对于有时限的资源（如微调算力），系统在到期前通过邮件、短信等方式自动提醒用户，用户可发起延期申请，否则到期后流程自动触发回收操作。
• 低效监控回收：运营平台定期扫描长期低效（如连续一个月利用率低于10%）的资源，生成“待回收建议清单”，由流程驱动通知用户确认，若在规定时间内未响应或无合理理由，则强制回收。

服务请求管理流程

处理用户日常的各类非故障类请求，如咨询、权限申请、软件安装等。

• 统一服务目录：将所有可提供的服务（如“申请JupyterLab环境”、“安装特定Python库”、“咨询模型并行方案”）标准化为服务目录项，用户按需点选即可。
• 分类与自动派单：系统根据服务目录的分类，自动将请求工单派发给对应的处理团队或个人（如L1支持、平台运维等），并启动SLA计时。

事件与问题管理流程

处理影响服务正常运行的故障和问题。

• 事件管理流程：目标是“快速恢复服务”。当监控系统告警或用户报障时，自动创建事件单。流程的核心是快速响应、诊断、提供临时解决方案（Workaround）或升级，以最短的时间恢复业务。
• 问题管理流程：目标是“根除故障原因”。对于重复发生的事件或重大事件，流程会创建一个关联的问题单。问题管理团队（通常由总部高阶工程师和厂商专家组成）将进行深入的根因分析（RCA），并制定永久性的解决方案，以防止同类事件再次发生。

变更管理流程

控制对生产环境的所有变更，如平台升级、配置修改、补丁安装等，以最小化变更带来的风险。

• 变更申请与评估：所有变更必须通过变更请求（RFC）流程提交，内容包括变更内容、理由、风险评估、回退方案、测试报告等。
• 变更咨询委员会（CAB）：设立由各相关方代表组成的CAB，对高风险的重大变更进行评审和审批。
• 变更发布与复核：在批准的变更窗口期内实施变更，并对变更结果进行验证和复核。

通过这一系列环环相扣、权责清晰的流程设计，我们将复杂的算力运营活动分解为标准化的、可控的步骤，极大地提升了运营的规范性、效率和安全性。

人员与厂商服务管理办法

人是运营体系中最核心、最活跃的因素。无论是内部的运营团队，还是外部的厂商服务团队，他们的能力和责任心直接决定了运营的质量。因此，我们制定了一套专门的管理办法，以确保“人”这个关键要素能够发挥最大效能。

算力运营人员管理办法

• 岗位与能力模型：为算力运营的各类岗位（如运营经理、运维工程师、技术支持等）定义清晰的职责说明（JD）和任职资格（能力模型），涵盖技术技能、服务意识、沟通能力等维度。
• 培训与发展体系：建立从新员工入职培训、在岗技能提升到专家级认证的职业发展路径，鼓励员工持续学习和成长。

绩效考核与激励机制：

• 制定人员评价细则：将岗位职责量化为具体的KPI指标，如工单解决率、SLA达成率、用户满意度、知识库贡献数等。
• 建立考核与奖惩标准：定期（如按季度）进行绩效评估，评估结果与薪酬、晋升、评优等直接挂钩，奖优罚劣，激发团队活力。

厂商服务质量考核管理办法

在算力平台的建设和运维中，我们不可避免地需要依赖外部厂商（硬件供应商、软件开发商、技术服务商）的支持。如何有效管理厂商，确保其服务质量满足我们的要求，是运营成功的重要一环。

明确服务范围与SLA：在采购合同和服务协议中，以法律形式清晰界定厂商的服务范围、响应级别、解决时限等SLA条款，作为考核的基准。

定厂商评价细则：

• 服务支持水平：考核指标包括故障响应及时性、问题解决能力、技术支持人员的专业度、备品备件的保障能力等。
• 服务主动性：考核厂商是否能提供主动性的健康巡检、性能优化建议、技术趋势分享等增值服务。
• 配合与协同度：考核厂商在处理复杂问题、参与联合项目时的沟通、协作和资源投入情况。

建立厂商考核与奖惩机制：

• 定期评估与打分：运营团队定期（如按季度）依据评价细则，对厂商的服务表现进行量化打分，并形成《厂商服务质量评估报告》。
• 与商务条款挂钩：将考核结果直接与服务费支付、合同续约、未来项目投标资格等商务条款挂钩。对于表现优异的厂商，可以给予“优秀合作伙伴”认证和优先合作权；对于长期不达标的厂商，则采取服务费扣罚、降低合作级别甚至终止合同等惩罚措施。

通过对内部人员和外部厂商建立起科学、严格的管理和考核体系，我们成功地构建了一个权责清晰、激励有效、质量可控的“责任共同体”，确保了整个运营体系的执行力和服务水平。

本章小结

第二章详细阐述了算力运营体系构建的两大支柱：组织保障和制度先行。通过设计“总部+省侧”两级一体化运营模式，我们解决了“谁来干”的组织问题，形成了战略统一与一线灵活兼备的强大合力。通过编制算力使用评价标准、核心运营管理流程以及人员与厂商服务管理办法，我们解决了“怎么干”和“干得好不好”的制度问题，为算力平台的高效、规范、精益运营奠定了坚实的规则基础。至此，算力运营的“四梁八柱”已然搭建完毕，为后续的算力规划、资源管理和技术支撑等具体工作的展开，铺平了道路。