单个 NPU 卡用 npu-smi（asc-tools）查状态就够了。几十张卡组成集群，还需要考虑负载均衡、故障恢复、固件版本一致性、多租户资源隔离——oam-tools 就是干这个的。面向数据中心运维人员，把集群级的 NPU 管理员操作封装成命令+Web 界面。

oam-tools 和 asc-tools 的职责边界

维度	asc-tools	oam-tools
管理范围	单卡/单节点	集群（多节点、多节点多卡）
主要用户	节点运维 / 开发者	集群管理员 / 运维 SRE
硬件接口	npu±smi（命令行）	REST API + Web UI + CLI
核心功能	状态查询/诊断	负载调度/容错/多租户
部署位置	每个节点上	管理节点（可以主动推送告警到监控平台）

集群健康状态监控

oam-tools 的核心功能是集群级的健康状态监控——每天 24 小时追踪集群中每个 NPU 的温度、HBM 占用、算力利用率、ECC 错误计数值。

# oam-tools CLI：集群健康概览
oam-cluster health --all

# 输出：
# Cluster: production-npu-cluster-01
# Nodes: 32
# +---------+-----------+--------+-----------+----------+------+-----+
# | Node    | NPUs      | HBM    | Temp Max  | Power    | ECC  | Jobs |
# +---------+-----------+--------+-----------+----------+------+-----+
# | node-01 | 8/8 OK    | 62%    | 48°C      | 1.2kW     | 0   | 3    |
# | node-02 | 7/8 OK ⚠ | 58%    | 51°C      | 1.1kW     | 0   | 4    |
# | node-03 | 8/8 OK    | 61%    | 81°C 🔴   | 1.3kW     | 12  | 2    |
# | node-04 | 0/8 DOWN | 0%    | N/A       | 0kW       | N/A | 0    |
# +---------+-----------+--------+-----------+----------+------+-----+
#
# ⚠ node-02: 1 NPU offline (driver crashed?)
# 🔴 node-03: 81°C, ECC errors=12 → 建议排查散热
# 🔴 node-04: ALL DOWN → 告警已触发 PagerDuty

# 查看单个节点的详细信息
oam-cluster node --detail node-03

# NPU 0: Temp 56°C, HBM 32/64 GB, ECC=0
# NPU 1: Temp 81°C, HBM 28/64 GB, ECC=12  ← 温度异常 + ECC 增长
#                          ↑ Single Bit 8, Double Bit 4
# NPU 2: Temp 52°C, HBM 48/64 GB, ECC=0
# ...

从集群健康概览直接能看到问题节点和指标异常——不需要逐台 SSH 上去查 npu-smi。

RMC（Resource Management Controller）资源调度

oam-tools 内置 RMC 组件——专门做 NPU 资源调度，集成 Kubernetes 实现 NPU 的 GPU/NPU 调度。

# oam-tools 和 Kubernetes 集成配置
# kubectl apply -f npu-device-plugin.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ascend-device-plugin
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: ascend-device-plugin
  template:
    metadata:
      labels:
        name: ascend-device-plugin
    spec:
      hostNetwork: true
      containers:
      - name: ascend-device-plugin
        image: ascendai/ascend-device-plugin:v5.0.1
        command: ["ascend-device-plugin", "-logtostderr", "-v=3"]
        securityContext:
          privileged: true
        volumeMounts:
        - mountPath: /var/lib/kubelet/device-plugins
          name: device-plugin
        - mountPath: /usr/local/Ascend
          name: ascend-driver
      volumes:
      - hostPath:
          path: /var/lib/kubelet/device-plugins
        name: device-plugin
      - hostPath:
          path: /usr/local/Ascend
        name: ascend-driver

部署后，Kubernetes 的 Pod 可以在 YAML 里申请 ascend/Ascend910 资源（类似 nvidia.com/gpu）：

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: inference-worker
    image: my-model:latest
    resources:
      limits:
        ascend/Ascend910: 1   # 申请 1 张 NPU 卡

RMC 负责：

• 资源发现：Node 上线时自动注册 NPU 可用列表
• 调度：Pod 申请 NPU → RMC 找可用 NPU → 绑定
• 隔离：不同 Pod 看不到对方的 NPU（通过设备号映射）
• 回收：Pod 终止 → RMC 释放 NPU 给其他 Pod 用

Prometheus 集成和自动告警

oam-tools 暴露 Prometheus metrics 端点——集群监控平台（Grafana + Prometheus）直接订阅：

# oam-tools 自动暴露 metrics
# http://<oam-service>:9090/metrics

# 核心 counters
npu_hbm_memory_used_bytes{node="node-01", npu="0"} 34359738368
npu_temperature_celsius{node="node-01", npu="0"} 48
npu_power_watts{node="node-01", npu="0"} 280
npu_ecc_errors_total{node="node-01", npu="0", type="single"} 0
npu_ecc_errors_total{node="node-01", npu="0", type="double"} 0
npu_utilization_cube_percent{node="node-01", npu="0"}  85
npu_utilization_vector_percent{node="node-01", npu="0"} 62
npu_jobs_running{node="node-01"} 3
npu_driver_status{node="node-01"} 1   # 1=OK, 0=ERROR

# 自定义告警规则（Prometheus AlertManager）
# alert: NPUOverheating
# expr: npu_temperature_celsius > 80

多租户资源隔离

NF 集群通常被多个团队共享——训练团队占 4 个节点跑 7 天训练，推理团队占 2 个节点跑 24/7 服务。oam-tools.json 实现资源隔离。

# 创建租户分区
oam-tenant create --name=team-training --nodes=node-01:node-04
oam-tenant create --name=team-inference --nodes=node-05:node-06
oam-tenant create --name=team-dev --nodes=node-07

# 查询租户资源使用情况
oam-tenant status --name=team-training
# Nodes: node-01 ~ node-04 (4 nodes, 32 NPUs)
# Allocated: 28 NPUs
# Available: 4 NPUs
# Running Jobs: 7

# 给租户设资源配额（防止一个租户吃满所有资源）
oam-tenant quota --name=team-training --max-npus=24
# 训练团队最多用 24 张 NPU → 既保证资源又不让其他团队饿死

Pod 提交时需要指定租户：

apiVersion: v1
kind: Pod
metadata:
  labels:
    ascend/oam-tenant: "team-inference"
spec:
  ...

租户粒度的隔离避免了「一个团队的 OOM 把其他团队的 NPU 也搞挂了」的问题。

踩坑一：N节点下线后 RMC 没有释放资源

一个节点因为散热故障被管理员手动下线（oam-cluster node --offline node-03）。在这个节点上跑的推理 Pod 应该被 Kubernetes 自动迁移到其他节点——但 RMC 没有收到离线通知，仍然认为 node-03 的 NPU 可用。调度器把新 Pod 调度到 node-03 上——失败。

根因：oam-cluster node --offline 没有通知 RMC。RXMC 和 oam-cluster 是两个独立的进程，之间的 state 同步靠心跳（5 秒间隔）。

修复：手动做三件事：

# 1. 离线节点（oam-cluster）
oam-cluster node --offline node-03

# 2. 驱逐节点上的 Pod（kubectl）
kubectl drain node-03 --ignore-daemonsets

# 3. 标记节点为不可调度（kubectl）
kubectl cordon node-03

# 4. 清理 RMC 中该节点的资源记录（oam-rmc）
oam-rmc node --deregister node-03

四步缺一不可。线上运维最容易漏掉第 4 步——RMC 残留的节点记录让调度器做出错误决策。

踩坑二：Prometheus 指标延迟导致告警风暴

NPU 温度从 50°升高到 85°是一个慢过程（~30 秒）。但 Prometheus 的 scrape interval 是 15 秒——中间可能有 2 次指标在 50-85°之间波动。如果设 npu_temperature_celsius > 80 直启动告警，可能导致多次告警。

修复：用 for: 1m 延迟触发。

# alertmanager 规则
- alert: NPUOverheating
  expr: npu_temperature_celsius > 80
  for: 1m   # 持续 1 分钟才触发（避免瞬时尖峰）
  labels:
    severity: warning
  annotations:
    description: "NPU {{ $label.npu }} on {{ $label.node }} is {{ $value }}C"

温度区别于别的指标：温度升高是物理过程，不会在 15 秒内从 50°突然跳到 85°再降回来。for: 1m 的前提是温度升高到 80°确实是真实故障，不是信号抖动。

踩坑三：多租户的 NPU 内存隔离不完整

RMC 在租户级别限制了 NPU 数量（team-training --max-npus=24），但没有限制单张 NPU 的 HBM 使用上限。一个租户的 1 个 Pod 申请了 NPU 0，然后 HBM 使用到上限 64 GB——同节点上 Node 更新的其他 Pod（包括其他租户）的 NPU 共享 HBM 带宽被耗尽。

根因：RMC 是 NPU 粒度的分配器，不是 HBM 粒度的分配器。

部分缓解：在 Pod 层面设 HBM 限额。

# Pod 层面的 HBM 限额（通过环境变量，驱动层支持）
env:
- name: ASCEND_HBM_LIMIT
  value: "48Gi"   # 最多用 48GB HBM
# NPU 上有 64GB HBM，但 Pod 只能用 48GB
# 剩下的 16GB 留给同一个 Node 上的其他 Pod

但这个机制不强制——驱动层可以忽略（取决于 CANN 版本）。在分层存之前，最佳实践是把训练（HBM 需求大）和推理（HBM 需求小）混合调度到不同 Node 上。

---

oam-tools 解决的不是单卡问题（asc-tools 负责这个），而是集群问题：负载均衡、故障恢复、多租户隔离、监控告警。数据中心的 NPU 不是一台机器，是一群机器——这群机器出了问题（散热故障、节点宕机、固件版本不一致），影响的不是一张卡，而是整个集群的调度效率。oam-tools 让运维人员从一个命令看到集群全景，而不是逐台 SSH 上去查。