批次从小变大，吞吐量不一定持续上升：序列变长会占用更多 KV cache，等待凑批也会增加响应时间。设计大型语言模型批量推理的吞吐量优化方法，应先明确延迟目标，再用真实请求分布测量显存与性能，而不是只追求最大批次。
先分清吞吐和延迟
吞吐量通常指单位时间生成的 token 数或完成的请求数。在线服务还要关注首 token 延迟（TTFT）、生成过程中的 token 间隔，以及请求排队时间。离线摘要任务可以接受较长等待，交互式问答则更在意及时开始响应。
测试时记录输入、输出 token 数，批次大小、并发请求数、吞吐、延迟分位数和显存峰值。固定模型版本、硬件、精度与采样参数，并重复测试；若只统计平均延迟，少数长请求造成的尾部问题可能被掩盖。
显存不只由批次大小决定
推理显存包括模型权重、运行时工作区和 KV cache。KV cache 随并发序列数及已生成 token 增长；上下文越长，可容纳的并发请求往往越少。量化可以减少权重占用，但不意味着 KV cache、临时缓冲区和显存余量也同比下降。
因此，大型语言模型批量推理的吞吐量优化方法应同时约束批次请求数与批次 token 总量。设定 token 上限能降低长短请求混在一起时的显存波动；还应预留空间给运行时开销，避免把设备显存按理论权重容量用满。
按服务形态选择批处理方式
在线请求：限制等待，允许动态合批
动态批处理器在短暂窗口内收集新请求，达到数量或 token 上限后启动推理。窗口越长，越容易凑成较大批次，但队列延迟也越高。可从几毫秒到数十毫秒范围内试探，具体起点取决于服务延迟目标和流量密度；低流量时应重点观察等待时间。
离线任务：按长度分组
批量摘要、文档抽取等任务通常更能容忍排队。先估算输入长度，再将相近长度的请求分组，可减少短请求陪长请求等待的情况。对输出长度差异大的任务，也可按预计生成长度拆分批次。vLLM 的连续批处理会在请求结束后补入新请求，适合请求到达和完成时间不一致的负载；但仍需结合版本、模型配置与显存上限验证。
按步骤找到可用边界
- 建立基线：用代表性请求记录单请求与小并发的 TTFT、生成速度和显存占用。
- 分档增加负载：逐步提高并发或 token 上限，每档观察吞吐是否仍增长、延迟是否越过业务目标。
- 覆盖长请求：加入接近实际上限的上下文和较长输出，检查 KV cache 增长、显存不足及请求被迫等待等情况。
- 设置安全余量：选择未触发显存溢出且延迟达标的配置；流量波动较大时，保留更多余量并限制最大输入长度。
- 小流量上线复核：观察队列长度、错误率、显存峰值和延迟分位数；不符合目标时回退到上一档。
常见问题
批次越大，吞吐一定越高吗？
不一定。达到设备效率较高的区间后，继续增大批次可能只增加排队和显存压力，吞吐提升有限，甚至因频繁回退或溢出而下降。
应该优先调并发数还是 token 上限？
两者需要配合。并发数限制同时处理的请求，token 上限控制批次工作量；长上下文负载下，token 上限尤其有助于控制显存波动。
如何确定最终配置？
以目标模型、实际输入输出长度和预期流量压测，选择同时满足显存安全、吞吐需求与延迟目标的配置。大型语言模型批量推理的吞吐量优化方法没有适用于所有模型的固定批次值，需持续按负载复核。
