首字时间和吞吐有什么区别？选型不再纠结

挑 AI 推理服务时，首字时间和吞吐是两个最容易混的指标，一个管「第一句话多久来」，一个管「后面出得多快」，混着看很容易选错。

可以把它想成餐厅上菜：首字时间是从点单到第一道菜上桌的等待，吞吐是厨房每小时能出多少道菜。这个类比的失效之处在于，餐厅出菜受厨师手工限制，模型的「出菜」是逐 token 生成，可以被批处理成倍优化。带走一个判断：两个指标经常此消彼长，选型本质是在替你的场景选取舍。

先说结论：交互看首字，批量看吞吐

做对话产品、智能客服这类用户在线等待的场景，首字时间是命门，超过两三秒用户就开始烦躁；做离线批量生成、夜间跑任务的，吞吐才是关键，整体完成时间短才是硬道理。先对号入座，再比较服务商的数字，才不会被带偏。混合场景也有解法：白天接交互、夜里跑批量的业务，可以给两条线分别设预算，白天守住首字上限，夜里放开并发冲吞吐，互不拖累。

维度一：衡量的是什么

首字时间计的是从发出请求到收到第一个 token 的时长，主要反映排队和预填充的开销；吞吐计的是单位时间内产出的 token 总量，可能按单请求计，也可能按整个实例计，口径要先看清。两者口径不同、单位不同，直接拿数字比大小没有意义，先对齐口径再谈高低。

维度二：受什么影响

首字时间受排队长度、输入长度和调度策略影响，高峰期波动明显，实例健康度的起伏也会传导过来，见推理服务的健康检查是怎么做的？；吞吐主要受并发度和解码效率影响，批处理做得好，吞吐能成倍上去。两阶段的耗时归属不同，见预填充和解码差在哪？两阶段的分工。一个粗略的换算习惯：交互场景把首字时间控制在呼吸节奏内，批量场景把吞吐折算成每日可完成的任务数，两个数字都比裸指标好懂，汇报时也更好解释。

实测这两个指标时还有几个要点。测首字时间要用典型输入而非空提示，空请求的首字快得没有参考价值；测吞吐要区分「单请求的出字速度」和「整批的完成速度」，前者看体验，后者看产能，混淆口径是选型对比里最常见的错误。服务端返回的统计数字往往不含网络传输段，客户端实测总会略高，差值稳定即可，不必追求严丝合缝，看趋势比看单点更有用，单次波动不算数。

两个指标会不会互相拖累

会。为了压首字时间，服务可能把请求尽快开跑，结果和后续请求挤在一起，单请求的解码节奏被拖慢、吞吐下滑；反过来追求吞吐，把请求攒成一批再算，每个请求的首字都会变晚。豆包、海螺AI 这类交互产品天然偏向首字优先，批量工具则相反，选型时看产品定位比自己调参更省事。流式与否也会改变体感，见流式和非流式有什么区别？分界点在哪；思考模式的开启同样拉长首字等待，见思考模型和直接回答有什么区别？。

指标选择速查：

• 在线对话：优先首字时间
• 批量任务：优先吞吐
• 混合场景：设首字上限，余量给吞吐

指标对准场景，数字才有意义。

关于首字时间和吞吐，再多问三句

• 两个指标能同时做到最优吗？：很难，调度策略上此消彼长，工程上通常按场景定取舍。
• 官方公布的数字能直接信吗？：要区分测试口径和自己的真实输入，拿自己的典型请求实测更可靠。
• 高峰期哪个指标先崩？：多数是首字时间先变长，排队最先反映在这里。

记住一句话：你要挑的是对你场景最合适的节奏。