算力运营管理 · 让每一张卡都发挥价值
面向读者：AI平台运营负责人、IT基础设施管理者、FinOps（算力财务运营）团队
核心问题：如何提升算力利用率、管理多团队、核算成本，让算力投入产出最大化？
为什么需要"算力运营管理"
买了算力只是开始，运营好算力才是核心。大量企业的AI算力存在以下问题：
- 利用率低：平均GPU/NPU利用率不足30%，大量算力闲置
- 分配不均：部分团队算力不够用，部分团队占着不用
- 成本不透明：不知道谁用了多少算力，花了多少钱
- 运维粗放：缺乏监控和调度，资源碎片化严重
算力运营管理的本质是把算力当作一种资源来经营，就像云计算的FinOps（Financial Operations）一样，实现算力的精细化管理。
一张Atlas 800T A2服务器（8卡昇腾910B）的年化成本（折旧+电费+运维）约20-30万元。如果利用率从30%提升到70%，相当于不增加投入的情况下多出近一半的算力。
核心指标体系
算力运营四大核心指标
| 指标 | 定义 | 计算公式 | 健康值 | 告警值 |
|---|---|---|---|---|
| 利用率 | 算力实际被使用的比例 | 已用算力 / 总算力 × 100% | ≥ 70% | < 40% |
| 闲置率 | 算力完全未被使用的比例 | 闲置算力 / 总算力 × 100% | ≤ 15% | > 30% |
| 碎片率 | 因分配不连续导致的浪费比例 | 碎片浪费算力 / 总算力 × 100% | ≤ 10% | > 20% |
| ROI | 算力投入产出比 | (业务收益 - 算力成本) / 算力成本 × 100% | ≥ 200% | < 100% |
指标详解
利用率（Utilization Rate）
利用率是最核心的指标，但需要分层理解：
| 层级 | 定义 | 监控方式 |
|---|---|---|
| 芯片利用率 | NPU芯片的计算单元实际使用比例 | npu-smi info 查看AI Core使用率 |
| 显存利用率 | NPU显存占用比例 | npu-smi info 查看HBM使用率 |
| 时间利用率 | 算力在时间维度上的使用比例 | 作业调度系统统计运行时长 |
| 综合利用率 | 加权综合评估 | 芯片利用率 × 时间利用率 |
注意：芯片利用率高不代表效率高。如果一个任务占了8张卡但每张卡只用10%算力，综合利用率实际很低。这就是为什么需要vNPU虚拟化分片。
闲置率（Idle Rate）
闲置率关注的是"有没有被使用"，与利用率关注"使用了多少"不同：
- 闲置 = 算力既没被分配也没被使用
- 低利用 = 算力被分配了但使用效率低
闲置的常见原因：
- 团队项目结束但未释放资源
- 预留资源未及时使用
- 硬件故障未及时修复
- 环境搭建中但未运行任务
碎片率（Fragmentation Rate）
碎片率是指因资源分配不连续导致的浪费：
示例：一台8卡服务器已分配5张卡给任务A，剩余3张卡。如果下一个任务B需要4张卡，这3张卡无法满足，造成碎片。
碎片率 = 碎片卡数 / 总卡数
降低碎片率的策略：
- 任务打包（多个小任务共享一台服务器）
- 弹性分配（允许任务使用不连续的卡）
- 定期整理（合并碎片资源）
ROI（Return on Investment）
算力ROI需要从业务视角衡量：
算力ROI = (业务增量价值 - 算力总成本) / 算力总成本 × 100%
算力总成本 = 折旧 + 电费 + 软件 + 运维 + 场地运营管理框架
算力运营管理五层模型
┌─────────────────────────────────────────┐
│ 第五层：价值运营 │
│ ROI分析 · 成本分摊 · 业务赋能 │
├─────────────────────────────────────────┤
│ 第四层：成本管理 │
│ 计费体系 · Chargeback · TCO分析 │
├─────────────────────────────────────────┤
│ 第三层：调度管理 │
│ 作业调度 · 资源池化 · 公平分配 │
├─────────────────────────────────────────┤
│ 第二层：监控管理 │
│ 利用率监控 · 告警 · 容量规划 │
├─────────────────────────────────────────┤
│ 第一层：基础设施 │
│ 硬件管理 · 环境运维 · 网络存储 │
└─────────────────────────────────────────┘各层职责与工具
| 层级 | 核心职责 | 推荐工具/方案 |
|---|---|---|
| 基础设施 | 硬件运维、环境管理 | npu-smi、Atlas硬件管理、Ansible批量部署 |
| 监控管理 | 资源监控、性能告警 | Prometheus + Grafana、npu-smi采集 |
| 调度管理 | 作业调度、资源分配 | Slurm、KubeSphere + Volcano |
| 成本管理 | 计费核算、成本分析 | 自研计费系统、Chargeback报表 |
| 价值运营 | ROI分析、业务赋能 | BI看板、运营报告 |
运营管理核心流程
1. 资源申请与分配流程
团队提交算力申请
↓
需求评估（场景/模型/周期/卡数）
↓
容量评估（现有资源是否充足）
↓
├── 充足 → 分配资源 → 开通环境
└── 不足 → 排队等待 / 资源回收 / 扩容评估
↓
资源使用监控（利用率跟踪）
↓
使用结束 → 资源回收 → 归档统计2. 日常运营巡检流程
| 巡检项 | 频率 | 关注点 | 工具 |
|---|---|---|---|
| 硬件健康 | 每日 | NPU状态、温度、故障告警 | npu-smi info |
| 利用率 | 每日 | 整体/分团队利用率趋势 | Grafana看板 |
| 作业状态 | 每日 | 运行/排队/异常作业 | Slurm squeue |
| 存储使用 | 每周 | 存储空间、I/O性能 | 系统监控 |
| 成本统计 | 每周 | 各团队卡时消耗 | 计费系统 |
| 容量规划 | 每月 | 资源使用趋势、扩容需求 | 容量规划报表 |
3. 资源回收流程
定期回收机制：
- 连续闲置 > 7天的已分配资源，通知团队确认
- 连续闲置 > 14天的资源，自动回收
- 项目结束的资源，72小时内回收
回收操作：
bash
# 查看空闲资源
npu-smi info
# Slurm中回收空闲分区资源
scontrol update partition=team_a state=down
# K8s中缩容
kubectl scale deployment <app> --replicas=0运营管理成熟度模型
帮助企业评估自身算力运营水平：
| 等级 | 特征 | 利用率 | 成本透明 | 调度能力 |
|---|---|---|---|---|
| L1 初始级 | 手动分配，无监控 | < 30% | 无 | 无 |
| L2 基础级 | 有基本监控，手动调度 | 30-50% | 部分 | 基础 |
| L3 规范级 | 自动调度，成本核算 | 50-70% | 较全 | 较好 |
| L4 优化级 | 智能调度，精细计费 | 70-85% | 完整 | 强 |
| L5 卓越级 | 自适应调度，价值驱动 | > 85% | 精细 | 智能预测 |
各等级提升路径
L1 → L2：建设监控体系
- 部署npu-smi采集 + Prometheus + Grafana
- 建立利用率日报/周报
- 实现资源分配登记
L2 → L3：引入调度系统
- 部署Slurm或KubeSphere + Volcano
- 建立作业排队和调度机制
- 启动成本核算（卡时统计）
L3 → L4：精细化运营
- 启用vNPU虚拟化分片
- 实施Chargeback计费
- 建立资源回收机制
- 实施公平调度策略
L4 → L5：智能化运营
- AI预测算力需求
- 自动弹性伸缩
- 基于价值的最优调度
- 算力市场（团队间算力交易）
运营管理导航
| 主题 | 文档 | 核心内容 |
|---|---|---|
| 利用率监控与优化 | 利用率优化 | 利用率定义、低效分析、优化策略 |
| 多团队调度 | 调度管理 | Slurm、KubeSphere、vNPU、公平调度 |
| 成本核算 | 成本核算与计费 | 计费模型、Chargeback、TCO框架 |
| 交付验收 | 交付验收 | 到货验收、测试脚本、文档模板 |
| 批量部署 | 批量部署 | Ansible部署、Playbook、配置管理 |
快速开始
如果您是初次建设算力运营体系
- 先建监控：部署npu-smi采集 + Grafana看板，先看清"家底"
- 再做调度：根据场景选择Slurm（HPC场景）或KubeSphere（容器化场景）
- 然后计费：建立卡时统计，实现成本可视化
- 最后优化：基于数据持续优化利用率和成本
如果您已有基础但想提升
- 评估成熟度：对照成熟度模型确定当前等级
- 找短板：利用率低？调度差？成本不透明？
- 定向提升：阅读对应文档，实施优化措施
- 持续迭代：建立月度运营评审机制
常见问题
Q1：算力利用率多少算正常？
一般标准：
- 推理集群：60-80%为健康（有峰值波动空间）
- 训练集群：70-90%为健康（任务连续性强）
- 混合集群：50-70%为健康（兼顾两类负载特点）
低于40%说明有大量闲置或调度效率低，需排查原因。
Q2：如何平衡不同团队的算力需求？
建议实施三步走：
- 配额管理：按团队业务重要性设定基础配额
- 公平调度：超配额时按权重排队，保证公平
- 弹性借用：允许闲时借用其他团队配额，忙时自动回收
详见调度管理文档。
Q3：算力成本如何分摊到各团队？
推荐Chargeback模式：
- 统计各团队实际消耗的卡时
- 按统一单价计算费用
- 月度生成账单，反馈给各团队
- 费用从团队预算中扣除
详见成本核算文档。
下一步
本文档由昇腾AI解决方案架构师团队编写，持续更新中。最后更新：2026-08-26