想象你开了一家“大模型私房菜馆”，厨房里只有一口昂贵的黄金灶（GPU）。每位客人都点不同的菜谱（AI 模型），每个菜谱都要求独占整口灶来做菜。结果一道小炒只用了灶台十分之一的火力，其余时间大火空烧，煤气费却一点不少。这正是很多 AI 团队的真实写照：模型推理请求很短，但每张 GPU 卡都被单个模型独占，算力利用率低得可怜。 GPU 池化与共享技术，就是把这口黄金灶变成后厨共享系统。要么按时间表让不同菜谱轮流上灶——这是“时间分片”；要么用隔板把灶切成几个小灶眼同时炒菜——这是“空间分区”。再配合隔离机制防止串味、混部策略避免抢火、监控看板盯住出菜节奏，最终让每一口 GPU 灶都不空转。本文用“共享厨房”的故事，拆解这套推理服务架构的关键设计。
对 AI 从业者而言，掌握 GPU 池化与共享技术，意味着能在大模型推理成本高企的今天，用更少的卡支撑更多的业务，是 AI 平台工程师和推理架构师的核心竞争力之一。
可视化演示
三步展示GPU池化与共享技术：时间分片/MIG/vGPU/空间分区四种方案、CUDA Context/显存/SM底层原理、以及多模型混部部署提升GPU利用率。
本节配有交互动效（进入视口后自动加载，约 3KB）。
GPU共享方案 时间分片：轮流占用GPU MIG: 硬件级强隔离 vGPU: 虚拟化细分 虚拟化逻辑单元 提升推理资源利用率。
背景与动机
老胡的后厨有一口进口“黄金灶”，平时只炒一道“小炒黄牛肉”。这道菜从备料到出锅只用两分钟，但灶台预热、等待翻锅的时间却占了一大半。老板发现，厨师基本在闲着，灶火在空烧——这正是很多 AI 团队面对 GPU 的真实写照：模型推理请求很短，但每个模型都独占整卡，GPU 算力大量闲置。
推理不像训练。训练像一次马拉松，可以把 GPU 跑得满满当当；推理像外卖订单，一会儿来一单，每单只有几毫秒到几十毫秒。如果为每个模型单独分配一张物理 GPU，多数时间这张卡都处于“等单”状态。GPU 利用率低带来两个直接后果：硬件成本居高不下，资源碎片化严重。小模型占着大卡，大模型又排不进去，算力被切得七零八落。
池化技术就是把这口大灶交还给“后厨总管”统一管理。总管把多张物理 GPU 纳入同一个资源池，再按模型请求切成逻辑资源：一个模型需要多少算力就分多少。硬件层面由驱动或虚拟化层完成逻辑隔离，软件层由调度器决定谁在什么时候用。这里的核心指标就是 GPU 利用率。
因此，池化不是换一口更大的灶，而是让每一口灶尽量不空烧。理解了这一点，再看时间分片和空间分区，就会明白它们是两种不同的“开火策略”。
- GPU 忙碌时间 $T_{\text{busy}}$真正执行矩阵乘、卷积等运算占用的时间。
- GPU 空闲时间 $T_{\text{idle}}$等待下一条请求、等待数据加载的时间。
- 利用率 $U$忙碌时间占总时间的比例，越接近 1 说明灶台越充实。
池化核心原理
老胡决定不再让每道菜独占一口灶，而是把所有灶台交给一位“后厨总管”。总管手里有一张总表：左边是十口灶的实时状态，右边是所有客人的点单。哪道菜要用多大的火、多长时间，总管按需分配——这就是资源池的雏形。
在 AI 推理服务中，池化通常由驱动层或虚拟化层完成。物理 GPU 被虚拟成多个逻辑设备，每个逻辑设备有独立的显存视图、算力配额和句柄。容器或进程看到的是一张“虚拟 GPU”（vGPU），而不是物理卡。调度分配器则负责把推理请求派发到合适的逻辑实例上，避免某张卡忙死、另一张卡闲死。
这个过程中最关键的原则是：逻辑实例可以有多份，但所有实例的容量之和不能超过物理 GPU 的总容量。
老胡的厨房里，十口灶变成一张“总表”。每位厨师不再盯着固定灶台，而是按订单领取临时灶台。这个“总表”就是资源池，也是后面所有调度、隔离和监控的基础。
- 物理 GPU 容量 $V$一张物理卡拥有的总算力和显存上限。
- 逻辑 GPU 实例 $v_i$从物理卡中切出的第 $i$ 个虚拟设备。
- 并集关系 $\bigcup$物理设备被拆成多个逻辑设备，它们共同对外提供算力。
- 容量约束 $\sum$所有逻辑实例容量之和必须小于等于物理容量，这是池化必须遵守的边界。
时间分片方案
老胡没有真的把黄金灶切开，而是给每道菜排了一张“上灶时间表”：剁椒鱼头炖五分钟，小炒肉炒两分钟，番茄蛋汤煮三分钟。灶台在同一段时间只服务一道菜，但通过快速轮换，所有菜看起来都在被照顾。这正是时间分片。
在技术实现上，GPU 的驱动调度器把计算单元的使用权按时间片切分。多个模型轮流获得执行机会，每个模型的显存上下文仍然保留在卡上，所以显存是“独占”的，但计算任务需要排队。时间分片允许一定程度的超卖：多个模型可以登记同一份算力份额，因为大多数推理请求不会持续占满计算单元。
每个模型分到的时间片长度，由共享的模型数量决定：
时间分片适合小模型、短请求和能容忍排队的场景。老胡的经验是：菜越简单，翻台越快；一旦来了一道要炖两小时的硬菜，后面所有菜都会遭殃。
- 调度周期 $T_{\text{cycle}}$一轮时间片轮转的总时长，通常由调度器配置。
- 共享模型数 $m$同一张 GPU 上参与时间分片的模型数量。
- 每个模型的时间片 $t_i$每个模型在一轮周期中分到的执行时间，模型越多，等待越久。
空间分区方案
老胡买了四块隔板，把黄金灶台切成四个小灶眼。每口小灶眼有自己的炉芯、锅架和排烟管，几位厨师可以同时炒菜，谁也不碰谁的火。这就是空间分区：从物理上把 GPU 的显存、计算单元和带宽切成多个独立区域。
空间分区的典型实现包括 NVIDIA MIG（Multi-Instance GPU）和 vGPU 方案。MIG 可以把一张物理 GPU 划分为多个显存和算力都隔离的实例，每个实例拥有自己的计算核心和显存带宽，互不抢占。每个实例获得的总算力比例由配额系数决定。
空间分区就像把大锅固定成几个小锅，几道菜可以同时开火、互不串味。但如果来了一条几十斤的大鱼，固定小锅可能装不下。所以在选型时，必须看模型是否适合某个分区规格。
- 物理总算力 $C_{\text{total}}$整张 GPU 的计算能力。
- 配额系数 $\alpha_i$第 $i$ 个实例占物理总算力的比例，取值范围通常在 0 到 1 之间。
- 实例算力 $C_i$第 $i$ 个分区实际获得的算力。
- 配额上界 $\sum \alpha_i \le 1$所有分区分配出去的算力不能超过物理上限。
隔离机制设计
厨房里最怕串味：宫保鸡丁的辣椒味窜进清蒸鲈鱼的蒸笼里。老胡给每个小灶眼配了独立锅盖、独立调料盒，还规定每口灶只能从自己的食材柜里取料。对应到 GPU 隔离机制，就是显存隔离、算力隔离和故障隔离。
显存隔离确保每个逻辑实例只能使用自己的显存配额，超限时触发 OOM，而不是抢占其他实例。算力隔离通过 MIG 或配额调度限制每个实例对计算单元和显存带宽的占用。故障隔离则保证某个实例崩溃时，不会拖垮整张卡或同卡上的其他租户。安全边界进一步防止不同租户读取彼此的显存数据。
这里的隔离可以用一个简单的不等式表达：每个实例的显存使用量不能超过平均配额。
隔离不是把厨师关进小黑屋，而是给每个人一张限额取料卡：谁也不能拿出超过配额的材料，出了事故也只是自己那口锅遭殃。有了这层保障，多租户混部才敢真正上线。
- 实例显存用量 $M_i$第 $i$ 个虚拟 GPU 当前实际占用的显存。
- 物理总显存 $M_{\text{GPU}}$整张 GPU 的显存容量。
- 平均配额 $\frac{M_{\text{GPU}}}{n}$在 $n$ 个实例平均分配时，每个实例最多可用的显存。
多模型混部
老胡开始尝试“川粤同灶”，几个模型共享一张卡。结果宫保鸡丁和清蒸鲈鱼同时开火，整间厨房都是辣椒味，粤菜师傅连连咳嗽，出菜速度慢了一半。这就是多模型混部中的性能干扰。
混部调度器会按模型特征做组合：延迟敏感的模型搭配离线批处理模型，计算密集的模型搭配访存密集的模型。亲和性策略则把互相干扰的小模型放在同一张卡上，把大模型和强隔离需求高的模型放到独立分区。QoS 保障是硬约束：无论怎么混部，线上请求的延迟目标不能突破。
在评估混部效果时，通常会计算干扰因子，也就是混部后的延迟与独占时延迟的比值：
混部不是把模型丢进一口锅就完事，而是要像配菜一样讲究“荤素搭配”。搭配得当，所有灶都能热起来；搭配不当，再好的食材也会糊成一锅。
- 独占延迟 $L_{\text{solo}}$模型独占整张 GPU 时的 P99 延迟。
- 混部延迟 $L_{\text{mixed}}$模型与其它模型共享 GPU 后的 P99 延迟。
- 干扰因子 $f$混部延迟除以独占延迟，用来量化性能被干扰的程度。
性能调优监控
老胡在后厨挂了一块看板：每口灶的温度、排队人数、出菜时长一目了然。哪口灶要空烧了，总管就多派单过去；哪口灶排队太长，总管就少接单。对于 GPU 推理服务，这块看板就是监控系统。
性能调优时，不能只看 GPU 利用率。利用率高可能是好事，也可能意味着请求正在排队，延迟早就超标。所以需要联合观察三个维度：GPU 利用率、请求延迟、排队等待长度。调优参数包括时间片大小、空间分区规格、最大并发数和 batch 大小。容量规划则根据监控趋势决定什么时候加卡、什么时候缩容。
平均利用率是容量规划中最常用的指标，它表示一段时间内 GPU 忙闲的平均水平：
看板不是用来炫耀的，而是用来发现“灶太忙、菜出不来”的问题。理想状态不是利用率 100%，而是稳定在目标区间，同时 P99 延迟不突破 SLO。这样才算是把 GPU 池化真正用好了。
- 瞬时利用率 $u(t)$在时刻 $t$ 采样到的 GPU 利用率。
- 监控周期 $T$统计利用率的时间长度，比如 5 分钟、1 小时。
- 平均利用率 $U_{\text{avg}}$周期内利用率的时间平均，也是容量规划和告警阈值的基准。
AI 应用场景
云上大模型推理平台
阶段：推理服务资源池化
解决的问题：多个业务部门各自申请 GPU 整卡，模型流量不大却占满整卡，导致利用率低、成本高。AI 平台通过 GPU 池化把轻量模型组合共享在同一张卡上，再按模型需求分配逻辑实例。
具体案例：某 SaaS 公司有 20 个轻量模型，原来每天占用 20 张卡；池化后按时间分片加空间分区组合部署到 5 张卡，P99 延迟从 300ms 变为 350ms，仍在 SLO 内，GPU 平均利用率从 18% 提升到 64%。
金融风控实时推理
阶段：租户隔离与安全合规
解决的问题：不同风控模型分属不同业务部门，不能互相读取参数或显存数据，传统时间分片很难满足强隔离要求。空间分区加显存配额可以给出硬边界。
具体案例：银行将反欺诈和信用评分两个模型部署在一台 A100 的 MIG 分区上，两个实例的显存和算力配额相互独立，任何一侧 OOM 都不会影响另一侧，季度安全审计顺利通过。
多模型混部容量规划
阶段：容量规划与性能调优
解决的问题：新增模型后不确定能否与现有模型共用 GPU，需要先用监控和压测验证干扰因子，再决定是否混部。
具体案例：推理团队用线上流量回放，对比混部前后的 P99 延迟和 GPU 利用率，发现实时翻译与离线图像分类混部后干扰因子约为 1.1，于是把它们固定在同一亲和性节点上长期运行。
Python 演示
# -*- coding: utf-8 -*-from dataclasses import dataclass @dataclassclass Request: model: str size: int duration: int class VirtualGPU: def __init__(self, gpu_id, capacity, mode): self.gpu_id = gpu_id self.capacity = capacity self.mode = mode self.dispatched_count = 0 def submit(self, req): if req.size > self.capacity: return False self.dispatched_count += 1 return True class GpuPool: def __init__(self): self.vgpus = [] def add_vgpu(self, vgpu): self.vgpus.append(vgpu) def schedule(self, req, mode): for vgpu in self.vgpus: if vgpu.mode == mode and vgpu.submit(req): return vgpu.gpu_id return None def simulate(mode, requests): pool = GpuPool() pool.add_vgpu(VirtualGPU("gpu-time-1", 4, "time")) pool.add_vgpu(VirtualGPU("gpu-space-1", 4, "space")) mappings = [pool.schedule(req, mode) for req in requests] print(mode, mappings) if __name__ == "__main__": reqs = [ Request("chat", 1, 10), Request("vision", 3, 5), Request("nlp", 2, 8), ] simulate("time", reqs) simulate("space", reqs)
class VirtualGPU:定义虚拟 GPU 实例，保存自己的调度模式和容量上限。if req.size > self.capacity:容量不足时直接拒绝，避免挤占其它实例的资源。if vgpu.mode == mode and vgpu.submit(req):同时匹配调度模式和容量条件，决定是否派发。mappings = [pool.schedule(req, mode) for req in requests]对每个请求调用调度器，形成派发名单。if __name__ == "__main__":让代码既可被导入也能直接运行。
常见误区
误区我一开始以为 GPU 池化后，一张卡能当很多张卡用，显存和算力都会翻倍，模型想放多少个就放多少个。
正解池化只是让一张物理 GPU 被多个模型共享，总算力和显存仍然受物理上限约束。时间分片可以超卖时间片，但计算总量没有增加；空间分区更是把总量拆成了几份。就像一口大灶切成四口小灶，总火力不会变多。
为何常见：“虚拟化”和“资源池”这些词容易让人产生无限资源的错觉，尤其超卖概念更强化了这种误解。
误区时间分片不需要切显存、不需要改硬件划分，只是排队执行，应该比空间分区更轻松，也不会带来性能损失。
正解时间分片会引入调度切换开销和排队延迟，多个模型共享计算单元时，P99 延迟会明显上升。空间分区虽然能并发执行，但受固定分区规格限制。两种方案都有代价，没有所谓的“无损共享”。
为何常见：因为时间分片在配置上看起来只是加一个参数，容易被当成零成本方案。
误区只要把多个模型部署在同一张 GPU 上，GPU 就不会闲着，吞吐量一定比单独部署高。
正解混部确实能提高资源利用率，但如果模型之间互相争抢算力，延迟可能大幅劣化，最终为了满足 SLO 反而要降低并发。必须结合干扰因子和延迟指标来判断混部是否划算。
为何常见：大家看到的是“卡被用起来了”，却忽略了服务质量这个约束，于是把占用率提高误当成收益。
误区MIG 分区后每个实例都有独立显存和算力，所以它们完全不会互相影响，可以用在一切高要求场景。
正解MIG 的隔离能力确实很强，但电源、散热、部分 PCIe 带宽等物理资源仍然共享，极端负载下仍可能出现尾部延迟波动。此外，模型必须能适配 MIG 的固定分区规格，并不是所有模型都适合。
为何常见：硬件隔离的宣传容易被绝对化，忽略共享物理组件带来的长尾影响。
误区看板显示 GPU 利用率 90%，我就认为资源用得很好，服务一定很健康。
正解利用率高可能意味着任务在排队，延迟已经超标。正确的做法是把利用率和 P99 延迟、排队长度联合观察，利用率一旦超过合理阈值而延迟上升，就要触发扩容或降并发。
为何常见：利用率是最容易看到的数字，直觉上会觉得越高越好，但推理服务真正要守护的是延迟 SLO。
面试题
Q1. GPU 利用率偏低的主要原因是？
- A.芯片制程太过老旧
- B.模型独占整张显卡← 正确答案
- C.显卡风扇噪声太大
- D.显存容量不够使用
答案：B。推理请求往往很短暂，模型独占整卡会导致大部分时间 GPU 处于等待状态，所以利用率偏低。芯片制程、风扇噪声、显存不足都不是推理场景利用率低的根本原因。
Q2. 时间分片方案的核心思路是什么？
- A.按显存大小切分
- B.按时间段轮流使用← 正确答案
- C.多张显卡并联扩容
- D.强制提高显卡频率
答案：B。时间分片让多个模型按时间片轮流使用同一块 GPU 的计算单元，而不是按显存或频率切分。它相当于让几道菜在同一口灶上轮着烧。
Q3. 空间分区与时间分片最大的区别是什么？
- A.多个实例能同时运行← 正确答案
- B.显存不能再被共享
- C.必须使用多张物理卡
- D.只能部署一个小模型
答案：A。空间分区把 GPU 切成多个独立区域，多个实例可以同时运行；时间分片虽然也有多个模型，但它们轮流使用计算单元，并非真正同时。空间分区并不要求多张物理卡，也不限定只能部署小模型。
Q4. MIG 分区后实例显存超限通常会发生什么？
- A.自动借用其他实例剩余显存
- B.触发 OOM 而不抢占他人显存← 正确答案
- C.降低其他实例的运行频率
- D.整张 GPU 直接停机不可用
答案：B。MIG 的显存隔离是硬隔离，实例超限会触发自己的 OOM，而不是去借用或抢占其它实例的显存。这就像每口灶只能用自己灶台上的食材，不能去拿隔壁的菜。
Q5. 多模型混部时最主要的风险是什么？
- A.模型权重文件会互相覆盖
- B.算力争抢导致延迟抖动← 正确答案
- C.GPU 驱动版本无法加载
- D.容器网络 IP 地址冲突
答案：B。模型文件、驱动和网络一般由容器和编排系统隔离，真正的风险是计算与显存带宽的争抢，导致请求延迟抖动。混部前要通过干扰因子评估这种风险。
Q6. GPU 池化通常带来哪些收益？
- A.提升 GPU 整卡利用率← 正确答案
- B.降低推理平均成本← 正确答案
- C.让显存容量无限扩大
- D.让更多模型共用一张卡← 正确答案
答案：ABD。池化通过共享减少空转，提高利用率，让更多模型共用一张卡，从而摊薄平均推理成本。但它不会让显存或算力凭空变多，物理上限仍然存在。
Q7. 以下属于 GPU 隔离机制关注点的是？
- A.显存使用上限控制← 正确答案
- B.算力配额公平分配← 正确答案
- C.故障影响范围隔离← 正确答案
- D.屏幕分辨率自动调高
答案：ABC。显存、算力和故障域是 GPU 隔离的三大核心。屏幕分辨率与 GPU 虚拟化无关，属于干扰项。
Q8. 时间分片模式下延迟上涨的直接原因是什么？
- A.显存容量被切分变小
- B.任务排队等待时间片← 正确答案
- C.GPU 风扇转速变慢降低
- D.宿主机网络带宽被占满
答案：B。时间分片让多个模型轮流使用计算单元，任务需要排队等待属于自己的时间片，等待时间会直接反映为延迟升高。显存容量并不是时间分片的主要瓶颈。
Q9. 性能调优时通常需要联合观察哪些指标？
- A.平均 GPU 利用率← 正确答案
- B.请求 P99 延迟← 正确答案
- C.任务排队等待时长← 正确答案
- D.机房咖啡机剩余杯数
答案：ABC。利用率高不一定代表健康，必须与 P99 延迟和排队长度一起看。如果利用率高但 P99 也在上涨，说明资源已经过载。咖啡机数据和性能无关。
Q10. 需要兼顾利用率和租户隔离时，通常优先选择哪种方案？
- A.MIG 空间分区← 正确答案
- B.独占物理整卡
- C.时间分片超卖
- D.显存软限制限额
答案：A。MIG 空间分区能在共享物理 GPU 的同时提供较强的显存和算力隔离，适合兼顾利用率和多租户隔离。独占整卡隔离最好但利用率低，时间分片超卖隔离弱，显存软限制难以防止算力争抢。