在 Kubernetes 生态中，GPU 共享调度已趋于成熟——时间片轮转、显存隔离、按 Pod 粒度分配，各家方案百花齐放。
但在虚拟机场景下，GPU 切分的选择一直受限：NVIDIA vGPU 需要额外授权费用，MIG 仅支持少数高端型号且切分规格固定——大量企业私有云的 GPU 虚拟机，实际仍停留在整卡直通的粗放模式。
一张 80GB 显存的 A100，分配给一个 7B 模型调试任务，实际显存占用不到 20%，剩余算力完全闲置。高授权门槛与有限的硬件覆盖，让 IaaS 层的 GPU 利用率长期停留在较低水位。
ZStack dGPU（dynamic GPU）提供了一条新的工程路径：无需 NVIDIA vGPU 授权、不受 MIG 硬件型号限制，以纯软件方式实现虚拟机级别的 GPU 显存与算力动态切分。
为什么虚拟机需要 GPU 切分能力
容器以其轻量调度和高密度部署的优势，成为 AI 训练与批量推理的主流载体。但在企业私有云实践中，存在三类GPU 工作负载，其运行时特征决定了虚拟机仍然是更合理的交付形态。
算法开发与模型复现环境。 AI 项目对 Python、PyTorch、CUDA Runtime、cuDNN 的版本组合有严格要求，开发者需要长期维护 Conda 环境、模型权重缓存、代码仓库及 SSH/Jupyter/IDE 入口。容器虽可封装用户态依赖，但 GPU Driver 与容器 Runtime 仍依赖宿主机统一配置，针对单项目做差异化适配将显著增加运维复杂度。
Windows 及桌面图形工具链。 以 Stable Diffusion 生态为例，大量整合包、数据标注工具和批处理流水线围绕 Windows 构建。带 GPU 的 Windows 云主机，是面向设计师和非技术人员最自然的交付方式。
Windows 虚拟机将在2026年5月支持。*
多租户强隔离需求。 容器共享宿主机内核，租户间的隔离依赖 cgroup 和 namespace 等软边界。虚拟机则具备独立内核、独立网络栈和独立存储视图，隔离粒度在操作系统级别。对于跨部门、跨项目甚至跨租户共享 GPU 资源池的场景，VM 提供的硬隔离边界能更好地满足安全合规与责任划分要求。
在上述场景中，小模型调试、低并发推理验证、Embedding/Rerank 服务等轻量级 GPU 负载，长期因缺乏 VM 侧切分能力而被迫整卡独占。
dGPU 的技术定位，是将 GPU 细粒度切分能力从容器层下沉至 IaaS 层，补齐虚拟机场景的关键缺失。
核心机制：动态分配，生命周期级回收
dGPU 的核心设计原则是资源动态化——GPU 显存不做静态预切分，而是跟随虚拟机生命周期按需分配、即时回收：
管理员基于物理 GPU 型号定义显存规格模板，覆盖典型负载档位（7B 开发调试 / 14B 推理服务 / 32B 低并发验证 / Embedding 服务等）。模板可根据模型精度、上下文长度、并发规模和 KV Cache 策略灵活调整，相比固定等分物理 GPU，更贴近真实工作负载的资源需求曲线。
运行时行为：
-
云主机启动 → 平台从 GPU 资源池中动态分配指定显存规格的 dGPU 实例
-
云主机停机 / 卸载 → 显存资源即时释放，回归资源池可供其他 VM 申请
-
全程无需预切分 → 管理员不必提前将物理卡固定划分为 2/4/8 等份
这一机制将 GPU 从静态硬件资源转变为弹性云资源——可申请、可回收、可度量、可运营。
架构设计：VM 边界内的 CUDA 调用链透传
dGPU 的核心技术挑战在于：在不修改用户应用代码的前提下，实现跨 VM 边界的 CUDA 调用链透传与显存隔离。
架构分为三层：
-
VM 内 dGPU Client：接管云主机内所有 CUDA API 调用，对上层应用完全透明
-
高性能共享内存通道：VM 与宿主机之间的低延迟数据通路，承载 CUDA 调用与数据传输
-
宿主机 dGPU Worker：接收并执行 CUDA 调用，完成显存隔离、算力调度、实例生命周期管理
同一张物理 GPU 可同时承载多个 dGPU 实例，由平台统一完成调度、隔离与回收。用户无需感知底层切分拓扑，也无需手动维护实例映射关系。
对 VM 内的 AI 应用而言，使用体验与 GPU 直通完全一致——标准 CUDA 工具链、PyTorch、vLLM 等框架均可直接运行，零代码改造。
性能验证：可量化开销，长时间零故障运行
软件层 GPU 虚拟化最核心的工程指标是性能开销与长期稳定性。以下数据基于 vLLM 推理场景实测：
性能开销
dGPU 相比 GPU 直通的综合性能损耗约为 7% ，涵盖单流 decode 延迟、Token 间延迟（ITL）、峰值吞吐量及持续压力吞吐量等关键指标，各维度波动均在可控范围内。
长期稳定性
在并发 16 的持续压力下，dGPU 连续运行 23.5 小时，累计完成 134,074 次推理请求，失败数 0，性能漂移低于 0.5% 。
这组数据验证了 dGPU 在 AI 推理负载下的工程可靠性。对于开发测试、多租户资源复用和中小规模推理服务而言，稳定性、可观测性与资源周转效率，优先级高于单点峰值性能。
平台级集成：从底层能力到可运营的算力资源
GPU 切分能力若脱离平台治理体系，难以在生产环境中规模化运营。ZStack 将 dGPU 作为一等资源纳入云平台统一管理：
-
资源管理：dGPU 模式启用/关闭，显存规格模板配置
-
业务接入：云主机、AI 推理服务、精调工作台均可加载 dGPU
-
配额管控：按部门/项目维度限制 dGPU 显存配额
-
运维监控：实时查看 GPU 利用率、显存使用率、实例运行状态
-
告警联动：dGPU 健康状态变化自动触发告警
至此，GPU 完成了从"挂在宿主机上的硬件设备"到"纳入项目、配额、监控、告警体系的云化算力资源"的跃迁。
适用场景与技术边界
推荐场景： 算法开发机、小模型推理服务、低并发验证环境、Embedding/Rerank 在线服务、教学实验平台、多项目 GPU 资源池共享。
核心价值： 以可量化的虚拟化开销（~7%），换取更高的 GPU 利用率、更灵活的 VM 级算力调度，且无需单独采购 NVIDIA vGPU 授权。
明确边界： dGPU 面向 CUDA AI 计算场景设计，不适用于 OpenGL/Vulkan 图形渲染。对于极致性能、硬件级强隔离或图形桌面类需求，建议选择 GPU 直通或 NVIDIA vGPU 方案。
结语
虚拟机场景下的 GPU 切分一直缺少一个低门槛的选项。直通不能切，vGPU 要授权，MIG 挑型号——大部分私有云客户最后还是整卡分配，然后看着监控里的显存利用率发愁。
dGPU 是我们给出的方案：纯软件实现，不依赖额外授权，覆盖主流 NVIDIA GPU 型号。vLLM 推理场景下 23 小时的长跑测试验证了基本面，但我们也清楚，真正的考验在客户的生产环境里。后续会持续扩展 GPU 型号覆盖和负载场景的适配。
