上述问题的答案，其实全都隐藏在这三个关键指标之中——TTFT（首Token时延）、TPOT（每Token输出时延）、RPM（每分钟请求数）。这组指标堪称衡量大模型推理服务体验、吞吐能力和限流效果的“三件套”，也是腾讯云TokenHub模型监控页面默认呈现的核心数据。

真正看懂并掌握这三个指标的常态表现，相当于为你的业务系统配备了一台能够实时监测健康状况的“体检仪”。

三大指标分别衡量什么

TTFT：首Token时延

定义：从你的API请求发出，到成功接收到模型返回的第一个Token所经历的总耗时。

这个指标直接决定了用户对“模型反应快慢”的主观感知。在流式输出应用（如实时对话）中，TTFT越短，用户就能越快地看到模型开始“打字”；而在批量处理任务场景下，TTFT则反映了服务的冷启动开销与请求队列的处理压力。

影响TTFT的关键因素：

• Prompt长度：输入的上下文越长，预填充计算耗时越多。
• 缓存命中率：如果请求命中了Prompt Cache，TTFT会显著降低。
• 模型规模：参数更多的大模型，其预填充阶段通常需要更长时间。
• 并发压力：当单个推理实例同时承载过多请求时，排队等待时间会拉高TTFT。
• System Prompt稳定性：动态变化或频繁更新的前缀会让缓存失效，增加计算负担。

TPOT：每Token输出时延

定义：在模型生成阶段，每诞生一个新Token所平均花费的时间。

TPOT直观体现了模型的“生成速度”或“打字效率”。在长文本生成、代码补全、深度思考等需要输出大量内容的场景下，TPOT直接影响整体响应耗时——总响应时长 ≈ TTFT + 输出Token数量 × TPOT。

影响TPOT的常见因素：

• 模型架构：例如MoE（混合专家）架构（如Hy3 preview的295B/21B激活参数），通常具有更快的解码速度。
• 输出长度：当输出内容特别长且并发请求多时，KV Cache的压力会增大，从而拖慢TPOT。
• 推理实例负载：当实例资源饱和后，排队效应同样会延后解码阶段的响应。
• 网络回传：跨地域或跨网络调用可能会引入额外的网络抖动。

RPM：每分钟请求数

定义：单位时间（每分钟）内发起的服务请求数量，反映了系统实际处理的吞吐能力。

RPM是判断是否触发限流的关键指标。针对每个模型，TokenHub都预设有相应的限流规则，你可以在模型详情页查看具体配额。当业务流量逼近上限时，RPM曲线会率先呈现出“撞顶”趋势，同时可能伴随大量429（请求被限流）错误或排队延迟升高。

在实际运维中，需将RPM与并发数、错误率结合分析：

• RPM上涨 + 错误率稳定 = 说明业务流量在健康增长。
• RPM趋平呈瓶颈 + 错误率上扬 = 大概率已经撞上预设的限流阈值。
• RPM突然下降 + TTFT急剧飙升 = 可能是上游链路或网络出现了异常中断。

在TokenHub控制台如何查看这些指标

操作路径指引

登录TokenHub管理控制台后，从左侧菜单进入“模型监控”页面；接着，选择你想要观察的目标模型、服务实例以及时间范围，即可便捷地切换并查看TTFT、TPOT、RPM等各项核心指标的动态视图。

此外，控制台还提供了“用量统计”入口，可以从模型、服务、API Key等不同维度，精确查看输入Token数、输出Token数、TPM（每分钟Token数）、插件调用次数等与账单相关的指标。将模型监控与用量统计两个页面结合起来看，就能同时掌握“服务快不快”和“成本花了多少”这两个核心问题。

推荐的日常监控节奏

• 日常巡检：每日浏览一遍当天的TTFT P95（第95百分位时延）、TPOT P95以及RPM峰值数据，并与昨日同时段数据进行对比。
• 版本发布前后：在版本更新前后半小时内，重点监控三大指标的波动，同时结合Prompt Cache命中率来验证缓存预热策略是否生效。
• 大促或活动之前：提前一周以上复盘历史流量峰值，并按照预估业务量的1.5至2倍来制定资源扩容预案。
• 故障排查复盘：针对出现异常的时段，拉取TFT、TPOT、RPM的详细时序曲线，并结合具体的错误码进行深度根因分析。

将指标转化为行动：三大典型排障场景

场景一：TTFT突然升高，用户反馈“AI反应卡顿”

排查清单：

• 检查Prompt Cache命中率是否发生显著下降——动态的System Prompt（例如在系统消息中插入“今天是2026年X月X日”这样的动态时间戳）会导致缓存大面积失效。
• 确认是否因为业务逻辑变更，在messages列表的中间部分插入了新内容，破坏了请求前缀的稳定性。
• 判定是否新出现了对长上下文的大量调用——超长Prompt会显著增加预填充阶段的计算耗时。
• 排查是否存在共享实例上、由其他业务发起的突发性流量冲击。

优化修复思路：

• 将动态变化的时间等内容放到user message中，避免其污染System Prompt。
• 发起API调用时带上X-Session-ID Header，确保同一用户的多轮对话能够路由到同一个推理实例。
• 在请求体中增加prompt_cache_key参数，建议使用业务层面的conversation_id作为该字段。
• 优先选择支持Prompt Cache功能的模型（如Hy3 preview、DeepSeek-V4-Pro/Flash、GLM-5/5.1、Kimi-K2.5/2.6、MiniMax-M2.5/2.7）。

场景二：TPOT在夜间批量任务时突然变慢

排查清单：

• 是否同时提交了多个长输出的任务，导致KV Cache内存被过度占用。
• 是否同一个API Key在同一时段内发起了过高的并发请求。
• 在结构化输出场景中，输出Token数量是否远超了历史平均水平。

优化修复思路：

• 为API Key设置独占配额与TPM（每分钟Token数）上限（企业版专业套餐支持该功能），将生产环境的API Key与跑批任务的Key分开管理。
• 将离线批量任务迁移到专用的“批量任务场景”中——以GLM-5为例，批量任务的输入价格低至2元/百万tokens，输出为9元/百万tokens，约为在线推理价格的50%。
• 在必要时，将一次超长的输出请求拆分为多个较短的任务，避免单次请求长期占用推理实例。

场景三：RPM逼近上限，开始出现限流错误

排查清单：

• 进入模型详情页，查看预设的限流规则，确认实际RPM值与预设上限之间的差距。
• 评估是否有必要为不同业务模块创建独立的API Key，以防止共享配额相互挤占。
• 考虑是否需要为同一模型创建多个独立的在线推理服务实例，以实现流量隔离（多个服务实例的计费相互独立）。

优化修复思路：

• 通过合理拆分API Key和创建多个推理服务实例，实现更精细的限流隔离。
• 在业务流量高峰到来之前，提前在控制台提交工单，申请临时调整配额上限。
• 对于重度使用的业务，建议订阅Token Plan企业版，以获得更高的TPM上限和更稳定的并发处理性能。

将监控机制嵌入开发流程的几点建议

上线前准备

• 在模型选型阶段，就应仔细查阅模型规格表，关注其“任务类型与默认并发数”等关键参数。
• 在测试环境中完成一次完整的压力测试，记录下TTFT、TPOT、RPM的基线性能数据。
• 提前规划容灾切换方案：例如，主选方案为Hy3 preview，备选方案可以设置为DeepSeek-V4-Pro/Flash或GLM-5.1。

上线后运维

• 在腾讯云监控中配置告警策略，针对错误率突然飙升、TTFT的第95百分位值大幅上涨等异常情况，实现自动通知。
• 定期复盘缓存命中率与单次调用的成本，评估是否需要切换为带Cache缓存功能的更优模型。
• 结合“用量统计”功能，评估是否需将计费模式从API按量计费转移到Token Plan个人版或企业版套餐——相较前者，可节省50%至80%的成本。

长期治理机制

• 将核心性能指标同步至公司内部的BI大盘，建立业务方也能便捷查看的健康看板。
• 尝试建立“模型健康评分”机制，将TTFT、TPOT、RPM、错误率、缓存命中率等核心指标加权评分，并纳入业务的服务质量考核体系。

常见问题解答

Q1：监控数据多久刷新一次？
模型监控页面提供的是近实时数据，具体的数据刷新粒度请以TokenHub控制台的实际展示为准。

Q2：能否自定义指标监控看板？
当前控制台主要展示官方预置的指标体系。如果业务需要更高自由度的定制看板，可以结合用量统计API与公司内部的BI工具进行扩展构建。

Q3：批量任务和在线推理的指标该如何分别查看？
两类场景在控制台分别拥有独立入口，建议按服务粒度分别进行监控。当你为同一模型创建了多个在线推理服务后，可以在监控页面按服务下拉框进行切换。

Q4：限流被触发后会发生什么？
API请求会直接返回一个限流错误码。你可以在模型详情页查询每个模型预设的限流规则。对于重度依赖的业务，建议订阅企业版以获得更高的TPM上限。

Q5：免费体验额度产生调用也会计入监控吗？
是的，免费额度产生的调用同样可以在用量统计与监控页面中看到。这让你在“新人100万免费Tokens”试用阶段，就能提前完成性能基线的测量和评估。

马上行动，让监控成为日常习惯

有效的监控是一种习惯，而非一次性的任务。将TTFT、TPOT、RPM这三张关键图表固定在日常的观察视野中，你发现业务异常的速度，就能从“被动等待用户投诉”提前到“收到系统自动告警”。

现在就进入TokenHub控制台的“模型监控”页面，立即查看你所管理服务的实时性能表现。如果你是初次开通信，还能领取新人专属的100万免费Tokens。不妨先跑出几组基线数据，再做出准确合理的模型选型与优化决策。