在大规模 AI 推理场景中，"算力不够"往往并非由硬件规模不足导致。贝壳找房（以下简称贝壳）在千卡级 GPU 集群规模下，整体 GPU 利用率约为 13%，主要问题来自小模型与多模型混跑场景下的显存碎片化以及整卡独占使用方式。
在集群中存在 141G 等大显存 GPU 时，使用整卡运行 32B 以下模型，甚至仅占用 1--2G 显存的小模型服务，会导致大量显存长期处于空闲状态。与此同时，一些 GPU 共享方案并未提供真正的显存隔离能力，调度层在判断显存"看似充足"的情况下将任务调度到节点上，实际运行时因显存竞争导致 OOM，甚至引发线上事故。对于承载千万级请求的平台而言，这类不确定性风险需要被规避，因此方案需要满足不侵入业务、不改变开发者使用方式，并具备可控隔离与长期稳定运行能力。
贝壳找房算力平台开发工程师 王妮 的分享介绍了贝壳在大规模推理场景下围绕显存切分、资源池划分与显存隔离机制的实践过程，并结合实际运行中的问题，对生产环境下的资源治理经验进行了说明。
王妮 HAMi Meetup 北京站分享
按负载类型划分的资源使用策略
在落地路径上，贝壳首先对"提升利用率"进行场景拆分，将工作负载分为两类：
- 训练任务与强实时在线推理继续采用整卡独占方式，以保障性能与稳定性
- 小模型推理则以提高单卡显存填充率为目标，通过资源切分方式缓解显存碎片化问题。
基于这一判断，团队选择了 HAMi 的虚拟化方案。对于小模型推理场景而言，主要瓶颈在于显存空置而非算力不足，HAMi 通过内核侧实现显存硬隔离，能以相对较低的系统复杂度支持显存切分使用 。
显存资源池与整卡资源池的集群划分
在集群架构设计上，贝壳并未将整个集群统一切换为 HAMi 模式，而是根据节点能力进行划分，形成显存资源池与整卡资源池，并对上层业务保持透明。业务侧可根据资源请求的形态，选择将任务部署到支持显存切分的节点，或部署到裸卡节点。
在实现上，显存资源池节点部署了 HAMi device-plugin 及相关组件，支持按显存维度进行资源请求；而对整卡有需求的任务，则调度至未启用 HAMi 的裸卡节点。通过这种方式，在同一集群内同时支持整卡使用与显存切分两种运行模式 。
基于 Hook 的显存隔离机制
在 GPU 共享场景下，显存隔离通过 HAMi 的 hook 机制实现。服务启动时，HAMi 会向容器注入轻量级动态链接库，用于拦截应用的显存分配调用。对应用而言，其仍按照原有方式申请连续显存；而在底层实现中，物理显存被划分为多个相互隔离的区间，从而保障多个服务在同一张 GPU 上运行时互不干扰。
该方案已在生产环境中运行接近一年，期间未出现频繁的 OOM 重启问题，推理延迟及尾延迟均保持在可控范围内。整体 GPU 利用率由约 13% 提升至接近 30% 。
生产环境中的资源治理经验
在实际运行过程中，团队也遇到了一类具有代表性的问题：显存资源满足请求，并不意味着节点在整体上是可用的。当宿主机内存不足且未设置相应限制时，调度器会不断重试并产生大量日志，在极端情况下可能导致磁盘被写满，进而影响 CNI 等基础组件，最终在业务侧表现为 502 错误。
针对该问题，团队采取的临时处理措施包括避开调度器计算出的"最优节点"，将任务调度至其他节点运行，并对产生的日志文件进行清理 。该经验表明，在显存共享与切分场景下，资源治理需要从单一资源约束扩展到主机内存、磁盘等系统级资源，以避免引发系统层面的连锁风险。
上海密瓜智能科技有限公司专注于异构算力调度与统一管理，致力于为全球客户提供高效、灵活的算力解决方案。公司以"让异构算力因开源而好用"为使命，愿景是"构建全球领先的算力调度生态，赋能AI产业高效落地"。发起的CNCF 开源项目 HAMi，是唯一专注异构算力虚拟化的开源项目，通过灵活、可靠、按需、弹性的 GPU 虚拟化提升资源利用率，助力AI 时代算力效率提升。
邮箱：info@dynamia.ai