GPU 利用率账：为什么利用率低，共享能省多少卡

集群里最贵的资源是 GPU，但真实利用率往往只有 20-40%。本文把"利用率低"拆成可量化的几笔账：请求稀疏、显存碎片、隔离开销，再算连续批处理与共享能把利用率拉到多少、能省几块卡。方法框架参考开源书稿《深入理解 AI Infra》（Apache-2.0），公式与算例为本站自行推导整理。

1. 利用率的定义先统一

$$Utilization = \frac{实际有效 FLOPs}{理论峰值 \times 时间}$$

注意"显存占用率 ≠ 利用率"：一块卡显存 90% 满但只在等数据，利用率可能只有 15%。看利用率要看算力/带宽的忙闲，不是看显存。

2. 为什么利用率低：三笔账

账 1：请求稀疏。 推理请求到达不均匀，GPU 空转等请求。夜间利用率可能只有个位数。

账 2：显存碎片与 bin-packing。 请求规格不一（不同模型、不同上下文长度），显存按"最大可能"预留：一个 70B 服务预留 4 卡显存但常常只用到一半。装箱（bin-packing）问题导致资源颗粒度浪费。

账 3：隔离开销。 时间片切换有上下文开销，MIG 切分损失部分算力/带宽，多租户互踩缓存——共享省显存，但牺牲一部分性能。

3. 连续批处理：把利用率拉起来的核心账

vLLM 的核心是连续批处理（continuous batching）：不等整批完成，谁算完谁走、立即补新请求。

方式	空闲占比	说明
静态批（batch 满才跑）	高（尾部等待）	慢请求拖住整批
连续批处理	低（即算即走）	每个 step 重排请求，插空

量化：请求完成时间长尾从"最长请求"变成"平均请求"，吞吐可提升 2-3 倍（同卡同显存）。这是"同样的卡，QPS 差一倍"的常见来源。

4. 共享方案怎么选：隔离 vs 开销的账

方案	隔离	开销	适用
整卡独占	最强	无	训练、高要求推理
时间片（CUDA MPS 调度）	中	切换/排队	低优先推理、开发
MIG 切分	硬件级	算力/带宽按份额	显存大算力小的推理
多租 + 调度器（vLLM/K8s）	软隔离	排队与抢占	生产推理集群

判断：推理服务优先"连续批处理 + 调度器多租"，而不是一上来就 MIG——MIG 的颗粒度（显存倍数）往往和模型显存需求对不齐，浪费反而更大。

5. 可复算 Python 函数

def utilization_saving(gpus, avg_util, target_util=0.7):
    """当前利用率提到目标利用率，等效省多少块卡"""
    eff = gpus * avg_util
    needed = eff / target_util
    return gpus - needed, needed

utilization_saving(gpus=16, avg_util=0.3)
# (9.1, 6.9) → 利用率 30%→70%，16 卡的事 7 卡能干，省 9 卡

6. 交付清单

1. 用算力/带宽忙闲（非显存占用）统计真实利用率，作为改造基线；
2. 推理服务先上连续批处理（vLLM 等），观察 QPS/利用率提升，这是投入产出比最高的一步；
3. 再按"显存颗粒度 vs 模型需求"评估 MIG/时间片，颗粒度对不齐就别用 MIG；
4. 容量规划按"目标利用率"反推卡数（见上面函数），别按峰值请求买卡；
5. 每次共享改造记录隔离开销（P99 延迟变化），接受不了就回到独占。

---

本文为本站自行推导整理，方法框架参考开源书稿《深入理解 AI Infra》（Apache-2.0）；具体版本号与实测数据以现场为准。