HAMi 对接壁仞BirenGPU设备插件部署、任务调度与源码实现解析【免费下载链接】HAMiHeterogeneous GPU Sharing on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ha/HAMi导读本文聚焦开源项目 HAMiHeterogeneous GPU Sharing on Kubernetes对壁仞Biren国产加速卡的原生支持能力。你将了解如何部署壁仞设备插件、如何在 Kubernetes 中声明birentech.com/gpu资源并提交壁仞 GPU 任务以及 HAMi 调度器如何识别、分配并打标壁仞设备。文末结合 pkg/device/biren/device.go 与 Helm 配置深入剖析壁仞设备接入 HAMi 设备抽象层的完整实现链路帮助你掌握异构 GPU 共享体系下新增国产芯片后端的方法论。一、概述壁仞设备在 HAMi 中的接入方式壁仞Biren是国内 GPU 厂商其加速卡通过birentech.com/gpu资源名暴露给 Kubernetes。HAMi 将壁仞作为异构设备之一接入其统一的设备抽象层使壁仞卡能够像 NVIDIA GPU 一样被调度器统一管理、共享与打标。从 pkg/scheduler/config/config.go 的初始化代码可见壁仞设备在调度器启动时通过biren.InitBirenDevice注册进全局设备表{biren.BirenDevice, biren.BirenCommonWord, func(cfg any) (device.Devices, error) { birenConfig, ok : cfg.(biren.BirenConfig) if !ok { return nil, fmt.Errorf(invalid configuration for %s, biren.BirenCommonWord) } return biren.InitBirenDevice(birenConfig), nil }, config.BirenConfig},壁仞后端接入的关键点在于HAMi 本身不负责壁仞卡的底层探测与容器注入这部分由独立的壁仞设备插件biren-device-plugin承担。HAMi 调度器只负责在集群层面感知壁仞设备、执行资源分配与 Pod 打标。因此使用壁仞支持需要分两步先部署设备插件再通过 HAMi 调度任务。二、部署 biren-device-plugin在 HAMi 调度器介入之前集群中的每个壁仞节点都需要运行独立的壁仞设备插件其作用是探测节点上的壁仞加速卡向 kubelet 上报birentech.com/gpu可分配资源依据 HAMi 调度器写入 Pod 的分配注解annotation为容器注入壁仞运行库、完成设备挂载与环境变量设置。设备插件由独立的开源项目 biren-device-plugin 提供原文档指向其外部仓库本文不再重复外部链接部署方式为标准的 DaemonSet 部署。部署完成后节点上应出现壁仞资源可通过如下命令验证kubectl describe node node-name | grep birentech正常输出应包含类似birentech.com/gpu: 8的可分配数量且节点上出现 HAMi 约定的壁仞注册注解见下文源码解析表示设备插件已与 HAMi 完成握手。三、在 Helm 中启用并配置壁仞资源部署 HAMi 时壁仞支持默认开启。在 charts/hami/values.yaml 中#Biren Parameters birenResourceName: birentech.com/gpu对应devices.biren配置段charts/hami/values.yamlbiren: enabled: true customresources: - birentech.com/gpu各字段说明字段默认值说明birenResourceNamebirentech.com/gpu壁仞设备资源名即 Pod 中声明的资源配额名devices.biren.enabledtrue是否启用壁仞设备支持devices.biren.customresources[birentech.com/gpu]需要注册到 kube-scheduler 扩展资源清单中的壁仞资源名Helm 渲染时调度器的设备配置文件ConfigMap会生成壁仞段落charts/hami/templates/scheduler/device-configmap.yamlbiren: resourceCountName: {{ .Values.birenResourceName }}即最终的设备配置为biren: resourceCountName: birentech.com/gpu同时_helpers.tpl 会把birentech.com/gpu追加到调度器扩展资源白名单并标记ignoredByScheduler: true含义是该资源不参与 kube-scheduler 默认节点过滤逻辑节点是否满足条件完全交由 HAMi 扩展调度器extender判断从而让调度器可以灵活地在已注册壁仞设备的节点间做细粒度分配。四、提交壁仞 GPU 任务4.1 最小可运行示例原文档给出的壁仞任务清单与仓库 examples/biren/default_use.yaml 完全一致apiVersion: v1 kind: Pod metadata: name: pod1 spec: restartPolicy: OnFailure containers: - image: ubuntu name: pod1 command: [sleep] args: [infinity] resources: limits: birentech.com/gpu: 1关键点资源名birentech.com/gpu必须与 Helm 中birenResourceName配置一致声明方式在limits中声明请求数量即期望分配的壁仞卡数量例如birentech.com/gpu: 2表示申请 2 张壁仞卡配额模式HAMi 调度器读取的是容器limits中的壁仞资源数量。从源码看壁仞当前采用的是整卡数量分配模式见下文GenerateResourceRequests分析即以卡为单位进行切分复用不细粒度拆分显存/算力。4.2 多容器与多卡场景由于 HAMi 的设备抽象对容器是通用的壁仞资源同样支持在一个 Pod 中由多个容器分别声明、或单容器申请多张卡。调度器会为每个容器独立生成资源请求见 pkg/device/devices.go 的Resourcereqs它会遍历 init 容器与普通容器并调用各设备后端的GenerateResourceRequests。4.3 运行与验证kubectl apply -f examples/biren/default_use.yaml kubectl get pod pod1 -o widePod 调度成功后可通过以下方式验证壁仞设备已正确分配kubectl get pod pod1 -o yaml | grep -A5 hami.io正常输出应包含 HAMi 写入的壁仞分配注解hami.io/biren-devices-allocated其值形如birentech.com/use-biren:xxx,设备UUID,Biren,0,0;其中第一段为设备资源标识之后为设备 UUID、类型Biren、分配的显存与算力值。五、源码级原理壁仞后端如何接入 HAMi 设备抽象层HAMi 通过 pkg/device/devices.go 定义的Devices接口抽象所有异构加速设备。壁仞后端 pkg/device/biren/device.go 实现了该接口的全部方法下面拆解关键实现。5.1 常量与注解约定pkg/device/biren/device.go 定义了一系列关键标识const ( HandshakeAnnos hami.io/node-handshake-biren RegisterAnnos hami.io/node-biren-register BirenDevice Biren BirenCommonWord Biren BirenInUse birentech.com/use-biren BirenNoUse birentech.com/nouse-biren BirenUseUUID birentech.com/use-gpuuuid BirenNoUseUUID birentech.com/nouse-gpuuuid )这些注解的含义注解用途hami.io/node-handshake-biren节点握手注解用于节点健康检查与设备注册超时判断hami.io/node-biren-register节点注册注解设备插件将壁仞设备列表序列化后写入此注解birentech.com/use-biren/birentech.com/nouse-birenPod 级筛选指定使用/不使用某类型壁仞卡birentech.com/use-gpuuuid/birentech.com/nouse-gpuuuidPod 级筛选指定使用/排除特定壁仞卡 UUID其中use-biren/nouse-biren/use-gpuuuid/nouse-gpuuuid四类注解允许用户在提交 Pod 时通过 annotations 做精细化筛选这与 NVIDIA 后端的筛选机制完全对齐底层复用 pkg/device/devices.go 的CheckUUID实现。5.2 设备初始化与注册pkg/device/biren/device.go 的InitBirenDevice完成三件事保存resourceCountName即birentech.com/gpu向全局InRequestDevices/SupportDevices注册壁仞的请求/分配注解键hami.io/biren-devices-to-allocate与hami.io/biren-devices-allocated注册握手注解hami.io/node-handshake-biren。5.3 节点设备上报与解析GetNodeDevicespkg/device/biren/device.go从节点注解hami.io/node-biren-register中读取设备插件上报的设备列表进行反序列化后统一打上DeviceVendor Biren标记并将Devcore固定为 100仅用于评分计算。设备插件上报的设备编码格式由 pkg/device/devices.go 的EncodeNodeDevices定义每台设备字段依次为ID,Count,Devmem,Devcore,Type,Numa,Health,Index,Mode。5.4 资源请求解析整卡分配模式GenerateResourceRequestspkg/device/biren/device.go负责把容器 spec 中的资源声明翻译为调度器可用的请求结构。它从limits回退到requests读取birentech.com/gpu的数量校验其大于 0 且不超过math.MaxInt32后构造请求return device.ContainerDeviceRequest{ Nums: int32(n), // 申请卡数 Type: BirenDevice, // 设备类型 Biren Memreq: int32(memnum), // 显存请求固定 0 MemPercentagereq: int32(mempnum), // 显存百分比固定 100 Coresreq: corenum, // 算力核请求固定 0 }可以看出壁仞当前采用的是整卡100% 显存分配MemPercentagereq固定为 100Memreq与Coresreq为 0即每张卡作为一个不可再拆分的分配单位通过时间片共享time-slicing实现多 Pod 复用。5.5 调度过滤与分配FitFitpkg/device/biren/device.go是壁仞设备调度的核心依次执行以下过滤健康检查跳过Health false的设备类型匹配校验请求类型是否为BirenUUID 筛选调用CheckUUID校验use-gpuuuid/nouse-gpuuuid注解约束容量检查dev.Count dev.Used时说明该卡时间片已耗尽跳过独占模式检查若 Pod 指定了互斥调度策略GPUSchedulerPolicyMutex则已占用设备不再分配数量扣减每命中一台设备k.Nums--并记录设备 UUID、Index、类型等分配信息直到满足请求数量。此外AddResourceUsagepkg/device/biren/device.go在调度记账时累加设备的Used、Usedcores、Usedmem使后续 Pod 能够感知已占用的共享份额。5.6 Pod 打标与节点锁定调度成功后PatchAnnotationspkg/device/biren/device.go把分配结果写入 Pod 注解hami.io/biren-devices-to-allocate与hami.io/biren-devices-allocated设备插件据此完成容器注入。同时LockNode/ReleaseNodeLockpkg/device/biren/device.go在绑定阶段对节点加锁避免并发调度冲突NodeCleanUp在节点失联时清理握手注解。5.7 健康检查CheckHealthpkg/device/biren/device.go委托通用的device.CheckHealthpkg/device/devices.go实现通过握手注解判断设备插件是否存活若插件在 60 秒内未续约且节点上已无壁仞可分配资源则触发节点清理流程。六、端到端流程总结将以上源码串联起来一个壁仞 GPU 任务在 HAMi 中的完整生命周期如下注册节点上的 biren-device-plugin 探测壁仞卡上报birentech.com/gpu可分配资源并写入hami.io/node-biren-register注册注解请求解析用户提交声明birentech.com/gpu: N的 PodHAMi 调度器调用GenerateResourceRequests生成整卡请求调度过滤Fit依据健康状态、类型、UUID 约束、时间片余量与独占策略挑选合适的壁仞卡打标与绑定PatchAnnotations将分配结果写入 Pod 注解LockNode锁定节点随后 Pod 被绑定到目标节点容器注入biren-device-plugin 读取 Pod 注解为容器注入壁仞运行库与设备应用开始使用壁仞加速卡健康维护调度器通过握手注解持续巡检插件健康状态异常时触发节点清理与资源回收。七、限制与注意事项整卡分配从GenerateResourceRequests可知壁仞当前不支持显存/算力级别的细粒度切分多 Pod 共享依靠时间片机制外部依赖底层设备探测与容器注入依赖独立的 biren-device-pluginHAMi 仓库本身不包含该插件的部署清单需按插件项目文档单独部署资源名一致性Helm 中birenResourceName、设备配置biren.resourceCountName与 Pod 中limits的声明必须完全一致否则资源请求无法被识别无评分参与ScoreNode返回 0pkg/device/biren/device.go表明壁仞设备目前不参与节点优选评分节点选择主要依赖设备过滤后的适配性。八、参考资料壁仞设备后端实现pkg/device/biren/device.go设备抽象接口与通用工具pkg/device/devices.go调度器设备初始化注册pkg/scheduler/config/config.goHelm 壁仞配置 charts/hami/values.yaml、charts/hami/templates/scheduler/device-configmap.yaml壁仞任务示例examples/biren/default_use.yaml壁仞后端测试pkg/device/biren/device_test.go【免费下载链接】HAMiHeterogeneous GPU Sharing on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ha/HAMi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 HAMi 对接壁仞（Biren）GPU：设备插件部署、任务调度与源码实现解析
HAMi 对接壁仞BirenGPU设备插件部署、任务调度与源码实现解析【免费下载链接】HAMiHeterogeneous GPU Sharing on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ha/HAMi导读本文聚焦开源项目 HAMiHeterogeneous GPU Sharing on Kubernetes对壁仞Biren国产加速卡的原生支持能力。你将了解如何部署壁仞设备插件、如何在 Kubernetes 中声明birentech.com/gpu资源并提交壁仞 GPU 任务以及 HAMi 调度器如何识别、分配并打标壁仞设备。文末结合 pkg/device/biren/device.go 与 Helm 配置深入剖析壁仞设备接入 HAMi 设备抽象层的完整实现链路帮助你掌握异构 GPU 共享体系下新增国产芯片后端的方法论。一、概述壁仞设备在 HAMi 中的接入方式壁仞Biren是国内 GPU 厂商其加速卡通过birentech.com/gpu资源名暴露给 Kubernetes。HAMi 将壁仞作为异构设备之一接入其统一的设备抽象层使壁仞卡能够像 NVIDIA GPU 一样被调度器统一管理、共享与打标。从 pkg/scheduler/config/config.go 的初始化代码可见壁仞设备在调度器启动时通过biren.InitBirenDevice注册进全局设备表{biren.BirenDevice, biren.BirenCommonWord, func(cfg any) (device.Devices, error) { birenConfig, ok : cfg.(biren.BirenConfig) if !ok { return nil, fmt.Errorf(invalid configuration for %s, biren.BirenCommonWord) } return biren.InitBirenDevice(birenConfig), nil }, config.BirenConfig},壁仞后端接入的关键点在于HAMi 本身不负责壁仞卡的底层探测与容器注入这部分由独立的壁仞设备插件biren-device-plugin承担。HAMi 调度器只负责在集群层面感知壁仞设备、执行资源分配与 Pod 打标。因此使用壁仞支持需要分两步先部署设备插件再通过 HAMi 调度任务。二、部署 biren-device-plugin在 HAMi 调度器介入之前集群中的每个壁仞节点都需要运行独立的壁仞设备插件其作用是探测节点上的壁仞加速卡向 kubelet 上报birentech.com/gpu可分配资源依据 HAMi 调度器写入 Pod 的分配注解annotation为容器注入壁仞运行库、完成设备挂载与环境变量设置。设备插件由独立的开源项目 biren-device-plugin 提供原文档指向其外部仓库本文不再重复外部链接部署方式为标准的 DaemonSet 部署。部署完成后节点上应出现壁仞资源可通过如下命令验证kubectl describe node node-name | grep birentech正常输出应包含类似birentech.com/gpu: 8的可分配数量且节点上出现 HAMi 约定的壁仞注册注解见下文源码解析表示设备插件已与 HAMi 完成握手。三、在 Helm 中启用并配置壁仞资源部署 HAMi 时壁仞支持默认开启。在 charts/hami/values.yaml 中#Biren Parameters birenResourceName: birentech.com/gpu对应devices.biren配置段charts/hami/values.yamlbiren: enabled: true customresources: - birentech.com/gpu各字段说明字段默认值说明birenResourceNamebirentech.com/gpu壁仞设备资源名即 Pod 中声明的资源配额名devices.biren.enabledtrue是否启用壁仞设备支持devices.biren.customresources[birentech.com/gpu]需要注册到 kube-scheduler 扩展资源清单中的壁仞资源名Helm 渲染时调度器的设备配置文件ConfigMap会生成壁仞段落charts/hami/templates/scheduler/device-configmap.yamlbiren: resourceCountName: {{ .Values.birenResourceName }}即最终的设备配置为biren: resourceCountName: birentech.com/gpu同时_helpers.tpl 会把birentech.com/gpu追加到调度器扩展资源白名单并标记ignoredByScheduler: true含义是该资源不参与 kube-scheduler 默认节点过滤逻辑节点是否满足条件完全交由 HAMi 扩展调度器extender判断从而让调度器可以灵活地在已注册壁仞设备的节点间做细粒度分配。四、提交壁仞 GPU 任务4.1 最小可运行示例原文档给出的壁仞任务清单与仓库 examples/biren/default_use.yaml 完全一致apiVersion: v1 kind: Pod metadata: name: pod1 spec: restartPolicy: OnFailure containers: - image: ubuntu name: pod1 command: [sleep] args: [infinity] resources: limits: birentech.com/gpu: 1关键点资源名birentech.com/gpu必须与 Helm 中birenResourceName配置一致声明方式在limits中声明请求数量即期望分配的壁仞卡数量例如birentech.com/gpu: 2表示申请 2 张壁仞卡配额模式HAMi 调度器读取的是容器limits中的壁仞资源数量。从源码看壁仞当前采用的是整卡数量分配模式见下文GenerateResourceRequests分析即以卡为单位进行切分复用不细粒度拆分显存/算力。4.2 多容器与多卡场景由于 HAMi 的设备抽象对容器是通用的壁仞资源同样支持在一个 Pod 中由多个容器分别声明、或单容器申请多张卡。调度器会为每个容器独立生成资源请求见 pkg/device/devices.go 的Resourcereqs它会遍历 init 容器与普通容器并调用各设备后端的GenerateResourceRequests。4.3 运行与验证kubectl apply -f examples/biren/default_use.yaml kubectl get pod pod1 -o widePod 调度成功后可通过以下方式验证壁仞设备已正确分配kubectl get pod pod1 -o yaml | grep -A5 hami.io正常输出应包含 HAMi 写入的壁仞分配注解hami.io/biren-devices-allocated其值形如birentech.com/use-biren:xxx,设备UUID,Biren,0,0;其中第一段为设备资源标识之后为设备 UUID、类型Biren、分配的显存与算力值。五、源码级原理壁仞后端如何接入 HAMi 设备抽象层HAMi 通过 pkg/device/devices.go 定义的Devices接口抽象所有异构加速设备。壁仞后端 pkg/device/biren/device.go 实现了该接口的全部方法下面拆解关键实现。5.1 常量与注解约定pkg/device/biren/device.go 定义了一系列关键标识const ( HandshakeAnnos hami.io/node-handshake-biren RegisterAnnos hami.io/node-biren-register BirenDevice Biren BirenCommonWord Biren BirenInUse birentech.com/use-biren BirenNoUse birentech.com/nouse-biren BirenUseUUID birentech.com/use-gpuuuid BirenNoUseUUID birentech.com/nouse-gpuuuid )这些注解的含义注解用途hami.io/node-handshake-biren节点握手注解用于节点健康检查与设备注册超时判断hami.io/node-biren-register节点注册注解设备插件将壁仞设备列表序列化后写入此注解birentech.com/use-biren/birentech.com/nouse-birenPod 级筛选指定使用/不使用某类型壁仞卡birentech.com/use-gpuuuid/birentech.com/nouse-gpuuuidPod 级筛选指定使用/排除特定壁仞卡 UUID其中use-biren/nouse-biren/use-gpuuuid/nouse-gpuuuid四类注解允许用户在提交 Pod 时通过 annotations 做精细化筛选这与 NVIDIA 后端的筛选机制完全对齐底层复用 pkg/device/devices.go 的CheckUUID实现。5.2 设备初始化与注册pkg/device/biren/device.go 的InitBirenDevice完成三件事保存resourceCountName即birentech.com/gpu向全局InRequestDevices/SupportDevices注册壁仞的请求/分配注解键hami.io/biren-devices-to-allocate与hami.io/biren-devices-allocated注册握手注解hami.io/node-handshake-biren。5.3 节点设备上报与解析GetNodeDevicespkg/device/biren/device.go从节点注解hami.io/node-biren-register中读取设备插件上报的设备列表进行反序列化后统一打上DeviceVendor Biren标记并将Devcore固定为 100仅用于评分计算。设备插件上报的设备编码格式由 pkg/device/devices.go 的EncodeNodeDevices定义每台设备字段依次为ID,Count,Devmem,Devcore,Type,Numa,Health,Index,Mode。5.4 资源请求解析整卡分配模式GenerateResourceRequestspkg/device/biren/device.go负责把容器 spec 中的资源声明翻译为调度器可用的请求结构。它从limits回退到requests读取birentech.com/gpu的数量校验其大于 0 且不超过math.MaxInt32后构造请求return device.ContainerDeviceRequest{ Nums: int32(n), // 申请卡数 Type: BirenDevice, // 设备类型 Biren Memreq: int32(memnum), // 显存请求固定 0 MemPercentagereq: int32(mempnum), // 显存百分比固定 100 Coresreq: corenum, // 算力核请求固定 0 }可以看出壁仞当前采用的是整卡100% 显存分配MemPercentagereq固定为 100Memreq与Coresreq为 0即每张卡作为一个不可再拆分的分配单位通过时间片共享time-slicing实现多 Pod 复用。5.5 调度过滤与分配FitFitpkg/device/biren/device.go是壁仞设备调度的核心依次执行以下过滤健康检查跳过Health false的设备类型匹配校验请求类型是否为BirenUUID 筛选调用CheckUUID校验use-gpuuuid/nouse-gpuuuid注解约束容量检查dev.Count dev.Used时说明该卡时间片已耗尽跳过独占模式检查若 Pod 指定了互斥调度策略GPUSchedulerPolicyMutex则已占用设备不再分配数量扣减每命中一台设备k.Nums--并记录设备 UUID、Index、类型等分配信息直到满足请求数量。此外AddResourceUsagepkg/device/biren/device.go在调度记账时累加设备的Used、Usedcores、Usedmem使后续 Pod 能够感知已占用的共享份额。5.6 Pod 打标与节点锁定调度成功后PatchAnnotationspkg/device/biren/device.go把分配结果写入 Pod 注解hami.io/biren-devices-to-allocate与hami.io/biren-devices-allocated设备插件据此完成容器注入。同时LockNode/ReleaseNodeLockpkg/device/biren/device.go在绑定阶段对节点加锁避免并发调度冲突NodeCleanUp在节点失联时清理握手注解。5.7 健康检查CheckHealthpkg/device/biren/device.go委托通用的device.CheckHealthpkg/device/devices.go实现通过握手注解判断设备插件是否存活若插件在 60 秒内未续约且节点上已无壁仞可分配资源则触发节点清理流程。六、端到端流程总结将以上源码串联起来一个壁仞 GPU 任务在 HAMi 中的完整生命周期如下注册节点上的 biren-device-plugin 探测壁仞卡上报birentech.com/gpu可分配资源并写入hami.io/node-biren-register注册注解请求解析用户提交声明birentech.com/gpu: N的 PodHAMi 调度器调用GenerateResourceRequests生成整卡请求调度过滤Fit依据健康状态、类型、UUID 约束、时间片余量与独占策略挑选合适的壁仞卡打标与绑定PatchAnnotations将分配结果写入 Pod 注解LockNode锁定节点随后 Pod 被绑定到目标节点容器注入biren-device-plugin 读取 Pod 注解为容器注入壁仞运行库与设备应用开始使用壁仞加速卡健康维护调度器通过握手注解持续巡检插件健康状态异常时触发节点清理与资源回收。七、限制与注意事项整卡分配从GenerateResourceRequests可知壁仞当前不支持显存/算力级别的细粒度切分多 Pod 共享依靠时间片机制外部依赖底层设备探测与容器注入依赖独立的 biren-device-pluginHAMi 仓库本身不包含该插件的部署清单需按插件项目文档单独部署资源名一致性Helm 中birenResourceName、设备配置biren.resourceCountName与 Pod 中limits的声明必须完全一致否则资源请求无法被识别无评分参与ScoreNode返回 0pkg/device/biren/device.go表明壁仞设备目前不参与节点优选评分节点选择主要依赖设备过滤后的适配性。八、参考资料壁仞设备后端实现pkg/device/biren/device.go设备抽象接口与通用工具pkg/device/devices.go调度器设备初始化注册pkg/scheduler/config/config.goHelm 壁仞配置 charts/hami/values.yaml、charts/hami/templates/scheduler/device-configmap.yaml壁仞任务示例examples/biren/default_use.yaml壁仞后端测试pkg/device/biren/device_test.go【免费下载链接】HAMiHeterogeneous GPU Sharing on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ha/HAMi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考