vllm调参-gpu-memory-utilization

目录

• 参数设置实践
• 一、vLLM 显存占用与 OOM 的关系
• 二、如何在压测时发现潜在 OOM
  • 1️⃣ 观察指标
  • 2️⃣ “危险显存占比”参考
• 三、调节策略
  • 1️⃣ 调整 --gpu-memory-utilization
  • 2️⃣ 调整 batch_token / seq
  • 3️⃣ 压测建议
  • 四、工程实践经验
• 查看显存使用情况
• 一、vLLM 显存占用与 OOM 的关系
• 二、如何在压测时发现潜在 OOM
  • 1️⃣ 观察指标
  • 2️⃣ “危险显存占比”参考
• 三、调节策略
  • 1️⃣ 调整 --gpu-memory-utilization
  • 2️⃣ 调整 batch_token / seq
  • 3️⃣ 压测建议
  • 四、工程实践经验

参数设置实践

完全可以从工程和安全角度来分析。我们把它拆开来看：

---

一、vLLM 显存占用与 OOM 的关系

1. 核心公式（工程经验）：

[
\text{显存占用} \approx \text{KV Cache} + \text{模型参数} + \text{激活值} + \text{临时 buffer}
]

• KV Cache ∝ max-model-len × max-num-seqs × hidden_size × 2（K+V）
• 模型参数固定（14B AWQ → 约 14B × 2 byte = ~28GB float16/awq 小一点）
• 临时 buffer 受 batch_token/seq 影响

工程结论：KV Cache 是 OOM 的最常见“雷区”。

---

二、如何在压测时发现潜在 OOM

1️⃣ 观察指标

指标	工具	危险阈值
GPU 显存占用	nvidia-smi / gpustat / vLLM log	≥ 90–92% 对 24–48GB 卡算危险
GPU 利用率（SM）	nvidia-smi	利用率高没问题，但如果显存接近满 → OOM
vLLM 日志	INFO 级	会打印每个 step 的 KV Cache 占用 / batch_token 情况
TTFT / decode step 抖动	压测观察	突然抖动或长尾 → 可能隐性显存压力

---

2️⃣ “危险显存占比”参考

GPU 显存	安全上限建议	注释
24GB（4090）	≤ 90%	保留 ~2–3GB buffer
48GB（L40S）	≤ 92%	ECC + 稳定性好，可以稍高
80GB（A100/H100）	≤ 94%	高压运行可接受，但高峰要留 buffer

如果超过这个阈值，很容易在高并发或长上下文时触发 OOM。

---

三、调节策略

1️⃣ 调整 --gpu-memory-utilization

• vLLM 会根据这个值自动缩减 batch_token / seq

• 压测中，如果显存超过安全阈值：

  • 将 gpu-memory-utilization 调低 0.05~0.1
  • 再压测观察是否下降到安全区间

工程经验：对于 4090 24GB 卡，如果 batch_token=8192, seq=32, max-model-len=2048 → 占用约 21~22GB → gpu-memory-utilization 设置 0.9 就安全。

---

2️⃣ 调整 batch_token / seq

• batch_token 太大 → 单 step buffer 占用增加
• seq 太大 → KV Cache 占用增加
• 先固定 model_len，逐步调节 batch_token → 再调 seq

---

3️⃣ 压测建议

1. 用小请求先扫 batch_token / seq
2. 观察 GPU 显存曲线 (nvidia-smi -l 1)
3. 再用长请求压测
4. 如果看到显存峰值接近安全阈值 → 调低 gpu-memory-utilization 或减少 batch_token/seq

---

四、工程实践经验

1. 压测不等于真实负载

   • 压测时留 buffer 更安全

2. 短请求和长请求混合

   • 长请求显存占用大 → 潜在 OOM
   • 可以考虑 长请求独立服务 或 chunked prefill

3. 日志可视化

   • vLLM 日志会输出每个 step 的 KV Cache 大小
   • 超过 90% GPU 显存 → 必须调小 gpu-memory-utilization

---

总结一句话：

压测时，只要显存占用接近或超过 90–92%（消费卡/数据中心卡略有差异），就说明存在潜在 OOM，需要调小 --gpu-memory-utilization 或减少 batch_token/seq。

---

如果你愿意，我可以帮你整理一张 “vLLM 压测显存安全区与调参对应表”，直接给工程师参考，短/长上下文都适用。

你希望我做吗？

查看显存使用情况

完全可以从工程和安全角度来分析。我们把它拆开来看：

---

一、vLLM 显存占用与 OOM 的关系

1. 核心公式（工程经验）：

[
\text{显存占用} \approx \text{KV Cache} + \text{模型参数} + \text{激活值} + \text{临时 buffer}
]

• KV Cache ∝ max-model-len × max-num-seqs × hidden_size × 2（K+V）
• 模型参数固定（14B AWQ → 约 14B × 2 byte = ~28GB float16/awq 小一点）
• 临时 buffer 受 batch_token/seq 影响

工程结论：KV Cache 是 OOM 的最常见“雷区”。

---

二、如何在压测时发现潜在 OOM

1️⃣ 观察指标

指标	工具	危险阈值
GPU 显存占用	nvidia-smi / gpustat / vLLM log	≥ 90–92% 对 24–48GB 卡算危险
GPU 利用率（SM）	nvidia-smi	利用率高没问题，但如果显存接近满 → OOM
vLLM 日志	INFO 级	会打印每个 step 的 KV Cache 占用 / batch_token 情况
TTFT / decode step 抖动	压测观察	突然抖动或长尾 → 可能隐性显存压力

---

2️⃣ “危险显存占比”参考

GPU 显存	安全上限建议	注释
24GB（4090）	≤ 90%	保留 ~2–3GB buffer
48GB（L40S）	≤ 92%	ECC + 稳定性好，可以稍高
80GB（A100/H100）	≤ 94%	高压运行可接受，但高峰要留 buffer

如果超过这个阈值，很容易在高并发或长上下文时触发 OOM。

---

三、调节策略

1️⃣ 调整 --gpu-memory-utilization

• vLLM 会根据这个值自动缩减 batch_token / seq

• 压测中，如果显存超过安全阈值：

  • 将 gpu-memory-utilization 调低 0.05~0.1
  • 再压测观察是否下降到安全区间

工程经验：对于 4090 24GB 卡，如果 batch_token=8192, seq=32, max-model-len=2048 → 占用约 21~22GB → gpu-memory-utilization 设置 0.9 就安全。

---

2️⃣ 调整 batch_token / seq

• batch_token 太大 → 单 step buffer 占用增加
• seq 太大 → KV Cache 占用增加
• 先固定 model_len，逐步调节 batch_token → 再调 seq

---

3️⃣ 压测建议

1. 用小请求先扫 batch_token / seq
2. 观察 GPU 显存曲线 (nvidia-smi -l 1)
3. 再用长请求压测
4. 如果看到显存峰值接近安全阈值 → 调低 gpu-memory-utilization 或减少 batch_token/seq

---

四、工程实践经验

1. 压测不等于真实负载

   • 压测时留 buffer 更安全

2. 短请求和长请求混合

   • 长请求显存占用大 → 潜在 OOM
   • 可以考虑 长请求独立服务 或 chunked prefill

3. 日志可视化

   • vLLM 日志会输出每个 step 的 KV Cache 大小
   • 超过 90% GPU 显存 → 必须调小 gpu-memory-utilization

---

总结一句话：

压测时，只要显存占用接近或超过 90–92%（消费卡/数据中心卡略有差异），就说明存在潜在 OOM，需要调小 --gpu-memory-utilization 或减少 batch_token/seq。

---

如果你愿意，我可以帮你整理一张 “vLLM 压测显存安全区与调参对应表”，直接给工程师参考，短/长上下文都适用。

你希望我做吗？