行业背景与核心问题 - 大模型时代下，GPU算力成为稀缺资源，但全球GPU的平均利用率仅徘徊在10%-20%之间，大量显存与算力因“静态分配”模式而闲置[1] - 随着国产及多样化AI芯片发展，企业内部算力环境呈现多元复杂特征，不同架构、厂商的GPU与AI加速芯片并存，导致异构算力资源难以统一调度、共享效率不足、利用率不高[2] - 在AI智算时代，AI任务负载对算力的需求与底层硬件分配方式之间存在巨大错配，虚拟化被视为通向AI普惠的核心钥匙[13] 公司概况与融资情况 - 异构算力虚拟化与高效调度管理平台「密瓜智能」完成天使轮融资，由复星创富领投，拙朴资本和种子轮投资人跟投[1] - 天使轮融资金额为数千万元人民币，资金将主要用于HAMi开源生态建设及异构算力调度平台的产业化落地[1] - 公司成立仅一个季度内，便获得了200万元的产品订单合同[5] 核心技术：HAMi开源项目 - 密瓜智能发起并主导全球唯一专注异构算力虚拟化的CNCF开源项目——HAMi，其目标是成为算力调度领域的“统一语言”[2] - HAMi已完成对NVIDIA、华为昇腾、沐曦、摩尔线程、寒武纪、海光、燧原等9种以上芯片的适配[8] - 技术能力包括：1) 细粒度切分与显存超卖，支持将单枚GPU显存与算力进行精度达1/10甚至更小的切分；2) 支持动态MIG灵活配置；3) 支持显存自动弹性扩缩容及OOM抑制，配合任务优先级抢占机制；4) 通过高性能Turbo模式优化调度效率，实现与Kubernetes生态的原生融合，用户无需修改代码即可实现算力自动感知与分配[4][8] 应用案例与效果 - 在顺丰科技案例中，在仅有的6张GPU上成功部署了19个测试服务，节省了13张卡，资源效率提升了2倍以上[5][6] - 在越南AI学习平台PREP EDU案例中，面对RTX 4070与4090混装的复杂异构环境，实现了GPU集群痛点减少50%，GPU基础架构优化了90%[5][6] - 公司已获得AWS推理芯片的主动适配支持[5] 商业模式与团队背景 - 公司在开源项目HAMi基础上，打造面向企业客户的商业化产品与技术服务，提供工程能力、稳定性支持与持续运维保障，已与多家企业客户开展付费合作[10] - 核心创始团队长期深耕云计算、云原生及AI基础设施领域，CEO张潇曾任DaoCloud容器团队负责人，CTO李孟轩曾任第四范式异构算力技术负责人，两人均是Kubernetes核心贡献者及多个CNCF项目维护者[11] - 创始人表示，公司不追求激进的短期商业化，而是坚持通过开源社区HAMi建立行业的“事实标准”，愿景是让异构算力像水电一样简单好用[12] 投资人观点与行业意义 - 投资人认为，异构将成为算力市场的长期格局，密瓜智能在AI大生态中不可或缺地链接算力端与应用端，能极大提升算力效率并节省成本[12] - HAMi的开源路径与AI行业开源化、协同化发展趋势高度契合，其虚拟化技术能显著提升算力利用率，为客户带来极具竞争力的投资回报率[12] - 在国产算力多元异构的背景下，开源成为生存发展的必需，HAMi有望打破硬件藩篱，成为异构算力调度虚拟化的全球通用标准[13]

核心观点 - HAMi v2.7.0版本正式推出针对NVIDIA GPU的拓扑感知调度功能，旨在解决高性能计算和AI大模型训练场景下的多卡通信瓶颈问题 [2] - 该功能通过智能调度，将计算任务精确部署到物理连接最紧密、通信速度最快的GPU组合上，以最大化加速计算任务并提升集群整体的算力效能 [2] - 其设计哲学是用动态发现代替静态配置，用远见决策代替短视分配，构成了一套成熟、高效的GPU调度方案 [27] 核心特性总览 - 核心设计思想是先在节点本地将复杂的物理拓扑精确量化为设备间的“通信分数”，然后调度器基于这些分数做出最优选择 [5] - 具备动态计算拓扑分数特性，Device Plugin能够通过NVML动态探测节点上GPU间的物理连接拓扑（如NVLink、PCIe），并将其量化为通信分数 [6] - 采用双策略防碎片调度，Fit函数内置寻优算法，针对多卡任务和单卡任务自动采用“最佳匹配”与“最小破坏”策略 [6] 实现原理：拓扑注册与调度决策 - 拓扑注册阶段的目标是将GPU物理连接转化为调度逻辑可理解的标准化的数字分数 [9] - 信息探测环节通过NVIDIA的NVML获取所有GPU两两之间的物理连接类型（NVLink或PCIe） [11] - 数据建模与量化环节首先在内存中构建完整的GPU拓扑图，然后根据预设规则将连接关系计算转换为具体的通信分数 [11] - 最终产物是一个记录了每个GPU的UUID以及它与其他所有GPU之间通信分数的“设备分数表”，并被注册到节点的Annotation中 [11] - 调度决策阶段，Fit函数会先过滤掉不满足基本资源需求的GPU，然后基于设备分数表执行考虑了最佳匹配和最小破坏原则的寻优算法 [11] 代码深度解析：拓扑发现与分数计算 - 拓扑信息的发现与量化在Device Plugin本地完成，并最终生成可供上报的分数表 [13] - 构建拓扑图逻辑由`build()`函数完成，它初始化设备列表后，通过双重循环遍历所有GPU对，聚合连接信息，构建包含丰富连接信息的完整拓扑图 [15] - 量化为分数由`calculateGPUScore`函数完成，它会检查两个GPU之间的所有连接并根据详细的switch语句进行评分，最终分数是所有连接分数的总和 [15] 代码深度解析：设备端调度决策 - 调度决策核心逻辑位于设备端的`Fit()`函数中，该函数会根据请求的GPU数量自动切换寻优策略 [14] - 对于多卡任务（请求多于1个GPU），采用“最佳匹配”原则，目标是寻找内部通信总分最高的GPU组合 [19] - 具体实现是找出所有满足资源需求的空闲GPU，生成所有可能组合，计算每个组合内部所有设备对的分数总和，并选择分数总和最高的组合 [20][23] - 对于单卡任务（只请求1个GPU），采用“最小破坏”原则，目标是选择与其他可用GPU连接最“疏远”的卡 [22] - 具体实现是遍历所有可用单个GPU，计算每个GPU与其他所有可用GPU的分数总和，并选择总分最低的GPU，以保护拓扑完整性 [22] 使用方式 - 用户只需一个Annotation即可启用拓扑感知调度，调度器会根据任务请求的GPU数量自动应用相应的策略 [25] - 启用方式为在Pod的metadata annotations中添加`hami.io/gpu-scheduler-policy: "topology-aware"` [26]