从“小卡拉米” 杀入 CNCF，创始人却说：HAMi火了，我们每天仍如履薄冰

作者｜冬梅

HAMi 火了，但那种‘火’，更像是开源世界的烟火——好看，但不顶饭吃。

两年前，在欧洲的一场 KubeCon 大会上，李孟轩站在那些成熟开源项目的展台前，看着来自世界各地的开发者围在一起讨论代码、功能和未来路线。

那时，他参加大会分享的是另一个项目，一个与现在做的事情毫无关系的项目。因为那时，HAMi 还只是有了一个能叫得出来的名字，没有成熟庞大的社区，更还没有进入 CNCF，社区里知道它的人寥寥无几。

李孟轩后来用一个带着自嘲意味的词形容当时的 HAMi——“小卡拉米”。

他曾经想过，如果有一天，HAMi 的展台前也能聚集这么多开发者，大家愿意围绕它争论、贡献代码，甚至把自己的生产系统建立在它之上，那就太好了。但在当时，这个愿望更像是一个距离很远的理想。

同一时期，张潇面对的是另外一番图景。

彼时的张潇，更多站在企业云平台和实际项目交付一侧，GPU 已经被接入了 Kubernetes，但对企业而言，能识别一张卡远不等于能真正用好这张卡：开发任务长期占卡，零散负载无法充分利用显存，不同团队之间相互排队，一旦进入多租户和生产环境，资源隔离、故障定位和稳定性保障又会接连成为新的问题。

张潇被这些具体而琐碎的问题困在项目现场。所以在张潇的视角里，他希望有一天，企业不再需要为每一种 GPU、每一个业务团队和每一套集群重复搭建资源管理方案，要有一个项目不仅能够提高 GPU 利用率，也能够真正成为企业愿意放进生产环境、并长期依赖的一层基础设施。

张潇和李孟轩两人，一个从开源社区看见了项目可能成长为什么，另一个从企业现场判断它必须解决什么。

2026 年 7 月，他们终于在某种程度上等到了当年设想的那一幕。

7 月 2 日，HAMi 通过 CNCF 技术监督委员会评审，正式进入孵化阶段。此时，项目已经被数百家企业直接或间接采用，也聚集了来自 GPU 厂商、云厂商、金融机构和互联网公司的开发者。

HAMi 最初源于一个具体的生产问题，早期主要依靠个人力量维护。随着项目被越来越多企业采用，并进入 CNCF 孵化阶段，HAMi 所面对的问题也从单一功能的完善，逐渐延伸到社区治理、长期维护和企业级落地。

对于长期推动 HAMi 的张潇、李孟轩和密瓜智能团队来说，进入 CNCF 孵化阶段后面临的更现实的问题是，当一个开源组件进入银行、云平台和互联网企业的生产系统后，谁来持续处理硬件兼容、版本升级、故障排查、性能优化和长期运维？

当代码、商标和项目治理交给中立基金会后，一家围绕开源项目成立的公司，又该做什么？

HAMi 的成功，能不能等同于密瓜智能的成功？

采访接近尾声时，李孟轩给出了一个克制的判断：“这是一个必要不充分条件。HAMi 如果不成功，密瓜一定不会成功，但 HAMi 成功之后，密瓜还要想办法养活自己。”

这句话，也是理解 HAMi 与密瓜智能关系的起点。

被整卡分配困住的 GPU

HAMi 项目的全称是 Heterogeneous AI Computing Virtualization Middleware，翻译过来就是异构 AI 计算虚拟化中间件，听起来复杂，实际解决的是一个很直观的问题：企业买回来的 GPU，怎样才能不闲着，并且被不同应用更灵活地使用。

项目地址：https://github.com/project-hami/hami

传统的 GPU 管理方式比较粗放。一项任务需要 GPU，系统往往直接分给它一整张卡。但很多小模型、推理服务或者开发测试任务，实际上只会使用其中一部分显存和计算能力，剩余资源虽然空着，其他任务却用不了。就像一家三口租下整栋办公楼，只使用其中一间办公室，其他房间也不能再租给别人。

HAMi 所做的，就是在 GPU 硬件和上层应用之间增加一个“资源管理员”。它可以把一张完整的 GPU 切分成多个更小的虚拟资源，再根据不同任务的实际需求进行分配。一个任务可能只使用四分之一张卡，另一个任务使用一半，多项任务可以在相互隔离的情况下共享同一块硬件。这样一来，企业不必为每个小任务都准备一张完整的 GPU，也能减少资源空转和任务排队。

和许多后来改变软件产业的开源项目一样，HAMi 的起点不是一套宏大的商业计划，是创作者眼前一个具体、迫切且没有现成答案的问题。

项目出现时，企业中的主流 AI 工作负载还是推荐系统、OCR、风险识别和传统机器学习模型。模型规模远小于今天的大语言模型，但训练、迭代和推理频率并不低。

数据不断进入系统，模型持续更新，再根据生产反馈重新调整，每个环节都可能占用 GPU。

CPU 和内存已经被 Kubernetes 视为可以精细划分和调度的标准资源。应用可以申请若干 CPU 核心和一定容量的内存，系统再根据资源余量完成部署。但 GPU 在很长一段时间里仍然被当成一种特殊设备：一项任务只要需要 GPU，调度系统通常就给它分配一张完整的卡。

对于大规模训练，这种方式有时是合理的；但对于大量小模型、轻量推理和开发测试任务，整卡分配意味着资源浪费。一个只使用少量显存和计算能力的应用，也可能独占一张 GPU，其他任务只能排队或等待新增硬件。

2021 年前后，张潇和李孟轩还身处不同组织，但都注意到了同一个基础设施问题：随着 AI 工作负载逐渐迁移到 Kubernetes，GPU 共享、细粒度调度和异构设备统一管理能力仍不成熟。

基于对 Kubernetes GPU 共享、异构算力调度和 AI 基础设施演进方向的共同判断，张潇和李孟轩开始推动 HAMi 的早期版本。李孟轩更多从 AI 工作负载和底层技术出发，探索如何将 GPU 转化为可切分、可隔离、可调度的云原生资源；张潇则从企业云平台和生产环境出发，推动项目工程化，使其能够接入已有的 Kubernetes 和企业基础设施体系。两人从不同的技术和业务视角切入，最终汇聚到同一个问题上：如何让有限且异构的算力资源，以更标准化的方式被云原生系统管理和使用。

HAMi 的发起是张潇、李孟轩在不同组织背景下，围绕同一个基础设施问题展开的开源协作。两人是项目早期的主要发起者，也是此后长期推动技术演进、工程建设和社区发展的核心参与者。随着项目逐渐形成影响力，DaoCloud、第四范式以及更多组织、芯片厂商和社区开发者，也在不同阶段参与或支持了 HAMi 的发展，共同推动其适配更多硬件、场景和生产环境。这一过程既体现了开源项目多方参与的属性，也需要区分项目的早期发起、长期维护与各阶段组织贡献，避免将 HAMi 简单归属于任何一家机构。

不过，早期的 HAMi 主要解决 GPU 切分和共享问题，距离一个能够被其他企业直接采用的基础设施项目仍有明显差距。随着使用场景扩大，项目需要补齐的不只是核心调度能力，还包括持续集成与交付、自动构建、兼容性测试、版本发布、技术文档、社区治理和用户需求响应等一整套工程体系。

此后，密瓜智能现有团队中的一批研发人员陆续参与进来，承担并完善这些工作，推动 HAMi 从解决特定技术问题的早期项目，逐步发展为能够适配多种异构算力、进入企业生产环境的开源基础设施。

张潇在采访中将这种工作与“把代码放到 GitHub 上”区分开来。

对团队而言，开源不仅仅要把代码公开，还要建立一套持续运作的工程和协作体系：有人负责核心技术，有人处理工程化和版本发布，有人对接基金会和厂商，也有人把企业用户提出的问题转化为社区需求。

一个原本主要由少数开发者维护的技术雏形，开始逐步形成可以持续迭代的项目。

左：密瓜智能联合创始人& CTO 李孟轩；右：密瓜智能创始人& CEO 张潇

缺的不是又一个调度器，而是跨厂商生态

既然是行业普遍面临的痛点问题，当时就没有成熟的解决方案吗？

答案是有的，HAMi 面临的市场并非完全没有解决方案。

英伟达拥有自己的 GPU 虚拟化技术，公有云厂商也会开发资源切分和调度系统，一些商业公司同样提供 GPU 共享产品。真正的问题在于，这些方案往往服务于各自的硬件、云平台或商业边界。

英伟达的方案首先围绕英伟达 GPU 展开；阿里云、腾讯云、AWS 等云厂商提供的能力，通常与自身基础设施深度绑定；一家独立软件公司即使愿意适配多种芯片，也很难长期追上所有厂商的产品迭代。

GPU 的复杂性也远高于 CPU。

企业机房里可能同时存在不同代际的英伟达 GPU，也可能采购昇腾、AMD 以及多家国产 GPU。不同厂商的驱动、运行时、设备接口、显存规格和调度能力并不一致；同一家厂商每年也会推出新的芯片和软件版本。

如果一家软件公司依次适配十几家厂商，过程就像不断推石头上山：刚完成第二家、第三家的支持，第一家已经发布了新一代产品，原有适配随即落后。

张潇由此判断，这一层缺少的并不是一家公司的某项独占技术，而是一个能让 GPU 厂商、云厂商、企业用户和基础设施公司共同参与的开放生态。

HAMi 要做的，是试图完成一次“依赖反转”：以前一款产品发布后，项目团队就会四处奔走去逐一适配各家 GPU 厂商，HAMi 希望改变这种状况，去吸引芯片厂商主动扎根社区，自行维护设备支持、调度策略与新功能。如此一来，厂商发布新品的瞬间，工程师即可向 HAMi 提交代码，将原本数月的支持周期压缩至产品上市初期。

据张潇介绍，目前已有相当一部分 GPU 厂商在 HAMi 社区投入研发资源。一些厂商会在新卡发布时同步推进适配，争取做到 Day 0 或 Day 1 支持。李孟轩则提到，越来越多芯片厂商开始主动贡献自己的设备能力和调度优化，而 HAMi 团队也借助这一网络，帮助 CNCF 与国内芯片厂商建立联系。

这构成了 HAMi 与单厂商方案最本质的差异。

HAMi 没有试图替代某家 GPU 的驱动和运行时，他们把自己定位于 Kubernetes 与异构设备之间，把不同硬件抽象为更统一、更细粒度的资源。上层应用不需要为每一种 GPU 建立独立的管理系统，平台也不必围绕单一厂商形成新的烟囱。

对于企业而言，这种抽象首先意味着选择权。

一家银行可能已经部署了英伟达 GPU，又在持续采购国产算力；一家海外互联网公司可能同时保留 T4、P100、A100、H100 等多个代际的设备；还有企业把资源分散在 AWS、微软云和自有数据中心。它们面对的“异构”并不完全相同，但都不希望每增加一种设备，就重新建设一套调度、监控和运维体系。

HAMi 所做的，是把整张 GPU 转换为更细的可申请资源，再通过调度、虚拟化和池化能力，把不同型号、不同集群乃至不同云上的设备组织起来。用户需要资源时，可以根据任务需要申请其中一部分。

在这一体系中，开源就成了产品成立的前提，而不只是分发代码的方式。

这里隐含着一个关键前提：异构算力生态需要一个真正中立的土壤。一旦项目被打上某家芯片厂或云巨头的烙印，竞对往往会选择观望；而若寄生于单一商业公司的封闭体系，用户又不得不承担路线变更的风险。唯有开源共治，才能打破这种僵局。

因此，HAMi 后来选择进入 CNCF，与其说是为了获得一个拥有 CNCF 背书的开源项目的身份标签，不如说他们是为了以此来证明其中立性。

将项目交给 CNCF，意味着项目代码、商标、Logo、网站和法律所有权均按照基金会规则治理。维护者不能突然改变许可证，也不能把一个社区项目重新收回为私有产品。对于把 HAMi 部署进生产系统的企业来说，这降低了项目停止维护、突然闭源或改变许可规则的风险。

张潇将 CNCF 比作一所学校：项目从早期 Sandbox 进入孵化，再走向更加成熟的阶段，并不只是技术评级，更代表用户规模、生产验证、治理能力和上下游集成程度发生了变化。进入孵化意味着 HAMi 已经不再只是一个概念性项目，而是开始被更多企业作为生产基础设施使用。

对于两年前还站在 KubeCon 展台外想象未来的李孟轩来说，这也是 HAMi 第一次真正“跨过鸿沟”。

生产级系统开始为开源项目投票

开源项目是否解决了真实问题，最终不是由 Star 数决定，而要由生产系统投票。

据李孟轩回忆，HAMi 较早的一家生产用户是国内一家上市互联网金融公司。该公司最初在三个集群、16 个节点和 128 张 GPU 上部署 HAMi，运行推荐系统和 OCR 票据识别等小模型任务。按照用户向团队提供的反馈，其 GPU 利用效率提升超过一倍。

这一案例让 HAMi 第一次离开内部研发环境，进入持续运行的企业系统。随后，使用场景逐渐从推荐、OCR 和强化学习扩展到语言模型和更复杂的推理任务。

密瓜智能成立前后，团队又与顺丰科技展开合作。据张潇介绍，HAMi 被用于其 GPU 的虚拟化和调度，双方还共同整理了物流行业 GPU 高效利用相关实践，最后还发表了一份与之相关的《白皮书》。

但在采访中，张潇也提到，如果只依靠免费用户项目是无法长久维持下去的，真正让团队看到商业闭环可能性的，是一家大型股份制银行。

银行的生产环境比互联网公司的试验集群复杂得多。

这家银行内部可能同时存在多家厂商、多个型号和不同批次的 GPU，基础设施运行在私有环境中，对稳定性、风险控制、版本升级和现场服务都有严格要求。开源社区中异步提交 Issue、等待维护者响应的协作方式，很难满足银行对生产事故的处理要求。

所以该银行的需求很直接——希望拥有统一管理全行的异构算力：存量英伟达 GPU 需要提升利用率，新采购的国产 GPU 也要进入同一套资源体系，应用平台则不能因为更换硬件而大幅改造。

在这一项目中，银行、国产 GPU 厂商、HAMi 社区和密瓜智能形成了一个此前团队只在设想中描绘过的闭环：GPU 厂商通过 HAMi 进入客户已有环境；银行通过统一平台降低异构设备的管理复杂度；生产需求反过来推动社区和企业产品迭代；密瓜智能则提供适配、交付和生产保障，并由此获得商业收入。

对于一家当时只有二三十人的创业公司来说，这种合作给出的信号比融资更加直接——GPU 厂商和大型企业确实愿意为跨厂商适配、生产保障和资源效率付费。

生产用户也开始改变 HAMi 的技术路线。

项目最初专注于英伟达 GPU 的虚拟化。随着用户设备变得多样，团队逐渐把范围扩展到其他异构算力；随着部署规模扩大，仅做设备侧切分已经不够，HAMi 需要进入 Kubernetes 控制面，理解集群资源和任务需求，参与调度决策。

再然后，随着企业开始跨集群和跨云使用 GPU，项目又需要考虑多集群管理、可观测性、权限、API、计量计费和弹性。

张潇介绍，公司一路走来，如今取得的成就不是一开始就设定好的，是一个个具体的生产需求一点点把项目推向更完整的基础设施。

“先把底层基础能力做好，收集反馈，再一点点往上搭。”李孟轩说。

据张潇介绍，目前 HAMi 已被数百家企业以直接或间接方式使用，用户包括云厂商、互联网平台、金融机构、运营商、汽车企业和海外公司。大量企业通过开源社区、合作伙伴或云平台使用 HAMi，真正转换为商业客户的只是一部分。

HAMi 之外，为什么还需要密瓜智能

随着 HAMi 用户数量增加、应用场景不断深入，张潇和李孟轩逐渐意识到，仅靠开源社区，很难完整承担一个基础设施项目进入企业关键生产系统后的责任。

社区适合汇聚不同参与者的通用需求，也适合让代码、技术路线和治理规则接受公开讨论。

但当 HAMi 真正进入企业生产环境后，用户需要的不只是一个可用的开源项目，还包括稳定版本、兼容性验证、故障响应、持续维护、交付支持和明确的责任主体。这些工作往往需要长期投入，也很难完全依靠社区贡献来保证。

在这一过程中，两位创始人关注的问题开始有所区分。

李孟轩更多从 CTO 和开源项目维护者的视角出发，关注 HAMi 在技术架构、社区治理和项目边界上如何继续演进：哪些能力应该进入开源主干，如何兼容更多 GPU、NPU 和异构芯片，如何在功能扩张的同时保持项目的通用性，以及怎样避免 HAMi 变成只服务于某一家公司的封闭技术栈。

张潇则需要从创始人兼 CEO 的角度回答另一组更现实的问题：为什么需要成立一家商业公司，企业客户为什么愿意为 HAMi 相关服务付费，以及密瓜智能如何在开源代码之外，为客户承担部署、适配、运维和长期演进的责任。

密瓜智能的成立，正是为了补上社区机制难以独立覆盖的这一部分。

HAMi 继续作为开放项目吸收行业共性需求，而公司则围绕企业生产环境中的具体问题，提供工程化产品、技术服务和持续交付能力。

就像在云时代，客户需要的是确定性。

某个版本什么时候修复问题，升级是否会影响现有业务，新卡能否按时适配，跨集群部署出了故障由谁负责，能否进入现场排查——这些问题不能只靠 GitHub Issue 和社区邮件列表回答。

更重要的是，通用开源项目追求全局可接受的方案，企业生产环境追求的却是特定场景下的最优结果。

金融机构可能需要多种国产 GPU 的统一管理、私有化部署、权限控制和现场支持，互联网平台已经拥有成熟的算力平台，只需要一个可以嵌入其中的 GPU 虚拟化内核，GPU Cloud 则更在意资源切分、超卖和计量计费，因为这些能力会直接影响单位硬件能够产生的收入。

并不是所有企业能力都适合进入开源主干。一项只服务于某类银行的功能，可能增加其他用户的复杂度，针对特定型号 GPU 的深度优化，也未必适合默认开启。

密瓜智能由此形成了一条基本边界：跨厂商兼容、通用设备支持和具有普遍价值的能力应尽量进入 HAMi 社区。面向具体客户的生产保障、版本管理、场景优化、系统集成和商业服务，则由企业产品承接。如果一项企业能力后来被更多用户需要，也可以再反馈到开源社区。

在张潇看来，HAMi 开放的是技术和生态，客户购买的却是一套可运行、可升级、可追责的产品。这套产品需要解决 HAMi 与企业现有 Kubernetes、监控系统、权限体系、API 和多云环境的集成，需要支持跨版本无缝升级、多集群管理、可观测性、计量计费和弹性策略，还要在出现问题时提供明确的服务响应。

密瓜智能的成立，不是为了把 HAMi 重新包装成闭源商业版，是为了在开源项目之外建立一个责任主体。

两位创始人此前分别供职于数百人规模的公司，个人很难决定公司未来是否继续投入某个开源项目。行业中也不乏项目因为组织战略和人事变化而停止维护，甚至中途更换许可证的案例。

所以他们最终做了两个相互补充的选择：成立密瓜智能，集中人员和资金长期维护社区，并承接企业生产环境中的责任。项目日臻成熟后，把 HAMi 交给 CNCF，保证项目不会被任何一家公司收回，这种处理方式同时解决了两个问题：一个解决持续性，一个解决中立性。

李孟轩说，成立公司的意义之一，是向外界表明一种决心：“这个项目我们一定会维护到底。”

把 GPU 利用率变成一笔能算清楚的账

事实上，从年初爆火的“龙虾”到如今风头正劲的 Agent，耗费 token 已经成了大模型时代的“水电气”，每一轮交互都在燃烧真金白银。围绕 AI Infra 的创业公司越来越多，但它们解决的问题并不相同。

有的公司负责搭建算力集群和网络，有的优化训练通信，有的专注推理框架、PD 分离和算子性能，还有公司直接向客户交付 MaaS 平台或 Token Factory。

密瓜智能把自己的位置放在更靠近设备、又位于驱动之上的一层：通过 GPU 池化、虚拟化和调度，屏蔽不同硬件的差异，把整卡转化为更细粒度、可以弹性分配的资源。

这项能力的价值，最终需要落到一笔经济账上。

假设一家 GPU Cloud 以每小时 40 元的价格出租一张 GPU，但一个用户的任务只使用了其中一小部分资源，剩余能力就被浪费了。如果平台能够把一张卡切分成三个资源单元，分别提供给多个任务，即使每份价格降到 15 元或 20 元，用户成本下降的同时，平台总收入仍可能增加。

虚拟化之上还可以叠加超卖。与航空公司根据旅客到场概率多售少量座位类似，GPU 平台也可以根据不同任务的潮汐特征分配略高于物理容量的逻辑资源。当部分任务处于低负载或空闲状态时，其他任务可以使用释放出来的能力。

但超卖并不是简单地多发几个配额。平台必须持续观察任务负载，处理资源争抢，并在高峰期通过调度、抢占或其他机制避免影响关键业务。资源利用率越高，系统对隔离、稳定性和调度策略的要求也越高。

据张潇介绍，在部分推理场景中，企业原有 GPU 综合利用率不足 20%，采用开源 HAMi 后可提升至 40%至 50%左右。

密瓜智能企业产品的目标，则是结合超卖、抢占和场景优化让利用率进一步接近 70%。张潇坦言，这些数字来自团队服务项目的经验，或许不代表所有工作负载都能获得相同提升，但它们说明了商业价值的计算方式：减少多少闲置资源、避免采购多少 GPU、缩短多少排队时间，以及在相同硬件投入下增加多少服务能力。

这一逻辑对不同用户有不同含义。

银行更关注有限 GPU 能否承载更多应用，以及新增国产算力能否进入现有系统，互联网公司关注推理并发、用户排队和单位请求成本，云厂商则关注一张 GPU 可以被出售多少次、资源空闲率能否降低，GPU 厂商希望自己的芯片进入客户环境后，不必重新建设一整套管理平台。

HAMi 让设备从“属于某个厂商的一张卡”，变成可被平台统一编排的资源。

密瓜智能则试图把这种技术能力转换为可以被财务和业务负责人理解的 ROI。

张潇认为，基础设施产品最终必须回答一个直接的问题：用了之后，究竟省了多少钱、增加了多少收入，或者少解决了多少麻烦。

这也是密瓜智能接下来寻找产品市场匹配的核心。社区影响力可以带来用户和线索，但只有当效率提升变成可计算的收益时，用户才可能从开源使用者转化为付费客户。

“没有哪项技术可以永久领先”

把核心技术开源后，密瓜智能还能留下什么壁垒？这是开源商业公司无法回避的问题。

张潇并不认为某项技术可以永久领先。调度算法、虚拟化机制和产品功能都可能被学习和复制，AI 编程工具还在进一步降低阅读和重写代码的门槛。仅靠几项未公开功能，很难形成长期护城河。

他更看重的是生态位置。

AI Infra 的很多核心组件本身就是开源的，从 Kubernetes、PyTorch、TensorFlow，到 vLLM、SGLang，企业倾向于选择拥有广泛用户、持续维护和上下游兼容能力的项目。因为基础设施一旦进入生产系统，更换成本远高于普通应用，客户最担心的不是某项功能少一点，而是项目突然停止、公司倒闭，或者技术路线被单一厂商锁定。

HAMi 的优势在于，它已经聚集了不同 GPU 厂商、云厂商和企业用户。每增加一种设备支持和一个生产案例，项目就获得新的适配经验；更多用户又会带来更多问题和贡献，形成生态飞轮。

但生态之外，还有一项更“重”的工作：真机验证。

HAMi 与 GPU 硬件和驱动紧密相关。

新型号设备上线前，团队需要找到真实硬件，验证功能、部署方式和兼容性，对相关特性进行回归测试。不同厂商、不同型号和不同版本之间的差异，不可能只通过阅读代码或调用 AI 工具消除。

开源版本还需要兼顾老旧设备和最广泛的用户环境，因此一些新卡特性不能默认开启，企业产品则可以根据客户的真实集群组成，有针对性地启用优化。

这些设计为什么存在、哪些参数在什么硬件上会引发问题，往往来自长期测试和生产事故，而不是公开代码本身能够完整表达的信息。

这类工作不够性感，却十分消耗资源。

团队要协调不同厂商的设备，进入银行等严格隔离的私有环境，在多种芯片和驱动版本上复现问题。很多大厂不愿替竞争对手适配 GPU，单一芯片厂商也缺乏动力维护其他品牌的设备。这为一个保持中立、愿意长期处理“脏活累活”的团队留下了生态位置。

据李孟轩介绍，在拥有多家芯片设备的大型金融客户中，当用户需要一个能够进入生产环境、跨设备排查问题并持续适配的团队时，可选择的供应方并不多。

因此，密瓜智能真正不容易被复制的，不是 GitHub 上的某段代码，是代码背后的上下文：为什么当初这样设计、在哪些设备上验证过、哪些功能曾经为了兼容性妥协、某个生产故障如何发生，以及如何在多个厂商之间协调资源完成修复。

一个必要不充分条件

谈到未来五年，李孟轩没有把 HAMi 描绘成一套大而全的 AI 平台。

他希望 HAMi 继续向下，进入更接近设备和驱动的位置，与不同异构芯片建立更深的绑定和优化，向上则保持克制，继续作为一个让算力更容易使用、利用率更高的中间件，而不是与所有云平台、推理框架和 Token Factory 竞争。

在他看来，向上的调度平台、推理服务和模型系统已经有大量公司投入，但向下打通不同芯片厂商，消除设备之间的使用壁垒，仍需要长期而具体的工作。这也是 HAMi 能够保留独特生态位的地方。

张潇的设想更大一些。

他和李孟轩都深受 Linux 和 Linus Torvalds 的影响，希望在 AI 基础设施中建立一个类似“操作系统内核”的开放层。HAMi 是这个方向的起点，未来密瓜智能可能继续探索推理、存储和其他基础设施问题，但最核心的技术仍会尽可能回馈开源社区。

这是一个带有理想主义色彩的目标，但在现实中却必须接受商业世界的检验。

开源社区每天都很热闹，新的贡献、用户和合作不断出现，公司经营则完全是另一种节奏。市场从卖 GPU 转向卖算力，再转向 Token 和服务，AI Infra 的边界不断变化。

团队必须持续回答：自己的位置是否仍然成立，客户为什么付费，产品能否规模化，以及今天的技术优势会不会在下一轮变化中消失。

张潇用“度日如年”形容这种状态。一方面，AI 行业每天都有新模型、新框架和新产品发布，一天发生的变化像过去一年。

另一方面，创业公司每天都要面对产品、团队、融资和收入的压力。

采访最后，两人被问到，如果回到决定把 HAMi 做成长期项目、成立密瓜智能的那一天，会对当时的自己和对方说什么。

李孟轩的答案很短：“干得不错，继续加油。”

张潇却认为，只能算“差强人意”。HAMi 已经进入 CNCF 孵化，社区生态和用户基础得到了验证，但密瓜智能还没有完成真正的考题：找到足够清晰的产品形态，让客户持续付费，并把开源影响力转换为一家公司的长期经营能力。

HAMi 为密瓜智能开了一个好头，却不能替它完成后面的路。

项目的成功证明，两位创始人最初看到的问题确实存在：在一个由多种 GPU、多类云平台和不同生产系统组成的世界里，企业需要一个开放、中立的异构算力管理层。

但一家公司的成功，还要证明另一件事：当所有人都可以免费使用这套技术时，最理解它、维护它并推动它前进的团队，仍然能够创造不可替代的价值。

这或许正是 HAMi 从“小卡拉米”走进 CNCF 孵化之后，真正需要跨越的下一道鸿沟。

完整采访视频也很快会在 InfoQ 视频号发布，敬请期待。

会议推荐

2026 年 AICon 人工智能开发与应用大会 · 深圳站将于 8 月 21 日—22 日举办，聚焦 AI 基础设施、大模型系统、智能体工程、数据智能、多模态技术与行业落地等关键方向，邀请来自腾讯、阿里、华为、百度、蚂蚁集团等 50 + 头部科技企业技术负责人、科研机构一线专家，系统性分享前沿洞察与实战干货，共同探讨 AI 技术从能力到系统、从实验到生产的真实路径。大会限时 9 折优惠，现在报名立减 580，更多详情可扫码或联系票务经理 13269078023 进行咨询。