首字延迟(TTFB)与吞吐:大模型 API 的延迟优化怎么权衡

大模型 API 的“响应速度”,其实是三个不同的指标

很多团队评估大模型 API 时只看一个笼统的“响应速度”,但这个说法背后其实包含三个不同的指标:首字延迟、生成速率、总耗时。三者受的影响因素不同,对用户体验的意义也不同,分不清楚就容易把优化精力用错地方。

首字延迟、生成速率、总耗时分别衡量什么?

不论调用的是 Claude API、GPT API 还是其他厂商的模型,底层的服务过程都大致遵循“先处理完整输入,再逐个吐出 token”这套框架,所以下面这三个指标具有通用性,不是某一家模型独有的概念。

首字延迟(TTFB)具体指的是哪一段等待时间?

首字延迟(Time To First Byte,TTFB)指从客户端发出请求,到接收到模型返回的第一个输出 token 之间经过的时间。这段时间里包含网络往返、服务端排队,以及对整段输入 prompt 做前向计算(prefill)的耗时,但不包含后续逐个 token 吐出的生成过程。

从用户视角看,首字延迟就是“提交问题之后,要等多久才能看到第一个字出现”。它跟网络状况、服务端排队策略都有关系,但开发者能主动影响的部分主要在输入侧,也就是后面会讲到的 prompt 长度和缓存命中。

生成速率衡量的是什么,为什么和首字延迟是两回事?

生成速率(有时也叫 decode 速度)衡量的是模型开始吐字之后,平均每秒能输出多少个 token,单位通常是 tokens/s。它反映的是“已经开始回答之后,后面的字来得快不快”,跟“要等多久才开始回答”是两个维度——首字延迟慢的请求,生成速率不一定慢,反过来也一样。

从底层机制看,首字返回之前的计算(prefill)通常是算力密集型,输入越长,这部分计算量越大;首字之后的逐 token 生成(decode)则更多受显存带宽和并发负载影响,跟输入 prompt 长度本身的关系相对较小,但会随着服务端同时处理的请求数变化而波动。

总耗时和前两个指标是什么计算关系?

一次完整请求的总耗时,大致等于首字延迟加上生成阶段的耗时,而生成阶段的耗时又约等于输出 token 数除以生成速率。输出内容越长,生成速率对总耗时的影响权重越大;输出内容越短,首字延迟在总耗时里占的比例就越高。

这也是为什么同一句“响应快不快”的评价,套在不同任务上会得出不同结论——短问答场景里首字延迟几乎决定了整体体验,长文本生成场景里生成速率的权重会明显上升。

为什么同一个应用不能只用一套延迟指标做优化目标?

把首字延迟、生成速率、总耗时区分开之后,下一个问题是:同一个团队做的不同产品形态,该把优化精力放在哪个指标上,答案并不统一。

交互式对话产品为什么对首字延迟格外敏感?

在聊天助手、客服问答这类交互式产品里,用户提交问题后是真人在实时等待,首字延迟直接决定了“是不是感觉在正常工作”的第一印象——哪怕后续生成速率完全正常,首字迟迟不出现也会让用户怀疑请求卡住或失败了。

这也是为什么很多产品即使无法缩短模型本身的计算时间,也会优先通过流式输出让首字尽快呈现,把用户的注意力从“枯等”转移到“阅读正在生成的内容”上(流式输出优化的是哪种延迟,后面会具体展开)。

批处理或离线任务为什么更看重整体吞吐,而不是单次首字延迟?

批量处理文档摘要、离线跑评测集这类任务没有真人在实时盯着某一次请求的首字,真正决定任务能不能按时跑完的,是系统在给定时间窗口内能处理的总 token 吞吐量——即使把并发请求数调高导致单次请求的首字延迟略有上升,只要整体吞吐因此提升,对任务整体依然划算。

这类场景更合适的优化方向,是提高并发请求数、合理利用批处理(batching)能力,而不是纠结某一次请求的首字延迟具体是多少。

长文本生成场景里,真正主导体验的是哪个指标?

在生成长篇报告、大段代码这类输出内容本身很长的场景里,首字延迟只占总耗时的一小部分,真正主导总耗时和用户等待体感的是生成速率——哪怕首字延迟压缩得很短,如果生成速率跟不上,用户依然要盯着屏幕等很久才能看到完整结果。

哪些因素会拉长首字延迟?

首字延迟不是一个固定值,同一个模型在不同请求下也会有明显差异,主要受下面几类因素影响:

• 输入 prompt 的长度——系统提示词、历史对话,或者塞进上下文窗口的长文档越长,首字延迟通常越高
• 模型的计算规模——单次前向计算需要的算力越大,处理输入所需的时间通常也越长
• 是否命中缓存——重复出现的固定内容如果命中服务端缓存,可以跳过对应部分的重新计算
• 服务端当前的排队与并发负载——请求到达时后端是否有空闲算力可以立刻处理,会直接体现在首字延迟上

输入 prompt 的长度为什么会直接拉长首字延迟?

首字返回之前,模型需要先对完整的输入 prompt 做一次前向计算(prefill),把输入内容转换成后续生成要用到的中间状态。输入的 token 数越多,这一步要处理的计算量就越大,首字延迟也随之上升——这就是为什么塞入大段系统提示词、长历史对话或长文档上下文的请求,首字通常会更慢。

模型规模跟首字延迟、生成速率分别是什么关系?

模型的参数规模(更准确地说,是单次前向计算实际要激活的计算量)越大,处理同样长度的输入通常需要更多计算时间,这既拉长了首字延迟对应的 prefill 阶段,也会拉低首字之后的生成速率,因为 decode 阶段的每一步同样要做一次前向计算。选择参数规模更大的模型,本质上是在用延迟去换取回答质量,这个权衡需要按任务需求来做判断。

命中缓存为什么能明显缩短首字延迟?

如果这次请求里靠前的一段内容跟之前处理过的完全一致——比如固定不变的 system prompt、反复出现的长文档上下文——服务端在命中缓存时可以直接复用之前算好的中间结果,只需要对新增的那一小段内容重新计算,首字延迟里 prefill 这部分原本的计算开销因此被大幅压缩。这部分机制本专题此前的文章已经展开讲过,这里只强调一点:它对首字延迟的影响,往往比其他单一优化手段都更直接。

开发者能做哪些延迟优化?

知道了影响因素,对应的优化手段其实是顺着这几个因素往回推,核心是分清楚哪种手段影响的是哪种延迟。

精简 system prompt 具体能带来什么收益?

system prompt 里如果堆了大量示例、格式说明或者用不上的背景信息,这些内容每次请求都要被完整地重新处理一遍(除非命中缓存),直接拉长 prefill 阶段的耗时。把 system prompt 精简到任务真正需要的部分,对短输入、高频调用的场景收益尤其明显;如果这段内容本来就能稳定命中缓存,精简带来的边际收益会相应降低,两者需要结合起来看,不是孤立优化。

合理排布可复用内容,能让缓存命中率更高该怎么做?

缓存命中通常要求内容从开头开始逐字符匹配,所以把稳定不变的部分——system prompt、固定的少样本示例、复用的文档上下文——放在 prompt 靠前的位置,把每次都会变化的用户输入放在末尾,能明显提高命中率;如果把易变内容混在稳定内容前面,哪怕只改了一个字,后面本该复用的部分也会跟着失效。

流式输出改善的是感知延迟还是实际延迟?

流式输出把“等完整一段话生成完再显示”变成“从第一个 token 开始就陆续展示”,改善的是用户主观感受到的等待体验,而不是模型本身的计算速度——请求从发起到全部内容生成完毕的总耗时,并不会因为开启流式而缩短,真正决定首字延迟本身的,还是前面提到的输入长度、模型规模和缓存命中这几个因素。

如果调用是通过网关类服务转发的,后端排队和渠道调度同样是首字延迟的一个变量——比如 PioModel 这类支持多模型路由和故障转移的网关,能在某个上游模型渠道拥堵时自动切换到其他可用渠道,减少因排队等待拉长的首字延迟,这算是应用代码之外的另一层优化空间。

分场景选对指标,比笼统追求“更快”更重要

首字延迟、生成速率、总耗时衡量的是请求生命周期里不同阶段,没有哪个能单独代表“响应快”。按场景选对优化目标,再结合缓存排布与流式输出等手段针对性调整,比笼统追求“更快”更有效。