使用日志

入口：控制台 → 使用日志。

每一次 API 请求都在这里，是回答「我的额度花哪儿去了」和「为什么报错」这两个问题的唯一权威来源。

表格里的列

列	说明
时间	请求发生时间
令牌	哪把 key 发的。建多个令牌的好处就在这一列体现
分组	实际走的分组。开了跨分组重试时，这里可能和令牌绑定的分组不同
类型	消费 / 充值 / 管理 / 系统 / 错误
模型	实际调用的模型
用时/首字	总耗时与首字延迟。流式体验卡不卡主要看首字
输出	token 数
花费	这一次请求扣了多少
重试	重试了几次
详情	展开看完整信息，报错时的关键入口

顶部还能按时间范围、令牌名称、模型名称、请求 ID、分组、日志类型筛选。右上角「列设置」可以隐藏不关心的列。

场景一：额度掉得太快

1. 时间范围选最近一天
2. 日志类型选消费
3. 看花费列，哪个模型或哪把令牌占大头就一目了然

常见原因：

• 用了贵模型。 各模型倍率差很多，对照 模型广场
• 上下文太长。 每次请求都把整段历史重发一遍，长对话单价会持续上涨
• 令牌被别人用了。 看令牌列有没有你不认识的调用，有就立刻删掉那把 key（见 令牌管理）

场景二：客户端报错

1. 日志类型选错误
2. 找到对应时间的那条，点详情

详情里会带上游返回的原始错误。发工单时把这段贴上，比只说「用不了」快很多。

如果日志里根本没有记录，说明请求没到服务端——检查客户端的 Base URL 写对了没，网络有没有被代理拦截。

场景三：想定位某一次具体请求

客户端报错信息里通常带 request_id。把它填进顶部的请求 ID 框，直接定位到那一条。

先自查再提单

把使用日志的详情截图连同时间点一起发 工单，处理速度会明显快于纯文字描述。