让 NPU 更易共享：HAMi vNPU 技术演进与招商银行落地实践
7 月 25 日，招银数智创新 Meetup 杭州站举行，活动汇聚了金融机构、云厂商、开源社区与 AI Infra 领域的技术嘉宾，围绕国产算力、云原生推理与资源调度展开交流。HAMi 社区受邀参会，社区 Approver、密瓜智能（Dynamia）研发工程师 王纪飞带来了题为《让 NPU 更易共享：HAMi vNPU 技术演进与招商银行落地实践》的主题演讲。
这场分享的核心，不是某一项孤立的功能，而是一条完整的主线：HAMi vNPU 如何从"规格固定的硬切分"走向"按需分配的软切分"，又如何在这条路径上与招商银行一起，把能力推进到金融生产环境。本文结合现场分享与幻灯片，做一次更完整的技术回顾。
完整幻灯片 PDF 下载：hami-vnpu-cmb-practice-wangjifei-20260725.pdf
NPU 共享正在从"能用"走向"好用"——软切分让切分后的 NPU 在 Kubernetes 中被统一发现、调度与治理。
一、从"拥有算力"到"用好算力"
随着训练、推理与研发测试任务持续增加，不同厂商、不同型号的 GPU 与 NPU 分散管理，加上小型任务独占整卡带来的资源浪费日益突出，企业 AI 基础设施的重点正从"拥有算力"转向"用好算力"。这意味着算力不仅要被接入，还要能被切分、共享、调度和治理——这正是 HAMi vNPU 要解决的问题。
二、社区与招行的合作：需求、技术与验证形成闭环
这次分享的第一部分，回顾了 HAMi 社区与招商银行的协作脉络。双方的合作不是一次性的方案交付，而是一条连续的闭环：通过社区驱动建立长期联系，走进招行沐曦、昆仑芯、昇腾等真实项目去理解异构算力的实际需求，再把社区实现带进真实环境做联合验证。
在这条闭环里，招商银行既是 HAMi 的使用者，也是社区迭代的重要输入——它把异构算力场景中的真实约束、优先级与使用体验反馈回来，帮助社区判断哪些能力真正影响落地，避免闭门造车，并提供设备与环境来验证实现的兼容性、稳定性与可用性。
真实的生产需求，是开源社区最珍贵的输入；招商银行也由使用者，逐步成为社区的共建者。
三、vNPU 的演进：从硬切分到软切分
硬切分：能用，但离灵活共享还有距离
早期的 NPU 共享依赖厂商预先定义的硬切分。不同型号支持不同的固定切分类型（有的切四、有的切七），资源分配看似精确，实际上仍受硬编码边界约束。王纪飞把硬切分的局限归纳为三点：
- 规格不统一：跨型号体验难以一致，运维与调度都要为每种设备单独适配。
- 模板硬编码：只能选择预设组合，业务无法按实际负载弹性调整。
- 资源强绑定：算力限制与显存限制绑定在一起，只按显存对齐，利用率受限。
软切分为何一度受阻：底层 API 的差异
既然硬切分不够灵活，为什么不直接做软切分？王纪飞解释，问题的根子在底层 API。在 GPU 这条路径上，关键的运行时 API 可以被拦截与重定向，社区能够在进程与设备之间实施资源控制；但当时 NPU 的关键底层 API 并没有开放，无法完成同等程度的劫持与控制。
没有可控的执行入口，上层 Device Plugin 只能"分配设备"，无法实现真正的细粒度共享。
三次关键的技术条件变化
软切分真正变得可行，依赖技术条件的演进。社区经历了三次关键变化：首先是 CANN 开源，底层软件栈开放后社区开始准备支持昇腾共享；但在实验验证阶段，发现设备当时并不支持期望的多进程并发调用；直到驱动升级支持多进程，共享的基础才真正成熟。
这期间还有一个值得记录的"绕行"尝试——华为开源的 Flex:AI。它的目标是共享昇腾 NPU，但实现仍遵循当时的设备限制：通过远程调用汇聚请求，NPU 侧实际上保持单进程执行。它证明了"共享"在入口层可以做到，但设备侧仍受多进程限制，部署链路也更复杂。真正的突破，要等到设备本身支持多进程并发。
软切分落地：多进程 + hami-core → Kubernetes
当驱动升级让设备可以并发，华为加拿大实验室据此开发了底层的共享控制库（提供类似 hami-core 的能力），这套底层控制能力于是可以被 Device Plugin 与 Kubernetes 调度体系承接。王纪飞把生产落地拆成四步：
- 发现与注册：Device Plugin 识别昇腾设备，并向 Kubernetes 暴露可调度资源。
- 分配与注入：把调度结果转化为容器可见的设备与共享配置。
- 运行时控制：底层库在多进程条件下实施资源共享与限制。
- 闭环验证：把可用性、稳定性与体验问题带回社区持续迭代。
GPU 调度已经进入运行时编排层，不再只是简单的资源分配。
从实验室到生产：真实反馈反哺社区
从能跑通到真正好用，中间隔着大量工程细节。王纪飞坦言，HAMi 社区在落地中收到的真实反馈是：用户要处理复杂的驱动配置、面对 API 的不一致和独特的行为表现，心智负担很重。例如切分结果在容器内不可见（未劫持 dsmi，容器内执行 npu-smi info 仍看到整卡信息）、新分配的 vNPU 设备在一段时间未被使用会自动回收——这些都是社区需要持续打磨的地方。
也正是这种"把生产问题带回社区"的协作，沉淀出了可复用的开源能力。在与招商银行的联合验证中，相关超节点硬件入池率达到 100%，跨机调度概率降低 30%，资源切分粒度达到 1 GB 显存和 1% 算力。
四、性能数据：2 / 4 / 8 / 16 切分的拐点
软切分到底切多细才合适？王纪飞给出一组实测数据。测试环境为 910C 单卡、7B 级模型、输入 200 / 输出 128 token、每个 vNPU 单请求、取 P50：
| 切分规格 | TTFT（ms） | TPOT（ms/token） | 单卡实例数 | 场景判断 |
|---|---|---|---|---|
| 1 / 2 | 78 | 24.0 | 2 | 强时延 SLA |
| 1 / 4 | 92 | 29.7 | 4 | 线上推荐平衡点 |
| 1 / 8 | 134 | 43.9 | 8 | 密度优先 / 宽松 SLA |
| 1 / 16 | 248 | 76.4 | 16 | 开发测试 / 离线 |
关键观察是"拐点"而非"越细越好"。四切相对二切只增加约 18% 的 TTFT、24% 的 TPOT，时延仍可控，却把单卡实例密度提升到 4；而八切与十六切，则是用更明显的时延代价去换取实例密度，适合轻量模型、异步请求或更宽松的 SLA，乃至开发测试与离线任务。因此对在线服务，四切是推荐的平衡点。
切分粒度不是越细越好——找到满足 SLA 的那个最细档，才是真正的优化目标。
五、未来展望：体验改善与动态治理
分享的最后，王纪飞谈了两个方向。短期内是体验改善：让硬切分与软切分统一管理、任务按需分配且对上层无感知；支持容器内切分结果可见、补齐容器级算力显存监控；同步更新 volcano 昇腾 device-plugin 强化兼容矩阵；并优化 values 配置、补齐报错日志，让常见问题用户可以自主排查。一句话——让用户少记规则、平台看得清状态、升级有边界、异常能恢复。
更进一步的进阶能力，则是从静态切分走向动态治理：通过 Profiling 采集算子、显存、算力与时延特征，看懂负载并识别任务间干扰；在资源边界可控、状态可见之后，再做算力抢占（高优先级任务到来时动态回收或压缩低优先级算力，同时控制恢复成本与尾时延）和资源超卖（基于真实使用而非静态申请来共享余量，配合风险水位、限流与回退机制避免失控），从而理解负载、动态调整、提高整体利用率。
结语
从云原生走向 AI 原生，企业需要的不只是更多算力，更是一套能够统一管理、灵活共享、持续治理算力的基础设施底座。HAMi vNPU 从硬切分到软切分的演进，以及与招商银行的生产落地，正是这条路上的一次扎实推进——而真实需求持续反哺开源社区，让招行从使用者成长为共建者，才是这件事更长远的价值。
通过社区协作推动 AI 基础设施进步，而不是封闭系统——这是 HAMi 一直坚持的方式。
HAMi 项目地址：github.com/project-hami/hami。如果你对 NPU 共享、异构算力调度感兴趣，欢迎加入 HAMi 社区，与我们一起推动 Kubernetes 上的 AI 算力管理。