跳到主要内容
Router One
注册

LLM 可观测：一次请求一条 Trace

Router One 在控制台 → 日志（请求日志）中记录模型调用用量。按模型、API Key、状态和日期筛选后，打开一条记录即可查看请求 ID、发起请求的 Key、Token、总耗时（产生过输出的流式请求另有首字延迟）、状态和脱敏错误。流式响应需要单独检查结束事件，费用以记录的结算结果为准；支持团队可以通过请求 ID 关联内部路由尝试。

立即接入

一条请求日志能检查哪些信息？

信号Router One Trace如何解读
请求 ID 与模型打开详情复制 requestId，并查看记录的模型用请求 ID 关联应用日志中的同一次调用
输入 / 输出 Token已记录的输入、输出数量，以及可用的缓存读取 TokenToken 用量不等于客户端已收到完整回答
每请求成本已结算的实际 totalCost；待结算表示最终金额未知已结算总额已包含适用的计价倍率，不要再乘一次
延迟每条请求记录都有总耗时，产生过输出的流式请求另有首字延迟（TTFT）；总耗时缺失时显示为横线两者都从网关开始执行请求时起算，首字延迟包含故障转移前失败尝试的耗时；与客户端首个可见 Token 的差值来自你的网络、客户端和网关接收请求的环节
路由排查通过请求 ID 交给支持团队关联排查请求日志不显示供应商名称或中间尝试链
状态码与错误状态码，以及有记录时的脱敏错误文本仅凭 HTTP 200 不能确认流式回答成功完成
花费上限按 Key 的 maxSpend 能拦住失控循环应用自身也应设置循环上限

去哪里看

控制台 → 日志

按模型、API Key、状态和日期筛选，打开对应记录查看请求 ID、用量、状态和结算详情；API Key 列与请求详情会标出发起请求的 Key（网页端调用单独标注）。日志（按当前筛选）与钱包流水（所选时间段）可导出 CSV。仍在等待定价的记录可能暂未出现在列表里；如需细分到终端客户或单次运行，请在自己的应用日志中保留标签和请求 ID。

控制台 → 用量

查看请求量、Token 和花费趋势，以及按模型和能力类型拆分的汇总数据；还可按 API Key 查看所选时间段的花费、Token 和请求数，并跳转到该 Key 的日志。单次请求的实际费用和可用折扣详情请到日志中查看。

预算与默认限流

每个 API Key 自带 maxSpend；它的 rateLimit 和 tokenLimitTpm 按平台默认值执行，可申请调高。失控循环会先撞上自己的上限而停下，而不是把整个余额耗尽——无需治理套件即可管控花费。

示例：一条等待结算的流式请求

使用请求日志字段名的合成片段，数值仅供说明，不是真实生产记录或报价。若记录标为待结算，则最终费用尚未知；等待定价的记录也可能暂未出现在列表里。

trace.json
{
  "requestId": "demo_req_7f3a",
  "model": "example-chat-model",
  "inputTokens": 512,
  "outputTokens": 200,
  "firstTokenLatencyMs": 640,
  "latencyMs": 1180,
  "statusCode": 200,
  "totalCost": null,
  "billingPricing": {
    "status": "pending"
  }
}

请求数据处理

客户侧 Trace 包含用于调试和核对费用的请求元数据。Router One 不留存直接 API 调用的 prompt 和模型回复正文，仅记录用于计费、用量统计与故障排查的请求元数据。Playground 会保存会话历史，方便用户回看和继续对话。

查看数据留存政策

常见问题

HTTP 200 代表流式回答成功了吗？

不一定。HTTP 200 可能只是流已打开，生成随后仍可能失败或不完整。Chat Completions 要看 finish_reason 和流内错误，stop、length、tool_calls 含义不同；Responses 要检查 response.completed、response.failed 或 response.incomplete。连接关闭或控制台的成功标签都不足以单独证明回答完成。

“待结算”是不是这次请求免费？

不是。待结算表示最终费用未知，界面不会用 0 元或未折扣的 Token 费用小计替代。请稍后重新查看；已结算总额已包含适用折扣。显示的默认或模型专属折扣、套餐倍率、实际倍率用于解释该总额，不是让你再打一次折。

请求慢或失败时应该收集哪些排查证据？

保留请求 ID、带时区的时间戳、端点、精确模型 ID、SDK 版本、超时设置、HTTP 状态，以及最终错误或结束原因。记录客户端首个可见 Token 何时到达、是否主动取消，再与日志中的首字延迟（TTFT）对照：两者之差来自你的网络、客户端和网关接收请求的环节；首字延迟本身就长，则指向排队、故障转移前的失败尝试或模型本身的等待。比较多次相同模型、端点及相近提示长度的调用，单个耗时不足以归因；分享前移除 API Key 和敏感输入输出。

一条 Trace 里到底有什么？

请求日志展示记录的模型、请求 ID、发起请求的 API Key、输入 / 输出 Token、可用的缓存读取 Token、已结算费用或待结算标签、总耗时（产生过输出的流式请求另有首字延迟，即 TTFT）、状态码和脱敏错误。网关返回计价详情时会一并显示；日志 CSV 导出在「耗时 (ms)」旁有「首字 (ms)」列；这里不展示供应商名称或中间尝试链。

Router One 会保存我的 prompt 和响应吗？

Router One 不留存直接 API 调用的 prompt 和模型回复正文，仅记录用于计费、用量统计与故障排查的请求元数据。Playground 会保存会话历史，方便用户回看和继续对话。

怎么防止失控循环把余额耗尽？

给 API Key 设置 maxSpend；它的 rateLimit 与 tokenLimitTpm 按平台默认值生效，可申请调高。当循环撞到该 Key 的花费上限或限流时，这个 Key 上的请求会停止，而不会消耗整个钱包。预算是按 Key 设置的，不是按项目。

这是企业级审计或合规平台吗？

不是。这是面向开发者和小团队的请求级可观测与花费管控，不是审计日志、合规或 RBAC 系统。没有组织/角色结构——限额和预算挂在 API Key 上。

供应商出故障时 Trace 会显示什么？

请求日志记录这次模型调用的用量、状态和脱敏错误，不显示供应商名称或故障转移链。支持团队可以用请求 ID 在运维日志中排查中间尝试；请同时保留客户端错误和最终事件。

相关页面

看清每一次请求，管好每一块钱

立即接入