关卡阅读材料 // 05
资源隔离
当在线推理和大批任务共享 GPU 时，先建立硬资源边界，再在边界内用有界批处理与异步供给平衡延迟和吞吐。
建议边读边写下答案；时长包含代码推演与练习。
进入互动关卡→- 01导读与目标05 MIN
- 02心智模型08 MIN
- 03概念深挖15 MIN
- 04代码推演12 MIN
- 05历史生态08 MIN
- 06练习复盘12 MIN
从单个 Kernel 扩展到端到端 Pipeline，通过 Profiling 定位排队、资源竞争与数据移动瓶颈。
关卡把 Stream、MIG 与动态批处理分成三个层次；实验用尾延迟与时间线检验资源隔离和队列策略，而不是只优化平均吞吐。
- 课程 02
- 基本服务延迟概念
- 能区分平均值与 P95/P99
- Nsight Systems
- Triton Model Analyzer（可选）
- MIG-capable GPU（可选）
导读与目标
先记住这一句
并发表达独立性，隔离建立资源边界，调度决定边界内部如何排队。
完成后你应该能够
- 01
区分并发、优先级、资源隔离与服务调度四个层次。
- 02
解释 MIG GPU Instance 隔离了哪些计算与内存路径。
- 03
根据延迟预算设计最大 Batch、排队窗口与双缓冲。
- 04
为共享 GPU 场景选择可观测指标和验证方法。
建立心智模型
- 01竞争
两个 Stream 可以独立提交工作，却仍共享 SM、缓存和内存带宽。
- 02隔离
MIG 用受支持的 Profile 划分 GPU Instance，建立计算与内存资源路径的边界。
- 03供给
实例内部仍需限制 Batch 大小与等待窗口，并用缓冲区减少复制和计算之间的气泡。
概念深挖
Stream 不是 QoS
Stream 优先级是调度提示，不是 SM、L2 或内存带宽的硬预留。
MIG 是离散 Profile
GPU Instance 依照硬件支持的组合创建，不是可随意拖动的百分比分区。
隔离后仍要排队
动态批处理需要在最大 Batch、最大等待时间、请求优先级和延迟目标之间做测量驱动的选择。
独立提交并不建立资源边界
CUDA Stream 让两个程序或两类请求拥有独立命令流，但 Kernel 仍可能竞争 SM、寄存器、L2 与内存带宽。Stream Priority 可以影响待调度工作的选择，却不会抢占正在执行的大 Kernel，也不保证一份固定资源。
因此服务质量问题需要先明确目标：是避免安全域互相访问、限制故障影响，还是降低性能干扰？不同目标可能对应进程隔离、MPS、时间切片、MIG 或独立 GPU。不能把一种机制的保证外推到所有层次。
停下来想一想高优先级 Stream 能否保证请求在 5 ms 内完成？＋
参考答案不能。优先级只是调度提示，延迟还受正在运行的 Kernel、资源竞争、排队和模型执行时间影响。
MIG 用 Profile 固化实例边界
MIG 在受支持 GPU 上把计算切片与内存切片组合成 GPU Instance。每个实例拥有独立的地址空间与分配到的内存路径，可降低其它实例缓存抖动或带宽饱和造成的干扰，并提供更明确的故障与 QoS 边界。
Profile 是硬件支持的离散组合，配置通常需要运维层参与。切分后每个实例的容量与计算能力更小，模型是否放得下、实例内是否仍过载都需要重新验证。MIG 也不会替代容器、身份或应用级权限控制。
停下来想一想能否把一张 MIG GPU 任意划成 37% 与 63% 两个实例？＋
参考答案不能按任意百分比切分；必须选择设备支持且布局兼容的 Profile 组合。
批处理是在吞吐与等待间花预算
动态批处理让多个请求共享一次模型执行，提高矩阵 Shape 与设备利用率。但第一个到达的请求必须等待 Batch 成形，因此最大排队时间直接消耗延迟预算。应从目标 P95/P99 延迟倒推出可接受的 Queue Delay。
双缓冲让一个 Slot 计算时另一个 Slot 搬运下一批输入，但它不能消除模型计算本身。请求长度、Shape 或优先级差异较大时，还需要分队列、Ragged Batching 或调度策略，避免一个异常请求拖慢整个 Batch。
停下来想一想为何“最大 Batch 越大越好”不成立？＋
参考答案更大 Batch 可能提高吞吐，却增加成批等待、显存占用和单次执行时间，从而恶化尾延迟。
把概念放回代码
01while (serving) {02 batch = queue.take(max_batch, max_queue_delay);03 copy_async(slot[next], batch);04 infer_async(slot[current]);05 swap(current, next);06}代码逐段推演
- 01BUDGET先定义 max_queue_delay
排队只是端到端延迟的一部分；要为网络、预处理、执行与回传保留预算。
- 02FORM在大小或时间条件满足时成批
queue.take 同时受最大 Batch 与最老请求等待时间约束，任何一个触发都应发车。
- 03BUFFER两个 Slot 分离搬运与执行
next Slot 接收输入，current Slot 执行；复用前必须确认上一轮使用已经完成。
- 04MEASURE同时观察吞吐与尾延迟
平均延迟会掩盖排队尖峰，应按请求类型跟踪 Queue、Compute、Copy 与 P95/P99。
知识图谱
补充参考 · 不要求一次读完，也不计入核心 60 分钟
核心术语
- Throughput
- 单位时间完成的请求或样本数；它不能说明单个请求等待了多久。
- Tail Latency
- P95/P99 等高分位延迟，用来观察少量慢请求和资源争用。
- Queue Delay
- 请求在获得批次、Stream、显存或执行资源之前的等待时间。
- Dynamic Batching
- 在有限等待窗口内把多个请求组合为批次，以提高 GPU 利用率。
- MIG
- 从 Ampere 开始提供的硬件分区能力，可为实例分配隔离的计算与内存系统资源。
带数字推演
- 01正常负载
L = λW = 80 × 0.10 = 8，系统平均有 8 个在途请求。
- 02出现争用
若 W 升到 0.25 秒而到达率不变，L = 80 × 0.25 = 20。
- 03解释变化
平均多出 12 个请求正在排队或执行，内存与队列压力随之增大。
诊断手册
平均延迟正常但 P99 暴涨
- 先检查
- 长 Batch、队首阻塞、后台任务、内存回收和负载突发
- 需要的证据
- 逐请求 Queue/Copy/Compute 时间与延迟分布
启用 MIG 后吞吐下降
- 先检查
- 实例 Profile 是否匹配工作集，单任务是否原本需要整卡资源
- 需要的证据
- 每实例利用率、显存、带宽和相同流量下的 QoS 对比
Batch 增大但 GPU 利用率不升
- 先检查
- 前后处理、数据搬运、Shape 不一致、内存或 CPU 供给
- 需要的证据
- 端到端时间线和每阶段队列长度，而非单一 GPU 百分比
从硬件到生态
- 01单任务独占
批处理作业以整卡峰值吞吐为目标。
利用率容易理解，但无法满足多租户在线服务。 - 02Stream / MPS 软件共享
多个工作流可以并发提交与调度。
利用率提高，同时出现缓存、带宽与尾延迟干扰。 - 03MIG + 服务编排
硬件隔离结合批处理、调度、监控和容器生态。
资源问题从 Kernel 优化上升为 QoS 与容量规划。
硬件与生态坐标
MIG 从 Ampere 数据中心 GPU 开始提供硬件支持的实例化能力，让不同客户端获得独立的计算与内存资源路径。与此同时，Triton 等服务软件把动态批处理、队列策略和多模型部署变成系统设计问题。
练习与复盘
两个 CUDA Stream 能否保证在线请求不受大 Batch 的资源干扰？
- A. 能，Stream 天然预留一半 SM
- B. 不能，它们仍可能竞争同一资源池
- C. 能，只要提高 Host 线程优先级
查看答案＋
不同 Stream 允许潜在并发，但不建立硬资源边界。隔离与队列调度是不同层次的问题。
独立进程、独立 Stream 与独立 MIG Instance 的隔离强度是否相同？
提示＋
分别看地址空间、调度和硬资源。
参考答案＋
不同。进程提供软件地址空间，Stream 只表达命令顺序，MIG 进一步分配独立计算与内存路径；具体安全和 QoS 仍需结合平台。
P99 目标 50 ms，网络与预处理 8 ms、模型 30 ms、回传 4 ms。排队窗口理论上最多剩多少？
提示＋
先做静态预算，但要留抖动余量。
参考答案＋
静态相减为 8 ms，但真实系统必须为抖动与测量误差留余量，因此 max_queue_delay 应低于 8 ms 并通过压测调整。
双缓冲代码在上一批仍使用 slot[next] 时就覆盖它。如何修复？
提示＋
每个 Slot 需要完成信号。
参考答案＋
为每个 Slot 记录 Event 或 Future；复用前等待该 Slot 的复制与计算完成，再写入新批次。
验证 MIG 是否改善在线请求稳定性，应固定哪些变量并比较哪些指标？
提示＋
建立共享与隔离对照。
参考答案＋
固定模型、流量和批任务强度，对比共享 GPU 与 MIG 下的在线 P50/P95/P99、吞吐、错误率、显存与带宽，并记录 Profile 与实例内调度。
可选实践实验
不计入核心 60 分钟 · 需要相应 CUDA / GPU 环境
实验目标
用尾延迟评价共享 GPU 与有界批处理
在固定在线请求与后台 Batch 负载下，比较共享资源、受控微批次与可用时的 MIG 隔离。建议步骤
- 01
生成可重复的在线请求序列和后台批任务，分别记录 Queue、Copy、Compute 与总延迟。
- 02
在共享 GPU 上运行基线，保存吞吐、P50、P95、P99 与 Nsight Systems 时间线。
- 03
加入 max_batch 与 max_queue_delay，再用双缓冲重叠供给；保持流量不变重新测量。
- 04
若设备支持 MIG，使用明确 Profile 重复实验；否则只完成共享/调度比较，不模拟硬件隔离结论。
提交同一流量下的吞吐和尾延迟表、时间线，以及一段说明“隔离”和“调度”分别改变了什么。
为长请求与短请求建立两个队列，比较队首阻塞与公平性。