大模型响应效率如何衡量？艾体宝 TrueFoundry 的推理性能与网关延迟解析

大模型应用在单次测试中响应流畅，并发增加后却出现首字等待变长、输出断续，背后涉及推理计算与请求调度的不同瓶颈。仅看一次回答的总耗时，很难定位问题。本文从 LLM 推理的两个阶段入手，说明 TTFT、吞吐量与网关延迟各自衡量什么，以及如何用这些指标指导性能优化。

一、理解 LLM 推理的两阶段机制

自回归 Transformer 模型的推理分为 Prefill 和 Decode 两个阶段。Prefill 并行处理输入序列，建立生成文本所需的 KV Cache。长文档和较长的对话历史增加了输入计算量，计算资源利用率是这一阶段的调优重点。前缀缓存通过复用已有计算结果，减少重复输入的处理开销。

Decode 利用已有上下文逐步生成新的 Token，每一步都需要访问模型权重和缓存数据。小批量生成时，显存带宽是重要约束。增大批次能够提高权重读取的复用程度，同时也增加 KV Cache 的容量和带宽需求。

二、用 TTFT 与 ITL 衡量响应速度

TTFT（Time to First Token）记录从请求发出到收到首个输出 Token 的时间。以客户端为测量位置时，它包括网络传输、网关处理、上游排队，以及模型生成首个 Token 所需的计算。TTFT 对交互式应用尤其重要，直接影响用户开始阅读答案前的等待时间。

输入长度增加时，重点检查 Prefill 耗时与前缀缓存命中率。输入长度稳定、高并发下 TTFT 上升时，重点检查排队时间与资源竞争。客服短问答按交互等待要求设定时延目标，长文档分析则结合文档规模和任务完成时间制定目标。
ITL（Inter-Token Latency，Token 间延迟）反映持续生成阶段的输出节奏。较低且稳定的 ITL 对应连贯的流式输出。在输出速度相同的条件下，回答越长，生成耗时越多。TTFT 与 ITL 分别衡量这两个阶段。

三、区分单请求速度与系统吞吐量

吞吐量衡量单位时间内完成的工作量。Requests/s 统计请求完成量，Output tokens/s 统计输出 Token 总量。推理服务的对比测试应统一输入、输出长度和并发条件，按相同工作负载比较结果。单请求输出速度决定一次回答的生成时间，系统总吞吐量用于评估整体承载能力。以 20 个请求并发输出为例，每个请求保持 50 tokens/s 时，系统总输出吞吐量为 1,000 tokens/s。

连续批处理（Continuous Batching）在请求完成后释放批次中的位置，并纳入新请求，提高推理资源利用率。并发增长也会增加 KV Cache 占用和调度压力。服务进入饱和区间后，继续增加请求会拉长队列，推高尾部延迟。生产容量应以满足时延要求的成功请求量为依据。

在 GPU 配置和单位时间资源费用固定的条件下，提高有效输出吞吐量能够降低单位 Token 的计算成本。采购与运维预算还包括预留容量和高可用冗余，应按完整资源配置核算。

四、拆分网关开销与模型耗时

网关记录的一次请求耗时，包含等待模型响应的时间。即使日志显示调用耗时 5 秒，也不能将这 5 秒全部归为网关开销。认证、限流和路由属于网关处理；上游排队与推理属于模型服务耗时。通过链路追踪分别记录这些阶段，才能判断优化应落在哪一层。依赖外部服务的内容审核，也应单独计时。

流式接口还需要关注响应转发。模型已经生成内容，客户端仍需等到数据经过网关才能看到输出。网关或反向代理开启响应缓冲时，数据会积累后集中发送，造成首字等待延长、文本成批出现。因此，模型侧的生成速度不能直接代表用户端的输出体验，客户端观测到的 TTFT 还包含转发与传输时间。

测量网关引入的额外延迟，可以使用输出节奏固定的模拟上游，对比直连与经过网关的表现。测试应保持负载、连接复用和缓存条件一致，并记录启用的策略。两条路径的延迟差包含新增网络路径的影响，需要结合链路追踪定位内部开销。接入真实模型复测时，同时观察 TTFT 的 P95、P99 和成功吞吐量，确认并发增加后服务仍满足时延要求。

五、针对瓶颈选择优化方法

重复使用长系统提示词或相同文档前缀的请求，适合启用前缀缓存。命中缓存后，模型直接复用对应的 KV Cache，跳过匹配部分的 Prefill 计算，再处理剩余输入并生成回答。

Chunked Prefill 用于协调长输入处理与正在进行的生成任务。它将较大的 Prefill 任务拆分成小块，与 Decode 请求共同调度。在 vLLM 中，较小的批次 Token 预算优先改善 ITL，较大的预算为 Prefill 提供更多处理空间。参数选择应依据业务样本的压测结果。

网关层的优化集中在请求处理和端点选择。多端点应用通过路由策略分配流量，通过回退机制处理符合条件的失败。一次请求包含多次上游尝试时，端到端耗时应覆盖全部尝试和切换过程。

六、艾体宝Truefoundry 如何帮助企业打通“压测-路由-观测”全链路？

在实际工程落地中，从压测定位性能瓶颈，到线上环境的动态调度，自研这套基础设施往往成本高昂。艾体宝Truefoundry 将基准压测与运行时观测无缝集成，提供了开箱即用的解决方案：

贴合真实业务的 LLM Benchmarking（基准压测）

全参数模拟：支持配置峰值并发、阶梯式用户启动速率（Ramp-up Rate）、指定输入输出 Token 范围。

多维指标可视化：自动输出 TTFT、ITL、P50/P95/P99 延迟及 Token 吞吐量，帮团队快速定位集群容量临界点。

全链路 Request Tracing（请求追踪）

在生产运行时，艾体宝Truefoundry 自动捕获每一个请求的总耗时、网关耗时、平均 Token 间延迟及首字时间，让高并发下的性能抖动和异常排队无所遁形。

基于性能观测的 Virtual Model（虚拟模型路由）

在多模型端点或混合云场景下，艾体宝Truefoundry 的虚拟模型功能支持基于延迟阈值与优先级的动态路由：

可以设置当首选端点的 TTFT 或排队指标超过预设 SLA 阈值时，自动将流量平滑切至备用端点。

路由策略结合了真实业务分布与近期的观测数据，有效避免因偶发长文本请求导致的误切换，在保障用户体验的同时打顺了成本与性能的平衡。