1.背景与挑战

随着大模型训练规模从千卡向万卡演进，算力基础设施的主要瓶颈正从“GPU 规模不足”转向“算力调度与资源利用效率不足”。

在实际生产环境中，普遍面临如下问题：

1. GPU 利用率长期低于 60%，大量资源“空跑”

2. 高价值训练任务被低优任务排队挤占，SLA 难以保障

3. 多机 NCCL 通信受网络拓扑影响严重，性能抖动明显

4. GPU 各类共享机制复杂，使用门槛高

5. NUMA 亲和性调度仅限单节点内生效，集群级调度器无法感知 NUMA 资源

当集群规模达到千卡、万卡级别时：传统 Kubernetes 调度能力已经无法支撑大模型训练的稳定性与效率需求。经过多年在大规模算力调度方向积累的实战经验，360AI开发平台内部打造了一套高效、稳定、易用的能够支撑万卡乃至更大规模的HBox算力调度平台。

2.HBox 算力调度平台

HBox 是面向大规模 AI 集群的一体化算力调度平台，目标不是单点提升 GPU 共享能力，而是系统性解决算力调度问题，整合多种调度功能：

1. 算力池化

2. SLA 调度保障

3. 网络感知调度

4. GPU 虚拟化整合

5. NUMA 亲和性调度

6. 支持国产化芯片

7. 自动故障检测

8. 等等

通过多维调度协同，实现：在保证任务稳定性的前提下，大幅提高 GPU 资源利用率。

3.资源分类与算力池化

随着集群规模与业务类型的快速增长，算力平台同时承载着大规模训练、在线部署、弹性计算、关键生产及测试验证等多种类型的工作负载。不同任务在性能稳定性、资源独占性、调度灵活性及成本敏感度方面的诉求存在显著差异，若采用单一的资源分配模型，容易导致高优任务受资源争抢影响、普通任务资源浪费或整体利用率下降，难以同时兼顾 SLA 保障、资源效率与运营收益。

HBox 算力调度平台对集群资源进行分类管理，针对异构业务负载在稳定性、隔离性及成本敏感度上的差异，HBox 将集群统一划分为三类资源池：

资源类型	适用场景	资源特点
公共资源	普通计算任务、测试任务	所有用户可访问 高峰期无法保证稳定的资源分配。 适合对延迟/专属硬件要求不高的任务
池化资源	生产任务、弹性任务、无需占用整机资源的任务	为用户提供基本的资源保障，同时允许用户超额使用空闲资源 支持闲时共享、弹性调度，提高利用率 可设置优先级/抢占策略
独占资源	延迟敏感业务、关键生产任务、大规模训练任务、需要占整机资源运行的任务	强隔离保证性能稳定 不受其他任务干扰 提高 SLA 和预测性

对比传统集群调度：

维度	传统统一集群	HBox 三池模型
SLA 保障	不稳定	按池级保障
资源利用率	30~60%	70~90%
算力弹性	不可控	按任务精细复用
运维成本	高	平台统一治理

Hbox 三池模型能够在保障高性能的前提下，兼顾业务灵活性、资源利用率和收益提升：

1. 资源隔离程度由低到高：公共资源 < 池化资源 < 独占资源。

2. 不同任务可根据需求选择最合适的资源池，避免资源浪费或任务性能受限，提高用户体验与满意度。

3. 合理划分集群资源，不仅降低资源闲置成本，还能通过弹性调度和多租户管理，提高集群整体收益。

4.基于优先级的抢占调度

在同一部门的共享资源池中，生产任务、测试任务和开发任务通常并存，经常会发生资源竞争。为了保障关键业务的服务等级协议（SLA），HBox 引入基于队列与优先级的调度模型，对业务进行天然隔离与等级保障。

调度机制：

1. 每个部门对应独立资源队列

2. 队列内划分三级优先级：

   1. 高优先级：可抢占低优任务，不可被抢占

   2. 中优先级：固定保障，不参与抢占

   3. 低优先级：可以被抢占。

下面是高优先级任务抢占低优先级任务的示意图：

在 360 AI 开发平台内部，已启用抢占调度功能，达成如下效果：

• 核心业务抢占成功，无需排队

• 开发、调试任务自动利用碎片算力

• SLA 可预测性显著提升

5.网络拓扑感知调度

在网络密集型AI大模型训练与推理场景中，传统的资源调度策略往往仅关注计算资源（GPU、内存、CPU）的可用性，忽视了计算节点间的网络拓扑结构对整体性能的关键影响。为此，我们设计并实现了基于网络拓扑感知的调度策略，将集群网络结构纳入调度决策核心考量，显著提升分布式大模型任务的执行效率与资源利用率。

Hbox 算力调度平台通过下列两个组件来实现网络拓扑感知调度：

1. 网络拓扑探测器：

   1. 利用 NVIDIA UFM 实时采集 IB 交换机与端口链路信息

   2. 构建全局通信拓扑树

2. Network Topology Aware Scheduler：

   1. 调度时综合评估节点通信收益

   2. 优先将同一作业 Pods 分配至通信最优路径节点

网络拓扑探测器：使用 UFM 收集 IB 交换机、IB 网卡的连接情况，然后基于连接情况生成网络拓扑树。树的叶子节点是物理机，非叶子节点是交换机。一个物理节点可能含有多个 IB 网卡，从而连接到多个交换机上。

K8s 调度器：Hbox 算力调度平台的 K8s 调度器组件在为分布式大模型任务分配资源时，会根据网络拓扑树来分配资源。用户创建任务时，可以设置下列几种网络拓扑策略：

1. none：无需网络感知。

2. bestEffort：尽量分配通信最优节点

3. singleSwitch：任务的所有 Pod 必须运行在同一个交换机连接的节点上。如果集群无法满足，则禁止为任务分配资源。

实测收益：

• NCCL 通信 latency 下降 20%

• 集群调度稳定性显著提高

6.GPU 虚拟化

在使用 GPU 进行较大规模的 AI 模型训练时，大量的训练数据被 GPU 并行批处理，GPU 可以被充分的使用。但是，对于有些计算，例如交互式的 Notebook，小规模或者低使用量的模型推理服务，经常只需要使用 GPU 的部分计算能力。在这些情况下，如果能够让多个计算任务共享使用 GPU，将能极大地提高 GPU 的利用率，进而获得有益的投资回报率。

6.1 背景-NVIDIA 共享策略

目前，GPU 的主流供应商是 NVIDIA。下面介绍 NVIDIA GPU 提供的几种共享机制：

Time-Slicing

1. 描述：Time-Slicing 指多个容器/进程轮流占用同一张物理 GPU 的计算时间片。GPU 不做物理切分，每个 Pod 都看到“完整 GPU”，NVIDIA Driver 根据调度器策略进行上下文切换。

2. 优点：

   1. 部署成本低：不动硬件，只改 Device Plugin 配置。

   2. 调度弹性极强：容易进行多租户超卖。

   3. 零硬件门槛：主流型号的GPU都支持

3. 缺点：

   1. 无资源隔离：对显存无隔离限制，不可控性极强。

   2. 显存无法限额：任何 Pod 超用显存都会导致 OOM，导致所有任务崩溃。

MPS（Multi-Process Service）

1. 描述：GPU 进程级并发共享机制，通过一个 MPS Server 守护进程接管多个 CUDA 进程的 context，把它们合并为一个 context，减少 context 切换开销，提高 GPU 利用率。

2. 优点：

   1. 进程显存限制：可以限制单进程的显存大小。

   2. 更好性能：消除 CUDA context 的切换开销，相比于 Time-Slicing 有更好的性能。

   3. 零硬件门槛：主流型号的GPU都支持

3. 缺点：

   1. 无容器级别显存限制：当一个容器内启动多个使用 GPU 的进程时，MPS 只能限制每个进程使用的 GPU 显存。

MIG（Multi-Instance GPU）

1. 描述：硬件级切片，单个 GPU 被分割为最多 7 个独立的计算实例。每个实例拥有：独立 SM、独立显存、独立 cache、独立 context。

2. 优点：

   1. 硬件隔离：并发进程安全运行且互不影响

   2. 共享技术叠加：每个分区可以叠加使用其它共享技术，例如 vGPU，time-slicing, MPS。

   3. 分区监控：在分区级别提供监控和遥测（monitoring & telemetry）数据

3. 缺点：

   1. 硬件门槛高：只有A系列及以上型号的卡支持

   2. 切片规格固定：切片方式并不灵活，有可能造成资源浪费。详细切分方式见 https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html。

   3. 切分变更成本大：GPU 闲置情况下，才能更换切分方式。

vGPU

1. 描述：虚拟化技术，通过 借助 hypervisor + NVIDIA vGPU Manager 将一个物理 GPU 映射成多个虚拟 GPU。它对具有完整输入输出内存管理单元 (IOMMU) 保护的 VM (Virtual Machine) 提供支持，使得这些 VM 能够同时、直接地访问单个物理 GPU

2. 优点：

   1. 完整虚拟化：为每个虚拟机提供独立的虚拟 GPU 设备。

   2. 隔离性强：每个 vGPU 拥有独立显存配额，计算调度和地址空间隔离，工作负载互不可见。

   3. 动态切分：单物理卡可以动态切分成多个 vGPU。

3. 缺点：

   1. 性能损耗较大（10–20%+）：完整虚拟化层和中间调度开销、上下文切换和指令转发开销。

   2. 管理复杂：部署与运维复杂度较高。需部署并维护 Hypervisor；vGPU Manager 驱动与宿主机内核强绑定；Guest OS 需安装对应 vGPU Driver；Driver 版本、内核版本、Hypervisor 需严格匹配。

   3. 商用授权昂贵：部署 vGPU 需要额外的软件授权费用。

6.2 HBox 虚拟化策略

Hbox 算力调度平台集成 NVIDIA MIG与 HAMi vGPU 两种主流 GPU 虚拟化方案，构建了一套多层次、多场景的 GPU 资源管理与调度体系。这两种技术在架构设计、资源隔离机制和适用场景上形成互补，为用户提供从物理级隔离到虚拟化共享的全栈 GPU 资源解决方案。

NVIDIA MIG：Hbox 平台将 MIG 实例作为底层的、可被调度的离散资源单元进行管理。

1. 特点：

   1. 硬件隔离： 每个 MIG 实例拥有独立的流处理器（SMs）、二级缓存（L2 Cache）和显存带宽（DRAM Bandwidth）。

   2. 安全可靠：实例间无法互相访问内存或计算单元

   3. 性能稳定：每个实例提供可预测的性能表现

2. 适用场景

   1. 核心业务推理：对稳定性和隔离性要求极高的线上推理服务。

   2. 多租户环境：为不同租户提供物理隔离的 GPU 资源，保障数据安全与性能。

   3. HPC与高性能训练：需要独占部分 GPU 资源且要求稳定性能的训练任务。

HAMi vGPU：Hbox 平台引入 HAMi（Heterogeneous AI Computing Virtualization Middleware）作为软件定义的虚拟化层，通过拦截 CUDA API 指令和显存管理，实现了超越物理限制的细粒度资源切分与共享。

1. 特点：

   1. 细粒度切分： 不同于 MIG 的固定规格切分，HAMi 支持以 1% 为单位的算力切分和以 MB 为单位的显存切分，能够极其精准地匹配业务需求，拒绝资源虚占。

   2. 使用灵活： 用户无需感知底层物理 GPU 型号与拓扑，可按标准化的 vGPU 规格（如“8GB-算力型”）申请资源，实现业务的快速部署与弹性伸缩。

   3. 广泛兼容性： 不受限于特定高端 GPU 架构，可完美支持多种类型显卡。

2. 适用场景：

   1. 开发与调试环境： 针对代码调试、Jupyter Notebook 等交互式任务，这些任务通常占用显存小且算力利用率低，使用 HAMi 可实现极高的资源复用率。

   2. 中小规模推理与边缘场景： 对轻度算力需求的批量推理任务，或资源受限的边缘节点，通过 vGPU 实现成本最优的资源供给。

推荐的 GPU 使用方案：

场景	推荐方案
Notebook	HAMi
轻量推理	HAMi
SLA 严格推理	MIG
大规模训练	独占 GPU

总结：Hbox 算力调度平台通过统一的 GPU 设备插件与资源模型，将 NVIDIA MIG 与 HAMi vGPU 两种不同层级的虚拟化能力收敛到同一调度体系中，对上层调度器和用户屏蔽底层实现差异。用户仅需按标准化 vGPU 规格申请资源，即可完成从 Notebook 开发、轻量推理到 SLA 严格推理及训练任务的全场景算力调度。

7.NUMA 拓扑感知调度

在 GPU 显存和 CPU 内存频繁交互的场景下，如果任务被分配跨 NUMA 节点的 GPU、内存、CPU，会导致访问延迟高、带宽低，从而降低任务的运行效率。HBox 算力调度平台对 NUMA 拓扑感知调度的支持：

1. 现状：目前支持单节点上的 NUMA 拓扑调度。

2. 未来计划：通过改造 Kubernetes 调度器 + Device Plugin，实现集群级别的 NUMA 亲和性调度。

7.1 现状

目前，HBox 算力调度平台已在单节点范围内启用 NUMA（Non-Uniform Memory Access）拓扑感知调度能力，通过对 Kubernetes 节点资源管理组件的精细化配置，实现 CPU、内存、GPU等关键资源在 NUMA 节点内的就近分配，从而提升业务负载的性能稳定性与可预测性。

1.NUMA 拓扑调度基础配置

在节点层面，HBox 平台对 kubelet 进行了如下关键配置：

• CPU Manager Policy：static。为符合条件的 Pod 分配独占 CPU 核心，基于 cpuset 实现精确的 CPU 绑定，是 NUMA 感知调度生效的前置条件。

• Topology Manager Policy：best-effort。在 Pod 创建阶段，尽可能对齐 CPU、内存、GPU设备资源的 NUMA 拓扑关系，在不影响调度成功率的前提下，最大化 NUMA 本地性收益。

通过上述配置，kubelet 在节点内资源分配阶段具备了 NUMA 感知能力，为后续性能优化奠定基础。

2.用户任务侧约束要求

在 HBox AI 平台提交的计算任务都满足下列条件：

• Pod 的资源规格满足 Guaranteed QoS。

• CPU 资源以整数核形式申请

3.NUMA 实践中的关键配置经验

在实际生产环境中，除了基础 NUMA 功能的启用，HBox 平台还总结并沉淀了以下重要实践经验。

经验一：关闭 lxcfs

1. 在 NUMA 敏感场景中，建议关闭 lxcfs。

2. 原因：lxcfs 通过 FUSE 虚拟化 /proc 与 /sys 文件系统，为容器提供基于 cgroup 视角的资源视图。这一机制在限制容器资源观测性的同时，会对 NUMA 拓扑信息进行裁剪或重构。

3. 影响机制：

   1. lxcfs 会重写 /sys/devices/system/node 等 NUMA 相关路径；

   2. 用户态程序（如 NUMA 感知的运行时、计算框架或库）基于这些信息进行 NUMA 优化决策；

   3. 虚拟化后的拓扑信息可能导致用户态对 NUMA 架构产生误判，从而削弱甚至抵消 NUMA 亲和性优化效果。

经验二：合理配置 NPS（NUMA Per Socket）

1. 通过合理设置 NPS，可从硬件层面优化 NUMA 拓扑结构。

2. 原因：NPS 是服务器 BIOS 层面提供的 NUMA 划分策略，用于控制每个 CPU Socket 被划分成的 NUMA 节点数量。NPS 的设置直接决定了操作系统和 Kubernetes 所感知到的 NUMA 拓扑形态。

3. 实践建议：根据主板拓扑结构、CPU 型号、PCIe 设备分布（如 GPU） 以及 业务负载特性，选择合适的 NPS 值；

总结：通过 kubelet NUMA 感知配置 + 任务侧资源约束 + lxcfs 行为控制 + BIOS 层 NPS 调优的协同，HBox 算力调度平台在单节点范围内构建了一套可落地、可验证、可持续演进的 NUMA 拓扑调度实践，为高性能计算、GPU 推理与训练等场景提供了坚实的系统基础。

7.2 计划

未来，HBox 算力调度平台会实现集群级的 NUMA 调度能力。在集群层面，HBox 调度器具备对 CPU 与 GPU NUMA 拓扑资源状态的全局感知能力，能够在调度决策阶段综合考虑各节点的 NUMA 资源剩余情况，精确筛选满足拓扑约束条件的最优节点，避免将 NUMA 不匹配的负载调度至不合适的节点，降低跨 NUMA 访问带来的性能损耗。

设计架构：

实现原理：

NUMA 拓扑状态采集

1. CPU NUMA 信息收集：HBox 组件在节点侧持续采集 CPU 在各 NUMA node 上的可用核数、已分配情况等信息，形成细粒度的 NUMA 资源视图。

2. GPU NUMA 信息解析：通过对 Kubernetes Device Plugin 进行适配与增强，HBox 从 kubelet 获取 GPU 的实际分配状态，并结合 GPU NUMA 拓扑关系，解析出各 NUMA node 上 GPU 资源的剩余情况。

3. 通过上述机制，HBox 在集群层面构建了统一的 CPU 与 GPU NUMA 资源模型。

集群调度器的 NUMA 感知决策

1. 集群调度器在执行节点筛选与优选时：

   1. 评估 CPU 与 GPU 在各 NUMA node 上的可用资源；

   2. 对候选节点进行 NUMA 亲和性打分，优先选择能够在单一或最优 NUMA 拓扑内满足资源需求的节点；

   3. 在满足功能性调度约束的前提下，最大化 CPU–GPU 本地性和资源连续性。

2. 该机制使 NUMA 拓扑约束在调度阶段即被显式纳入考量，而非完全依赖节点内的事后修正。

8.GPU与CPU灵活配比调度

现状：在传统 AI 基础设施中，计算资源通常以静态规格、固定配额的方式进行分配，在 GPU 节点上，调度系统根据任务申请的 GPU 数量静态分配固定数量的 CPU 与内存资源，这会导致 GPU 节点上 CPU 资源的浪费。以 GPU 密集型任务（如大模型推理）为例：

1. GPU 利用率往往接近饱和

2. 实际 CPU 仅承担少量控制逻辑与任务编排工作

3. 大量已分配的 CPU 核心长期处于低负载甚至空闲状态

HBox 算力调度平台计划提供并完善 GPU、CPU 灵活配比调度能力，使得 CPU 任务运行在 GPU 节点上，充分利用 GPU 任务未使用的 CPU 资源，提供集群资源利用率。集群中会划分出一部分 GPU、CPU灵活配比调度的节点，这些节点可以同时运行 GPU 任务和 CPU 任务：

1. GPU 任务：以 GPU 计算为主的任务，如模型训练与大模型推理。HBox 为这些任务分配有限的 CPU 资源。

2. CPU 任务：以 CPU 计算为主，如数据预处理、特征工程、离线分析、分布式PD分离中的proxy等。

这种灵活的调度机制可以：

1. 充分利用 CPU 算力： 以前闲置的 CPU 核心现在成了处理大数据预处理的“主力军”，真正实现了节点内部的资源闭环。

2. 缩短任务周期： 更多的 CPU 任务无需排队等待专属 CPU 节点，利用 GPU 节点的剩余 CPU 资源即可即时启动，加速了 AI 开发的全链路流程。

3. 提高集群利用率：集群整体 CPU 利用率不再受 GPU 任务的限制，大幅提升了资源投资回报率。

9.国产化芯片调度支持

HBox算力调度平台在国产化芯片的适配、支持上也做了很多工作，其中国产化芯片的调度是重要的一项工作内容。目前HBox算力调度平台在昇腾910B系列、310P系列的调度及使用上都积累了大量的经验。

昇腾系列AI处理器的特点：

1. 内部处理器之间采用HCCS方式连接

2. 每台物理设备具备8颗或16颗处理器，两个HCCS，每个HCCS存在4颗或8颗处理器，同一HCCS内处理器可做数据交换，不同HCCS内处理器不能直接通信，需要通过PCIe或节点上的高性能网络经过交换机进行通信

基于昇腾AI处理器的上述特点，需要在创建昇腾AI任务时，尽可能将任务分配到同一个HCCS互联的处理器上。为适配这一场景，提升昇腾AI处理器在AI训推中的性能，华为开源了ascend-for-volcano调度插件。该插件基于开源Volcano调度的插件机制，增加昇腾处理器的亲和性调度，最大化发挥昇腾处理器的计算性能。HBox算力调度平台正是基于此方案，进行了大量的验证、实战，保证了昇腾AI训推任务的高效稳定运行。

未来，HBox算力调度平台还会在国产化芯片上持续投入，丰富支持的芯片类型比如海光DCU系列等。除此之外还会在国产化芯片的虚拟化、资源共享方面做更多的工作，更好的助力国产化芯片的落地应用。

10.稳定性建设

为保障大规模 GPU 集群在高负载、长时间运行场景下的稳定性，HBox 算力调度平台围绕 “故障可感知、风险可隔离、问题可自愈、状态可追溯” 的目标，构建了一套覆盖硬件层、驱动层、通信层与 Kubernetes 调度层 的算力稳定性监控与处置体系，并将该体系与AI任务调度相结合，充分保证大规模AI训推任务的稳定性。

该体系以 qihoo-smi 节点守护组件为核心，对 GPU、NVLink、网卡及关键系统服务进行持续巡检，并与调度系统深度联动，实现故障节点的自动隔离与业务保护。

10.1 异构算力环境的深度适配

HBox 目前已全面适配主流高性能计算机型，确保在不同算力架构下监控指标的一致性：

• 适配机型：包括 NVIDIA A100、A800、H800、H100、H200 、H20 以及 L20 等。

• 部署机制：通过 K8s 标签 qihoo.net/qihoo-smi.deploy: "true" 精确控制监控组件在特定节点上的部署。

10.2 多维度的故障监测体系

平台将故障细分为 GPU、网卡、慢节点及系统组件四大类，实现了从物理层到 K8s 资源层的深度穿透。

GPU 故障检测与处理

针对 GPU 资源，平台提供了极其细腻的监控策略：

• 基础故障（掉卡、NVLink 异常）：系统每分钟执行一次检测。一旦发现物理层面掉卡或 NVLink 状态异常，将立即执行 Cordon 节点操作并触发报警，防止新任务调度至异常节点。

• 显存故障（ECC）：涵盖单位/双位不可校验错误及 nvidia-smi 报错。对于影响较大的双位 ECC 错误，采取 Cordon 隔离策略，并探索在 GPU 无业务进程时自动进行重置自愈。

• 关键服务（Nvidia-Fabricmanager）：针对该服务的退出问题，平台通过修改 systemd 配置实现进程崩溃后的自动拉起（Restart=always），并同步发出告警通知。

• XID 错误捕捉：实时监控 Xid 74、109、79 等典型错误（如 GPU 掉线或上下文切换超时），及时隔离故障节点。

网络与扩展资源监控

AI 集群对带宽和拓扑极度敏感，HBox 专门强化了网卡与算力资源的联动监控：

• Mellanox 网卡监控：支持网卡服务降级（Downgraded）与断连（Down）检测。当网卡恢复正常（Up）时，系统支持自动执行 Uncordon 恢复节点调度。

• 内核模块自愈：如发现 nvidia_peermem 模块未加载，系统将触发自动修复逻辑重新加载内核模块。

• K8s 资源对齐：针对 mlx 扩展资源在 K8s 中显示为零的问题，平台通过升级设备插件并配合 qihoo-smi 检测，确保网络资源在调度层可见。

性能衰减与集群稳定性监控

• 慢节点检测（NCCL-Tests）：目前已上线针对 MPI 多机任务的性能检测，通过自动化测试发现集群中的性能“长尾”节点，避免单一节点的带宽瓶颈拖慢整体训练速度。

• API-Server 连接性：系统持续监测节点与 K8s 控制平面的通信状态。若连接失败持续 3 次，将触发报警，但考虑到业务稳定性，默认不进行 Cordon 操作，仅通过自愈逻辑尝试修复。

智能化告警与精细化管理

• 告警闭环：统一规范告警格式，支持告警恢复通知。当节点 Uncordon 时，系统会自动关联 ES 中的异常记录并发送恢复提醒。

• 豁免机制：针对部分已知但暂不影响业务、或无法立即修复的故障，支持通过标签 qihoo.net/qihoo-smi: exempt 实现节点豁免检测，避免不必要的 cordon 影响作业运行。

• 数据分析：所有异常告警信息同步存储于 Elasticsearch，为后续的故障频率统计和硬件选型优化提供数据支持。

11.总结

HBox 算力调度平台构建了一套面向万卡规模 AI 集群的全链路调度体系，本文介绍了 Hbox 的大部分算力调度能力：

• 三池模型保障 SLA

• 优先级抢占保障关键生产业务

• 网络拓扑与 NUMA 双感知

• MIG + vGPU 虚拟化融合

• GPU与CPU 灵活配比调度

• ……

通过上述能力的协同运作，HBox 算力调度平台能够在复杂、多变的 AI 负载环境中，实现资源利用率、业务稳定性与调度公平性之间的平衡，为上层训练与推理业务提供稳定、高效的算力支撑。

未来计划-硬件管理与资源分配机制的演进：

1. 目前，HBox 算力调度平台基于 Kubernetes 设备插件（Device Plugin）机制对 GPU 等硬件加速资源进行管理与分配。设备插件模式在当前 Kubernetes 生态中被广泛采用，但其资源模型以静态声明与节点级注册为核心，在资源表达能力、动态调度灵活性以及复杂硬件拓扑感知等方面存在一定局限。

2. 面向未来，HBox 计划引入 Kubernetes 动态资源分配（Dynamic Resource Allocation）机制，基于声明式资源请求与调度器原生协同，实现对硬件资源更精细化、动态化的分配与管理，以更好地支撑多样化和复杂化的算力使用场景。