权重卸载在解决什么
显存装不下整个模型时，可以选择把一部分权重留在主机内存里，推理时按需换入，用传输开销换显存空间。它的定位是「差一口气」的补救手段：显存缺口在一到两成以内时通常还能接受，缺口很大时换页占比过高，延迟会明显抖动。相比量化，卸载不改变数值精度，但代价体现在每步的等待时间上，而不是模型质量。
基本信息
| 适用引擎 | vLLM 提供 cpu-offload-gb 参数，单位为 GiB |
|---|---|
| 参数含义 | 指定卸载到主机内存的权重规模，不是比例 |
| 硬件前提 | 主机内存需容纳卸载部分，且 CPU 与 GPU 之间的传输通道足够快 |
| 典型位置 | 启动参数，需在服务启动时确定，运行中不可调整 |
| 与其他手段关系 | 可与量化叠加，先量化再卸载通常比直接卸载更划算 |
典型使用场景
- 显存与目标模型差一口气：模型略大于单卡显存，量化代价不愿承担时先试卸载
- 离线批处理任务：对单步延迟不敏感，只要能把更大的模型跑起来
- 评测与验证环境：临时跑通某个模型做效果对比，不追求线上性能
- 显存临时紧张：其他任务占用了部分显存，短期靠卸载顶过去
- 量化前的过渡方案：先确认模型可用，再决定是否投入量化改造
启用与验证
启用与验证
vllm serve <模型路径> --cpu-offload-gb 16 # 卸载 16 GiB 权重到内存
nvidia-smi --query-gpu=memory.used,memory.total --format=csv -l 5 # 观察显存水位
vllm serve <模型路径> --cpu-offload-gb 0 # 基线对照：不卸载
grep -i 'offload' <服务日志> # 确认参数已生效
# 用同一批请求对比两组的首字延迟与单 token 延迟分位卸载量对指标的影响
| 卸载量 | 显存占用 | 延迟表现 |
|---|---|---|
| 0 | 最高，可能直接装不下 | 基线性能，单步延迟最平稳 |
| 小幅（低于显存缺口的余量） | 明显下降 | 延迟略微抬升，尾延迟波动可控 |
| 中等 | 进一步下降 | 单步延迟上升，长上下文下更明显 |
| 过大 | 看似充裕 | 换页频繁，尾延迟成倍波动，吞吐大幅下降 |
| 超出主机内存 | 启动失败或频繁换出 | 表现为启动阶段报错或运行中卡顿 |
卸载量从零开始逐档加压测试，找到延迟仍可接受的拐点再固定；一次性开到很大再往回减，很难判断哪一档才是真正的边界。
主机内存同样要留余量：卸载部分占用的内存如果挤占了操作系统页缓存，会连带影响磁盘读取与日志写入，反而放大抖动。