HAMi × 沐曦 MetaX sGPU 共享、三档 QoS、拓扑智能调度与 WebUI 全面适配

近日，密瓜智能团队与沐曦 MetaX 团队紧密合作，基于曦云C系列产品，在 HAMi v2.7.0 版本中联合推出了统一调度方案。该方案通过深度整合，实现了 sGPU 共享、三档 QoS、拓扑智能调度与 WebUI 全面适配，旨在大幅提升大规模 AI 训练与推理场景下的资源利用率与任务执行效率，为构建国产自主可控的 AI 算力底座提供了坚实支持。

一、 核心特性总览

1. GPU  共享 (sGPU) 与资源隔离: 允许多个容器任务共享同一张物理 GPU 卡，并通过精确限制每个任务的显存（如 4G）与计算核心比例（vcore, 如 60%）来实现资源隔离，从而显著提高资源利用率。
2. sGPU 拓扑感知调度: (v2.7.0 新增) 针对单机多卡的场景，调度器能动态感知 GPU 间的连接拓扑（如 MetaXLink、PCIe Switch），并为多卡 sGPU 任务优先选择通信带宽最高的 GPU 组合，提升训练性能。
3. 服务质量 ( QoS ) 策略: (v2.7.0 新增) 支持为 sGPU 任务设置不同的资源服务等级，如 BestEffort (尽力而为)、FixedShare (固定份额) 和 BurstShare (突发份额)，以满足不同业务场景的需求。
4. 健康检查与监控: (v2.7.0 新增) 提供设备健康状态检查，在 HAMi-WebUI 中打通沐曦监控全链路，使得异构指标在界面中更直观呈现，可视化地展示整个集群的资源分配和使用情况。
5. GPU  拓扑感知调度: 基于DevicePlugin 的预先打分，为多卡 GPU 任务优先选择通信带宽最高的 GPU 组合，支持   binpack  和   spread  等调度策略，实现更精细化的资源布局。

二、sGPU 拓扑感知调度：智能寻优

阶段一：节点内设备选择 - “规则至上”的确定性决策

1. 输入： 节点上所有满足 Pod 资源请求（如显存、算力）的候选 GPU 列表。
2. 分组： 算法首先将这些候选 GPU 按照它们的 linkZone ID （高速互联域标识） 进行分组。
3. 决策树： 算法开始按以下优先级顺序进行决策：
   1. 第一优先级 （最优解：域内满足）: 算法会检查是否存在任何一个 linkZone 分组，其内部的 GPU 数量足以满足任务的全部需求。
   2. 第二优先级 （次优解：跨域组合）: 算法会创建一个新的空列表，然后逐个遍历所有 linkZone 分组，将里面的 GPU 全部添加到这个新列表中，直到列表中的 GPU 总数满足任务需求。
   3. 第三优先级 （保底解：补充无互联信息设备）: 如果遍历完所有 linkZone 分组后，列表中的 GPU 数量仍然不够，算法最后会用那些没有 linkZone 信息的 GPU 来补足剩余的数量。

// File: pkg/device/metax/sdevice.go

func prioritizeExclusiveDevices(candidateDevices device.ContainerDevices, require int) device.ContainerDevices {
        // ... (代码将所有候选 GPU 按 linkZone 进行分组) ...
        // linkDevices: 存储了所有带 linkZone 的设备组
        // otherDevices: 存储了所有不带 linkZone 的设备

        // 1. pickup devices within MetaLink (第一优先级)
        for _, devices := range linkDevices {
                if len(devices) >= require {
                        klog.V(5).Infof("prioritize exclusive devices: best result, within metalink")
                        return devices[0:require] // 找到一个linkZone能满足所有需求，直接返回，这是最优解
                }
        }

        prioritizeDevices := device.ContainerDevices{}

        // 2. pickup devices cross MetaLink (第二优先级)
        // ... (如果单个 linkZone 不够，则开始跨 linkZone 凑齐设备) ...

        // 3. if not satisfied, pick up devices no MetaLink (第三优先级)
        // ... (用 otherDevices 里的设备进行补充) ...

        return ... 
}

阶段二：节点间评分决策 - “深谋远虑”的量化评估

// File: pkg/device/metax/sdevice.go

func scoreExclusiveDevices(podDevices device.PodSingleDevice, previous []*device.DeviceUsage) int {
        // ... (代码构建 allocatedDevices, availableDevices, restDevices 列表) ...

        // 计算三个核心分数
        availableScore := availableDevices.Score() // 分配前总分
        allocatedScore := allocatedDevices.Score() // 分配组合得分
        restScore := restDevices.Score()         // 剩余设备得分

        // 计算拓扑损失分
        lossScore := availableScore - allocatedScore - restScore

        // 计算最终得分，放大 allocatedScore 的权重
        result := 10*allocatedScore - lossScore
        klog.V(5).Infof("calcScore result[%d] >>> availableScore[%d], allocatedScore[%d], restScore[%d], lossScore[%d]",
                result, availableScore, allocatedScore, restScore, lossScore)

        return result
}

1. allocatedScore （分配质量分）: 这个分数衡量的是第一阶段选出的那个 GPU 组合本身的内部连接紧密程度。组合内处于相同 linkZone 的设备对越多，这个分数就越高。10 * allocatedScore 表明调度器极度重视为当前任务分配一个高质量的组合。权重乘以 10，使其在最终得分中占据主导地位。
2. lossScore （拓扑损失分 / 碎片化惩罚）: 这是一个非常关键的“远见”指标。它衡量的是：“为了完成本次分配，我们对节点上剩余的、未被分配的 GPU 的拓扑完整性造成了多大的破坏？”
   1. 计算方式：lossScore = （分配前总分） - （分配组合得分） - （剩余设备得分）
   2. 这意味着调度器会惩罚那些会导致节点拓扑资源“碎片化”的分配行为，在分配质量分相同的时候会起作用，保护了集群为未来的大型任务保留优质、完整拓扑资源的能力。

三、 服务质量（QoS）策略：“同类聚合”的隔离实现

1. BestEffort （尽力而为）: 默认策略。资源尽力分配，不限制算力，追求最大化的资源利用率。
2. FixedShare （固定份额）: 严格保证任务分配到的算力 （vcore） 和显存 （vmemory）固定配额，性能稳定，不受其他任务干扰。
3. BurstShare （突发份额）: 有固定资源配额，但在 GPU 空闲时允许被 sGPU 使用，适合有突发负载的业务。

设计考量

核心原理与代码实现

• 如果第一个 Pod 是 FixedShare，这张卡就变成了“FixedShare 专用卡”。
• 如果第一个 Pod 是 BestEffort，这张卡就变成了“BestEffort 专用卡”。

1. 检查  GPU  是否空闲： 如果 GPU 完全空闲，允许任何 QoS 任务入驻，并由该任务设定卡的 QoS 模式。
2. 检查  QoS  是否匹配： 如果 GPU 已被占用，则新任务的 QoS 注解 必须严格等于卡上现有任务的 QoS 模式，否则调度将被拒绝。
3. 独占任务例外： 请求 100% 算力的任务，因不涉及共享，不受此规则限制。

// file: pkg/device/metax/sdevice.go
// func: checkDeviceQos (simplified logic)

func (sdev *MetaxSDevices) checkDeviceQos(reqQos string, usage device.DeviceUsage, request device.ContainerDeviceRequest) bool {
        if usage.Used == 0 { // 空闲卡
                return true
        }

        if request.Coresreq == 100 { // 独占卡
                return true
        }

    // ... 获取 devQos ...
        if devQos == "" || reqQos == devQos { // 核心匹配规则
                return true
        } else {
                return false
        }
}

四、WebUI 支持

五、 GPU 拓扑感知调度：Binpack 与 Spread

• spread   模式: 调度器会读取   metax-tech.com/gpu.topology.scores  ( MetaxAnnotationScore) 的注解值。为了配合 HAMi 框架“分数越低，越靠前”的   spread  逻辑，这里需要做反转处理 ( 分数 = 2000 - score)。这意味着，一个节点的预计算   score  越高，其在 HAMi 的最终得分反而越低，从而排名靠前，越倾向于被调度，进而选择最优拓扑。
• binpack   模式: 调度器会读取节点上   metax-tech.com/gpu.topology.losses  ( MetaxAnnotationLoss) 的注解值。这个 loss值越低，代表资源“损失”越小，节点得分就越高 ( 分数 = 2000 - loss)，从而被优先选择，进而保障剩余资源的拓扑尽可能完整。

// File: pkg/device/metax/device.go

func (dev *MetaxDevices) ScoreNode(...) float32 {
        res := float32(0)
        if policy == string(util.NodeSchedulerPolicyBinpack) {
                lossAnno, ok := node.Annotations[MetaxAnnotationLoss]
                if ok {
                        loss := parseMetaxAnnos(lossAnno, sum)
                        res = 2000 - loss
                }
        } else if policy == string(util.NodeSchedulerPolicySpread) {
                scoreAnno, ok := node.Annotations[MetaxAnnotationScore]
                if ok {
                        score := parseMetaxAnnos(scoreAnno, sum)
                        res = 2000 - score
                }
        }
        return res
}

MetaXLink 优先级高于 PCIe Switch，包含两层含义：  

1. 两卡之间同时存在 MetaXLink 连接以及 PCIe Switch 连接时，认定为 MetaXLink 连接；
2. 服务器剩余 GPU 资源中 MetaXLink 互联资源与 PCIe Switch 互联资源均能满足作业请求时，分 配 MetaXLink 互联资源。

• 当任务使用   node-scheduler-policy=spread，分配 GPU 资源尽可能位于相同 MetaXLink 或 PCIe Switch 下，如下图所示:

• 当使用   node-scheduler-policy=binpack，分配 GPU 资源后，以尽量减少对 MetaXLink 拓扑的破坏，保障剩余资源尽可能完整，如下图所示：

六、 使用方式

GPU 拓扑感知调度

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod2
  annotations: 
    # binpack 策略: 针对 'gpu' 资源，调度器将读取节点注解 'metax-tech.com/gpu.topology.losses' 的值。
    # 评分按 `2000 - loss` 计算，因此 loss 值越低的节点得分越高，会被优先选择，进而保障剩余资源的拓扑尽可能完整。
    hami.io/node-scheduler-policy: "binpack" 
spec:
  containers:
    - name: ubuntu-container
      resources:
        limits:
          metax-tech.com/gpu: 2

---
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod3
  annotations: 
    # spread 策略: 针对 'gpu' 资源，调度器将读取节点注解 'metax-tech.com/gpu.topology.scores' 的值。
    # 评分按 `2000 - score` 计算。这会配合 HAMi 框架的 spread 逻辑，优先选择得分较低（即 score 注解值较高）的最优拓扑节点。
    hami.io/node-scheduler-policy: "spread"
spec:
# ...

sGPU 拓扑感知调度

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod1
  annotations:
    metax-tech.com/sgpu-topology-aware: "true" # 开启拓扑感知调度
spec:
  containers:
    - name: ubuntu-container
      resources:
        limits:
          # 请求 4 张完整的 GPU。因未指定 vcore，默认为100，从而触发独占模式与拓扑感知
          metax-tech.com/sgpu: 4
# ...

sGPU 共享与 QoS 策略

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
  annotations:
    metax-tech.com/sgpu-qos-policy: "fixed-share" # 或 "best-effort", "burst-share"
spec:
  containers:
    - name: ubuntu-container
      resources:
        limits:
          metax-tech.com/sgpu: 1
          metax-tech.com/vcore: 60
          metax-tech.com/vmemory: 4

七、 总结

• 说明文档：   MetaX GPU 支持说明
• 使用样例：   MetaX GPU 样例
• 相关  PRs:
  • https://github.com/Project-HAMi/HAMi/pull/1123
  • https://github.com/Project-HAMi/HAMi/pull/1193
  • https://github.com/Project-HAMi/HAMi/pull/1295
  • https://github.com/Project-HAMi/HAMi-WebUI/pull/46