文章摘要
本文围绕开源项目HAMi展开，介绍其发展历程、技术特点、应用场景和商业价值。2026年7月，HAMi进入CNCF孵化阶段，已被数百家企业采用。它能提升GPU利用率，构建开放生态。密瓜智能成立以承担企业服务，解决社区不足。未来，HAMi将深耕底层，密瓜智能需将开源影响力转化为经营能力。

如今，开源项目HAMi的名字在AI基础设施领域被频繁提及，但这份热度更像开源社区里的绚烂烟火：看上去热闹，却未必能真正支撑起企业的核心生产需求。

两年前，在欧洲的一场行业技术峰会现场，李孟轩站在一众成熟开源项目的展台前，看着来自全球的开发者围在一起讨论代码、功能与未来路线。当时他分享的并非HAMi——那时这个项目还只有一个雏形，没有成熟的社区，更未进入任何中立基金会的孵化计划，知道它的开发者寥寥无几。

李孟轩后来曾自嘲，那时的HAMi不过是开源世界里的“小角色”。他曾畅想，有一天HAMi的展台前也能聚集这样一群开发者，围绕技术争论、贡献代码，甚至将生产系统搭建在这个项目之上。但在当时，这个愿望更像遥不可及的理想。

同一时期，张潇正站在企业云平台的项目交付一线。彼时GPU已经接入Kubernetes集群，但企业用户很快发现，能识别一张GPU卡，远不等于能真正用好它：开发任务长期占用整张显卡，零散负载无法充分利用显存，不同团队之间排队等待资源，一旦进入多租户生产环境，资源隔离、故障定位和稳定性保障又接连成为新的难题。

张潇被这些具体而琐碎的问题困住，他希望有一天，企业不必再为每一种GPU、每一个业务团队和每一套集群重复搭建资源管理方案——需要一个既能提升GPU利用率，又能真正成为企业长期依赖的生产级基础设施的项目。

一个从社区视角看到了项目的成长可能，一个从企业现场明确了必须解决的核心问题，张潇和李孟轩两人，最终在同一个基础设施痛点上汇聚到了一起。

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

HAMi的全称是异构AI计算虚拟化中间件，项目地址为https://github.com/project-hami/hami，最初源于一个具体的生产问题，早期仅靠少数开发者个人力量维护。随着项目被越来越多企业采用并进入CNCF孵化，它面临的挑战也从单一功能完善，延伸到社区治理、长期维护和企业级落地层面。

对于推动HAMi发展的张潇、李孟轩和密瓜智能团队来说，进入CNCF孵化后，最现实的问题随之而来：当一个开源组件进入银行、云平台和互联网企业的生产系统后，谁来持续处理硬件兼容、版本升级、故障排查、性能优化和长期运维？当代码、商标和项目治理交给中立基金会后，围绕开源项目成立的商业公司，又该如何找到自己的定位？HAMi的成功，是否等同于密瓜智能的成功？

采访尾声，李孟轩给出了一个克制的判断：“这是一个必要不充分条件。HAMi如果不成功，密瓜一定不会成功，但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上”区分开来。对团队而言，开源不仅仅是公开代码，还要建立一套持续运作的工程和协作体系：有人负责核心技术，有人处理工程化和版本发布，有人对接基金会和厂商，还有人把企业用户提出的问题转化为社区需求。一个原本由少数开发者维护的技术雏形，开始逐步形成可以持续迭代的项目。

既然是行业普遍面临的痛点问题，当时市场并非没有解决方案。英伟达拥有自己的GPU虚拟化技术，公有云厂商也会开发资源切分和调度系统，一些商业公司同样提供GPU共享产品。但真正的问题在于，这些方案往往服务于各自的硬件、云平台或商业边界：英伟达的方案首先围绕自家GPU展开；云厂商提供的能力通常与自身基础设施深度绑定；独立软件公司即便愿意适配多种芯片，也很难长期追上所有厂商的产品迭代。

GPU的复杂性远高于CPU。企业机房里可能同时存在不同代际的英伟达GPU，也可能采购昇腾、AMD以及多家国产GPU。不同厂商的驱动、运行时、设备接口、显存规格和调度能力并不一致；同一家厂商每年也会推出新的芯片和软件版本。如果一家软件公司依次适配十几家厂商，过程就像不断推石头上山：刚完成第二家、第三家的支持，第一家已经发布了新一代产品，原有适配随即落后。

张潇由此判断，这一层缺少的并不是一家公司的某项独占技术，而是一个能让GPU厂商、云厂商、企业用户和基础设施公司共同参与的开放生态。HAMi要做的，就是完成一次“依赖反转”：以往一款产品发布后，项目团队需要四处奔走去逐一适配各家GPU厂商，而HAMi希望吸引芯片厂商主动扎根社区，自行维护设备支持、调度策略与新功能。如此一来，厂商发布新品的瞬间，工程师即可向HAMi提交代码，将原本数月的支持周期压缩至产品上市初期。

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

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

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

HAMi所做的，是把整张GPU转换为更细的可申请资源，再通过调度、虚拟化和池化能力，把不同型号、不同集群乃至不同云上的设备组织起来。用户需要资源时，可以根据任务需要申请其中一部分。在这一体系中，开源成为产品成立的前提，而不只是分发代码的方式。

这里隐含着一个关键前提：异构算力生态需要一个真正中立的土壤。一旦项目被打上某家芯片厂或云巨头的烙印，竞争对手往往会选择观望；而若寄生于单一商业公司的封闭体系，用户又不得不承担路线变更的风险。唯有开源共治，才能打破这种僵局。因此，HAMi后来选择进入CNCF，与其说是为了获得一个带有基金会背书的开源项目身份标签，不如说是为了以此证明其中立性。

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

张潇将CNCF比作一所学校：项目从早期沙箱进入孵化，再走向更加成熟的阶段，并不只是技术评级，更代表用户规模、生产验证、治理能力和上下游集成程度发生了变化。进入孵化意味着HAMi已经不再只是一个概念性项目，而是开始被更多企业作为生产基础设施使用。对于两年前还站在峰会展台外想象未来的李孟轩来说，这也是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真正进入企业生产环境后，用户需要的不只是一个可用的开源项目，还包括稳定版本、兼容性验证、故障响应、持续维护、交付支持和明确的责任主体。这些工作往往需要长期投入，也很难完全依靠社区贡献来保证。

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

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

密瓜智能的成立，正是为了补上社区机制难以独立覆盖的这一部分。HAMi继续作为开放项目吸收行业共性需求，而公司则围绕企业生产环境中的具体问题，提供工程化产品、技术服务和持续交付能力。

就像在云时代，客户需要的是确定性。某个版本什么时候修复问题，升级是否会影响现有业务，新卡能否按时适配，跨集群部署出了故障由谁负责，能否进入现场排查——这些问题不能只靠GitHub Issue和社区邮件列表回答。更重要的是，通用开源项目追求全局可接受的方案，企业生产环境追求的却是特定场景下的最优结果。

金融机构可能需要多种国产GPU的统一管理、私有化部署、权限控制和现场支持，互联网平台已经拥有成熟的算力平台，只需要一个可以嵌入其中的GPU虚拟化内核，GPU Cloud则更在意资源切分、超卖和计量计费，因为这些能力会直接影响单位硬件能够产生的收入。并不是所有企业能力都适合进入开源主干。一项只服务于某类银行的功能，可能增加其他用户的复杂度，针对特定型号GPU的深度优化，也未必适合默认开启。

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

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

密瓜智能的成立，不是为了把HAMi重新包装成闭源商业版，是为了在开源项目之外建立一个责任主体。两位创始人此前分别供职于数百人规模的公司，个人很难决定公司未来是否继续投入某个开源项目。行业中也不乏项目因为组织战略和人事变化而停止维护，甚至中途更换许可证的案例。所以他们最终做了两个相互补充的选择：成立密瓜智能，集中人员和资金长期维护社区，并承接企业生产环境中的责任。项目日臻成熟后，把HAMi交给CNCF，保证项目不会被任何一家公司收回，这种处理方式同时解决了两个问题：一个解决持续性，一个解决中立性。

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

事实上，从年初爆火的相关AI应用到如今风头正劲的智能体，耗费token已经成了大模型时代的“水电气”，每一轮交互都在燃烧真金白银。围绕AI Infra的创业公司越来越多，但它们解决的问题并不相同：有的公司负责搭建算力集群和网络，有的优化训练通信，有的专注推理框架、PD分离和算子性能，还有公司直接向客户交付MaaS平台或Token Factory。

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

假设一家GPU云服务商以每小时40元的价格出租一张GPU，但一个用户的任务只使用了其中一小部分资源，剩余能力就被浪费了。如果平台能够把一张卡切分成三个资源单元，分别提供给多个任务，即使每份价格降到15元或20元，用户成本下降的同时，平台总收入仍可能增加。虚拟化之上还可以叠加超卖，与航空公司根据旅客到场概率多售少量座位类似，GPU平台也可以根据不同任务的潮汐特征分配略高于物理容量的逻辑资源。当部分任务处于低负载或空闲状态时，其他任务可以使用释放出来的能力。

但超卖并不是简单地多发几个配额。平台必须持续观察任务负载，处理资源争抢，并在高峰期通过调度、抢占或其他机制避免影响关键业务。资源利用率越高，系统对隔离、稳定性和调度策略的要求也越高。据张潇介绍，在部分推理场景中，企业原有GPU综合利用率不足20%，采用开源HAMi后可提升至40%至50%左右。密瓜智能企业产品的目标，则是结合超卖、抢占和场景优化让利用率进一步接近70%。张潇坦言，这些数字来自团队服务项目的经验，或许不代表所有工作负载都能获得相同提升，但它们说明了商业价值的计算方式：减少多少闲置资源、避免采购多少GPU、缩短多少排队时间，以及在相同硬件投入下增加多少服务能力。

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

HAMi让设备从“属于某个厂商的一张卡”，变成可被平台统一编排的资源。密瓜智能则试图把这种技术能力转换为可以被财务和业务负责人理解的投资回报率。张潇认为，基础设施产品最终必须回答一个直接的问题：用了之后，究竟省了多少钱、增加了多少收入，或者少解决了多少麻烦。这也是密瓜智能接下来寻找产品市场匹配的核心。社区影响力可以带来用户和线索，但只有当效率提升变成可计算的收益时，用户才可能从开源使用者转化为付费客户。

把核心技术开源后，密瓜智能还能留下什么壁垒？这是开源商业公司无法回避的问题。张潇并不认为某项技术可以永久领先。调度算法、虚拟化机制和产品功能都可能被学习和复制，AI编程工具还在进一步降低阅读和重写代码的门槛。仅靠几项未公开功能，很难形成长期护城河。他更看重的是生态位置。

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

HAMi的优势在于，它已经聚集了不同GPU厂商、云厂商和企业用户。每增加一种设备支持和一个生产案例，项目就获得新的适配经验；更多用户又会带来更多问题和贡献，形成生态飞轮。但生态之外，还有一项更“重”的工作：真机验证。HAMi与GPU硬件和驱动紧密相关。新型号设备上线前，团队需要找到真实硬件，验证功能、部署方式和兼容性，对相关特性进行回归测试。不同厂商、不同型号和不同版本之间的差异，不可能只通过阅读代码或调用AI工具消除。

开源版本还需要兼顾老旧设备和最广泛的用户环境，因此一些新卡特性不能默认开启，企业产品则可以根据客户的真实集群组成，有针对性地启用优化。这些设计为什么存在、哪些参数在什么硬件上会引发问题，往往来自长期测试和生产事故，而不是公开代码本身能够完整表达的信息。这类工作不够性感，却十分消耗资源。团队要协调不同厂商的设备，进入银行等严格隔离的私有环境，在多种芯片和驱动版本上复现问题。很多大厂不愿替竞争对手适配GPU，单一芯片厂商也缺乏动力维护其他品牌的设备。这为一个保持中立、愿意长期处理“脏活累活”的团队留下了生态位置。

据李孟轩介绍，在拥有多家芯片设备的大型金融客户中，当用户需要一个能够进入生产环境、跨设备排查问题并持续适配的团队时，可选择的供应方并不多。因此，密瓜智能真正不容易被复制的，不是GitHub上的某段代码，是代码背后的上下文：为什么当初这样设计、在哪些设备上验证过、哪些功能曾经为了兼容性妥协、某个生产故障如何发生，以及如何在多个厂商之间协调资源完成修复。

谈到未来五年，李孟轩没有把HAMi描绘成一套大而全的AI平台。他希望HAMi继续向下，进入更接近设备和驱动的位置，与不同异构芯片建立更深的绑定和优化，向上则保持克制，继续作为一个让算力更容易使用、利用率更高的中间件，而不是与所有云平台、推理框架和Token Factory竞争。在他看来，向上的调度平台、推理服务和模型系统已经有大量公司投入，但向下打通不同芯片厂商，消除设备之间的使用壁垒，仍需要长期而具体的工作。这也是HAMi能够保留独特生态位的地方。

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

这是一个带有理想主义色彩的目标，但在现实中却必须接受商业世界的检验。开源社区每天都很热闹，新的贡献、用户和合作不断出现，公司经营则完全是另一种节奏。市场从卖GPU转向卖算力，再转向Token和服务，AI Infra的边界不断变化。团队必须持续回答：自己的位置是否仍然成立，客户为什么付费，产品能否规模化，以及今天的技术优势会不会在下一轮变化中消失。

张潇用“度日如年”形容这种状态。一方面，AI行业每天都有新模型、新框架和新产品发布，一天发生的变化像过去一年。另一方面，创业公司每天都要面对产品、团队、融资和收入的压力。

采访最后，两人被问到，如果回到决定把HAMi做成长期项目、成立密瓜智能的那一天，会对当时的自己和对方说什么。李孟轩的答案很短：“干得不错，继续加油。”张潇却认为，只能算“差强人意”。HAMi已经进入CNCF孵化，社区生态和用户基础得到了验证，但密瓜智能还没有完成真正的考题：找到足够清晰的产品形态，让客户持续付费，并把开源影响力转换为一家公司的长期经营能力。

HAMi为密瓜智能开了一个好头，却不能替它完成后面的路。项目的成功证明，两位创始人最初看到的问题确实存在：在一个由多种GPU、多类云平台和不同生产系统组成的世界里，企业需要一个开放、中立的异构算力管理层。但一家公司的成功，还要证明另一件事：当所有人都可以免费使用这套技术时，最理解它、维护它并推动它前进的团队，仍然能够创造不可替代的价值。这或许正是HAMi从“小角色”走进CNCF孵化之后，真正需要跨越的下一道鸿沟。

完整采访内容后续将通过行业渠道发布，敬请期待。

以上内容不代表本平台立场，仅供读者参考