AI大模型推理侧性能度量:关键指标、优化逻辑与平衡策略

众所周知，AI大模型在推理阶段的性能表现，已成为决定智能服务商业价值的核心命脉。

与传统Web服务“请求—响应”的闭环模式不同，大模型的推理过程具有流式、自回归的典型特征。这意味着，评估推理引擎或API服务的优劣，不能仅依赖传统的QPS（每秒查询数），还必须衡量Token在推理过程中的生成速度、并发承载能力和资源利用水平。这些指标直接关系到用户侧的响应体验，以及系统在规模化交付下的整体效能。

本文旨在系统梳理大模型推理性能评估中的四个关键指标：TTFT、TPS、TPM与RPM，并分析其各自的测量意义与优化逻辑。

01首字响应时延：用户体验的第一印象

TTFT（TimeToFirstToken）指从客户端发出完整请求，到接收到模型生成的首个Token所经历的时间。通俗而言，即用户提交请求后，直至屏幕出现第一个字符所感知的等待时长。

该指标是衡量大模型服务初始响应速度的决定性维度。在对话交互场景中，若用户发送Prompt后长时间无返回内容，极易产生“系统卡顿”或“网络异常”的负面体验。TTFT主要反映模型推理中Prefill（预填充）阶段的耗时，包括网络传输、请求排队、Prompt编码及首个Token解码等环节。

业内通常要求中等长度文本的TTFT控制在2秒以内。当处理较长Prompt（如长文档摘要）时，TTFT会显著增加。为此，推理引擎普遍采用FlashAttention、KVCache初始化优化等策略，以加速Prefill阶段，从而确保用户在第一时间获得“系统已响应”的明确反馈。

02Token生成速率：内容输出的流畅度

TPS（TokensPerSecond）指模型在Decode（解码）阶段每秒生成的Token数量，直接反映文本生成效率与模型计算吞吐能力。

如果说TTFT决定用户“等待多久开始看到内容”，则TPS决定用户“观看内容时的流畅程度”。行业实践表明，当生成速度低于20Token/s（约每秒6至8个汉字）时，用户容易感知到明显的卡顿与断续感；而优质推理服务的TPS通常可达40Token/s以上，此时阅读体验较为平滑。

TPS受模型参数量、硬件算力、显存带宽及KVCache管理效率等多重因素影响。在长文本生成任务中，TPS直接决定任务的最终完成时长。通过引入动态批处理、张量并行或模型量化等手段，可在保障生成质量的前提下，最大化单请求的生成效率。

03每分钟Token处理量：系统吞吐的硬实力

TPM（TokensPerMinute）指系统在一分钟内成功处理的Token总数，是衡量大模型服务整体处理能力与资源利用水平的宏观指标。

与TPS侧重于单请求生成流畅度不同，TPM更多反映“集群总产能”。在商业API服务中，TPM常被用作限流策略与计费定价的基准之一。具备高TPM的系统，意味着在单位时间内可承载更多业务数据，有助于支撑大规模并发请求并降低单次推理的边际成本。

提升TPM的核心在于充分压榨GPU算力。通过合理的并发调度、显存高效复用，以及PD（Prefill-Decode）分离架构等方案，系统可在不显著增加单请求延迟的情况下，显著提升整体Token吞吐量。

04每分钟请求数：并发承载的调度阀

RPM（RequestsPerMinute）指系统每分钟成功处理的请求数量，衡量推理服务的并发承载能力与任务调度效率。

在实际生产环境中，RPM、TPM与并发数（Concurrency）构成动态博弈的资源池。若用户请求普遍较短，系统可能率先触及RPM瓶颈；若请求较长，则可能先耗尽TPM配额。RPM的高低，直接反映推理引擎在请求排队、资源分配与上下文切换等方面的调度能力。

值得注意的是，高RPM并不等同于可无限制接收请求。优秀的调度系统需在RPM、TPM与并发数之间取得平衡，避免因资源过载而导致TTFT与TPS显著劣化。压测实践中，通常采用阶梯式加压策略，以探明系统在保持服务质量前提下的RPM上限。

在大模型推理性能评估中，TTFT、TPS、TPM与RPM并非彼此孤立，而是相互制约、动态平衡的有机整体。片面追求极致的TPS，可能因过度批处理而牺牲TTFT；盲目拉高RPM，则可能导致显存溢出，进而引发TPM下降。

真正成熟的Token生产效率体系，不在于某项指标的极端优化，而应依据具体业务场景（如实时对话、离线报告生成、高并发搜索等），在生成速度、并发承载与资源成本之间寻求最佳平衡点。唯有深刻理解并灵活运用这四大指标，企业（如MaaS厂商、Token工厂等）方能有效驾驭大模型算力，构建既具用户体验优势、又具备商业可持续性的智能服务体系。

*本文分析仅基于公开信息与行业观察，不构成任何投资或采购建议，仅供参考。

▼点击关注我们▼

▼点击“阅读原文”跳转官网