前言在大模型项目中我们经常需要和模型服务商、基础设施团队或者业务方讨论下面这些问题模型接口需要申请多少 QPSTPM 配置 100 万够不够并发设置成 32 还是 64为什么 GPU 利用率很高用户还是觉得慢为什么提高并发后吞吐没有明显增加首字延迟却变得很高一个 RAG、Agent、文档解析平台到底应该如何估算模型容量这些问题看起来涉及很多独立指标但它们其实都在描述同一件事一批大模型请求进入系统后系统需要用多少时间、多少计算资源和多少显存才能完成这些请求。要真正理解 QPS、TPM、并发、TTFT、TPOT 和 Token 吞吐不能从术语本身出发而应该先观察一条请求在推理服务中的完整生命周期。一、一条大模型请求在系统中经历了什么假设用户向一个企业知识库助手提问请根据公司制度和历史案例分析这个项目可能存在的风险并给出改进建议。业务服务在调用模型之前可能会组装出一段很长的输入系统提示词1,500 Token Agent 规则和工具说明2,000 Token 历史对话3,000 Token RAG 检索结果8,000 Token 用户当前问题200 Token 总输入长度14,700 Token模型最终生成了一段 1,000 Token 的回答。从业务接口发出请求到回答全部生成完成通常需要经历以下过程请求到达网关 ↓ 鉴权与限流 ↓ 进入推理服务等待队列 ↓ 输入文本 Tokenize ↓ Prefill处理全部输入 Token ↓ 生成第一个输出 Token ↓ Decode逐个生成后续 Token ↓ 输出结束这条链路中存在两个非常关键的推理阶段Prefill 和 Decode。Prefill 是模型理解输入的过程。模型需要一次性读取系统提示词、历史消息、RAG 上下文和用户问题并为这些输入 Token 生成中间计算结果和 KV Cache。输入越长Prefill 的工作量通常越大用户等待第一个字的时间也越长。Decode 是模型生成回答的过程。大模型是自回归模型它不能一次直接生成完整回答而是一个 Token 接着一个 Token 地生成第 1 个 Token 第 2 个 Token 第 3 个 Token …… 第 1000 个 TokenPrefill 决定用户需要等多久才能看到模型开始回答Decode 决定回答开始后输出得是否流畅。因此大模型所谓的“响应速度”实际上至少包含三部分排队时间 Prefill 时间 Decode 时间后面所有性能指标基本都可以放回这条链路中理解。二、QPS、RPM 和 TPM 描述的是进入系统的业务压力1. QPS 描述请求数量但不能代表真实计算量QPS 是 Queries Per Second表示系统平均每秒处理多少个请求。假设一分钟内成功完成了 600 个推理请求那么平均 QPS 是600 ÷ 60 10 QPSRPM 是 Requests Per Minute也就是每分钟请求数。600 RPM 平均约等于 10 QPS。在普通业务接口中QPS 是一个非常重要的指标。查询一个用户和查询另一个用户通常消耗的资源比较接近因此每秒能处理多少次请求可以大致代表系统能力。但在大模型服务中请求之间的差异可能非常大。请求 A 可能只有输入100 Token 输出20 Token请求 B 可能是输入50,000 Token 输出5,000 Token这两个请求在 QPS 统计中都只算一次但请求 B 的计算成本、显存占用和执行时间可能远远超过请求 A。所以在大模型场景中只说“需要 10 QPS”是不完整的。还必须说明10 QPS 对应多长的平均输入 每个请求平均生成多少 Token 请求长度的 P95 是多少同样的 10 QPS可能只是一个很轻的聊天业务也可能足以压垮一套推理集群。2. TPM 用 Token 数描述真实流量TPM 是 Tokens Per Minute表示系统每分钟处理多少 Token。通常需要区分Input TPM每分钟处理的输入 Token Output TPM每分钟生成的输出 Token Total TPM输入和输出 Token 之和假设系统平均每个请求输入 4,000 Token 输出 1,000 Token每分钟有 300 个请求那么Input TPM 4,000 × 300 1,200,000 Output TPM 1,000 × 300 300,000 Total TPM 1,500,000这意味着即使业务请求量只有 300 RPM也需要至少约 150 万的总 TPM 配额。RPM 和 TPM 共同决定了模型接口容量。如果平台提供RPM 上限1,000 TPM 上限1,000,000而每个请求平均消耗 5,000 Token那么 TPM 实际只允许1,000,000 ÷ 5,000 200 RPM虽然名义上的 RPM 是 1,000但真正先触发的是 TPM 限制。反过来如果每个请求只消耗 500 Token那么 1,000 RPM 只需要500 × 1,000 500,000 TPM此时 RPM 会先成为瓶颈。因此申请模型配额时不能分别拍脑袋填写 QPS、RPM 和 TPM而应该从业务请求长度反推TPM ≈ RPM × 每个请求平均 Token 数更严谨一些还应分别计算 Input TPM 和 Output TPM因为输入和输出在推理系统中消耗的资源特征并不相同。三、并发描述系统中同时存在多少请求QPS 描述的是单位时间完成多少请求而并发描述的是某个时刻同时有多少请求处于系统中。假设某一时刻20 个请求正在 GPU 上执行 30 个请求正在等待队列中排队那么可以分别描述为运行并发20 等待请求30 系统内请求总数50并发与 QPS 并不是同一个概念。一家餐厅当前有 100 位客人描述的是并发餐厅每分钟完成多少桌服务描述的是吞吐。大模型服务也是一样。系统中同时存在很多请求不代表这些请求处理得快。它们可能只是在等待。在稳定状态下并发、QPS 和平均响应时间之间可以使用一个非常实用的近似关系平均并发 ≈ QPS × 平均响应时间假设系统稳定处理 5 QPS每个请求从进入到结束平均需要 12 秒那么平均并发大约是5 × 12 60也就是说为了稳定支撑 5 QPS系统中平均会同时存在约 60 个请求。这个公式解释了为什么大模型服务的并发通常明显高于 QPS。因为大模型请求不是几十毫秒就结束而是可能持续数秒甚至数分钟。同样它也说明了一个很重要的事实提高并发上限并不等于提高系统处理能力。如果 GPU 已经饱和把最大并发从 64 调到 128并不会让 GPU 计算能力翻倍只会允许更多请求进入等待队列。最终可能出现完成 QPS 基本不变 等待队列越来越长 TTFT 持续升高 超时请求越来越多因此并发配置本质上是一个容量和保护参数而不是越高越好的性能参数。四、TTFT、TPOT 和总延迟描述用户到底感觉快不快1. TTFT 决定用户多久看到第一个字TTFT 是 Time To First Token即从请求发出到用户收到第一个输出 Token 的时间。例如用户在 10:00:00 发出请求10:00:02 收到模型输出的第一个字那么TTFT 2 秒TTFT 通常包含网络与网关时间 请求排队时间 Tokenize 时间 Prefill 时间 生成并传输第一个 Token 的时间输入上下文越长Prefill 越重并发越高排队时间可能越长因此 TTFT 也会随之上升。对于聊天和 Agent 产品TTFT 是非常重要的用户体验指标。用户点击发送后如果 300 毫秒就开始看到输出通常会觉得系统反应很快如果等待 8 秒还没有任何内容即使后续输出速度很快用户也容易认为系统卡住了。这也是为什么有些系统的总生成时间不短但用户体验仍然不错——它们能很快返回第一个 Token然后持续流式输出。2. TPOT 决定回答开始后输出是否流畅TPOT 是 Time Per Output Token即生成一个输出 Token 平均需要多少时间。假设 TPOT 是 20 毫秒那么单请求的平均输出速度约为1 ÷ 0.02 50 Token/s也可以使用Token/s ≈ 1000 ÷ TPOT(ms)如果 TPOT 为 50 毫秒那么输出速度约为 20 Token/s。用户可能不会直接感受到“20 毫秒”这样的数字但会明显感受到文字是一段段快速出现还是断断续续地蹦出来。TTFT 和 TPOT 分别描述了两种不同的慢TTFT 高 很久没有开始回答 TPOT 高 已经开始回答但输出很慢这两种情况背后的原因也不同。如果 TTFT 很高但 TPOT 正常通常说明请求在排队或者 Prefill 很慢例如输入上下文过长。如果 TTFT 正常但 TPOT 很高通常说明 Decode 阶段压力较大可能是同时生成的序列太多、显存带宽不足或者多卡通信开销较高。3. 端到端延迟是完整回答需要多久端到端延迟也可以称为 E2E Latency表示从发出请求到完整回答生成结束所花费的时间。对于流式生成可以使用一个简化公式估算总延迟 ≈ TTFT 输出 Token 数 - 1× TPOT例如TTFT1 秒 输出长度501 Token TPOT20 毫秒那么总延迟大约是1 500 × 0.02 11 秒这三个指标共同描述用户体验指标用户感受TTFT点击发送后多久开始回答TPOT回答开始后文字输出是否流畅E2E Latency完整任务什么时候结束普通聊天通常更关注 TTFT 和 TPOT长文生成、文档解析和 Agent 任务则还需要重点关注 E2E Latency。五、系统吞吐和单个用户的输出速度不是一回事假设一个请求的输出速度是 40 Token/s这只是单个用户看到的生成速度。如果系统同时为 100 个请求生成 Token那么整个服务的输出吞吐可能达到100 × 40 4,000 Token/s这里需要区分两个指标Per-user Token/s 单个请求的生成速度 Output Token Throughput 整套服务每秒生成的总 Token 数提高并发后系统总 Token 吞吐通常会上升因为 GPU 可以在一次计算中同时处理更多请求。但单个请求的生成速度可能下降因为所有请求在竞争同一套计算和显存资源。系统性能通常会随着并发增加经历三个阶段。第一阶段GPU 尚未被充分利用。增加并发可以让 Batch 更充实系统总吞吐明显提高TTFT 和 TPOT 变化不大。第二阶段系统接近饱和。吞吐仍然增长但增速开始下降TTFT 和 TPOT逐渐升高。第三阶段系统已经过载。继续增加并发后总吞吐几乎不再增长但等待队列和 TTFT 快速上升。可以把它理解为并发较低 GPU 没吃饱 并发适中 GPU 利用充分吞吐较高 并发过高 GPU 已经吃不下新请求只能排队容量测试真正要找到的不是服务能够接受多少并发连接而是在满足 TTFT、TPOT 和错误率要求的前提下能够稳定维持的最大请求速率。六、连续批处理为什么能提高大模型吞吐大模型请求的输入长度和输出长度都不相同。假设有三个请求请求 A生成 20 Token 请求 B生成 200 Token 请求 C生成 2,000 Token如果使用传统固定批处理三个请求组成一个 Batch 后短请求即使已经完成也可能因为长请求仍未结束而无法有效释放位置。现代推理框架通常使用连续批处理。某个请求完成后可以立即从 Batch 中移除再把新的等待请求加入进来请求 A 完成 ↓ 释放它占用的位置 ↓ 请求 D 立即加入当前推理过程这样可以让 GPU 持续保持较高利用率提高系统总吞吐。但 Batch 也存在吞吐与延迟的权衡。Batch 越大一次 GPU 计算处理的 Token 越多整体吞吐往往越高但请求可能需要等待调度单个用户的 TTFT 和 TPOT 可能变差。因此在线聊天 更重视低 TTFT、稳定 TPOT 离线批量生成 更重视总 Token 吞吐和 GPU 利用率这两种业务不应该直接使用完全相同的调度参数和性能目标。七、KV Cache 为什么决定长上下文和并发能力大模型每生成一个新 Token都需要关注之前的上下文。如果每次生成 Token 时都重新计算全部历史内容性能会非常差。因此推理服务会保存历史 Token 对应的 Attention Key 和 Value这部分显存就是 KV Cache。KV Cache 的占用与以下因素相关并发请求数 每个请求的上下文长度 模型层数 KV Head 数量 数据精度可以用一个简化关系理解KV Cache 占用 ∝ 并发数 × 每请求 Token 数假设一套服务的 KV Cache 最多可以容纳 100 万个 Token。如果每个请求平均占用 10,000 Token理论上可以同时容纳大约 100 个请求。如果每个请求平均占用 100,000 Token那么理论上只能容纳大约 10 个请求。因此模型支持 128K 或 1M 上下文不代表在最大上下文下仍然可以保持高并发。这也是长上下文业务经常出现并发能力明显下降的原因。当 KV Cache 使用率接近上限时新请求可能无法立即进入运行状态只能进入等待队列进而导致 TTFT 上升。严重时还可能发生 Cache 换出、请求抢占甚至显存不足。所以线上监控不能只看 GPU Utilization还需要同时看KV Cache 使用率 运行请求数 等待请求数 平均上下文长度 Cache 命中率八、GPU 利用率高不代表服务一定健康很多团队判断推理服务性能时首先看 GPU 利用率。GPU 利用率当然重要但它只能说明 GPU 在忙不能说明 GPU 忙得是否高效也不能说明用户体验是否良好。例如 GPU 利用率长期是 100%可能存在两种完全不同的情况。第一种情况系统处于高效状态GPU 利用率高 Token 吞吐高 TTFT 稳定 TPOT 稳定 队列较短第二种情况系统已经过载GPU 利用率高 Token 吞吐没有继续增长 等待队列持续增加 TTFT P99 非常高 超时和取消请求增多两种情况下 GPU 都是 100%但前者是高效利用后者是拥塞。因此GPU 指标必须与业务性能指标放在一起看GPU 利用率 输入和输出 Token 吞吐 TTFT TPOT 等待队列 KV Cache 使用率只有这些指标同时健康才能说明推理服务运行良好。九、为什么性能报告必须看 P50、P95 和 P99只看平均值很容易掩盖真实问题。假设 100 个请求中99 个请求 TTFT 为 1 秒 1 个请求 TTFT 为 101 秒平均 TTFT 是(99 × 1 101) ÷ 100 2 秒从平均值看系统似乎只需要等待 2 秒。但实际上有一个用户等了 101 秒。因此生产系统通常使用分位数描述用户体验P50 一半请求低于该数值代表典型用户体验 P95 95% 的请求低于该数值代表大部分用户体验 P99 99% 的请求低于该数值代表尾部用户体验例如TTFT P50500ms TTFT P952s TTFT P9912s说明典型请求很快但仍有约 1% 的请求等待非常久。大模型服务容易出现尾延迟因为请求长度和生成长度差异很大。少量超长上下文、超长输出或者 Cache 换出都可能显著拉高 P99。因此一个生产级服务至少应该关注TTFT P50 / P95 / P99 TPOT P50 / P95 / P99 E2E Latency P50 / P95 / P99 Queue Time P50 / P95 / P99十、如何从业务流量反推并发、TPM 和模型配额下面通过一个完整例子把这些指标连接起来。假设某个 Agent 平台预计有以下负载平均请求速率4 QPS 平均输入长度6,000 Token 平均输出长度1,000 Token 平均端到端时长15 秒首先计算 RPM4 × 60 240 RPM然后计算 Input TPM6,000 × 240 1,440,000Output TPM1,000 × 240 240,000Total TPM1,440,000 240,000 1,680,000接着估算平均并发并发 ≈ QPS × 平均响应时间 ≈ 4 × 15 ≈ 60这意味着如果业务稳定运行在 4 QPS系统平均会同时存在约 60 个请求。但生产配置不能只按照平均值申请。还需要考虑流量波动、长请求比例、失败重试和多个业务共享模型等情况。例如增加 50% 的容量余量目标 QPS6 目标并发90 目标 Total TPM约 252 万如果 RAG、Agent、文档解析增强和普通聊天共用同一模型还要分别估算每种业务的请求特征。业务请求量输入特点输出特点普通聊天高输入较短输出中等RAG 问答中高Context 较长输出中等Agent中多轮调用、多次模型请求输出和耗时不稳定文档解析增强低到中单次输入可能很长结构化输出批量任务波动大可削峰通常不要求低 TTFT最终配额应该按共享资源池汇总而不是只计算某一个 RAG 接口。十一、性能测试应该如何设计大模型性能测试不能只写并发 32QPS 8测试成功。这样的结果缺少输入和输出条件几乎无法比较。一次有效的性能测试至少需要固定或记录以下信息模型名称和精度 GPU 型号和数量 推理框架 输入 Token 分布 输出 Token 分布 并发或请求到达速率 测试持续时间然后重点观察四类结果。第一类是请求流量成功 QPS 失败 QPS Input TPM Output TPM第二类是用户体验TTFT P50 / P95 / P99 TPOT P50 / P95 / P99 E2E Latency P50 / P95 / P99第三类是调度状态运行请求数 等待请求数 队列等待时间 平均 Batch Token 数第四类是硬件资源GPU 利用率 GPU 显存 KV Cache 使用率 CPU 和内存 网络和多卡通信测试时应该逐级增加负载例如并发 1 并发 4 并发 8 并发 16 并发 32 并发 64 并发 96观察每个阶段的总吞吐和延迟变化。当出现以下现象时通常意味着已经接近或超过稳定容量总 Token 吞吐几乎不再增加 TTFT P95 快速上升 等待队列持续增长 错误率或超时率增加 KV Cache 长期接近上限最终选定的生产并发不应该是系统不崩溃的最高并发而应该是满足业务 SLO 的最高并发。十二、如何为线上服务定义合理的 SLO一个完整的 SLO 不应该只规定 QPS。例如可以定义在输入 Token P95 不超过 12,000、 输出 Token P95 不超过 1,500、 稳定负载 6 QPS 的情况下 成功率不低于 99.9% TTFT P95 不超过 2 秒 TPOT P95 不超过 40ms E2E Latency P95 不超过 60 秒 Queue Time P95 不超过 500ms这样的目标同时规定了请求有多重 系统要处理多少 用户最多等待多久 服务需要多稳定如果只说“系统支持并发 64”无法判断这个并发是在什么上下文长度、什么生成长度和什么延迟下实现的。同理如果模型服务商告诉你“支持 TPM 200 万”你仍然需要确认是输入 TPM、输出 TPM还是总 TPM是否所有模型共享是否多个 API Key 共享是否允许短时间突发Reasoning Token 是否计入缓存命中的输入是否计入并发限制是否独立存在十三、遇到性能问题时如何定位理解了整条链路后性能问题就可以按照指标组合判断。如果 TTFT 很高但 TPOT 正常通常意味着请求开始前等待太久或者 Prefill 太慢。应重点检查等待队列、输入长度、Prefill 吞吐和 Tokenize 开销。如果 TTFT 正常但 TPOT 很高说明请求能够快速开始但 Decode 过程较慢。应检查 Decode 并发、Batch 规模、显存带宽、KV Cache 和多卡通信。如果 TTFT 和 TPOT 都在恶化同时等待队列不断增长通常表示系统整体过载需要限流、扩容或者拆分业务流量。如果平均指标正常但 P99 很高应重点检查少量超长上下文、超长输出、实例性能不均以及 KV Cache 换出。如果 GPU 利用率不高但等待队列很多则不一定是 GPU 计算不足还可能是 CPU Tokenize、请求调度、网络、预处理或者配置过于保守造成的瓶颈。结语QPS、TPM、并发、TTFT 和 TPOT 并不是一组互相独立的术语。它们共同描述了一条大模型请求从进入系统到生成完成的全过程请求进入 ↓ QPS / RPM / TPM 描述流量 ↓ 进入等待和运行状态 ↓ 并发数与 Queue Time 描述系统压力 ↓ Prefill ↓ TTFT 描述多久开始回答 ↓ Decode ↓ TPOT 描述回答输出速度 ↓ 请求完成 ↓ E2E Latency 描述完整耗时与此同时Token Throughput 描述整套系统单位时间完成多少计算 KV Cache 决定长上下文和并发容量 GPU 指标 描述硬件资源状态 P95 和 P99 描述大部分用户与尾部用户的真实体验因此在评估一个大模型推理服务时最准确的问题不是这个模型支持多少 QPS而应该是在指定的输入长度、输出长度、并发规模和延迟目标下这套服务能够稳定提供多少请求吞吐和 Token 吞吐一个完整的容量结论至少应该同时包含模型与硬件配置 输入和输出 Token 分布 稳定 QPS Input / Output TPM 稳定并发 TTFT P95 TPOT P95 E2E Latency P95 KV Cache 使用率 错误率只有把请求规模、Token 规模、用户延迟和硬件容量放在同一套体系中大模型推理指标才真正具有指导架构设计、资源申请和生产扩容的价值。