HAMi Meetup 上海站深度解读（七）：从使用者到共建者，企业为什么需要一个可持续的 HAMi 社区？
企业把开源软件用进生产环境后，关注的问题会逐渐延伸到代码之外。遇到问题能否得到响应？新的需求如何进入公共路线？团队投入的适配与优化，能否与社区一起长期维护？这些问题，直接影响企业采用开源基础设施的信心。
本文是 HAMi Meetup 上海站 系列深度解读的第七篇（完结篇），聚焦本场活动的社区圆桌《从 Incubating 再出发：HAMi 如何走向更开放、更可持续的社区共建？》。这些问题也是 HAMi 进入 CNCF Incubating 后，社区需要持续面对的工作。圆桌中，密瓜智能联合创始人兼 CTO、HAMi Maintainer 李孟轩，与密瓜智能研发工程师、HAMi Approver 王纪飞，星环科技人工智能产品部 AI 工具平台研发 侯雨希，以及第四范式研发工程师、HAMi Approver James，围绕真实使用、贡献门槛与协作质量展开讨论。对企业平台团队，这场对话提供了技术选型之外的另一组判断依据。
核心亮点
- 企业采用 HAMi 的实际动机包括 GPU 共享和异构适配，长期维护质量同样影响选型。
- 清楚的贡献路径、及时的问题反馈和可复用的设计知识，帮助用户参与共建。
- AI 可以辅助编码与评审，需求判断、代码理解和真实环境验证仍需贡献者承担。
企业选择开源，也在选择共同维护的方式
James 提到，团队最初关注 HAMi，来自一个直接的使用需求。不同用户和内部团队都要使用 GPU，测试等场景又不一定需要独占整卡，共享能力因此成为选型的重要因素。
侯雨希的经历则涉及自研与社区方案之间的选择。团队原本已有 GPU 管理组件，评估新方案时，除了已有投入，也关注国产算力适配的覆盖范围，以及持续增加功能的能力。最终选择 HAMi，既考虑了异构硬件适配，也看重多方共同贡献能够带来的持续演进。
HAMi 吸引企业用户的起点，可能是把测试任务放进共享 GPU，也可能是减少异构设备适配的重复投入。持续采用之后，企业还要判断这些能力能否长期维护、问题能否进入公共讨论。密瓜智能重视的社区价值，就体现在这一过程中：让各家企业面对的共性需求进入共同维护的项目，减少每个团队独立承担全部适配与演进工作的负担。
从第一个 Issue 开始，把有价值的问题接住
新人如何参与 HAMi？几位嘉宾给出的路径都很具体。
王纪飞建议，先阅读贡献规范，再从已有 Issue 中寻找真实需求。理解问题发生的环境，与提出问题的用户和维护者讨论清楚，再决定实现方式，可以减少重复开发，也能让贡献更贴近实际使用。
James 补充，HAMi 的贡献入口并不限于调度器代码。文档是否清楚、使用步骤与实际行为是否一致，都是值得反馈的问题。熟悉 C++ 或 CUDA 的开发者可以关注 HAMi-core，也可以根据自身经验参与其他组件。发现问题、补充复现信息、修正文档，都能帮助项目向前推进。
社区也需要主动降低参与门槛。侯雨希提到，一条涉及底层并发锁优化的高价值 Issue 曾较长时间没有得到充分响应，提出者又因跨仓库流程和贡献经验不足，没有继续提交 PR。他认为，对新人第一次提交的问题和贡献给予及时反馈，有助于让有价值的参与持续下去。
对参与 HAMi 的企业团队，清晰的复现步骤、环境信息和定位过程，都是推动改进的有效输入。对维护者，及时确认问题、说明设计边界和引导贡献路径，同样重要。社区能否接住第一次参与，会影响下一次高质量贡献是否还会到来。
AI 可以协助写代码，提交者仍要解释需求与设计
AI 编码是本场讨论中展开较多的话题。代码产出变快之后，评审压力也随之增加。嘉宾们关注的重点，是如何确认一项修改确有必要，以及提交者是否理解自己提交的内容。
王纪飞介绍了社区当时在贡献规范上的调整，包括说明 PR 中 AI 的参与情况，以及由贡献者本人回应评审讨论。他在审阅时会进一步追问，需求来自什么场景，为什么采用这种实现，某个针对特殊场景的开关是否应该默认开启。
James 强调，开发者需要对提交的代码负责。AI 辅助评审可以帮助查找问题，但无法替代提交者对实现逻辑的理解。王纪飞也结合自身实践提到，在真实环境中进行端到端验证，有助于检查功能是否达到预期。
对企业基础设施团队，这些讨论对应着一项清晰的要求。评审除了检查代码，还需要检查需求依据、行为变化和验证结果。尤其是默认配置与兼容性相关的修改，影响可能超出提出需求的单个场景。
面向下一阶段，先把知识和真实负载理解清楚
谈到是否需要为 HAMi 增加专门的 MCP 工具，嘉宾们给出了不同侧重。
王纪飞认为，在他使用 AI 排障的经验中，难点更多在于判断问题可能出现在哪里，增加工具未必能直接补足这一点。侯雨希更希望沉淀设计决策、实现背景等知识，让 AI 在分析日志和代码时拥有更多上下文。James 则从新用户的角度出发，认为便捷地收集日志与运行状态、获得初步分析，可以降低排障门槛，具体形式不必局限于 MCP。
讨论并未形成统一的工具选型结论，但提出了一个值得持续验证的方向。帮助使用者理解系统，需要可获取的运行信息，也需要解释系统为何这样设计的知识。
关于大模型趋势下 HAMi 的作用，嘉宾们没有把未来归结为单一负载。王纪飞提到大小模型协作、路由模型和投机解码中的小模型需求。侯雨希指出，公司的 GPU 节点已集中用于大模型推理，当下细粒度切分需求并不明显；他也结合个人使用经历，补充了 Embedding、语音识别等小模型场景，以及部分拆分推理环节可能产生的共享需求。James 则强调国产算力适配。HAMi 的价值需要放回实际负载判断：适合共享的任务利用细粒度资源，整卡或多卡任务保留相应资源形态，不能为了提高共享比例而忽略业务要求。
密瓜智能参与 HAMi 共建的立场，是让企业问题、验证经验和设计讨论进入开放协作，而不是把社区价值仅仅归结为新功能的数量。这场圆桌也清楚地提出了需要改进的地方：新人反馈要能被接住，设计背景要便于查阅，AI 辅助开发仍要由贡献者解释需求并承担验证责任。对企业用户，可持续的社区应让采用者逐步拥有参与改进的能力；对 HAMi，这些日常协作决定了共享与异构适配能力能否持续贴近真实使用。
欢迎从一个真实问题、一次讨论或一份文档改进入手，参与 HAMi 社区共建。