HAMi进入CNCF孵化阶段：异构算力调度的开源路径与真实边界

当AI应用从试点走向规模化生产，行业对算力基础设施的关注正在发生转向：从“能不能买到足够的GPU”，变成“能不能把已经买到的算力用好”。尤其是在信创落地和多技术路线并行的背景下，越来越多的企业同时持有NVIDIA、昇腾、昆仑芯、摩尔线程等不同架构的算力芯片，却因调度标准不统一、设备之间无法互通，形成一个个算力孤岛——大量硬件资源闲置，新的AI任务却拿不到足够算力。

2026年7月，由中国团队发起的开源异构算力调度项目HAMi正式晋升为CNCF（云原生计算基金会）Incubating（孵化）项目，随后招商银行基于HAMi搭建的AI调度平台入选CNCF官方标杆案例，让这个长期专注于底层调度的开源项目走到了台前[1][6]。要准确判断这一技术的真实价值，需要从可验证的事实出发，明确区分已被确认的进展、有前提约束的适用场景，以及仍待验证的假设。

已被确认的三个核心进展

在所有公开信息中，有三类事实具备独立的验证路径，不受宣传话术或关联信源的影响，构成了当前判断HAMi价值的基础。

首先是CNCF孵化认证的合规性与含金量。作为全球云原生领域最具影响力的开源组织，CNCF对项目的成熟度评估有着严格的三级体系：Sandbox（沙箱）面向早期探索的技术方案，Incubating（孵化）要求项目在技术成熟度、安全实践、社区治理、生产采用四个维度通过技术监督委员会的尽职调查，而Graduated（毕业）则代表项目已经成为全球范围内大规模应用的主流基础设施[6][7]。HAMi从2023年进入沙箱阶段，到2026年以全票通过孵化投票，意味着它已经跨过了开源项目从“有潜力的试验品”到“可用于生产环境的可信方案”的关键门槛，这一事实可以通过CNCF官方项目名录独立验证[8]。

其次是生产环境的落地验证，尤其是金融级场景的可行性。招商银行作为国内金融行业数字化转型的头部机构，其基于HAMi搭建的统一异构AI计算调度平台，是HAMi进入孵化阶段后首个被CNCF官方收录的标杆案例[2][9]。根据公开披露的信息，招商银行此前同时持有昆仑芯、昇腾、NVIDIA、摩尔线程等多个品牌的算力芯片，分属8个独立的资源集群，不同集群之间的算力无法互通，硬件资源的闲置问题突出。引入HAMi之后，所有异构芯片被纳入同一个统一调度池，实现了算力的跨架构弹性分配，分布式训练任务的跨机调度概率下降30%[9]。这里需要明确的是，公开宣传中提到的“硬件利用率提升至100%”，实际统计口径为硬件资源池化覆盖率——即所有异构硬件均已接入统一调度池、消除了算力孤岛，而非单卡稳态任务负载的占用率，这一口径差异是后续所有性能判断的基础[9]。

第三类最具说服力的证据，来自独立第三方的技术路线背书。2026年6月，NVIDIA正式在其官方KAI Scheduler中集成HAMi-core，将其作为GPU显存硬隔离的内置能力[6]。作为全球GPU领域的头部厂商，NVIDIA本身拥有成熟的vGPU技术和调度方案，其选择将开源社区的技术纳入官方产品体系，本身就是对HAMi核心技术路线合理性的有力认可。这一动作的证据强度远高于项目方或用户的自披露数据，也是HAMi区别于大量小众开源调度项目的核心标志。

除此之外，公开信息显示HAMi目前已经吸引了来自17个国家和地区的500余名开发者参与贡献，最终用户覆盖金融、汽车、物流、云服务等多个领域的超过300家企业。其中韩国SNOW Corp（NAVER旗下）用HAMi管理1000余张A100 GPU，在700%的流量峰值下将所需GPU数量减半，估算节省约1740万美元；蔚来汽车将其用于自动驾驶仿真场景，CI流水线的GPU利用率提升约10倍；贝壳找房的平台GPU利用率从13%提升至37%[6]。上述用户场景效果均为企业或项目方自披露数据，尚未经第三方独立审计或验证，仅代表特定部署环境下的落地结果，不构成通用效果承诺。

异构调度痛点下的真实价值

如果把HAMi的进展放到整个云原生AI基础设施的发展脉络中，就能看到它的出现恰好回应了行业长期存在的两个核心痛点。

第一个痛点是异构算力调度的标准碎片化问题。在Kubernetes最初的设计中，资源调度的核心对象是CPU和内存，对GPU、NPU等异构加速器的支持始终是补丁式的。长期以来，不同硬件厂商都有自己的调度接口和虚拟化方案，企业如果同时使用多个品牌的算力芯片，就必须为每一种芯片维护独立的集群、独立的调度系统，不仅运维成本极高，也无法实现算力的跨架构共享——这正是招商银行、国有大行等信创落地场景中普遍面临的问题。

HAMi的核心价值在于，它基于Kubernetes 1.26版本引入的动态资源分配（DRA）标准接口，实现了对不同架构算力芯片的统一抽象：不管是NVIDIA的GPU还是昇腾的NPU，对上层调度器来说都是可以统一分配、切分、隔离的算力资源。目前HAMi已经适配了NVIDIA、华为昇腾、寒武纪、海光DCU、摩尔线程、燧原、昆仑芯、AWS Neuron等十余种主流加速器，是当前CNCF生态中公开适配硬件品类最广的异构调度开源方案之一[6]。对于需要同时使用多品牌芯片的企业来说，这意味着不需要再为每一种芯片单独做适配开发，只需要一套系统就能完成所有异构算力的统一管理。

第二个痛点是中国开源技术从本土实践走向国际主流的路径问题。过去很长一段时间，中国的开源项目要么是面向本土场景的闭环方案，要么是国际主流项目的本地化定制，很少有能进入全球云原生核心生态的原创技术路线。HAMi的特殊之处在于，它起源于中国企业的内部工程实践，却没有停留在本土市场——它不仅进入了CNCF的孵化阶段，获得了NVIDIA的官方集成，还落地了韩国、东南亚、欧洲等地区的海外客户，其核心维护者多次在全球各地的KubeCon等技术峰会上分享技术方案[6]。这意味着这套源于中国本土信创场景的异构调度方案，已经被纳入了全球云原生技术的主流发展路径，而不是一个孤立的区域型项目。

对于正在大规模推进信创落地的中国行业用户来说，这一路径的价值尤为突出：它既可以满足多品牌芯片统一调度的本土需求，又符合全球云原生的技术标准，避免了采用封闭方案带来的技术栈锁定风险。尤其是对于金融、运营商、央企等对技术开放性和供应链安全要求极高的行业，这一特性是大量闭源调度方案或小众开源项目不具备的。

技术能力的明确边界与证据缺口

尽管HAMi的技术价值已经得到初步验证，但现有公开信息中大量关于性能优势、成本收益的宣传，都存在明确的适用边界和证据缺口。如果忽略这些约束，很容易形成不符合实际的预期。

最核心的边界是性能指标的口径差异。如前所述，公开宣传中提到的“100%利用率”实际是硬件池化覆盖率，而非单卡稳态任务负载的占用率。根据数据中心行业的通行共识，为了应对突发负载和容灾需求，金融行业生产集群的单卡稳态利用率通常不会超过70%，超过这一阈值就需要预留冗余算力。目前公开的符合行业统计标准的调度效果数据中，贝壳找房的单卡利用率从13%提升至37%、DaoCloud的非金融场景集群平均利用率超过80%，均来自企业自披露[6]。如果将池化覆盖率误读为单卡运行效率，会直接导致对投入产出比的错误测算。

其次是技术落地的工程约束，这些隐形成本会直接吃掉大部分预期的硬件节省收益。HAMi的核心能力强依赖于Kubernetes 1.26及以上版本的动态资源分配接口[6]，对于大量仍在使用1.25及以下版本的存量集群来说，升级的成本和风险都不容忽视。尤其是在金融行业，集群版本升级需要经过业务无中断迁移、等保合规验证、容灾系统切换等多个环节，整个周期长达3-6个月，单集群的隐形成本可达百万级。这一成本测算主要来自金融行业云原生落地的普遍经验，尚未有公开的第三方统计数据支撑。除此之外，对于未被HAMi官方适配的小众信创芯片，每新增一款芯片的适配成本约为2-3人月的研发投入；如果采用1/16以下的细粒度算力切分，还会带来最高15%的性能损耗。上述适配成本与性能损耗数据均来自项目方的工程实践总结，尚未经第三方公开验证。这些工程约束意味着，HAMi的成本收益仅对同时持有3类以上异构芯片、年硬件采购额超过5000万的头部客户成立，如果客户的异构芯片少于3种，开源方案的收益甚至无法覆盖集群升级的成本。

第三是相对技术优势的未验证性。目前没有任何第三方中立实验室发布过HAMi与CNCF生态中其他成熟调度项目（如已经毕业的Volcano、同处于孵化阶段的Koordinator）的头对头性能测试报告，所有关于HAMi性能更优的表述都缺乏参照基准。目前公开的同类项目落地信息显示，Volcano和Koordinator均已在国内头部机构实现生产部署，二者与HAMi的性能差异尚未有公开的对比数据支撑。HAMi目前的错位优势仅在于公开适配的硬件品类更多，而非在技术性能上具备经过验证的领先优势。此外，目前公开的最大规模落地案例仅为SNOW Corp的1000张A100集群，尚无万卡级大模型训练集群的生产验证数据，大规模调度下的延迟、资源碎片率等扩展性风险尚未排除。这意味着HAMi的能力目前仅能在千卡级及以下的集群规模下得到验证，万卡级大模型训练场景的适用性仍待观察。

社区治理与商业化的待解问题

除了技术层面的边界，HAMi在社区中立性和商业化路径上的不确定性，是影响其长期发展的更核心因素。

首先是社区中立性的待验证。尽管HAMi已经通过了CNCF孵化阶段的治理要求，但根据CNCF项目公开的贡献者统计信息，目前其核心维护者中多数来自项目发起方，非发起方的核心贡献占比仍然较低。对于金融、信创等对供应链安全要求极高的客户来说，开源项目的社区中立性优先级往往远高于10%以内的性能差异——如果项目的核心控制权高度集中于单一商业公司，客户就会面临未来项目闭源、商业版本涨价、技术路线被绑定的风险。此外，不同公开信源中对HAMi发起主体的表述存在不一致，部分信源标注为范式智能发起，部分标注为密瓜智能发起，尽管这大概率是企业架构调整或品牌更名带来的传播疏漏，但也从侧面反映出项目的治理透明度仍有提升空间。按照CNCF的开放治理标准，只有当非发起方的核心贡献占比提升至30%以上，才能认为项目真正实现了社区中立，不再受单一商业主体的控制。

其次是商业化路径的不确定性。目前公开信息中提到的300余家企业用户，绝大多数使用的是免费的开源版本，没有任何公开的付费客户数量、商用服务收入、云厂商合作分成协议等数据。这意味着尽管HAMi的技术已经得到了广泛应用，但发起方尚未跑通清晰的价值截留路径——如果客户只需要免费的开源版本就能满足需求，或者云厂商直接将HAMi作为免费组件集成到自己的云服务中，那么发起方就很难从开源项目中获得足够的商业回报来支撑持续的研发投入。从开源项目的发展规律来看，大量技术优秀的开源项目最终都变成了云厂商的免费上游组件，未能形成独立的商业化闭环，这也是HAMi当前面临的最大长期风险。

从竞争格局来看，HAMi也并未占据绝对的市场优势。如前所述，Volcano和Koordinator都已经在头部客户中实现了大规模落地，且二者的社区中立性更好、成熟度更高。如果HAMi不能在硬件适配的广度之外建立更多的差异化优势，或者不能尽快提升社区中立性，那么很容易被成熟项目挤压市场空间——毕竟对于大多数客户来说，如果主流调度项目经过简单适配就能满足需求，就没有必要引入一个新的技术栈。

后续值得追踪的核心判断指标

当前所有关于HAMi的判断，都建立在有限的公开信息基础上。如果要将判断从“特定场景可用的技术方案”升级为“通用可复用的基础设施”，还需要等待五个核心指标的落地，每一个指标的出现都会显著改变当前的判断边界：

第一，是否有第三方中立实验室发布HAMi与Volcano、Koordinator在通用AI负载下的头对头对比测试报告，且所有性能指标都明确披露统计口径、对比基期和业务控制变量，排除场景特殊性的影响。如果这一报告落地，才能确认HAMi相对同类方案的真实性能优势。

第二，发起方是否公开澄清项目的治理结构，且非发起方的核心贡献者占比提升至30%以上。这是判断项目是否真正实现社区中立、解除客户供应链安全顾虑的核心标志。

第三，是否有3家以上非关联的头部客户披露同口径的利用率提升、成本节省数据。目前所有公开的用户性能数据均来自项目方的宣传材料，只有当非关联客户主动披露真实的落地效果，才能排除宣传话术的放大效应，确认其通用价值。

第四，是否有万卡级大模型训练集群的生产验证数据。这一指标将直接验证HAMi的大规模调度能力，决定它是否能进入大模型训练这一算力需求最集中的核心场景。

第五，是否有公开的商用服务收入、付费客户转化率或云厂商合作分成协议。这是判断HAMi是否能形成独立商业化闭环的核心证据，也决定了它最终是成为独立的基础设施产品，还是云厂商的免费上游组件。

HAMi的这次进展，是中国开源技术从本土工程实践走向全球云原生主流的关键一步，它的价值不需要靠夸大的宣传话术来证明。对于行业用户来说，明确它的适用边界不是否定其价值，反而能更清晰地判断自己是否适合采用这一方案：如果是持有3类以上异构芯片、已经完成Kubernetes 1.26以上版本升级的头部客户，HAMi是当前解决算力孤岛问题的最优开源选项之一；如果是异构芯片数量少、存量集群版本较低的客户，那么引入它的成本可能会超过收益。

开源技术的生命力从来都不是来自夸大性的口号，而是来自可复现的能力、开放的社区、可验证的落地效果。从这个角度来说，明确当前的边界和待验证的问题，恰恰是HAMi走向成熟的开始。