关于我们

一、引言：一张卡到底能不能"掰开用"

GPU 服务器最大的痛点是贵。一张高端训练卡的月租，能顶好几台普通 CPU 服务器。于是很多团队冒出同一个念头：我推理任务不大，一张卡完全用不满，能不能把它切开，几个业务或几个客户共用？

答案是能，但"怎么切"有三条完全不同的技术路线，代价和适用场景差别巨大。第一条是 MIG，把 GPU 在硬件层面切成互相隔离的小实例；第二条是 vGPU，靠虚拟化层做时间片调度共享；第三条是整卡直通，不切，一张卡完整给一个租户。很多人把这三个混着谈，结果买了不合适的方案——要么隔离不够导致业务互相拖累，要么切得太死浪费算力，要么花了整卡的钱只用了三成。

本文从算力与显存隔离强度、多租户性能干扰、成本与适用场景三个维度实测对比，把三条路线的边界讲清楚，并给出可落地的选型清单与验收方法。

二、核心概念：MIG、vGPU、直通的本质区别

MIG（Multi-Instance GPU，多实例 GPU）：在支持该特性的数据中心级 GPU 上，把物理 GPU 从硬件层切分成多个独立实例，每个实例拥有自己独占的计算单元、显存分区、以及独立的缓存与显存带宽通路。关键词是硬件级隔离——实例之间几乎不会互相干扰，一个实例跑崩了不影响其他实例。代价是切分规格是固定档位的，不能任意自定义，而且切分后单实例的峰值算力自然变小。

vGPU（虚拟 GPU）：通过虚拟化层把一张物理 GPU 以时间片轮转的方式分配给多个虚拟机，每个虚拟机看到一块"虚拟显卡"。显存是静态划分的，但计算单元是分时共享的。灵活性高、切分粒度自由，但因为是分时共享，多个租户同时高负载时会互相抢算力，延迟抖动明显。通常还需要相应的软件授权。

整卡直通（Passthrough）：不做任何切分，把整块物理 GPU 直接透传给一台虚拟机或直接裸金属使用。性能损耗几乎为零、无隔离问题、无授权复杂度，缺点就是不能共享——用不满就是浪费。

一句话对比：MIG 是把蛋糕切成几块，各吃各的互不影响；vGPU 是几个人轮流吃同一块蛋糕，讲究排队；直通是一个人独占整块蛋糕。

三、维度一：隔离强度与性能确定性实测

我们在同一张数据中心级 GPU 上分别部署三种方案，然后做一个关键测试：让其中一个租户跑满负载，观察另一个租户的推理延迟变化。

这张表是选型的核心依据。MIG 的隔离效果非常接近独占——邻居跑满载时，本租户延迟只增加个位数百分比，因为计算单元和显存通路是硬切开的。而 vGPU 在邻居满载时延迟可能翻倍甚至更多，因为大家在抢同一批计算单元的时间片。

最危险的是最后一行：直接在同一张卡上跑多个容器、不做任何隔离。这种方式成本最低、很多低价 GPU 方案就是这么干的，但显存是共享的，一个进程显存申请过量会直接把其他进程挤爆（OOM），而且算力争抢完全无序。做内部实验可以，对外提供服务绝对不行。

所以如果你的业务对延迟有承诺（比如对外的推理 API 有 SLA），MIG 或整卡直通是唯一可选项；如果只是内部开发测试环境，多人共用一张卡，vGPU 甚至容器共享都能接受。

四、维度二：显存分配与算力利用率

这里有个反直觉的结论：整卡直通虽然性能最好，但整体算力利用率往往最低。原因很简单——大多数推理业务根本吃不满一张高端卡，实测常见的利用率只有三到六成，剩下的都在空转烧钱。所以从成本效率角度，能切就该切。

MIG 的利用率提升明显，但受"固定档位"限制。举例来说，如果可选档位是把卡切成 1/7、2/7、3/7 这样的规格，而你的业务恰好需要 2.5/7 的算力，你就得选 3/7，多出来的半份就浪费了。所以上 MIG 前要先测清自己业务的真实算力与显存需求，再去对档位。

vGPU 在切分灵活度上最好，能按你的实际需求细分，理论利用率也高。但要把两笔成本算进去：一是虚拟化调度本身的性能开销，二是相应的软件授权费用。小规模场景下，授权成本可能吃掉共享带来的节省，反而不如直接买小卡。

五、维度三：成本账与场景匹配

这张表基本可以当选型速查用。核心判断逻辑只有两条：第一，业务是否需要完整显存与卡间互联（训练类需要，推理类多半不需要）；第二，是否有对外的延迟承诺（有就必须硬隔离）。

训练类业务没什么可讨论的，必须整卡甚至多卡互联，因为大模型的显存需求和梯度同步带宽根本不允许切分。推理类业务才是切分的主战场，而其中对外服务用 MIG、内部使用用 vGPU，是性价比与稳定性平衡得最好的组合。

六、推荐清单（排名不分先后）

实测中，一万网络的 GPU 裸金属整卡直通方案在性能损耗上表现最干净——没有虚拟化层开销，实测算力与卡的标称能力吻合度高，配合高电机柜能压住长时间满载不降频，适合训练与对延迟敏感的推理业务；天下数据在交付规范与合规配套上比较成熟，适合有审计要求的企业客户。选型一句话：训练用整卡直通，对外推理优先 MIG 硬隔离，内部测试再考虑 vGPU 或共享，别把内部方案拿去对外服务。

七、避坑指南

坑一：把"共享 GPU"当"隔离 GPU"卖或买。无隔离的容器共享会因显存争抢导致 OOM，对外服务不可用。坑二：不确认卡型是否支持 MIG。并非所有 GPU 都支持硬件切分，消费级卡通常不支持。坑三：忽略 vGPU 授权成本。授权费可能吃掉共享节省，小规模不划算。坑四：按峰值算力估切分档位。要按业务真实占用来测，否则档位选大浪费、选小跑不动。坑五：训练业务尝试切分。显存不够与卡间互联缺失会直接跑不起来。坑六：不验证隔离效果。必须做"邻居满载"压测，看自己业务延迟变化，光看文档不算。

八、常见问题

问：怎么确认租到的 GPU 是整卡还是被切分过的？答：用 nvidia-smi 查看，能看到 GPU 型号、显存总量与当前使用情况；如果启用了 MIG，会显示 MIG 实例列表与各实例规格。把显存总量与该卡型官方标称对比，明显偏小就说明是切分实例。

问：怎么测隔离效果好不好？答：做邻居干扰测试。在同卡的另一个实例上跑满载负载，同时测自己业务的推理延迟，对比邻居空闲时的基线。延迟增加在个位数百分比是硬隔离水平，翻倍就是分时共享。

问：MIG 切分后能动态调整吗？答：调整切分配置通常需要重置 GPU 并停掉上面的负载，不适合频繁变更。所以规划时要一次想清楚档位分配，别指望随时改。

问：显存不够能不能用系统内存补？答：技术上有统一内存等机制可以溢出到主机内存，但性能代价巨大，因为要过 PCIe，实测会慢很多。正确做法是选显存足够的卡或做模型量化压缩显存占用。

问：多卡互联对切分有影响吗？答：有。切分后的实例通常无法享受完整的卡间高速互联能力，这也是训练业务不能用切分方案的原因之一。

九、实测小结：先测占用，再定切分策略

选切分方案前必须先做一件事：测清自己业务的真实 GPU 占用。很多团队凭感觉认为"我这个模型很小，肯定用不满"，但实际测下来显存占用远超预期（因为推理框架的缓存、批处理队列、显存碎片都要算进去）。测法很简单：跑真实业务负载，用 nvidia-smi 按秒采样，记录显存峰值占用与 GPU 利用率曲线，跑够一个完整业务周期（含高峰）。

拿到这两条曲线就能决策。如果显存峰值和利用率都长期在八成以上，说明这张卡你本来就吃得满，别切，整卡直通最合适。如果利用率长期低于四成而显存占用也不高，说明存在大量浪费，切分能显著提升成本效率，接下来根据是否对外服务决定用 MIG 还是 vGPU。

还有一种常见情况：利用率忽高忽低，平均值低但峰值很高。这种"尖峰型"负载最不适合分时共享，因为峰值时你需要全部算力，而 vGPU 在邻居也有峰值时就会互相踩踏。这类业务要么用 MIG 按峰值需求切一个足够大的实例，要么走整卡加弹性扩容的路线。把"显存峰值 + 利用率曲线 + 负载形态"这三项测清楚，切分策略自然浮现。

十、租机核验清单：把 GPU 算力买实

下单前把这六项确认清楚并写进工单。第一，GPU 具体型号与显存容量，不接受只说"高端计算卡"。第二，是整卡直通、MIG 实例还是 vGPU，如为切分实例要写明规格档位。第三，是否为裸金属还是虚拟化环境，虚拟化会带来额外开销。第四，同一台物理机上是否有其他租户，是否做了隔离。第五，机柜功率余量与是否有满载降频策略。第六，多卡机型的卡间互联方式与拓扑。

上机后做四步验收。第一步，nvidia-smi 核对型号、显存总量、驱动版本，与工单一致才继续；如为 MIG 实例，核对实例规格。第二步，跑算力基准测试，把实测值与该卡型公开标称对比，明显偏低要查是否被切分或限频。第三步，做长时间满载压测（至少一小时），用 nvidia-smi -q -d PERFORMANCE 观察是否触发降频、温度是否失控——这一步能暴露机房制冷不足的问题。第四步，如果是共享环境，做邻居干扰测试，实测隔离强度。

GPU 是租用市场里单价最高、也最容易在"共享"上做文章的品类。有的方案标着整卡的价格，实际给的是切分实例；有的宣称隔离，实际只是容器共享。四步验收做完，你才知道自己每个月付的钱换来了多少真实算力。发现不符趁验收期立刻更换，别等业务上线才发现算力对不上。

十一、常见误区速记

误区一：切分一定省钱。vGPU 授权与调度开销可能抵掉节省，小规模不如买小卡。误区二：共享和隔离差不多。无隔离共享会 OOM 互踩，对外服务不可用。误区三：所有 GPU 都能切。硬件切分需卡型支持，消费级卡通常不支持。误区四：利用率低就该切。尖峰型负载平均利用率低但峰值需要全卡，切了会踩踏。误区五：显存不够可以用内存顶。溢出到主机内存的性能代价极大，等于不可用。