vllm推理加速之 - continuous batching +Rag合并请求优化

目录

• 最大吞吐量的“三剑客”
• batch 设置多大合适
  • 1️⃣ 影响 batch 大小的核心因素
  • 2️⃣ 工程经验参考表
  • 3️⃣ 结合显存计算
  • 4️⃣ 连续批 + Ray 调度策略
  • 5️⃣ 工程实践总结

KV Cache = max_model_len × batch × hidden_size × 2 × dtype

符号	含义
max_model_len	上下文长度（Token 数）
batch	一次推理请求中同时处理的序列数
hidden_size	模型隐藏层维度（Qwen-14B = 12288）
2	Key + Value，各 1 份
dtype	每个元素占用显存（FP16 = 2 byte, 8-bit = 1 byte, 4-bit ≈ 0.5 byte）

每次 forward 只处理 1 条请求
batch > 1 的优势
-多条请求合并成 batch，一次 forward 同时处理多条请求
-GPU 核心利用率提升 → 吞吐量明显提高
-tradeoff：单条请求延迟略增加，但平均吞吐（QPS）提升

最大吞吐量的“三剑客”

手段	作用	备注
1️⃣ Continuous Batching	vLLM 内部把短请求排队，短时间内合并成 batch 送入 forward	提高 GPU 利用率，减少每条请求独立 forward 的开销
2️⃣ Ray / AI 网关自动合并请求	高 QPS 场景下，把来自多客户端/多线程的请求调度、排序、聚合	可以把更多请求填满 batch，让 GPU 始终满载
3️⃣ batch > 1	一次 forward 同时处理多条请求	核心 GPU 并行利用率提升，吞吐量线性增加（理论上）

batch 设置多大合适

明白，你想知道 vLLM / 大模型推理场景下 batch 的最佳实践，尤其是短请求 / 高 QPS 的智能客服场景。下面我从工程实战角度给你整理一套参考方案。

---

1️⃣ 影响 batch 大小的核心因素

因素	说明
上下文长度（max_model_len）	KV Cache ∝ token × batch → 上下文越长，batch 越大显存压力越大
GPU 显存大小	显存越大 → 可承受 batch 越大
权重量化 / dtype	FP16 > 8-bit > 4-bit → 权重越小，batch 可越大
请求并发 / QPS	高 QPS → batch 可以大一些，吞吐最大化
延迟要求	单请求延迟敏感 → batch 不宜太大，单条请求等待合并时间增加
多机 / 多卡部署	batch 可以拆分到多 GPU，每卡 batch 分配影响单卡显存

---

2️⃣ 工程经验参考表

假设：

• GPU：48GB（SL400S / 3090 / 4090）
• 模型：Qwen-14B 8-bit
• 请求短文本：≤2K token
• vLLM continuous batching 开启
• 单机 1–6 卡

场景	上下文长度	QPS / 并发	推荐 batch	备注
短请求，低 QPS	2K	50–100	2–4	延迟优先，小 batch 足够
短请求，高 QPS	2K	200–500	4–8	GPU 利用率高，吞吐最大化
中等请求	4K	50–200	2–4	KV Cache 占显存多，batch 不宜过大
长请求	8K+	50–100	1–2	单请求 forward 时间长，batch 大影响延迟

规律总结：

1. 上下文越长，batch 越小
2. QPS 越高，batch 越大（吞吐优先）
3. 延迟敏感 → batch 控制在 1–4

---

3️⃣ 结合显存计算

KV Cache 占用公式：

KV Cache = max_model_len × batch × hidden × 2 × dtype

举例（Qwen-14B 8-bit，hidden=12288，batch=4，2K token）：

KV Cache ≈ 2048 × 4 × 12288 × 2 × 1 byte ≈ 196 MB × 2 ? ≈ 384 MB

• 权重 8-bit ≈ 16–18GB
• GPU 48GB → 显存足够

batch 太大 → KV Cache 占用增加 → gpu-memory-utilization 要降低，否则 OOM

---

4️⃣ 连续批 + Ray 调度策略

1. continuous batching

   • max_batch_size = 推荐 batch
   • max_wait_ms = 5–20ms（短请求延迟敏感）

2. Ray / AI 网关

   • 自动收集高 QPS 请求
   • 填满 batch
   • 结合优先级队列：短请求优先，长请求单独处理

通过两层合并（网关 + vLLM continuous batching），可以保证 batch 在 吞吐量最大化 的同时 延迟可控

---

5️⃣ 工程实践总结

条件	batch 建议
token ≤ 2K，低延迟，QPS < 100	1–2
token ≤ 2K，高吞吐，QPS 200–500	4–8
token 4K，QPS < 200	2–4
token 8K+，延迟敏感	1–2

核心原则：
batch 大 → GPU 利用率高，吞吐高，但显存增加，单请求延迟增加
batch 小 → 延迟低，显存小，但吞吐受限