大模型延迟与吞吐估算器

流式输出下，"快"有两种含义

用户感知的"快"和系统吞吐的"快"是两件事，对应两个完全不同的指标：

很多人只优化后者（买更多卡、提高并发）却忽略了前者。实际上对交互式产品而言，TTFT 的体验权重远高于吞吐——用户宁可看到文字慢慢冒出来，也不愿盯着空白等 3 秒。

为什么并发会拖慢每个请求

推理引擎（vLLM、TGI 等）默认开启连续批处理（continuous batching）：把多个请求的解码步骤合并成一个批次同时算。好处是总吞吐大幅提升，代价是每个请求的单步延迟变长——因为 GPU 要同时算所有人的 token。

本工具用一个简单模型近似这个现象：有效解码速度 = 解码速度 ÷ (1 + (并发 − 1) × k)，其中 k 是衰减系数（默认 0.15，代表每增加一个并发，单请求速度下降约 15%）。真实的衰减曲线更接近对数或分段函数，但线性近似足以用来做容量规划。

上表的规律值得记住：并发翻倍，系统吞吐远不到翻倍，但单请求延迟必然变差。这就是为什么有经验的团队会按业务分层——交互式请求走小并发队列，批处理任务走大并发队列，两者物理隔离。

三个容易被忽略的延迟来源

• 排队时间：高峰期请求要先排队等到有空闲槽位，这部分延迟不在本工具的直接计算内，但会叠加在 TTFT 上。
• 输入长度对预填充的影响是超线性的：注意力机制的复杂度随序列长度增长，10 万 token 的预填充不是 1 万 token 的 10 倍，可能更慢。
• 网络与首包：跨境调用时网络延迟常达 200–400ms，占了 TTFT 的一半以上。就近部署或使用边缘接入点收益明显。

你可能还想问

延迟由哪几部分组成？

主要分首词元时间与后续生成时间，另有网络往返与排队等待；优化时要先定位瓶颈在哪一段，而不是笼统提速。

吞吐和延迟矛盾吗？

常存在权衡。批处理能提高吞吐但可能增加单请求延迟；交互场景保延迟，离线场景保吞吐，按业务目标取舍。

怎么降低首词元延迟？

缩短输入上下文、启用提示缓存、选择更小或更快的模型、就近部署减少网络时间；这些往往比换硬件更立竿见影。

相关工具

相关内容