TokenHub 模型监控指标：TTFT、TPOT、RPM 在控制台怎么看

摘要：

腾讯云大模型服务平台 TokenHub 在控制台提供完整的模型与服务监控视图，涵盖 TTFT（首 Token 时延）、TPOT（每 Token 输出时延）、RPM（每分钟请求数）等关键指标。本文系统讲解三大指标的含义、查看路径、健康阈值参考与排障思路，帮你把大模型调用的性能、稳定性与成本变成可度量、可优化的工程数据。

一、调用大模型时，你真正需要盯的是这三个指标

接入大模型 API 之后，团队最常被提的需求是这几句：

a. "为什么响应有时快、有时慢？"

b. "晚高峰会不会被限流？"

c. "我能不能提前发现服务异常？"

这些问题的答案，全都藏在三个指标里：TTFT（首 Token 时延）、TPOT（每 Token 输出时延）、RPM（每分钟请求数）。它们是衡量大模型推理服务体验、吞吐与限流的"三件套"，也是腾讯云 TokenHub 模型监控页面默认提供的核心指标。

把这三个指标看懂、看会、看常态，等于给业务装上了一台"体检仪"。

二、三大指标分别在度量什么

2.1 TTFT：首 Token 时延

定义：从 API 请求发出到接收到第一个 Token 之间的耗时。

TTFT 直接决定用户主观感受到的"反应速度"。流式输出场景下，TTFT 越短，用户越能立刻看到模型开始"打字"；批量任务场景下，TTFT 反映了服务的冷启动与队列排队压力。

影响 TTFT 的常见因素：

a. Prompt 长度：输入越长，预填充计算越久；

b. 缓存命中率：命中 Prompt Cache 时 TTFT 显著降低；

c. 模型规模：参数更大的模型预填充阶段更耗时；

d. 并发压力：实例承载请求过多时排队增加 TTFT；

e. System Prompt 稳定性：动态时间或频繁变化的前缀会让缓存失效。

2.2 TPOT：每 Token 输出时延

定义：模型生成阶段，每生成一个 Token 平均所需的时间。

TPOT 决定了"打字速度"。在长文本生成、代码生成、深度思考等场景下，TPOT 直接影响整体响应耗时——总耗时 ≈ TTFT + 输出 Token 数 × TPOT。

影响 TPOT 的常见因素：

a. 模型架构：MoE 架构（如 Hy3 preview 的 295B/21B 激活）通常有较好的解码速度；

b. 输出长度：超长输出叠加并发，KV Cache 压力上升会拖慢 TPOT；

c. 推理实例负载：实例饱和后排队效应同样作用于解码阶段；

d. 网络回传：跨地域调用会引入额外抖动。

2.3 RPM：每分钟请求数

定义：单位时间内的请求条数，体现服务实际承接的吞吐量。

RPM 是限流监控的"主角"。TokenHub 每个模型都有预置限流，可在模型详情页查看具体规则。当业务流量逼近上限时，RPM 曲线会率先吃紧，伴随 429（限流）错误或排队时延上涨。

实际工作中需要把 RPM 与并发数、错误率一起看：

a. RPM 上涨 + 错误率稳定 = 业务正常增长；

b. RPM 趋平 + 错误率上扬 = 大概率撞限流；

c. RPM 突降 + TTFT 飙升 = 上游链路或网络异常。

三、在 TokenHub 控制台哪里查看

3.1 路径

1. 登录 TokenHub 控制台；
2. 左侧菜单进入"模型监控"；
3. 选择目标模型 / 服务 / 时间范围；
4. 切换 TTFT、TPOT、RPM 等指标视图。

控制台同时提供用量统计入口，可按模型、服务、API Key 维度查看输入 Token、输出 Token、TPM、插件调用次数等账单类指标。两个页面一起看，可以同时回答"快不快"和"花了多少"两个问题。

3.2 推荐的看图节奏

a. 每日例行：拉一遍当日 TTFT P95、TPOT P95、RPM 峰值，对比昨日同时段；

b. 发版前后：版本更新前后 30 分钟密切监控三大指标，配合 Prompt Cache 命中率验证缓存预热效果；

c. 大促 / 活动前：提前一周拉历史峰值数据，按 1.5–2 倍预估容量预案；

d. 故障复盘：异常时间段拉详细曲线，结合错误码做根因分析。

四、把指标变成行动：三大常见排障场景

4.1 场景一：TTFT 突然变高，用户反映"AI 卡顿"

排查清单：

a. 检查 Prompt Cache 命中率是否下降——动态 system prompt（如写入"今天是 2026 年 X 月 X 日"）会导致缓存大面积失效；

b. 确认是否因业务变更让 messages 中段插入新内容，破坏前缀稳定性；

c. 是否新增长上下文调用——超长 Prompt 显著拉高预填充耗时；

d. 是否有共享实例的其他业务突发流量。

修复思路：

a. 把动态时间内容放到 user message，不要污染 system prompt；

b. 调用时带上 X-Session-ID Header，把同一用户多轮对话路由到同一推理实例；

c. 调用体加上 prompt_cache_key，建议取业务侧 conversation_id；

d. 选用支持 Cache 缓存的模型（如 Hy3 preview、DeepSeek-V4-Pro/Flash、GLM-5/5.1、Kimi-K2.5/2.6、MiniMax-M2.5/2.7）。

4.2 场景二：TPOT 在夜间任务突增

排查清单：

a. 是否同时跑了多个长输出任务挤压 KV Cache；

b. 是否同一个 API Key 同一时段并发数过高；

c. 是否结构化输出场景输出 Token 数远超平均水平。

修复思路：

a. 在 API Key 上设置独占配额与 TPM 上限（企业版专业套餐支持），把生产 Key 与跑批 Key 分开；

b. 离线批量任务改走"批量任务场景"——以 GLM-5 为例，批量任务输入 2 元 / 百万 tokens、输出 9 元 / 百万 tokens，约为在线推理价格的 50%；

c. 必要时拆分长输出请求，避免单次任务持续占用实例。

4.3 场景三：RPM 撞顶，开始出现限流错误

排查清单：

a. 在模型详情页查看预置限流规则，确认实际 RPM 与上限差距；

b. 检查是否需要为不同业务创建独立的 API Key，避免共享配额相互"挤压"；

c. 是否需要把同一模型创建多个在线推理服务做隔离（多个服务计费独立）。

修复思路：

a. 通过 API Key 与服务的拆分实现限流隔离；

b. 业务高峰前预先在控制台联系工单调整额度；

c. 重度业务可考虑订阅 Token Plan 企业版，享受更高 TPM 上限与多并发稳定性。

五、把监控嵌入开发流程的几个建议

5.1 上线前

a. 模型选型阶段就关注模型规格表里的"任务类型与默认并发数"；

b. 测试环境完成压力测试，记录 TTFT/TPOT/RPM 基线；

c. 准备容灾切换方案：如主用 Hy3 preview，可备选 DeepSeek-V4-Pro/Flash 或 GLM-5.1。

5.2 上线后

a. 在腾讯云监控接入告警，对错误率突增、TTFT P95 大幅上涨等情况自动通知；

b. 周期性复盘缓存命中率与单位调用成本，识别是否需要切到带 Cache 缓存的模型；

c. 配合"用量统计"评估是否切换到 Token Plan 个人版或企业版套餐——相比 API 按量计费便宜 50%–80%。

5.3 长期治理

a. 把核心指标同步到内部 BI 大盘，形成业务方可见的看板；

b. 建立"模型健康分"，把 TTFT/TPOT/RPM/错误率/缓存命中率等加权得分，纳入业务质量考核。

六、常见问题

Q1：监控数据多久刷新？

模型监控页提供近实时数据，具体粒度以控制台展示为准。

Q2：能否自定义指标看板？

当前控制台展示官方预置指标体系。如需更高自由度的看板，可结合用量统计 API 与公司 BI 工具扩展。

Q3：批量任务和在线推理的指标怎么分别看？

两类场景在控制台分别有入口，建议按服务粒度分别监控。同一模型创建多个在线推理服务后，可在监控页按服务下拉切换。

Q4：限流被触发会怎样？

请求会返回限流错误码。可在模型详情页查询每个模型的预置限流规则。重度业务建议订阅企业版获得更高 TPM 上限。

Q5：免费体验额度也会进入监控统计吗？

免费额度的调用同样可在用量统计与监控页中看到，便于在新人 100 万免费 Tokens 阶段就完成性能基线测量。

七、立刻动手把监控用起来

监控是一种习惯，不是一次任务。把 TTFT、TPOT、RPM 三张图固定到日常视野里，业务异常的发现速度可以从"用户投诉"提前到"指标自动告警"。

进入 TokenHub 控制台 的"模型监控"页面立即查看你当前服务的实时表现；第一次开通还可领取新人 100 万免费 Tokens，先把基线数据跑出来再做选型决策。