连续批处理常被描述为“让新请求动态加入正在执行的批次”，但企业平台真正关心的不是开关有没有打开，而是调度后能否满足既定服务目标。离线批量生成可以追求总 Token 吞吐，在线问答更在意排队时间、首 Token 延迟、输出 Token 间隔和高分位尾延迟。若把这些指标压缩成一个平均响应时间，就很容易得到错误结论：短请求看似变快，长请求却持续占用 KV Cache；总体吞吐提高，少数交互请求的首 Token 反而超过预算。
用真实请求分布定义问题
评估前应先从业务日志形成不含敏感内容的长度分布，包括输入 Token、期望输出 Token、并发到达方式、中止比例和流式返回需求。固定长度的合成请求适合校准平台，却不能代表生产。尤其是提示词很长而回答很短、提示词很短但生成很长、多个请求同时到达和持续泊松到达，会对预填充与解码阶段产生完全不同的压力。建议把请求划分为数个业务桶，每个桶单独定义权重，再构造混合流量；不能用最有利的一种长度宣称整个服务已经优化。
四类指标必须分开
首 Token 延迟反映排队、预填充和调度开销；逐 Token 延迟影响用户看到文本连续输出的节奏；端到端延迟包含完整生成长度；吞吐则可能按请求或 Token 统计。应同时报告中位数和 P95、P99 等分位数，并标明是否包含网络与网关。连续批处理有机会填补解码阶段的空隙，但也会引入调度竞争。一个合理的测试不只测稳定满载，还要从低并发逐级升压，找到尾延迟开始陡升的拐点。这个拐点通常比峰值吞吐更适合作为容量边界。
KV Cache 是调度约束而非背景数字
连续加入请求会改变 KV Cache 的分配、复用和回收节奏。可用显存并不等于都能分给缓存，还要为权重、运行时工作区、通信缓冲和波动留出空间。请求长度上限设置过宽，少数长会话可能挤压大量短请求；设置过窄又会造成业务拒绝或截断。评估时应记录缓存占用、水位变化、驱逐或重计算行为以及请求终止后的回收时间。若使用张量并行或多实例部署，还要观察缓存压力是否在各进程之间均衡，避免总量看似充足但某个分片先达到边界。
调度策略要和服务等级一起验证
最大批量、最大 Token 数、调度队列、优先级和并发实例数彼此影响。盲目放大批量可能提高设备利用率，却让交互请求等待更久。更实用的方法是先给不同业务类定义可接受的首 Token 和逐 Token 区间，再在这些约束下寻找吞吐上限。若平台混合实时与离线任务，可考虑分池、优先级或容量预留，而不是让所有请求共享一个没有边界的队列。任何策略变更都应验证取消请求、客户端断开、超长输入和模型加载中的异常路径。
压测结果怎样才可复用
- 固定模型制品、精度或量化方式、引擎参数、GPU 拓扑和服务端版本。
- 保存每个请求的输入与输出长度、到达时间、首 Token、完成时间和错误状态。
- 分别运行低负载、阶梯升压、突发流量与长短请求混合场景。
- 同步采集 GPU 利用率、显存与 KV Cache 水位、队列深度和网络侧延迟。
- 用相同请求种子对比调度参数，并把超时、拒绝和取消纳入统计而非丢弃。
连续批处理不是适用于所有模型和业务的固定答案。团队应把结论写成“在某个版本、请求分布和服务等级约束下的容量区间”，而不是一个脱离条件的吞吐数字。TensorRT-LLM 的功能入口、后端与运行参数可从 NVIDIA TensorRT-LLM 官方文档继续核对；文档能力会随版本变化，上线前仍需锁定制品并在目标环境回归。
WeChat
Profile