vLLM 批大小怎么定：吞吐与延迟的实务 FAQ
批太大，延迟尾部变差；批太小，GPU 吃不饱。没有放之四海的魔法数字，只有「目标延迟 + 显存 + 观测」的回路。
FAQ
先定什么？
先定服务目标：P95 延迟预算、是否流式、上下文长度分布。再谈提高吞吐。
和 max_num_seqs / 连续批处理有何关系？
它们共同约束同时驻留的请求。调参时一次只改一类旋钮，并记录前后指标，否则无法归因。
显存不够时优先砍什么？
常见顺序（需按你的版本文档核对）：降并发序列数、降最大生成长度、检查 KV cache 占用、考虑量化或分片。不要只靠「再加大批碰运气」。
如何判断批偏小还是偏大？
看 GPU 利用率、KV 缓存使用率、排队时间与 P95。利用率低且排队短 → 可能偏小；排队或尾延迟炸且缓存近满 → 可能偏大或上下文过长。
和本地卸载有什么不同？
服务端 vLLM 与桌面「CPU 卸载跑本地模型」目标不同。桌面场景见本地模型 CPU 卸载 FAQ；vLLM 概念见vLLM 推理。
建议记录的配置指纹
模型名与修订、GPU 型号、关键并发/批相关参数、最大上下文、量化情况、测试流量形状。
小结
批大小是目标函数问题，不是玄学。固定测量剧本，小步改参，留下指纹，服务才能稳定扩。
流量形状决定参数
全是短提示与全是长上下文，合适的并发完全不同。用生产流量的近似重放做实验，比用玩具提示拍板更靠谱。改参后看 P95 与拒绝率，不只看平均延迟。
版本差异
vLLM 参数名随版本变化，调前对照你安装版本的文档。把版本号写进配置指纹，避免同事用旧笔记调新版本。
发布前检查表
改完批/并发参数后：跑固定流量剧本；对比 P50/P95、吞吐、拒绝率、显存；保留配置指纹；观察至少一个业务高峰再定稿。回滚路径要明确——配置进版本库，出问题能一键回到上一指纹。
同一模型不同量化级别，显存与速度曲线不同，批参数不可照搬。上线新量化后重新跑测量剧本。若启用前缀缓存等特性，记录是否开启，否则同事复现不了你的吞吐。把「已知不良参数组合」记入运维手册，避免重复踩坑。