企业官网建设流程全解析

如何注册公司网站免费注册,百度关键词竞价价格,国际知名工程咨询公司,电商设计素材网在企业级大模型场景迅速普及的背景下#xff0c;如何在同一平台上高效管理寒武纪、海光等国产加速器#xff0c;并实现跨厂商、跨架构的统一调度与性能可观测#xff0c;成为许多 AI 基础设施团队共同面对的挑战。星环科技的人工智能产品部 AI - 工具平台研发侯雨希#xf…在企业级大模型场景迅速普及的背景下如何在同一平台上高效管理寒武纪、海光等国产加速器并实现跨厂商、跨架构的统一调度与性能可观测成为许多 AI 基础设施团队共同面对的挑战。星环科技的人工智能产品部 AI - 工具平台研发侯雨希在本次HAMi Meetup分享中深入解析了团队在 HAMi 上适配多型号国产 GPU 的全过程并介绍了如何借助 DRA 建立更标准化、更具可延展性的算力抽象体系。痛点与挑战星环科技的 LLMOps 平台承担企业级 AI 开发的核心职责从训练、微调、推理到在线代码开发与调试再到底层资源调度、任务排队策略、多租户隔离、可观测性体系建设所有功能都必须建立在可靠、可扩展的算力管理之上。然而当前国产 GPU / AI 加速器生态呈现出多型号、多架构、多设备插件并存的特点不同厂商在资源上报方式、切分能力、序列号获取、指标暴露及隔离机制实现上各不相同。对于 LLMOps 这种高度依赖底层资源精确感知的平台而言这意味着难以统一抽象更难以在多租户环境中保障资源一致性。在寒武纪环境中设备插件支持动态配置 sMLU 显存的切片粒度但是 HAMi 硬编码资源单位导致无法正确计算显存总量动态切片过细又会触发 GRPC 包过大的问题多型号混布时HAMi 无法区分型号不允许指定型号部署。海光 GPU 又存在另一类挑战设备 ID 不唯一使得多租户管理无法依赖稳定 IDexporter 指标暴露路径和 HAMi 插件记录路径不匹配使得 Pod–设备映射错误VDCU 切分后更需要序列号级别的唯一标识。种种挑战让国产 GPU 的统一接入变得困难尤其在资源共享、隔离、配额、调度策略以及可观测性等方面更是错误频发。解决这一系列问题的关键是以 HAMi 作为统一的适配层并借助 DRA 建立通用算力抽象。解决方案侯雨希首先介绍了利用 HAMi 作为多厂商硬件的统一管理底座为星环 LLMOps 平台带来的结构性价值。HAMi 在调度器、设备插件、资源抽象三个层面提供了清晰的接口使平台能够不依赖厂商自研插件的实现细节而以统一的方式接入不同架构的国产 GPU。在寒武纪设备上团队首先解决的是 sMLU 动态切片粒度问题由于 HAMi 默认的 sMLU 粒度固定为 256MB而寒武纪设备插件允许用户配置切分粒度甚至可以将 sMLU unit 设置为 0表示按 1% 粒度切分这一特殊值无法直接参与显存推导计算从而导致总显存与可切分单元无法正确解析。为此团队在 HAMi 的寒武纪设备配置中新增 sMLU unit 以及总可分配显存 MemoryAllocatable使其既能支持固定粒度也能在“0 值”情况下通过先读取总显存再除以 100 获得粒度成功消除计算死锁。其次在多型号混布情况下寒武纪设备插件默认不会区分不同型号设备导致 HAMi 不支持将任务分配到特定类型的寒武纪设备。星环团队通过启用设备插件的 --enable-device-type 与 --node-label 选项让设备插件按型号生成不同的资源名并周期性上报型号信息至节点 label随后再修改 HAMi 对寒武纪的实现以及配置文件支持每种型号独立配置资源名称、显存容量、可分配单元、sMLU unit从而使寒武纪的多型号管理与其他厂商对齐。面对“切分过细导致 GRPC 信息体过大”的问题团队结合设备插件与 HAMi 的实现逻辑提出了两种缓解方式一是限制最小显存切分单元避免因粒度过小使资源更新失败二是迁移至 Kubernetes DRA利用 DRA 的“可消耗容量的设备”的特性通过用容量来定义显存资源数量从而避免该问题。在海光适配中挑战完全不同。海光开源设备插件使用“设备序号”构造 ID但序号在不同节点间会重复导致平台无法以设备 ID 维度进行资源组管理、GPU 限制调度或算力大盘统计。为此星环团队直接调用海光驱动 go SDK 的 API 查询硬件序列号并以序列号作为设备真实 ID从而实现“节点无关、硬件绑定”的唯一标识。在 VDCU 场景中团队还建立了序列号到设备序号的反向映射确保切片后的虚拟设备也能准确追踪对应物理 GPU。在指标采集方面HAMi 的 DCU exporter 与设备插件记录路径不一致会导致 Pod–VDCU 映射错误。星环团队参考 HAMi 插件的记录方式从 /usr/local/vgpu/dcu 目录中解析容器与虚拟 GPU 的绑定关系并改写 exporter 逻辑通过查询 Pod 注解而非 PodResource API 获取设备分配信息从而修复指标标记让平台可观测性保持一致性。更具战略价值的是 DRA 在未来算力抽象中的作用。侯雨希指出DRA 的两大核心能力——可消耗容量与计数器使其能够表达“同一物理 GPU 被重复分配给多个 ResourceClaim”的共享模式以及“逻辑设备通过计数器消耗物理资源”的约束模型。在寒武纪、海光、英伟达等需要动态切分的设备中团队以“每张物理卡作为一个 DRA 设备”进行建模使用设备容量直接定义算力与显存对于昇腾等使用固定模板切分的架构则以“每个模板作为一个 DRA 设备”通过在 Shared Counter 共享计数器中定义单个 Ascend NPU 可分配的硬件资源总量以及为每个模板对应的 DRA 设备使用 Consumes Counter 消耗计数器来定义每个模板实例分配的资源数量使模板选择可以按需动态分配。通过这些模型星环团队为 DRA 构建了一个能够覆盖市面主流国产加速器的抽象基础奠定了未来向原生 Kubernetes 过渡的路径。落地实践在星环科技的 LLMOps 平台中这套基于 HAMi 与 DRA 的多加速器管理体系已在多个企业场景落地验证。首先是 LLMOps 的核心需求——多租户隔离与资源组管理。通过 HAMi 的多型号资源识别能力与海光设备唯一 ID 的修复平台能够针对不同租户配置独立资源池、配额与优先级策略结合 DRA平台还可以进一步将每个资源组划分为“独占资源”、“共享资源”、“弹性资源”满足训练、推理与开发任务的差异化需求。在寒武纪 MLU370/590 场景中平台能够以统一方式为不同型号配置资源对象避免了以往“混布导致调度不可控”的情况。同时平台可以按需创建不同规格的 SMU 分片根据用户任务选择合适的算力与显存组合避免整卡占用让资源利用率显著提升。特别是在多模型、多租户并行运行的企业场景中SMU 动态切片配合 HAMi 的调度策略使平台具备“高密度混部”的能力实现更高复用率。在海光 DCU 环境中修复后的设备唯一 ID 使平台首次实现“跨节点的设备连续性管理”这对于算力大盘统计与 GPU 调度策略至关重要。团队能够准确地追踪每张 GPU 的长期健康状态、利用效率、任务负载模式为企业提供稳定性评估、资源规划建议以及 GPU 成本分析。此外经重构的 DCU exporter 让平台能够获得与实际 GPU 分配完全一致的指标信息为模型训练监控、推理 SLA 保证、任务排查等提供坚实基础。更值得关注的是 DRA 建模的落地实践它为未来异构 GPU 的“原生统一抽象”铺平了道路。在海光场景中团队通过允许 DRA 设备 multiple allocations使多个任务能在同一物理 GPU 上共享算力与显存并通过 computer unit 与 memory 的声明确保合理分配。在昇腾场景中团队以模板为 DRA 设备通过 shared counter 表达硬件资源池使模板选择可以按需动态分配实现自动适配不同任务规模。通过这些案例星环科技验证了 DRA 在动态算力切分、多租户混部与资源抽象上的可行性为未来更多厂商与设备加入统一抽象体系提供了范例。目前星环科技已将 HAMi 与 DRA 的适配能力融入 LLMOps 平台为企业提供跨加速器的统一训练与推理环境同时在模型管理、自动化训练任务编排、运维监控等方向进一步集成使平台可在海外 GPU、高端国产 GPU 与多元异构硬件间灵活切换为企业智能化升级提供长期可持续的算力基础。结语星环科技在寒武纪、海光等国产加速器上的适配实践展示了 HAMi 作为统一算力抽象与调度底座的价值也验证了 DRA 在异构资源建模中的未来潜力。通过双方的深度协同国产 GPU 能力得以在云原生体系内被一致管理而 LLMOps 平台也获得了跨架构、跨型号的统一资源视图。