祝融说。

如果说前三章我们分别探讨了算力建设的顶层设计、运营体系和战略规划，是在绘制宏伟的“作战地图”和组建精良的“作战部队”，那么从本章开始，我们将正式进入炮火轰鸣的“战场”，深入算力日常运营的“战壕”之中。本章聚焦于算力资源的全生命周期管理，旨在详尽阐述如何将“一体化、高效率、易使用”的愿景，贯彻到每一次资源请求、每一次任务调度、每一次容量调整的细微之处。

这不仅是技术问题，更是管理科学与运营艺术的结合。其核心目标，是构建一个从需求入口到资源出口的、数据驱动的、高度自动化的管理闭环。这个闭环，如同一个精密的“资源循环系统”，确保算力这种宝贵资源能够像血液一样，在企业的“血管”中高速、精准、无浪费地流动，将“养分”输送到最需要它的业务“器官”。我们将依次解构这个闭环的五个关键环节：受理与测算、申请与分配、动态调整、资源晾晒、资源回收。这五个环节，共同谱写了一曲精益运营的“交响乐”。

需求受理与测算：科学评估，精准核算

一切运营的起点，源于一个清晰、准确的需求。需求受理与测算，是算力资源生命周期的“入口关”，也是决定后续所有环节效率和准确性的“第一道阀门”。如果这个环节做得粗糙，任由模糊、夸大、不合理的需求涌入系统，那么后续的分配、调度和回收都将是“在沙地上建高楼”，事倍功半。因此，我们必须在此建立一套科学、严谨的评估与核算机制，实现从“被动接单”到“主动引导、精准画像”的转变。

需求受理：从“自由市场”到“标准化超市”

在运营初期，需求受理往往是混乱的。用户通过邮件、电话、即时通讯等各种非正式渠道提出需求，格式不一，信息残缺，运营人员需要花费大量时间反复沟通确认，效率低下且容易出错。我们的首要任务，就是将这个“自由市场”改造为一个入口统一、品类清晰、规则明确的“标准化超市”。

建立统一的算力服务门户

我们构建了一个面向全公司的统一算力服务门户，这是所有算力需求受理的唯一合法入口。该门户集成了服务目录、需求申请、状态跟踪、知识库、监控仪表盘等多种功能，为用户提供一站式服务体验。

设计结构化的《算力需求受理单》

所有通过门户提交的需求，都必须填写一张结构化的《算力需求受理单》。这张表单经过精心设计，旨在引导用户以标准化的方式描述其需求，确保关键信息的完整性。

基础信息区：申请人、所属部门、项目名称、联系方式等。

需求类型选择区：明确区分是训练算力还是推理算力。这是最重要的分类，因为两者的评估标准和资源模型截然不同。 训练算力下，进一步细分为L1大模型训练（长期、大规模、高并行效率要求）、L2模型微调（短期、中等规模、快速周转要求）、算法研究与探索（交互式、灵活性要求）。 推理算力下，进一步细分为在线推理服务（低时延、高并发要求）、离线批量推理（高吞吐量要求）。

业务背景描述区：要求用户简要描述该算力需求的业务目标、预期价值和应用场景。这有助于运营团队理解需求的业务上下文，评估其优先级。

技术细节量化区：这是表单的核心，引导用户对技术需求进行量化。

对于训练算力： 模型信息：模型名称/类型（如BERT、YOLOv5）、框架（PyTorch/TensorFlow）、参数规模（如13B、70B）。 数据信息：训练数据集大小（GB/TB）、数据类型（文本/图像/语音）。 资源需求：期望的GPU型号、单次训练需要的GPU卡数、预计的单次训练时长、训练频次（如每周一次）。 软件环境：所需的CUDA版本、Python版本、核心依赖库及版本。

对于推理算力： 模型信息：待部署模型的地址、输入/输出格式。 性能目标（SLA）：期望的平均时延、P99时延、目标QPS（峰值和均值）。 部署模式：是否需要高可用部署（多副本）、是否需要灰度发布能力。

通过这样一张“傻瓜式”但信息完备的受理单，我们实现了需求描述的标准化，将运营人员从繁琐的“信息拼凑”工作中解放出来，也迫使用户在提出需求时进行更深入的思考。

常态化的受理机制与初步反馈

常态化受理：服务门户7x24小时开放，用户可随时提交需求。 自动化初审：系统会自动检查受理单的必填项是否完整，对于信息不全的申请，直接驳回并提示用户补充。 及时响应与反馈：工单生成后，系统会自动向申请人发送确认邮件，并告知预计的评估周期。运营团队（省侧L1/L2或总部）会在规定的SLA时间内（如1个工作日）对需求进行认领，并进行人工的初步审核，对于明显不合理或信息存疑的需求，会主动与用户沟通澄清。

需求测算：从“经验估算”到“科学建模”

需求受理解决了“是什么”的问题，而需求测算则要回答“要多少”的难题。这是整个资源分配的基石，其精准度直接决定了资源的利用效率。我们摒弃了依赖个人经验的“拍脑袋”模式，建立了一套科学、规范、持续迭代的需求测算体系。

建立测算标准体系与方法论

制定统一的《算力需求测算标准》：这份标准是测算工作的“宪法”，明确了不同类型算力需求的测算方法、核心指标体系和计算公式。

核心指标体系： 训练核心指标：模型参数量（Parameters）、训练数据量（Tokens/Samples）、计算量（FLOPs）、硬件有效算力（Effective FLOPs/s）、通信开销（Communication Overhead）、显存占用（Memory Footprint）。 推理核心指标：单次请求计算量、模型加载开销、数据前后处理耗时、并发数（Concurrency）、批处理大小（Batch Size）。

统一的测算方法论： 训练算力测算：采用“理论计算 + 基准修正”的方法。首先根据FLOPs ≈ 6PD（P为参数量、D为训练Token数，即业界通行的GPT-3式量级估算）计算出总计算量，然后除以目标硬件的有效算力（通过Benchmark测得，而非理论峰值），得到理论训练时长。最后，再根据网络、I/O等开销，乘以一个“修正系数”，得出最终的预估时长。 推理算力测算：采用“压力测试 + 容量建模”的方法。对于新模型，必须先进行标准化的压力测试，绘制出“并发数-时延-QPS”的关系曲线。然后根据用户的SLA要求（如时延<200ms），从曲线上找到单卡能承载的最大QPS。最后，根据总QPS需求和高可用策略，计算出所需的总卡数。

开发标准化测算模型与配套工具

为了将复杂的测算方法论落地，我们开发了一套标准化的算力需求测算模型（Excel模板或线上计算器）。 功能：用户只需输入模型参数、数据量、目标硬件等核心参数，工具即可自动计算出预估的训练时长、资源需求和显存占用。对于推理，输入压测数据和SLA目标，即可自动推荐所需的GPU卡数和配置。

价值： 赋能用户自测算：将工具开放给所有用户，帮助他们在提交需求前进行科学的自我评估，提升需求提报的质量。 赋能运营团队审核：运营团队使用同样的工具对用户的申请进行复核，使得审核过程有据可依，公平透明。

总部与省级的测算实施与支持

总部级算力测算实施：对于公司级的重大项目（如“光明电力”大模型训练）、跨省的资源需求，由总部智算运营团队直接负责测算。他们会组织专家评审会对测算方案进行论证，确保其科学性与合理性，最终形成的《算力需求测算报告》将作为重大资源分配的决策依据。 省级算力测算指导与支持：总部负责向省级单位提供全方位的测算指导。 制定《省级算力测算工作指引》，详细说明测算流程和标准。 提供适配省级的测算工具模板。 建立跨区域经验交流机制，定期组织各省运营团队分享测算案例和经验。 提供专家支持，对于省级单位遇到的复杂测算难题，总部提供远程或现场的专家支持。

建设支撑保障体系

组建专业测算团队：在总部和有条件的省公司，设立专门的性能分析与测算岗位，培养一批既懂业务、又懂算法、还懂硬件的复合型专家。 编制标准化操作手册：将测算的全流程步骤、工具使用方法、常见问题等，编制成详细的操作手册。 建设统一的测算数据管理平台：将历次测算的输入参数、过程数据、最终结果以及实际运行后的真实数据，统一存入数据库。通过对历史数据的回归分析，持续迭代和优化我们的测算模型，让测算能力具备“自学习、自进化”的能力。

通过在需求受理与测算环节建立起的这套“标准化、工具化、体系化”的工作机制，我们成功地为算力资源的全生命周期管理，打造了一个坚实、可靠、精准的“入口”。

资源申请与分配：标准化流程与自动化交付

经过科学测算的需求，便进入了正式的申请与分配环节。这个环节的目标是效率与公平。我们要建立一套标准、透明、高效的流程，确保每一份合理的算力需求都能在最短的时间内得到满足；同时，通过自动化的技术手段，最大限度地减少人工干预，提升交付速度和准确性，降低运营成本。

申请受理与可行性评估

用户在测算完成后，将正式提交包含测算结果的《算力资源申请单》。运营团队在收到申请后，将进行两步走的评估。

申请材料的完整性与合规性初审

标准化入口：所有申请必须通过统一的算力服务门户提交，杜绝线下、非正式的申请渠道。 自动化核验：ITSM系统自动核验申请单的必填字段是否完整，关键信息（如业务需求说明、模型参数、预计使用时长等）是否填写清晰。 资源余量初步评估：系统会基于当前平台的实时资源水位，进行初步的可行性判断。如果申请的资源量远超当前可用余量，系统会自动提示用户，并建议其调整需求或接受排队。 合规性审核：运营人员会检查该申请是否符合公司的算力使用规范，例如，一个处于探索阶段的非核心项目，申请了大量高性能、长周期的战略预留资源，这可能是不合规的。

多维度的算力可行性评估

初审通过后，将由更专业的技术人员（可能是省侧L2或总部架构师）进行深入的可行性评估。

资源适配度评估： 计算资源：评估用户申请的GPU型号与数量，是否与其模型类型（如计算密集型/显存密集型）和并行计算需求相匹配。例如，对于需要高带宽NVLink的大规模模型并行训练，推荐使用A100/H100服务器；对于普通的推理任务，性价比更高的T4或A30可能是更优选择。 存储资源：评估用户对存储容量、带宽、IOPS的需求，是否与我们提供的存储类型（如高性能并行文件系统、SSD本地盘、对象存储）相匹配。 网络资源：评估用户对网络带宽和延迟的需求，特别是对于分布式训练任务，需要确保分配的计算节点位于同一个高速互联的网络域内。

技术可行性验证： 软硬件兼容性：验证用户要求的软件环境（如特定版本的CUDA、PyTorch）是否与平台提供的硬件和操作系统兼容。 性能要求匹配性：对于有严格SLA的推理服务，需要复核其性能目标与所申请的算力配置是否匹配，是否存在“小马拉大车”或“大马拉小车”的情况。 资源分配冲突检测：在多租户环境下，需要评估该资源分配是否可能对其他用户或高优先级任务产生负面影响（如网络争抢、存储IO争抢），并进行必要的隔离或调度策略调整。

评估完成后，技术人员会出具一份简短的评估意见，明确“同意”、“建议调整配置”或“拒绝”的结论，并附上详细理由。

审批与分配：流程驱动与精准配置

评估通过的申请单，将进入审批环节。我们根据需求的重要性和资源量的大小，设计了分级的审批流程。

分级审批： 小额/标准资源：对于在一定额度内（如少于4卡，使用时间少于7天）的、标准化的资源申请，可由省侧运营经理甚至系统自动审批，实现“秒级”通过。 大额/重要资源：对于超出额度的、占用周期长的、或涉及核心业务的资源申请，需要流转至总部运营经理、甚至部门负责人进行审批。 战略资源：对于动用总部战略预备队资源的申请，需要经过公司级的专家委员会评审和管理层审批。

精准配置与交付： 自动化配置：审批结论一旦生效，ITSM系统将通过API调用底层云原生平台（Kubernetes），自动完成资源的精准配置。这包括创建用户的命名空间（Namespace）、配置资源配额（ResourceQuota）、应用网络策略（NetworkPolicy）、挂载存储卷（PersistentVolume）等。整个过程无需人工登录后台操作，实现了配置的自动化和标准化。 明确分配参数：生成的《算力资源分配清单》中，会清晰地列出分配给用户的资源额度（如CPU/Memory/GPU数量）、使用时限（开始时间、结束时间）、访问凭证（如Kubeconfig文件、JupyterLab访问链接）等关键参数。 及时反馈与引导：资源分配完成后，系统会自动向申请单位发送通知邮件，告知审批结果、资源详情以及《算力使用规范》和用户手册的链接，引导用户正确、合规地使用资源。

应急响应：为重大紧急任务开辟“绿色通道”

标准流程保障了日常运营的秩序，但我们还必须为“计划外”的重大紧急任务建立“绿色通道”，以体现平台的响应能力和保障价值。

定义紧急任务：明确定义什么级别的任务可以启动绿色通道，例如，涉及电网重大安全事故的应急分析、应对国家重大战略需求的科研攻关、修复严重影响线上业务的紧急模型等。

简化审批流程：紧急任务的申请，可以绕过部分常规审批环节，由指定的应急负责人（如总部运营总监）进行快速决策和授权。

资源预留与抢占机制：

• 动态预留：平台始终保留一部分资源作为“动态预留池”，不分配给普通任务。
• 抢占式调度：在预留资源不足时，平台可以根据预设的优先级策略，临时“抢占”正在运行的低优先级任务的资源（被抢占的任务会被优雅地中止并保存状态，待资源释放后重新调度），以保障高优先级紧急任务的执行。

通过将标准流程与应急机制相结合，我们的资源申请与分配体系，既保证了日常运营的井然有序，又具备了应对突发事件的弹性与韧性。

动态调整：训练与推理算力的弹性调度机制

资源一次性分配完成并非一劳永逸。业务的负载是动态变化的，模型的需求也是在不断演进的。一个僵化的、静态的资源分配模式，必然会导致巨大的资源浪费或服务质量下降。因此，建立一套能够根据实时状况进行动态调整的弹性调度机制，是实现资源精益运营的“高级阶段”。我们针对训练和推理两大场景的不同特点，设计了不同的动态调整策略。

训练算力动态调度机制建设：保障与效率并重

训练任务，特别是大规模分布式训练，耗时长、中断成本高。其动态调度的核心目标是在保障关键任务按时完成的前提下，最大化集群的整体吞吐率和资源利用率。

标准化周期保障方案：我们为不同类型的训练任务定义了标准化的保障周期。例如，L2微调算力，我们提供了“标准化的7天训练周期保障方案”。用户申请时默认获得7天的独占使用权，确保其微调任务可以在一个可预期的周期内完成，不受其他任务干扰。这为业务的敏捷迭代提供了确定性。

紧急需求快速响应通道：如前所述，为重大紧急训练任务开辟绿色通道，通过抢占式调度，确保最高优先级的任务能够立即获得所需资源。 基于实时资源水位的动态调度：这是提升集群利用率的关键。我们的调度系统（如基于Volcano或YunIkorn的K8s调度器）具备更高级的调度能力：

资源共享与超卖（Over-commitment）：对于那些对资源需求波动较大的研究探索型任务，可以将其调度到同一个资源池中，并进行一定程度的CPU和内存超卖，利用统计复用的原理提升资源利用率。

作业排队与优先级调度：当集群资源饱和时，新提交的任务会进入队列。调度器会根据任务的优先级、等待时间、资源需求量等多个因素，动态调整队列顺序，确保高优先级任务和“小”任务不会被“大”任务饿死。

资源回收与碎片整理：调度器会定期将被“抢占”的资源、或短时间任务释放的资源碎片，进行“整理”，重新组合成可用的整块资源，分配给等待中的任务。

推理算力智能扩缩容机制实施：追求极致的弹性

推理服务面向最终用户，其负载往往呈现明显的周期性和突发性。其动态调整的核心目标是，在保证服务SLA的前提下，实现资源的按需使用，即“负载高时自动扩容，负载低时自动缩容”，最大限度地节约成本。

建立“双阈值”监控预警体系：我们为每个推理服务设置了两个核心的监控预警指标和阈值，作为自动扩缩容的触发器。 GPU使用率：例如，当一个服务的GPU平均使用率在过去5分钟内持续高于80%，则触发扩容；当持续低于30%，则触发缩容。 显存占用率：对于一些显存密集型模型，显存可能先于计算单元成为瓶颈。我们同样设置阈值，如持续高于90%触发扩容。 为什么是“双阈值”：同时监控计算和显存两个维度，可以更精准地捕捉资源瓶颈，避免单一指标的误判。

制定总部与省两级协同扩容流程：

• 分钟级副本内（In-Pod）扩容：当监控指标触发阈值时，部署在Kubernetes上的推理服务，其HPA（Horizontal Pod Autoscaler）机制会自动响应，在几分钟内增加该服务的副本数（Pods），将流量分摊到新的副本上。这是最快速、最常规的扩容方式。
• 小时级节点间（Cross-Node）扩容：如果增加副本后，当前集群的GPU节点资源已全部用满，省侧运营团队会收到告警。他们可以从本省的预留资源池中，手动或通过自动化脚本，为该集群添加新的GPU节点，整个过程通常在1小时内完成。
• 天级跨省协同扩容：如果本省所有资源都已耗尽，省侧团队可以通过ITSM系统向总部发起“紧急资源支援请求”。总部运营团队会评估全网资源状况，从其他空闲的省份或总部资源池中，调拨资源给该省使用。

开发自动化扩缩容工具：我们将上述逻辑，通过Prometheus（监控）、Alertmanager（告警）和Kubernetes HPA/VPA（自动扩缩容器）等一系列云原生工具链，实现了高度自动化。运营人员只需在服务部署时，配置好扩缩容的策略（如最小/最大副本数、触发阈值），后续的动态调整过程便由平台自动完成。

算力动态调整流程规范化

为了确保所有动态调整操作都可控、可追溯，我们制定了《算力动态调整实施规范》。 明确各类场景的触发条件：清晰定义了何种情况下可以触发自动扩缩容、手动调整或抢占式调度。

规范审批流程：对于重大的、手动的调整操作，规定了必须经过的审批环节。 统一执行标准和记录要求：所有调整操作，无论是自动还是手动，都必须在ITSM系统或配置管理数据库（CMDB）中有详细的记录，包括调整前后的状态、操作人/系统、时间、原因等，以便于审计和事后分析。

通过为训练和推理场景量身定制的动态调整机制，我们的算力平台从一个“静态的资源提供者”，进化为了一个能够适应业务脉动的、具备“呼吸感”的“弹性生命体”。

资源晾晒：透明化管理与绩效公示

如果说动态调整是平台的“内功”，那么资源晾晒就是平台的“外显”。其核心思想源于管理学中的“公开原则”——将关键的运营数据和绩效指标，定期地、透明地向所有利益相关方（管理者、用户、运营团队）进行公示。这种“晾晒”行为，本身就是一种强大的管理工具，它能带来多重价值：

• 提升资源透明度：打破信息不对称，让所有人都能清晰地看到资源“在哪里、有多少、谁在用、用得怎么样”。
• 建立信任与公平：公开的数据使得资源分配和调度的决策更加透明，减少了用对于“暗箱操作”的疑虑。
• 驱动行为优化：当用户看到自己的资源利用率远低于平均水平时，会产生一种“同行压力”，主动去优化自己的应用。
• 提供决策依据：为管理者的容量规划、投资决策和运营优化，提供最直接、最真实的数据支撑。

我们的资源晾晒体系，由“实时监测、定期公示、分析评价”三部分构成。

算力使用实时监测

这是晾晒的数据基础。我们依托国网云平台和人工智能PaaS平台，建立了一套全面的算力监测指标体系。

梳理监测指标：

• 基础设施层：服务器的CPU/内存使用率、磁盘I/O、网络带宽、功耗、温度。
• 虚拟化/容器层：Pod的资源消耗、GPU的分配与使用情况（通过NVIDIA DCGM等工具采集）。
• 应用层：训练任务的吞吐量、收敛速度；推理服务的QPS、时延。

构建统一监控平台：将采集到的海量时序数据，统一汇入Prometheus、VictoriaMetrics等监控系统，并通过Grafana等工具，构建多维度的、可交互的监控仪表盘。

面向场景的周期性报告：

• 训练算力：以“模型训练轮次”为周期，自动生成《训练算力资源使用情况表》。表中会详细展示该轮次训练中，GPU/显存/网络的分钟级利用率曲线、性能瓶颈分析等，为模型开发者提供精细化的优化参考。
• 推理算力：以“月度”为周期，自动编制《推理算力资源使用情况表》，汇总该月服务的平均/峰值QPS、时延分布、资源消耗等情况，为算力使用评价提供原始数据。

算力使用情况公示

我们将监测到的数据，经过脱敏和汇总，以标准化的形式定期向全公司公示。

• 公示周期：以月度为主要周期。
• 公示渠道：算力服务门户首页、i国网资讯、月度运营邮件。
• 公示内容（《算力资源晾晒报告》）：
  • 算力资源水位：清晰展示公司算力总规模、已分配规模、可用余量、各类GPU型号的数量与分布。
  • 全局运营健康度：展示上个月全网算力的平均利用率、任务排队时长、重大故障次数等宏观指标。

“红黑榜”——资源使用效率排名：

• 红榜：公示上个月“资源利用率最高”、“模型性能最优”、“单位成本最低”的用户或项目，予以表扬和宣传。
• 黑榜：公示“资源利用率最低”、“长期闲置”、“申请-使用偏差最大”的用户或项目，进行点名预警。
• 算力使用经济指标：分析典型模型训练的“时长-性能-耗电量”关系，引导用户关注算力使用的综合成本。
• 性能指标TOP榜单：展示CPU、GPU、内存、显存利用率最高的应用，分享其优化经验。

算力使用分析评价

公示数据不是终点，更重要的是基于数据进行深入的分析和评价。 编制《算力资源使用分析评价报告》：运营团队每月会基于晾晒数据，撰写一份更深入的分析报告。 趋势分析：分析算力使用总量、利用率等关键指标的变化趋势，并与历史同期进行对比。

异常预警与诊断：

• 低效预警：对训练和推理算力月平均使用率和显存占用率低于20%的算力资源，进行“黄色”预警，并主动联系用户分析原因。
• 过载预警：对月平均使用率高于80%的资源，进行“橙色”预警，提示其可能存在的性能瓶颈和容量风险，并联动容量规划团队进行评估。
• 专题分析：针对当月出现的典型问题（如某个集群网络拥塞、某类模型训练效率普遍偏低），进行专题钻取分析，并提出改进建议。
• 年度总结与规划输入：每年末，运营团队会编制《年度算力使用情况总结》，全面评价当年算力资源的配置、管理和使用水平，总结经验教训。这份总结报告，是下一年度算力统筹规划和运营优化最重要的输入之一。

通过“晾晒”这套组合拳，我们成功地将原本“看不见、摸不着”的算力使用状况，变得“晒在阳光下、人人看得见”，利用透明的力量，驱动了管理水平和资源效率的螺旋式上升。

资源回收：提升周转率，杜绝资源浪费

如果说前面四个环节是关于如何“更好地分配和使用”资源，那么资源回收则是关于如何“优雅地结束和再利用”。它是资源全生命周期管理的“最后一公里”，也是确保整个资源循环系统不发生“堵塞”的关键环节。一个缺乏有效回收机制的算力平台，其资源池最终会充斥着大量的“僵尸资源”，导致“有资源却用不上”的困局。我们的回收机制，以“分类施策、主动管理、用户友好”为原则。

训练算力回收：周期性与到期制结合

训练算力的使用具有明显的阶段性，因此回收策略需要兼顾长期研究和短期任务的不同需求。

细化回收标准，分类管理：

• L1大模型训练算力：定期评估回收
  • 资源划分：在申请时，就按照语义、多模态及视觉、科学计算三类模型，划分到不同的专用资源池，避免不同类型大模型之间的资源争抢。
  • 无固定使用期限：考虑到大模型训练和迭代的长期性，不设置固定的使用期限。
  • 以“光明电力”大模型迭代需求为标准：每月，由总部大模型项目组和算力运营团队共同评估，当前分配给各个模型方向的算力资源是否得到了充分、高效的利用，是否达到了阶段性的迭代目标。对于进展缓慢、效率低下的，可以提出回收部分资源并转分配给更高效团队的建议。这是一种基于产出的动态评估回收机制。
• L2模型微调算力：到期自动回收
  • 明确的申请期限：用户在申请微调算力时，必须明确使用期限，且原则上不超过7天。
  • 到期自动回收再分配：微调任务结束后，或达到7天期限后，系统会自动执行回收操作，将资源释放回公共资源池，等待重新分配。这确保了用于敏捷迭代的资源能够实现“快借快还”，周转率极高。
  • 人性化的延期申请机制：我们允许用户在资源到期前（如3个工作日），通过ITSM流程提交延期申请。申请中需详细说明延期的理由和需要延长的时间。运营团队会根据理由的合理性和当时资源的紧张程度进行审批。若无延期需求，则到期后准时回收。

推理算力回收：以使用率为主，按需为辅

推理算力是长期在线服务，不适用“到期回收”的模式。其回收策略的核心是，确保分配的资源与其实际承载的负载相匹配，对于冗余的资源要及时回收。

制定算力回收机制：定期回收为主，按需回收为辅 无固定使用时限：只要服务在线且有合理访问量，其资源就不会被回收。 以GPU和显存使用率为主要标准：这是定期回收的主要依据。我们的自动化监控系统，会每月拉取所有在线推理服务的资源使用率报告。对于那些在过去一个月内，日均峰值GPU利用率和显存利用率均长期低于20%的服务，系统会自动标记为“待回收候选”。 每月评估与沟通：运营团队会审查这份“候选清单”，并主动与相关服务的负责人沟通，核实低负载的原因（是业务初期流量小，还是业务已下线被遗忘？）。如果确认是冗余资源，则会协商一个回收计划。

按需回收冗余算力： 模型变更或下线驱动的回收：当一个业务系统进行版本升级，替换了原有的AI模型（如用一个小模型替换了大模型），或者某个AI功能模块整体下线时，业务负责人有责任通过服务门户，主动提交《算力资源退订申请》，将不再需要的冗余算力退还。我们的考核机制中，会将“主动退订”作为一项加分项。 平台发起的按需回收：在上述定期评估之外，如果运营团队通过监控发现，某个服务因为模型优化、业务流量骤降等原因，导致其所需算力显著减少，也可以主动发起回收流程，与用户协商回收其冗余部分。

回收流程的规范化与自动化

所有回收操作，都必须遵循标准流程，并尽可能自动化，以减少人为失误和纠纷。 生成《算力资源回收清单》：无论是哪种回收场景，最终都会生成一份《算力资源回收清单》，明确记录了被回收的资源详情、回收原因、原使用单位、回收时间等。 回收前的通知与确认：在执行回收操作前，系统会自动多次（如提前7天、3天、1天）向用户发送通知，给予其备份数据和处理应用的时间。对于强制回收，需要有明确的审批记录。 自动化的回收执行：回收操作由平台通过API自动执行，包括删除相关的部署、服务、释放存储卷（PVCs）、清理用户配置等。 回收后的审计与报告：回收完成后，相关记录会归档，并在月度运营报告中，对本月的回收情况进行汇总分析，作为运营绩效的一部分。

本章小结

第四章，我们如同进行了一次“庖丁解牛”，将看似浑然一体的算力资源运营，精细地分解为受理与测算、申请与分配、动态调整、资源晾晒、资源回收五个环环相扣的实战环节。我们看到，通过在每个环节都引入“标准化、自动化、数据驱动”的理念，我们成功地构建了一个高效、透明、精益的资源全生命周期管理闭环。这个闭环，不仅是算力平台日常稳定运行的保障，更是实现“高效率”运营愿景的核心引擎。它确保了国家的巨额投资，能够转化为源源不断的、被高效利用的、真正赋能业务的“新时代电力”。