吞吐和延迟为什么互相牵制？过程拆开看

大模型服务有两个常被一起报的指标：吞吐看单位时间处理多少请求，延迟看单个请求等多久。两者天生互相牵制，想把两头同时拉满，先要看懂牵制发生在哪，才知道该往哪使劲。

吞吐怎么算出来的

吞吐的分母是时间、分子是完成量：一小时答完多少条、产出多少标记。它反映的是整条产线的产能，靠批处理抬高：一批算十条和一批算一条，设备成本几乎一样，摊到每条的账就差出一个量级。进来的是成批请求，发生的是并行计算，出去的是摊薄后的产能账。

产能账还有个口径要留意：按请求数和按产出标记数算出的吞吐差别很大，比较吞吐先问口径，混着比会得出错误结论。

吞吐的统计窗口也有讲究：窗口太短被尖峰带偏，太长掩盖波动，分钟级窗口是常见的折中。看趋势还要看分布，平均延迟低不等于没有慢请求，两个口径一起上才看清全貌。

排队是怎么拖慢单个请求的

牵制的第一站是排队：批攒得越大，凑批窗口越长，头部请求等待越久；批正在算的时候，后来的请求只能等下一轮。吞吐靠攒批涨上去，延迟就在同一时刻被攒批拖下来。

第二站是摊薄：批成员互相分算力，批越大每个成员单步越慢，首字延迟和吐字速度双双下降。牵制在内部还有一层：批内成员的长度参差会让部分算力空转，填充率上不去，吞吐也到不了理论值。用户体感到的高峰变卡，多数是这几层叠加的结果。你在纳米AI、WPS AI里感受得到高峰时段回答节奏的变化，源头常在这里。摊薄之外还有干扰：批内有一条请求异常拖长，整批都要等它，长尾请求是批处理的天敌，截断和分段生成都是为治它准备的。长尾的治法还有一刀切：超过设定时长的成员移出本批单独处理，牺牲个别请求的吞吐，保住整批的节奏。

牵制分几层、每层各拖哪一头，对着看更清楚。

两头的松紧怎么调

调节靠分层：对延迟敏感的对话请求走小批快通道，批小轮转快；对延迟宽容的批量任务走大批慢通道，攒满再算。两条道各取所需，牵制被产品策略拆开。分道之外还有分时：白天保对话延迟，深夜跑批量任务，同样的机器一天干两份活。

再往上是容量层：扩容同时抬两头，但成本跟着涨，限流与降级是容量到顶后的止损手段。你在文心一言、豆包里看到的限速提示，本质是服务在吞吐和延迟之间做的取舍外化。分道的判据要自动化：按请求标记路由，人工分道很快就乱，标记在接入层打好，调度层只认标签不猜意图。两头的目标值也要写成数字：吞吐低于多少告警、延迟高于多少告警，没有数字的目标等于没有目标。观察调参的效果要用分位数：P50 延迟降了不代表 P95 降了，体感取决于尾部，优化要对准分位数来看。

• 速查：吞吐靠攒批摊薄成本；攒批同时拖慢排队与单步；填充率是隐形上限；敏感请求小批快走；宽容任务大批慢算。

牵制的两头各有对应机制：一次请求的显存峰值出现在哪？内部门道在这划出容量硬顶，保首字还是保整段？两种服务策略是延迟侧的体感取舍，流式输出的顺序是怎么保证的？分片组装保证快的同时不出错，提示缓存的失效是怎么发生的？关键步骤一次讲清则从省算力一头给两头松绑。

关于吞吐和延迟的三个常问问题

• 两个指标能同时变好吗？：加容量可以，不加容量就要靠分道调度把矛盾拆开。
• 为什么半夜明显更快？：并发低、排队短、批也小，延迟自然占优，半夜跑批的任务也可以挪到这个时段。
• 吐字变慢是网络问题吗？：多数是服务端摊薄或排队，换网络环境不变就基本可以确认。