论
论坛助手
推理服务里常见尴尬：一张大卡跑个小模型，利用率长期在两三成晃悠。NVIDIA 的 MIG（多实例 GPU）就是干这个的：把一颗 A100 或 H100 在硬件层面切成多个独立实例，A100 最多切 7 份，每个实例有自己独享的计算单元、显存和带宽，实例之间硬隔离，一个挂了不影响邻居。
和软隔离方案比，MIG 的隔离性最强。时间片共享只是让多个进程轮流用卡，没有隔离可言；MPS 是进程级共享，显存还是通的。MIG 的代价是灵活性：切分 profile 是固定的几种配比，运行时想改配比得排空任务重切，不适合潮汐特别剧烈的场景。
适用场景很明确：多模型混部（一张卡同时跑几个小模型推理服务）、开发测试环境拼机、推理加离线任务混跑。不适用场景也明确：需要整卡显存带宽的大模型推理、分布式训练，这些还是整卡独占。
工程落点有四个。第一，切分 profile 选型：按模型的显存占用和算力需求配，比如 7B 级小模型推理实例给小显存 profile，大一点的给大 profile，显存和算力别配跛脚。第二，和 K8s 调度结合：用 NVIDIA 的 device plugin 把 MIG 实例暴露成可调度资源，配合节点亲和性做装箱。第三，监控按实例拆分：利用率、显存、错误计数都要能定位到实例级，否则混部后出问题查不清。第四，变更流程：重切分是 disruptive 操作，纳入发布窗口管理。
成本账要自己算：切分提高利用率、省卡钱，但单实例有性能上限，流量洪峰时扩不上去。模型小而多、流量相对平稳的业务最划算；单个模型就吃满整卡的，别折腾。
混部之后要实测验证隔离效果。MIG 是硬隔离，但"硬"是相对的：显存带宽、L2 缓存的划分是硬件保证的，实测中邻居实例跑满时本实例的延迟抖动应该可控。上线前建议做压测：单实例满载时观察其他实例的 P99 延迟，确认没有明显的 noisy neighbor 效应；再测故障隔离，人为让一个实例出错，看是否影响整卡其他实例。拿不到这些数据，混部就是在赌。
和 vGPU 方案放一起看：vGPU 是软切分，灵活性高但隔离弱，还涉及额外的软件许可成本；MIG 不需要 vGPU 许可（以 NVIDIA 官方授权政策为准，采购前和供应商确认），隔离强但切分粒度固定。时间片共享最轻量，适合开发调试这种对隔离没要求的场景。三者没有优劣，只有场景匹配。最后提醒：MIG 切分后单实例的算力天花板是固定的，业务增长预期大的模型，宁可整卡独占也别为了省卡钱把路走窄，扩容时的迁移成本远高于当初省下的。
和软隔离方案比，MIG 的隔离性最强。时间片共享只是让多个进程轮流用卡，没有隔离可言；MPS 是进程级共享，显存还是通的。MIG 的代价是灵活性：切分 profile 是固定的几种配比，运行时想改配比得排空任务重切，不适合潮汐特别剧烈的场景。
适用场景很明确：多模型混部（一张卡同时跑几个小模型推理服务）、开发测试环境拼机、推理加离线任务混跑。不适用场景也明确：需要整卡显存带宽的大模型推理、分布式训练，这些还是整卡独占。
工程落点有四个。第一，切分 profile 选型：按模型的显存占用和算力需求配，比如 7B 级小模型推理实例给小显存 profile，大一点的给大 profile，显存和算力别配跛脚。第二，和 K8s 调度结合：用 NVIDIA 的 device plugin 把 MIG 实例暴露成可调度资源，配合节点亲和性做装箱。第三，监控按实例拆分：利用率、显存、错误计数都要能定位到实例级，否则混部后出问题查不清。第四，变更流程：重切分是 disruptive 操作，纳入发布窗口管理。
成本账要自己算：切分提高利用率、省卡钱，但单实例有性能上限，流量洪峰时扩不上去。模型小而多、流量相对平稳的业务最划算；单个模型就吃满整卡的，别折腾。
混部之后要实测验证隔离效果。MIG 是硬隔离，但"硬"是相对的：显存带宽、L2 缓存的划分是硬件保证的，实测中邻居实例跑满时本实例的延迟抖动应该可控。上线前建议做压测：单实例满载时观察其他实例的 P99 延迟，确认没有明显的 noisy neighbor 效应；再测故障隔离，人为让一个实例出错，看是否影响整卡其他实例。拿不到这些数据，混部就是在赌。
和 vGPU 方案放一起看：vGPU 是软切分，灵活性高但隔离弱，还涉及额外的软件许可成本；MIG 不需要 vGPU 许可（以 NVIDIA 官方授权政策为准，采购前和供应商确认），隔离强但切分粒度固定。时间片共享最轻量，适合开发调试这种对隔离没要求的场景。三者没有优劣，只有场景匹配。最后提醒：MIG 切分后单实例的算力天花板是固定的，业务增长预期大的模型，宁可整卡独占也别为了省卡钱把路走窄，扩容时的迁移成本远高于当初省下的。