★ FEATURED ARTICLE 1. vGPU 到底在解决什么问题从一张显卡被十个人抢说起机房里有台服务器插着一张数据中心级显卡第一天上班的场景我印象很深三个同事排着队要跑模型一个要训小网络一个要做推理压测还有一个只想开个图形界面看看渲染效果。结果是谁先占上谁用另外两个人干瞪眼。这台机器的算力利用率可能连 15% 都不到但所有人都觉得资源不够。vGPU 就是从这个矛盾里长出来的东西。它的核心思路很朴素把一块物理 GPU 的计算单元和显存切分成若干份每一份以独立虚拟设备的形式分配给一台虚拟机。对虚拟机里的操作系统来说它看到的就是一块真显卡有显存、有驱动、能跑 CUDA、能开图形加速。但宿主机知道这只是物理显卡上的一块时间片加一块显存分区。这里要先分清两个容易混的概念。**直通Passthrough**是把整块物理显卡原封不动交给一台虚拟机独占、性能最高、零损耗但一卡只能一用。vGPU 则是共享一卡多用代价是调度开销和隔离约束。两者不是替代关系是取舍关系。我在实际项目里见过太多人一上来就要 vGPU问他业务形态——单机跑大模型训练一张卡要占满 80GB 显存那 vGPU 对他毫无意义直通才是正解。vGPU 真正的甜点区间是三这类场景虚拟桌面几十个办公用户同时开设计软件、看图、剪短视频多租户推理若干小模型服务各自跑在独立虚拟机里互不干扰开发测试环境一批工程师要各自的 GPU 沙箱谁也不想排队。这三类的共同特征是单实例需求不大但实例数量多且需要强隔离。所以判断要不要上 vGPU我的经验是先算一笔账把当前所有 GPU 任务的峰值显存占用和峰值算力占用列出来。如果存在大量显存只用了 4GB、算力只跑了两成的实例且这些实例对延迟不敏感那 vGPU 就有价值。反过来如果单个任务就要吃掉整卡七成以上资源切分只会让所有人都变慢。还有一个常被忽略的维度是隔离等级。vGPU 不是切得越细越好切得越细单实例的性能抖动越明显而且某些切分规格下不支持 CUDA 的某些特性。我在一个渲染集群里吃过这个亏为了多塞几个实例选了最小的切分规格结果发现部分实例跑复杂着色器时帧率掉得厉害最后只能回退到更大的规格重排。这件事后面会详细展开。2. 拆开看vGPU 的三种实现路径与选型判断2.1 时间分片、空间分区与SR-IOV的本质差别vGPU 这个叫法在实践中其实覆盖了三类技术路线很多文档把它们混着讲导致选型时一头雾水。时间分片Time-Slicing多个虚拟实例轮流使用同一组物理计算单元靠调度器快速切换让每个实例都觉得自己在用整卡。优点是切分灵活、规格不受限缺点是切换有开销且实例之间在计算单元层面没有硬隔离一个实例把算力打满其他实例的延迟就会被拉长。这种方式适合对吞吐敏感、对单次延迟不敏感的场景比如离线批处理、批量推理。空间分区Spatial Partitioning / MIG 思路把物理 GPU 的显存和计算单元在物理上划成互不重叠的区块每个区块有独立的显存通道和计算单元。这种隔离是硬件级的一个区块出问题不影响另一个。代价是分区规格受硬件支持矩阵限制不能任意切而且切完之后不能动态重组要改配置得把上面的实例全停掉。SR-IOV单根输入输出虚拟化让一个物理设备在硬件层面呈现出多个独立的功能实例每个实例可以被直接分配给虚拟机绕过宿主机的软件调度层。这条路径的虚拟化开销最小接近直通性能但对硬件和固件的要求最高且实例数量受硬件限制。我把三者的关键差异整理成一张表选型时对着看会快很多维度时间分片空间分区SR-IOV隔离强度弱软件调度强硬件隔离强硬件实例切分灵活性高规格较自由低受支持矩阵约束低受硬件实例数约束虚拟化开销中等较低最低动态调整可动态增减实例需停机重组需重新配置典型适配场景批处理、多租户推理强隔离多租户、混合负载高性能虚拟桌面、低延迟推理注意这三种路线不是同一款产品的三个开关而是不同代际、不同硬件能力下的方案。选型前必须先确认手上的卡和固件支持哪一条别照着别人的方案硬套。2.2 切分规格怎么定一个真实的容量测算过程假设你要给一个开发团队做 GPU 沙箱10 个人任务是训练中小型模型和跑推理验证。手上有一张 48GB 显存的卡。怎么切第一步摸清单人峰值。让团队里最重的那个任务先跑一遍用显存监控工具看峰值。假设最大峰值是 12GB其余大多数在 6GB 到 8GB 之间。第二步算最坏情况。如果 10 个人同时满负荷按 12GB 算需要 120GB显然不可能。这时候要做的是错峰假设实际并发率通常在 0.4 到 0.6 之间即同时满负荷的只有 4 到 6 人。按 5 人满负荷算需要 60GB还是超。第三步做规格分层。不要给所有人一样的规格。给 2 个人配 12GB 的大规格跑训练给 8 个人配 4GB 的小规格跑调试和推理总计 24 32 56GB仍超 48GB。那就把大规格降到 1 个小规格降到 8 个总计 12 32 44GB留 4GB 余量给驱动和系统开销刚好可行。这个过程的关键不是算术而是承认资源一定不够然后按优先级分配。我见过太多方案文档写按需分配、弹性伸缩落地时发现根本没人愿意主动释放资源。所以一定要在规格设计阶段就把谁拿大规格、什么条件下收回写成规则。另外提醒一个坑显存切分不等于算力切分。你给某个实例分了 4GB 显存不代表它的算力上限就被限制在四分之一。在时间分片模式下多个实例仍然共享同一批计算单元如果某个实例持续满载其他实例的算力会被挤压。所以容量测算要同时看显存和算力两个维度只算显存是不够的。2.3 什么情况下不该用 vGPU这条我要单独强调因为踩过坑。以下三种情况直通或者干脆物理独占更合适单任务显存占用超过整卡七成切分后剩余空间太小实例数上不去调度开销反而成了纯损失。对延迟极其敏感的业务实时推理要求稳定在某个毫秒级阈值内时间分片带来的抖动可能直接击穿 SLA。需要完整 GPU 特性的负载某些并行计算特性、某些调试能力在虚拟化层下受限跑出来的结果和裸机不一致排查成本极高。判断方法很简单拿一个代表性任务分别在直通和 vGPU 环境里跑对比完成时间和结果一致性。差异超过 15% 就要慎重超过 30% 基本可以放弃 vGPU 方案。3. 部署落地从驱动匹配到实例跑通的关键步骤3.1 版本矩阵是第一个拦路虎vGPU 部署失败的原因里版本不匹配能占一半以上。这里涉及四层东西必须对齐宿主机操作系统版本、虚拟化平台版本、GPU 驱动版本、虚拟机内驱动版本。它们不是各自独立升级的而是有一套官方发布的兼容矩阵必须整组对齐。我的做法是先在纸上把四层版本写清楚再去查对应矩阵确认这一组是已验证的组合然后再动手。千万不要先把最新的都装上试试那条路通向无尽的排查。具体到操作层面宿主机侧的驱动安装有几个细节值得说安装前必须确认 GPU 处于可被虚拟化层接管的状态有些平台需要在固件层开启特定选项否则驱动装完也认不到可分片的设备。安装过程会要求重启重启后要验证虚拟化层能否正确枚举到 GPU 的分片能力这个验证步骤不能跳。宿主驱动和虚机内驱动是两套不同的包名字很像装错了会出现虚机里能看到设备但无法初始化的典型症状。虚机内驱动的安装顺序也有讲究先装平台侧的工具组件再装 GPU 驱动顺序反了经常出现设备识别不全。装完之后用一条最简单的查询命令验证能列出设备型号和驱动版本才算这步过了。3.2 实例创建与资源绑定的实际操作路径实例创建这一步不同平台的操作入口不一样但逻辑是通的先定义切分规格再创建虚拟设备最后把虚拟设备挂到虚拟机上。第一步确认可用的切分规格列表。这一步会列出当前硬件支持的所有规格以及每种规格最多能开几个。这里有个容易被忽略的约束不同规格之间会互相挤占。比如一张卡上开了两个大规格可能就再也开不出小规格了因为显存和计算单元已经被占满。所以规划时要先定大规格的数量再拿剩余空间去排小规格。第二步创建虚拟设备。这个过程要指定规格类型和数量。创建完成后平台会给出每个虚拟设备的标识记下来绑定虚拟机时要用。第三步把虚拟设备挂载到目标虚拟机。挂载时要注意虚拟机的配置里是否已经存在其他显卡设备如果存在冲突设备需要先清理否则挂载会失败或者挂上了但虚机内识别异常。第四步启动虚拟机进系统后检查设备管理器或对应的设备列表确认新设备出现且驱动正常加载。这一步如果设备出现但带感叹号八成是虚机内驱动版本和宿主侧不匹配回退到版本矩阵重新核对。我把这四步里最常见的失败症状和对应原因整理了一下实际排查时按这个顺序看能省不少时间症状最可能的原因处理方向宿主机枚举不到分片能力固件层未开启虚拟化支持检查固件配置并重启虚拟设备创建成功但挂载失败虚机已有冲突的显示设备清理冲突设备后重挂虚机内设备带感叹号虚机内驱动与宿主驱动版本不匹配按兼容矩阵整组对齐设备正常但程序报无可用 GPU虚机内运行时组件缺失或版本过低补齐运行时组件多个实例同时跑时性能剧烈波动切分规格过小或算力被挤占提高规格或减少实例数3.3 一个必须做的基线测试实例跑通不代表可用。我养成的习惯是每配好一台机器先跑一组基线测试记录三个数字。第一单实例满负荷性能。让一个实例把算力打满记录完成时间和峰值显存。这是后续所有对比的基准。第二多实例并发性能。所有实例同时满负荷记录各自的完成时间和总吞吐。这个数字最能暴露切分规格是否合理。我遇到过一种情况单实例跑得挺好一并发就集体变慢三倍说明规格切得太细调度开销吃掉了大部分收益。第三长稳测试。连续跑几个小时观察是否有实例掉线、显存泄漏、性能随时间衰减。虚拟化层的资源回收机制在某些负载下会有问题长稳测试是唯一能提前发现的办法。这三组数字一定要存档。后面加实例、改规格、升级驱动都要拿新数字和这组基线对比。没有基线所有变快了或变慢了的判断都是感觉不是事实。4. 性能调优与那些文档里不写的坑4.1 为什么并发一上来性能就崩根因排查链路这个现象我遇到不止一次排查过程值得完整写一遍。现象四个实例单跑各自正常四个同时跑每个的完成时间从 10 分钟涨到 35 分钟。第一步确认是不是显存不够导致的换页。查每个实例的显存使用发现都远低于分配上限排除显存不足。第二步确认是不是宿主 CPU 或内存带宽成了瓶颈。看宿主机的 CPU 使用率和内存带宽发现 CPU 只有三成但内存带宽接近饱和。这就是线索了——虚拟化层在实例切换时要搬运数据切换越频繁内存带宽压力越大。第三步确认切换频率。这一层要看虚拟化层的调度统计。如果实例数远大于计算单元能同时容纳的数量切换就会非常频繁。第四步定位到根因切分规格过小导致单实例分到的计算单元时间片太短切换开销占比过高。四个实例争抢的资源总量是固定的切得越细切换次数越多损耗越大。修复方案把实例数从四个降到两个规格翻倍。重新测试两个实例并发的完成时间是 12 分钟虽然实例数少了但单实例体验和总吞吐都改善了。举一反三这个逻辑适用于所有共享型资源。判断标准是看切换开销占总耗时的比例如果这个比例超过两成就说明切得太细了应该往粗调。这个判断方法比看任何指标都直接。提示如果业务确实需要很多实例而粗规格又满足不了隔离要求那就要考虑换硬件或者换方案而不是继续在软件层硬调。这是选型问题不是调优问题。4.2 显存分配的隐性开销给实例分配 8GB 显存实际可用并不是 8GB。虚拟化层要占一部分做地址映射和元数据虚机内的系统也要占一部分做显示缓冲。实际可用可能是 7.2GB 到 7.6GB。这个差异在小规格下影响很大。你按 4GB 规格去规划结果业务峰值要 3.9GB看着能塞进去实际跑起来就 OOM。我的经验是按分配值的 90% 到 92% 来估算可用上限小规格取下限大规格取上限。另一个坑是显存回收不及时。某些负载会申请大块显存然后不主动释放虚拟化层的回收有延迟。表现出来的症状是实例跑完一个任务后再跑第二个任务就报显存不足。解决办法是在实例配置里开启更积极的回收策略或者在业务层做显式释放。这个问题在长时间运行的实例上尤其明显短任务测试是测不出来的。4.3 隔离边界在哪里一个安全视角的提醒vGPU 的隔离不是绝对的。时间分片模式下实例之间共享计算单元理论上存在侧信道风险。对于多租户环境尤其是租户之间互不信任的场景这一点必须评估。我给出的实践建议是信任边界内的多实例用时间分片跨信任边界的用空间分区或 SR-IOV。什么叫信任边界内同一个团队、同一个项目组、同一个内网环境可以认为是信任边界内。如果是给外部客户提供算力或者不同部门之间数据敏感就应该用硬件级隔离的方案。这个判断我在一个项目里做错过一次。当时为了省资源给两个不同业务线的人分在同一张卡的时间分片实例上结果一方跑的压力测试把另一方拖垮虽然没造成数据问题但事故复盘时隔离不足这条被点名了。后来改成每个业务线独立分区问题消失。5. 监控指标与日常运维的几个实战心得5.1 必须盯住的四个指标vGPU 环境的监控和裸机不一样多了虚拟化层这一层指标要多看几项。我日常盯这四类第一类是单实例资源占用包括显存使用率和算力使用率。这两个指标决定了规格是否合理。如果长期低于三成说明规格给大了可以缩如果频繁顶到上限说明要扩或者要拆。第二类是实例间的资源争抢程度。这个指标在裸机上看不到需要看虚拟化层统计的调度等待时间。等待时间占比持续走高就是切分过细的信号。第三类是虚拟化层自身的开销包括宿主 CPU 占用和内存带宽占用。这两项如果接近饱和说明瓶颈不在 GPU加卡也解决不了问题。第四类是实例的健康状态包括是否有掉线、是否有驱动异常、是否有回收失败。这类指标适合做告警出问题时第一时间知道。我把这四类指标和对应的判断阈值整理如下供参考阈值需按实际硬件和业务调整不能照搬指标类别具体项关注阈值处置动作单实例占用显存使用率长期低于 30%规格偏大降规格或合并实例单实例占用显存使用率频繁超 85%规格偏小升规格或拆分负载争抢程度调度等待时间占比超 20%切分过细减少实例数、提高规格虚拟化开销宿主内存带宽接近饱和瓶颈转移排查数据搬运量健康状态实例掉线或回收失败任意出现立即排查并重启实例5.2 变更管理为什么临时改一下最危险vGPU 环境里任何改动的影响面都比你想象的大。改一个实例的规格可能要停机重组其他实例跟着中断升级一次驱动整个宿主上的实例都要重启。我吃过一次教训为了给一个临时任务腾资源随手把一个实例的规格调小结果那个实例的操作系统里驱动重新初始化失败连带另外两个实例也报了设备异常。事后复盘发现规格变更在某些平台上是整卡级别的操作影响的是所有实例。所以我的做法是定三条规矩所有规格变更走计划窗口和所有使用者提前对齐时间不在业务高峰期做。变更前必须有一次完整备份把当前可用的配置组合记下来出问题能快速回滚。变更后必须重跑基线测试和存档的基线对比确认性能没有意外下降。这三条看起来很重但比事故后通宵排查要轻得多。5.3 什么情况下应该加卡而不是继续优化优化有上限。当你已经按信号调整过规格、减少过实例数、清理过显存回收问题性能还是不够那就该加卡了。判断标准我一般用两个一是所有实例的平均资源占用都超过七成说明是真的资源不够不是分配不合理二是调度等待时间占比在合理规格下仍然超过两成说明物理资源已经饱和。这两条同时满足就不要再调了直接提扩容需求。继续优化的边际收益很低而且容易在调参过程中引入新的不稳定。反过来如果只有个别实例占用高、大多数很闲那是分配问题不是容量问题加卡解决不了只会让闲置更多。6. 收尾时分享一个我常用的判断口诀这套东西用久了我总结出一句话来判断要不要上 vGPU、该怎么切看峰值不看平均看并发不看单跑看隔离不看性能。看峰值是因为平均值会骗人一次显存打满就可能把整个实例搞崩。看并发是因为单实例跑分好看没有意义真实的收益体现在多实例同时工作时的总吞吐。看隔离是因为性能不够可以加卡隔离不足是方案层面的错改起来成本最高。另外一条经验是先用直通跑通业务再考虑虚拟化。很多人一上来就搭 vGPU 环境结果业务本身的问题和虚拟化的问题混在一起排查时分不清是哪一层的错。先用最简单的直通方式确认业务能跑、性能达标再把业务搬到 vGPU 环境里对比差异就一目了然。这个顺序看起来多花了一步实际省下的排查时间远不止一步。最后提一个细节给每个实例做命名规范把规格、用途、负责人写在名字里。当实例数量上去之后没有命名规范的环境基本没法运维。这个成本几乎为零收益却贯穿整个生命周期。
阅读完成 · 觉得有帮助？
