目录
- 最大吞吐量的“三剑客”
- 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 大影响延迟 |
规律总结：
- 上下文越长，batch 越小
- QPS 越高，batch 越大（吞吐优先）
- 延迟敏感 → 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 调度策略
-
continuous batching
- max_batch_size = 推荐 batch
- max_wait_ms = 5–20ms（短请求延迟敏感）
-
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 小 → 延迟低，显存小，但吞吐受限