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

大模型应用在单次测试中响应流畅，并发增加后却出现首字等待变长、输出断续，仅看一次回答的总耗时很难定位问题。文章从 LLM 推理的两个阶段入手，说明 TTFT、吞吐量与网关延迟各自衡量什么，以及如何用这些指标指导性能优化。 自回归 Transformer 模型的推理分为 Prefill 和 Decode 两个阶段。Prefill 并行处理输入序列，建立生成文本所需的 KV Cache，长文档和较长对话历史会增加输入计算量，前缀缓存可复用已有计算结果减少重复开销。Decode 利用已有上下文逐步生成新 Token，每一步都需访问模型权重和缓存数据，小批量生成时显存带宽是重要约束，增大批次能提高权重读取复用程度，同时增加 KV Cache 的容量和带宽需求。 TTFT 记录从请求发出到收到首个输出 Token 的时间，以客户端为测量位置时包括网络传输、网关处理、上游排队以及模型生成首个 Token 的计算。ITL 反映持续生成阶段的输出节奏，较低且稳定的 ITL 对应连贯的流式输出。吞吐量方面，Requests/s 统计请求完成量，Output tokens/s 统计输出 Token 总量，对比测试应统一输入、输出长度和并发条件。文章举例：20 个请求并发输出、每个请求保持 50 tokens/s 时，系统总输出吞吐量为 1,000 tokens/s。 网关记录的一次请求耗时包含等待模型响应的时间，日志显示调用耗时 5 秒不能全部归为网关开销，认证、限流和路由属于网关处理，上游排队与推理属于模型服务耗时，需通过链路追踪分别记录。流式接口还需关注响应转发，网关或反向代理开启响应缓冲时数据会积累后集中发送，造成首字等待延长、文本成批出现。测量网关额外延迟可用输出节奏固定的模拟上游，对比直连与经过网关的表现，并保持负载、连接复用和缓存条件一致。 优化方法上，重复使用长系统提示词或相同文档前缀的请求适合启用前缀缓存；Chunked Prefill 将较大的 Prefill 任务拆分成小块与 Decode 请求共同调度，在 vLLM 中较小的批次 Token 预算优先改善 ITL，较大的预算为 Prefill 提供更多处理空间。网关层优化集中在请求处理和端点选择，多端点应用通过路由策略分配流量、通过回退机制处理符合条件的失败。 艾体宝 TrueFoundry 将基准压测与运行时观测集成：LLM Benchmarking 支持配置峰值并发、阶梯式用户启动速率和指定输入输出 Token 范围，自动输出 TTFT、ITL、P50/P95/P99 延迟及 Token 吞吐量；全链路 Request Tracing 在生产运行时捕获每个请求的总耗时、网关耗时、平均 Token 间延迟及首字时间；Virtual Model 虚拟模型路由支持基于延迟阈值与优先级的动态路由，当首选端点的 TTFT 或排队指标超过预设 SLA 阈值时自动将流量切至备用端点。