Yifu's Blog

分类： 未分类

  • AI最前沿

    “AI最前沿”是一个快速演进的概念。综合近期的权威报告和趋势判断，当前AI的前沿已超越单纯追求大模型参数量，正快速向“理解物理世界”、“赋能科学发现”及“颠覆底层效率”三个核心方向跨越。

  • Hi，我是第一次写博客，请多多关照！

    1. 摘要

         随着人工智能、高性能计算（HPC）、深度学习等算力密集型业务的爆发式增长，GPU（图形处理器）已成为支撑各类核心任务的算力核心，其凭借海量并行计算单元的架构优势，高效承载模型训练、推理部署、科学计算等场景的海量矩阵运算需求。然而，当前GPU集群在实际部署与运营中，普遍面临着算力资源利用率偏低的核心痛点——高端GPU（如H100、A100）硬件采购与运维成本高昂，但单一任务往往仅能占用部分GPU算力，导致大量算力资源长期处于闲置或低负载状态，形成“高成本投入、低算力产出”的资源浪费困境。与此同时，云计算、本地分布式部署等主流场景，对算力资源的虚拟化、共享化、精细化管理需求日益迫切：一方面，多用户、多任务并行的业务模式，需要打破GPU物理硬件的独占性，实现资源的高效复用；另一方面，企业亟需通过虚拟化技术降低算力投入成本，提升集群的统一管理、动态调度与弹性扩展能力。

    2. 研究背景和挑战

        在此背景下，GPU虚拟化技术作为破解算力闲置、实现资源高效利用、适配分布式与云计算场景的核心路径，其研究具有重要的现实意义和产业价值。

        尽管GPU虚拟化的应用需求迫切，但在技术落地过程中，仍面临诸多核心挑战，制约着其性能发挥与规模化应用，主要集中在以下四个方面：

    一是性能损耗控制难题

    GPU的核心优势在于并行计算效率，而虚拟化层的引入会增加指令转发、资源调度的额外开销，尤其是在算力密集型任务（如深度学习训练、大规模矩阵运算）中，虚拟化带来的延迟与性能损耗可能显著降低任务执行效率，如何在实现虚拟化的同时，最大限度保留GPU原生算力性能，是核心技术难点之一。

    二是资源隔离与调度精度不足

    GPU虚拟化需实现多任务、多用户对GPU资源的共享，但若资源隔离机制不完善，易出现任务间的算力抢占、数据干扰等问题，导致任务执行稳定性下降；同时，如何根据不同任务的算力需求，动态分配GPU计算单元、显存等资源，实现“按需分配、精准调度”，平衡资源利用率与任务执行效果，仍需进一步突破。

    三是显存资源的虚拟化瓶颈

    GPU显存是支撑大模型训练、高分辨率图形处理等任务的关键资源，但其容量有限且无法像CPU内存那样灵活扩展；在虚拟化场景下，多任务共享显存易出现显存溢出、分配不均等问题，如何通过虚拟化技术（如显存分片、动态复用），提升显存利用率，避免显存资源成为性能瓶颈，是重要挑战。

    四是兼容性与生态适配问题

    不同厂商的GPU硬件（如NVIDIA、AMD）架构差异较大，对应的驱动程序、算力调度接口互不兼容；同时，各类上层应用（如深度学习框架、HPC软件）对GPU的调用方式不同，如何实现GPU虚拟化技术与不同硬件、不同应用场景的无缝适配，降低用户迁移成本，推动虚拟化方案的规模化落地，也是当前研究需解决的重要问题。

    3. GPU虚拟化的方案分类

    GPU虚拟化可按三种方式分类，每种分类方式可以相互正交

    • 按控制面形态分类
    • 按底层共享机制分类
    • 按实现位置分类
    图片

    控制面形态是GPU“对外长什么样”，决定可运营能力与对外交付形态

    共享方式是GPU“能不能并发、怎么切”，通常是性能/QoS 讨论里的第一关键因素

    实现位置是虚拟化“在哪一层拦截/仲裁”, 决定工程可落地性与长期维护成本

    所以做 GPU 虚拟化，通常

    1. 先确定业务, “把 GPU 以什么形态交付给用户”，

    2. 再决定技术，“一块 GPU 怎么被多人/多任务共享”，

    3. 最后选择工程，“在哪一层实现，去做隔离、限流、计量和调度”。

    3.1

    按控制面形态分类

    图片

    1. 直通（Passthrough）：独占上车，一人一卡

    原理：把整张物理 GPU（或一个硬件实例）直接分配给一个隔离域（裸金属/VM/OS 域）。常见实现是 VFIO + IOMMU 设备直通，Guest 基本以“接近原生”的方式访问 GPU。

    形象比喻：把整套健身器材搬进一个人的家里，别人用不了。

    特点：隔离最强、性能最接近裸金属，但天然不共享。利用率主要靠上层队列、调度与弹性伸缩来“拼”。

    2. 硬件分区（Hardware Partition / MIG）：硬切成房，互不串门

    原理：由 GPU 硬件/驱动直接提供可独立分配的“分区/实例”（典型是 MIG）。实例作为最小交付单元，可分配给 VM 或容器。

    形象比喻：一套大房子隔成多套独立公寓，门禁、水电都分开。

    特点：隔离语义更硬，QoS 更稳定可预期；但切分规格离散、形态相对固定，编排更容易出现碎片与重配成本。（注：SR-IOV 的隔离语义强度取决于具体硬件与驱动实现。）

    3. 中介设备（vGPU / mdev）：表面一人一车，方向盘由司机统一管

    原理：对 VM/容器暴露一块“看起来像 PCIe GPU 的虚拟设备”（寄存器/MMIO/BAR 接口都做出来），但命令提交、上下文、队列与调度由 Host/Hypervisor 统一仲裁。常见实现是 QEMU 设备模型 + mdev 或厂商 vGPU 栈。

    形象比喻：每个人都有一把车钥匙，但车库管理员决定谁什么时候出车、跑多久。

    特点：这是控制面/交付形态，本身不等于某一种底层共享机制。它可以绑定时间复用（更灵活但更吃调度），也可以绑定 MIG（MIG-backed vGPU，隔离与 QoS 往往更稳）。最终性能与隔离强度取决于底层机制与实现细节。

    4. 拉远虚拟化（Remote / Disaggregation）：本地没车，也能远程打车

    原理：GPU 不在本机，本地通过 RPC/代理把 CUDA 等 API 调用或作业请求转发到远端 GPU 服务执行。典型范式是 API remoting（库级拦截 + 转发），也可以进一步做成训练/推理服务接口。

    形象比喻：不买车，直接叫网约车，买的是“出行服务”而不是车本身。

    特点：算力可池化、接入统一、跨机调度更自然；但更依赖网络时延/带宽，且服务端需要配套隔离、限流、公平、计量与可观测，才能真正可运营。

    3.2

    按底层共享机制分类

    图片

    1. Time-Slicing：轮流上车，按时间分

    原理：同一张 GPU 在时间维度轮转给多个进程/任务使用。对外可以“伪装成多张逻辑卡”（replicas），但底层仍是同一块物理 GPU。

    形象比喻：一台跑步机，大家按分钟轮换。

    特点：部署简单、通用性强；但隔离弱（进程/显存不隔离），上下文切换会带来固定开销与抖动，在线推理类场景要谨慎。

    2. MIG（Multi-Instance GPU）：硬件切分，划清界限

    原理：GPU 在硬件层把资源切成多个实例（compute/memory/cache/带宽等按 profile 划分），实例之间有明确的隔离语义。

    形象比喻：大商场分成多个独立店铺，各自用各自的水电。

    特点：隔离强、QoS 更稳、干扰更可控；但切分规格离散，存在碎片与重配成本，是否支持取决于 GPU 代际与型号。

    3. MPS（Multi-Process Service）：并发上车，提升吞吐

    原理：多个 CUDA 进程通过 MPS server 共享执行资源，让小 kernel 更容易并发填满 SM，减少部分上下文切换开销。

    形象比喻：多车道高速，不同公司的车可以并排跑。

    特点：适合多小任务并发、提升吞吐；但隔离不是强项（带宽/L2/显存路径等仍共享），容易受 noisy neighbor 影响，通常需要额外的配额与治理手段。

    3.3

    按实现位置分类

    图片

    1. 内核态（Kernel / Driver-side）：驱动口拦截，内核仲裁

    原理：在驱动入口（设备文件/ioctl 路径）把请求先拦下来，由内核侧做排队、限流、隔离等仲裁，再交给原厂驱动执行。

    形象比喻：高速入口的闸口，先验票、再放行。

    特点：离硬件近，控制力强；但实现/维护成本高，升级适配压力大。

    2. 用户态（Library-level）：库层拦截，代理转发

    原理：在 CUDA/OpenCL API 层做 wrapper/hook，把调用“接走”，交给用户态代理调度后执行（本机或远端）。

    形象比喻：前台接单，跑腿转单。

    特点：部署灵活、易跨环境；但兼容性难（API 覆盖与版本适配成本高）。

    3. 设备侧（On-device）：逻辑下沉，卡上细分

    原理：把部分调度逻辑下沉到 GPU 上常驻运行，在设备端把工作切细、排队并分配份额。

    形象比喻：车上常驻乘务员，车不停也能分座。

    特点：理论上粒度更细、抖动更好控；但研发门槛极高，可观测与排障困难。

    4. 框架层（Framework-level）：看懂阶段，按负载调度

    原理：在 PyTorch/TensorFlow 等框架或适配层拦住执行计划，利用训练阶段/算子图/显存曲线等信息做共享与调度。

    形象比喻：导演按剧本排场次，资源用在刀刃上。

    特点：对 AI 负载更贴合；但通用性弱，依赖框架生态，对非框架程序覆盖有限。

    4. 总结

        本文系统介绍了GPU虚拟化技术产生的背景、面临的主要挑战，以及典型的技术方案。从控制面形态、底层共享机制、实现位置这三个正交维度，宏观地阐述了GPU虚拟化的技术方案划分，下期文章我们将从性能角度对比当前主流的GPU虚拟化方案。

    参考文献

    1. A comprehensive review of GPU virtualization and sharing methods[EB/OL]. HAL (Petr Mandrik, Huawei Technologies), 2025.

    2. GPU Virtualization and Scheduling Methods: A Comprehensive Survey[J]. ACM Computing Surveys, 2017.