1. 三种“用上显卡”的物理事实，混淆了方向就会白折腾一整天
很多人第一次在虚拟化环境里接独显，脑子里只有一个模糊的念头：让虚拟机“用到”显卡。可实际动手才发现，“用到”这两个字的含义差得极远。有人装了 VMware Workstation，勾上“加速 3D 图形”，跑个三维小场景确实流畅了不少，于是以为自己搞定了；有人把这套经验搬到 ESXi 上，照着教程加了个 PCI 设备，开机后设备管理器里挂着个黄色感叹号，代码 43，折腾两天没解决；还有人买了张数据中心卡想跑 vGPU，结果卡在许可和版本矩阵上，硬件本身完全没问题。
这三种情况对应的是三条在物理层面完全不同的技术路线：3D 加速（图形指令转发）、PCIe 直通（整卡独占过户）、vGPU（物理卡切片共享）。它们对硬件的要求、对宿主机的影响、能承载的负载类型、许可证成本，每一条都不一样。选错了路线，后面所有配置工作都是白费；选对了路线，很多看起来玄学的报错其实一眼就能定位。
这篇内容面向的是手上有带独显的机器、想让虚拟机真正把显卡用起来的从业者——不管是搭测试环境、跑图形工作站、做渲染农场，还是在实验室里给多个人分显卡。我会把三条路线的底层机制、配置链路、性能边界和典型故障都拆开讲，尽量给到能直接照着做的参数和命令。前提是你已经会基本的虚拟机创建和系统安装，纯新手可能会在个别步骤上卡一下，但整体不影响理解。
1.1 显卡资源到底被谁“拿走”了
理解三条路线，最好先想清楚一件事：一块物理显卡在系统里表现为一个 PCIe 设备，它有自己的 BAR 空间（基址寄存器映射的内存区域）、自己的中断、自己的固件和驱动栈。所谓“给虚拟机用显卡”，本质上是在回答一个问题——这块 PCIe 设备的控制权，最终交到谁手里。
在 3D 加速路线里，控制权完全留在宿主机，虚拟机里看到的是一个虚拟的显示适配器（VMware SVGA 设备）。虚拟机里的图形调用被前端驱动截获，序列化之后交给宿主机上的 VMX 进程，由宿主机的真实显卡驱动完成渲染，结果再作为帧缓冲回传给虚拟机。这个过程有点像“你打电话点菜，厨房在别人家”——菜确实是你点的，但锅碗瓢盆你一个都摸不到。
在直通路线里，控制权被整体转移。宿主机在启动时通过 IOMMU 把这块设备从自己的设备树里摘出去，虚拟机启动时由 hypervisor 把设备的 BAR 空间直接映射进虚拟机的物理地址空间，中断也重定向过去。虚拟机里装的是原厂驱动，跑的是真实的固件，宿主机反而看不见这张卡了。这是“整间厨房过户给你”，代价是别人没法同时用。
在 vGPU 路线里，控制权被切分。宿主机装 NVIDIA 的 vGPU 主机驱动，显卡被划分成若干虚拟 GPU 实例，每个实例有独立的帧缓冲区间和独立的调度时间片，再由 hypervisor 分发给不同虚拟机。虚拟机里同样装 NVIDIA 驱动，看到的是一块“完整”的 GPU，但它实际上只是在用这块卡的一个切片。
注意：这三种模式的驱动栈完全不通用。直通模式下虚拟机里装的是标准数据中心/专业卡驱动；vGPU 模式下虚拟机里必须装带 vGPU 支持的客户机驱动，且版本要和主机驱动严格对齐。装错了就是代码 43 或者设备直接不识别。
1.2 一张对照表先把方向定下来
动手之前先对号入座，比装完再返工省事得多。
| 维度 | 3D 加速（转发） | PCIe 直通 | vGPU |
|---|---|---|---|
| 显卡归属 | 宿主机独占 | 单台虚拟机独占 | 多台虚拟机共享 |
| 并发能力 | 多台（性能叠加下降明显） | 一张卡一台机 | 一张卡切多份 |
| 需要 IOMMU | 不需要 | 必须 | 不需要（但需要卡在支持列表） |
| 需要许可证 | 不需要 | 不需要 | 必须 |
| 虚拟机快照 | 支持 | 不支持 | 部分支持 |
| 虚拟机热迁移 | 支持 | 不支持 | 有条件支持 |
| 典型场景 | 办公桌面、轻量 CAD、测试 | 图形工作站、单机渲染、AI 单机训练 | VDI 桌面池、多人共享算力 |
| 性能上限 | 受限于转发开销，通常不到物理卡三成 | 接近物理卡裸机性能 | 单实例接近切分比例，整体吞吐高 |
这张表里最容易被忽略的是“快照”和“迁移”两行。直通设备挂上去之后，虚拟机就失去了快照能力，这是硬约束，不是配置问题。很多人在生产环境里布好了直通，等到要做一次变更前备份时才发现快照按钮是灰的，只能临时想别的办法。如果你的流程强依赖快照和迁移，那从一开始就应该往 vGPU 方向走，而不是硬上直通。
2. 3D 加速路线：不动硬件归属，只把图形指令翻译过去
先讲最简单也最容易被低估的一条。这条路线的价值在于“零侵入”——不需要在 BIOS 里翻 IOMMU 开关，不需要担心设备分组，不需要为了装个驱动重启三次宿主机。它适合的场景其实比想象中多：远程办公桌面、轻量二维设计、教学演示、老版本工业软件的兼容性测试，这些负载对帧率的要求不高，但对“能不能跑起来”很敏感。
2.1 虚拟 SVGA 设备与转发链路是怎么工作的
虚拟机启动时，虚拟机会枚举出一块 VMware SVGA II 显示适配器，Windows 下走的是 VMware 自己的显示驱动，Linux 下是内核里的vmwgfx模块。这块“卡”没有真正的 GPU 核心，只有一组寄存器和一块显存区域，用来接收宿主机塞进来的帧数据。
当虚拟机里的程序发起 OpenGL 或 Direct3D 调用时，前端驱动会把这些调用打包成一套自定义的命令流，通过 VMX 进程的共享内存通道送到宿主机。宿主机侧再把命令流翻译成自己显卡驱动能理解的调用。这里的关键开销在于上下文切换和命令批处理效率：虚拟机的命令是批量提交的，宿主机要等一批攒够了再执行，中间还要处理状态同步。对于连续的大批量绘制（比如视频播放、简单的三维旋转），批处理效率高，体验接近原生；对于状态频繁切换、draw call 极其密集的负载（比如复杂装配体的 CAD 模型、大型游戏），每一批命令的有效载荷变低，开销占比就上去了。
我实测过一个比较典型的场景：一台虚拟机里跑轻量三维标注软件，旋转模型能到 40 帧左右，看起来够用；换成包含几十万个三角面的装配体，帧率直接掉到个位数，而此时宿主机的显卡占用率还不到 15%。这不是显卡不行，是转发链路成了瓶颈，GPU 在等命令。
2.2 Workstation 上的 3D 加速开关与显存设置
在 VMware Workstation 上，这条路线的开关藏在虚拟机设置的显示器页里。三个关键项：加速 3D 图形（必须勾选）、图形内存（决定虚拟机可见的显存上限）、显示器数量与最大分辨率。
图形内存的默认值通常偏小，跑纯办公没问题，跑稍微复杂一点的图形就吃紧。可以在关机状态下改.vmx配置文件，比图形界面更直接：
mks.enable3d = "TRUE" mks.gl.allowBlacklistedDrivers = "TRUE" svga.autodetect = "FALSE" svga.vramSize = "1073741824"svga.vramSize单位是字节，上面这行是 1GB。这个值不是越大越好，因为它会从虚拟机内存里额外划走一块，设置过大反而挤压客户机可用内存。经验值是按虚拟机内存的 1/4 到 1/2 来给，2GB 内存的虚拟机给 512MB 到 1GB 就够，超过这个量对转发路线几乎没有收益。
mks.gl.allowBlacklistedDrivers这一行是给宿主机驱动被 VMware 判定为“不兼容”时用的。它不会提升性能，只是让虚拟机在宿主机驱动版本较新时能正常启用 3D 加速，避免因为驱动黑名单直接退化成软件渲染。用之前先确认宿主机的显卡驱动本身是正常工作的，否则只是把一个明确的问题掩盖成另一个模糊的问题。
提示：判断虚拟机到底有没有真的用上硬件加速，别只看“设置里勾了没”。Windows 客户机里按
Win+R输入dxdiag，看“显示”页里的“呈现”字段，显示Direct3D 11之类的硬件路径才算真正启用；如果是GDI或者软件光栅化，那就是在跑软渲染，性能差一个数量级。
2.3 ESXi 上的 3D 渲染选项与其真实天花板
在 ESXi 环境里，虚拟机设置里有一个“3D 渲染”选项，可以选硬件、软件或自动。选硬件时，ESXi 需要宿主机上安装了对应的图形驱动组件，虚拟机的硬件版本也要够新。这条路线的并发能力比很多人预期的好——十几台轻负载虚拟机同时跑办公套件、浏览器、二维图表，宿主机显卡的占用率可能都不到一半。
但要有清醒认识：这类共享式 3D 加速在较新版本的 ESXi 中已经逐步退出主流支持，官方推荐的方向转到了 vGPU 或者直接放弃 GPU 依赖。它的固有局限在于每台虚拟机可用的显存和渲染上下文数量都有上限，而且不具备 CUDA 能力。任何涉及 GPU 通用计算、编码加速、深度学习推理的需求，这条路线一点忙都帮不上——虚拟机里连nvidia-smi都不会存在，因为根本没有 NVIDIA 驱动栈。
我个人的判断标准很粗暴：如果负载里出现“CUDA”“编码器”“显存占用”这三个词中的任何一个，直接跳过这条路线，别在转发模式上浪费时间调优。它解决的是“图形能不能显示得流畅”，不是“算力能不能用得上”。
3. PCIe 直通：把整块卡“过户”给一台虚拟机
直通是三条路线里性价比最高、也最容易在细节上翻车的一条。它不需要许可证，不需要特殊型号的卡（消费级卡也能上，只是有额外门槛），性能几乎等于裸机。代价是独占，以及一系列围绕 IOMMU 的硬性条件。
3.1 IOMMU 分组：直通成不成立的第一道门槛
IOMMU（Intel 平台上叫 VT-d，AMD 平台上叫 AMD-Vi）是直通的技术基础。它的作用是让 hypervisor 能够把物理设备的 DMA 访问隔离到指定的地址空间里。没有它，设备发起的直接内存访问会绕过虚拟机的边界，把内存改乱，所以 hypervisor 宁愿不让直通，也不会在没有 IOMMU 的情况下放行。
开启顺序有讲究：先进 BIOS/UEFI，找到虚拟化相关的两项——CPU 虚拟化（VT-x / SVM）和 I/O 虚拟化（VT-d / IOMMU）——两个都要开。有些主板把 VT-d 藏在“高级 → 系统代理配置”里，默认关闭；有些主板开了 VT-d 之后还需要把“Above 4G Decoding”一起打开，否则大显存的卡 BAR 空间映射不全。
装好 ESXi 之后验证 IOMMU 是否真的生效：
esxcli hardware pci list | grep -i "Segment: 0000" esxcli hardware pci pcipassthru list第一条能看到完整的 PCI 设备列表说明基础枚举正常。更直接的判断方法是看设备是否支持直通：
esxcli hardware pci pcipassthru list | grep -i true如果显卡出现在不支持列表里，通常有两个原因。一是 IOMMU 没开或者没生效，二是这张卡所在的IOMMU 分组里还有别的关键设备。分组是个绕不开的概念：同一分组内的设备必须一起直通，因为 IOMMU 的隔离粒度就是分组。消费级主板上常见的情况是显卡和某块板载网卡、或者和芯片组的 PCIe 桥分在同一个组里，这时候要么换插槽（不同 CPU 直连的插槽分组往往不同），要么在 BIOS 里开启 ACS（Access Control Services）强制拆分分组。
3.2 从 BIOS 开关到虚拟机加设备的完整操作链
确认设备支持直通之后，剩下的流程其实是机械的，但每一步都有个坑等着。
第一步，在 ESXi 的“管理 → 硬件 → PCI 设备”里找到显卡，点击“切换直通”，状态从“活动”变成“可直通”。注意，如果有多个功能（显卡通常带一个 HDMI 音频 function），要一起切换。
第二步，重启主机。切换直通这个动作在 ESXi 上是需要重启才真正生效的，界面上虽然立刻显示“可直通”，但设备实际还在宿主机驱动手里。这一点很多人会漏，直接去虚拟机加设备，加完开机发现设备不在或者报错。
第三步，编辑虚拟机设置，添加“其他设备 → PCI 设备”，选中刚才的显卡。这里要注意虚拟机的几个硬性限制：
- 虚拟机必须关闭，不能是运行状态
- 虚拟机的内存不能被交换（不能配置内存预留不足，也不能开启内存超额分配）
- 虚拟机不能有快照，也不能在挂载直通设备后创建快照
- 虚拟机硬件版本建议 13 以上
第四步，虚拟机里的驱动安装。这一步的坑最多，尤其是消费级卡。
3.3 配置文件里几个必须手改的参数
图形界面上加完 PCI 设备只是把设备挂上去了，能不能驱动起来还取决于.vmx文件里的几个参数。这些参数在图形界面里看不到，需要关机后通过 SSH 或者数据存储浏览器直接编辑。
hypervisor.cpuid.v0 = "FALSE" pciPassthru0.msiEnabled = "FALSE" pciPassthru.use64bitMMIO = "TRUE" pciPassthru.64bitMMIOSizeGB = "64"hypervisor.cpuid.v0 = "FALSE"是最关键的一行。它的作用是让虚拟机在 CPUID 指令里不再报告“我运行在 hypervisor 之上”。NVIDIA 的部分驱动（尤其是消费级 GeForce 驱动）在检测到虚拟化环境时会主动拒绝初始化，表现就是设备管理器里出现代码 43。把这一行加上，相当于把虚拟机的“隐身衣”穿上，驱动就正常加载了。这是绕开软件限制的常规做法，不涉及任何破解。
pciPassthru0.msiEnabled = "FALSE"关掉 MSI 中断模式。某些主板和显卡组合下，MSI 中断重定向会出问题，表现为虚拟机开机后设备能识别但一用就掉线、或者频繁报错。关掉之后回退到传统 INTx 中断，牺牲一点点中断效率换来稳定。
pciPassthru.use64bitMMIO和64bitMMIOSizeGB这两行是给大显存卡准备的。现代显卡的 BAR 空间动辄 8GB、16GB、24GB，如果不开启 64 位 MMIO 并且给出足够大的空间，虚拟机的地址空间里映射不下整块 BAR，驱动只能看到一部分显存，或者干脆初始化失败。设置的值一般给到显卡显存的 2 倍以上比较稳妥，24GB 的卡给 64 是个常见的经验值。
注意：
64bitMMIOSizeGB的数值不能超过宿主机实际可用的物理地址空间余量，尤其是宿主内存比较小（比如 64GB）又插了大显存卡的时候。设置过大可能让虚拟机直接开不了机。
3.4 代码 43 出现之后的排查顺序
代码 43 是直通场景里出现频率最高的报错，Windows 只给一句“该设备报告了问题，因此 Windows 已将其停止”，信息量为零。我一般按下面这个顺序往下查，基本三四步就能定位。
| 排查顺序 | 检查项 | 判断依据 | 处置 |
|---|---|---|---|
| 1 | hypervisor.cpuid.v0是否设置 | .vmx内容 | 加上并重启虚拟机 |
| 2 | 虚拟机内是否开了 Hyper-V / 内存完整性 | msinfo32看虚拟化相关项 | 全部关闭并重启 |
| 3 | MMIO 空间是否够 | 设备属性里显存显示异常 | 开 64bitMMIO 并加大容量 |
| 4 | 驱动版本是否匹配卡型 | 设备 ID 与驱动支持列表 | 换对应驱动 |
| 5 | 宿主机是否还占着这张卡 | 宿主机设备列表 | 确认直通状态并重启主机 |
第 2 项经常被忽略。Windows 客户机里如果启用了基于虚拟化的安全（VBS）、WSL2、或者沙盒功能，这些会占用嵌套虚拟化能力，NVIDIA 驱动在有这类特征的系统上同样可能拒绝加载。很多人为了跑 Docker 顺手开了 WSL2，然后显卡就用不了了，回头查了半天是这里的问题。判断方法很简单，msinfo32里看“基于虚拟化的安全性”是不是“正在运行”，是的话先关掉再试。
第 5 项也值得单独说。在 Workstation 这类宿主同时也是桌面系统的环境里，宿主机自己是要用显卡的，驱动一直加载着，直通给虚拟机时两边会打架。这种情况下要么接受转发的性能损失走路线一，要么把宿主机切成无头模式（比如 ESXi 或者 Linux 无桌面环境），让显卡彻底空出来。
4. vGPU：把一块物理卡切成多份并发给多台虚拟机
如果需求是“多个人同时用显卡”，直通就无能为力了——一张卡只能给一台虚拟机。这时候要么堆卡，要么上 vGPU。vGPU 的核心价值在于显存切分 + 时间片调度，让一块数据中心卡同时服务多个虚拟桌面或者多个计算任务。
4.1 切片机制与直通的本质区别
vGPU 不是把设备“过户”，而是把设备的资源“配额化”。主机驱动在显卡上创建若干个虚拟 GPU 实例，每个实例分配一段独立的帧缓冲（framebuffer），并注册到 hypervisor 的调度器里。虚拟机启动时，hypervisor 把某个实例挂给它，虚拟机里看到的是一块完整的、有自己显存的 GPU。
调度层面，多个实例共享 GPU 的计算单元，由驱动在时间维度上做分片调度。这意味着单实例的峰值性能会低于整卡直通，但只要切片数量控制得当，整体吞吐反而更高——因为一块卡在大部分时间里其实是闲置的，切分让闲置资源被别人用上了。
这套机制对硬件有明确要求：卡必须在官方支持列表里，通常是数据中心系列（计算卡、虚拟工作站卡）。消费级卡官方不支持 vGPU，即便某些版本能装上主机驱动，也拿不到许可，跑起来会进降级模式。
4.2 版本矩阵与许可：比技术配置更容易翻车的地方
vGPU 项目里出问题，八成不是配置写错，而是版本对不上。这条链上有四个版本必须严格对齐：ESXi 版本、NVIDIA 主机驱动版本、客户机驱动版本、许可证服务器版本。主机驱动和客户机驱动的大版本号必须一致，差一个分支就会出现虚拟机里设备能识别但初始化失败的情况。
安装主机驱动的大致流程：
# 上传 vib 到数据存储后，先看当前状态 esxcli software vib list | grep -i nvidia # 安装主机驱动 esxcli software vib install -d /vmfs/volumes/datastore1/NVIDIA-vGPU-VMware_ESXi_Host_Driver.vib # 重启后确认 nvidia-smi nvidia-smi vgpunvidia-smi vgpu能列出当前创建的 vGPU 实例和占用情况，这个命令在排查“虚拟机到底有没有拿到实例”时非常有用。
许可方面，vGPU 必须在环境里部署一台许可证服务器，虚拟机启动后向它申请授权。授权的类型决定了这个实例能跑什么负载。授权申请失败时，虚拟机通常不会直接黑屏，而是进入受限状态——分辨率被限制、性能被压到很低，或者干脆驱动不加载。这种“能起来但用不了”的状态比报错更难查，因为它没有明确的错误提示。
提示：部署前先把许可服务器跑通，用客户端工具做一次连通性测试，确认能正常取到授权再动虚拟机。反过来操作的话，你会同时面对“驱动装没装对”和“授权通不通”两个变量，排查成本翻倍。
4.3 profile 选择与并发容量的实际估算
vGPU 的切片规格叫 profile，命名里带一个数字和一个字母。Q 系列面向虚拟工作站（有完整的图形加速能力），B 系列面向虚拟应用（偏向编码和基础图形），C 系列面向纯计算（没有图形输出）。选型时先确定负载类型，再看显存。
以一块 48GB 帧缓冲的数据中心卡为例，常见的 Q 系列 profile 大致是 1Q 约 4GB、2Q 约 8GB、3Q 约 12GB、4Q 约 16GB，一路到 12Q 用满 48GB。理论上 1Q 能切 12 份，但实际上不能这么算：
- 每份实例都要占用一部分固定的管理开销，切得越碎，总开销占比越高
- 多个实例抢同一批计算单元，切得太碎会让每个实例的调度等待变长
- 虚拟机的 vCPU 和内存配置必须跟 profile 匹配，1Q 配 8 个 vCPU 是浪费，4Q 只给 2 个 vCPU 又跑不动
我的经验算法是：先按显存算理论份数，再打七折作为实际可用并发，然后用一台虚拟机做基准测试，看单实例在你这个负载下的帧率或吞吐，如果单实例性能已经接近下限，就该往上提一档 profile。
5. 三条路线的实测差异与选型判断
纸面参数看完，真正决定选型的是实际跑起来的手感。下面是我在不同场景里反复比对后总结的判断依据，不追求绝对数值的精确，重点在相对关系。
5.1 图形工作站类负载怎么选
三维建模、渲染、工程仿真这类负载的共同特征是：显存占用大、对帧率敏感、对延迟敏感。这类场景里，直通的表现最接近裸机，转发路线的表现最差，vGPU 介于两者之间且取决于切片大小。
| 负载类型 | 转发路线 | 直通 | vGPU（中等切片） |
|---|---|---|---|
| 办公 / 二维图表 | 完全够用 | 大材小用 | 成本过高 |
| 轻量三维查看 | 可用，大模型掉帧 | 流畅 | 流畅 |
| 复杂装配体交互 | 明显卡顿 | 接近裸机 | 略有延迟 |
| 离线渲染 | 不可用 | 接近裸机 | 可用，需排队调度 |
| 多人共享设计 | 体验差 | 无法并发 | 最合适 |
一个常被忽略的判断维度是交互式还是批处理。交互式的场景（人在操作，等不了）对延迟敏感，直通或者较大的 vGPU 切片更合适；批处理的场景（提交任务后等结果）对延迟不敏感，可以用小切片多并发，把整体吞吐拉满。
5.2 计算类负载的现实约束
计算类负载（训练、推理、科学计算）在三条路线上的表现差异更极端。转发路线直接出局，因为虚拟机里根本没有 CUDA 运行时。直通能拿到接近裸机的算力，但一张卡只能给一个人用，做实验环境时资源利用率很低。vGPU 的 C 系列 profile 就是为这个场景准备的，可以让多个任务分时共享一块卡。
但计算类负载用 vGPU 有个隐性成本：显存是按 profile 硬切的，切小了模型就装不下。一个需要 20GB 显存的任务，在 16GB 的切片上跑不起来，你只能选更大的 profile，并发数立刻掉下来。所以做容量规划时，先算清楚单个任务的最大显存需求，再决定切片粒度，别一上来就按最小切片算并发数，算出来的数字很好看但跑不了真实任务。
6. 几个反复踩到的坑和对应处置
这一节写的是文档里基本不会提、但实际动手时大概率会遇到的问题。都是我在不同环境里重复踩过的，列出来省点时间。
6.1 直通之后宿主机丢失设备引发的连带故障
直通完成、虚拟机正常跑起来之后，宿主机侧会出现一系列看似无关的症状：某个管理网口不通了、风扇转速突然拉满、IPMI 界面卡住。原因通常是显卡和这些设备分在同一个 IOMMU 分组里，直通时被一起摘走了。
处置办法有两个方向。一是换插槽，把显卡插到 CPU 直连的插槽（通常是第一条 x16），这类插槽的分组往往更干净；二是在 BIOS 里找 ACS 相关选项，开启后可以强制把分组拆细。如果两个都不行，最后一招是在 hypervisor 层面把整组设备一起直通给一台“管理虚拟机”，用软件方式接管，但这属于比较重的方案，不到万不得已不建议。
6.2 快照和迁移在直通虚拟机上的隐性失败
直通设备挂载之后，虚拟机的快照功能不可用。有些版本会在界面上直接禁用按钮，有些版本允许你点，但创建到一半失败，留下一个残缺的快照文件，后续清理起来很麻烦。
更隐蔽的是迁移。直通虚拟机做冷迁移（关机后迁移）通常是允许的，但热迁移不行。有些自动化运维流程里默认会尝试热迁移，失败之后触发重试，反复几次把任务队列堵死。如果你的环境里有这类自动化，记得在直通虚拟机上把迁移策略显式关掉，别指望调度器自己识别。
vGPU 虚拟机的迁移是有条件支持的，需要主机驱动和 hypervisor 版本都支持对应特性，并且虚拟机配置里要打开相应开关。做迁移演练前一定要先确认版本组合在支持矩阵里，不然演练当天才发现不支持，回滚都来不及。
6.3 多虚拟机抢显存时的现象与判断
vGPU 环境下，如果切片分配不合理，会出现一种很奇怪的现象：单台虚拟机测试时一切正常，一旦并发上来，所有虚拟机同时变慢，但nvidia-smi里看每台的显存占用都不高。
这不是显存不够，是计算单元在抢。切片的显存是独立的，但计算单元是共享的，实例越多，每个实例分到的时间片越短，上下文切换开销占比越高。判断方法是看主机侧的 GPU 利用率，如果接近 100% 且每台虚拟机的实际吞吐都只有单机测试时的一半以下，那就是切太碎了，往上调 profile 档位减少并发数，总吞吐反而会上升。
我个人的习惯是留出至少 20% 的算力余量不做分配。看起来是浪费，但在有突发负载的时候，这点余量能避免整个池子一起卡死，运维体验差别很大。
