AI API 网关实践：用户用量统计做好之后，异常排查会简单很多
前面一篇聊了为什么 AI API 网关不能只按 Key 统计，还要按用户统计。
这篇继续往下写。
因为真正上线以后，你会发现一个很现实的问题：
记录用量只是第一步。
更重要的是，当 Token 消耗突然上涨时，你能不能快速知道问题出在哪里。
一开始我以为，只要后台能看到总调用量就够了。
比如：
今天请求 3000 次
今天消耗 120 万 tokens
平均响应时间 2.3 秒
失败请求 46 次
这些数据当然有用。
但如果某一天总 Token 突然翻了几倍，只看这些总数，其实还是很难排查。
因为你不知道是哪个用户、哪个项目、哪个 Key、哪个模型、哪个任务在变化。
所以后来我越来越觉得：
AI API 网关不只是转发请求的地方，更应该是排查问题的入口。
一、总量上涨不等于所有地方都有问题
很多时候，Token 总消耗上涨，并不是整个系统都出问题了。
可能只是某一个用户在批量调用。
可能只是某一个项目上线了新功能。
可能只是某个知识库问答的上下文变长了。
可能只是某个脚本重复执行了。
可能只是某个接口失败后一直重试。
如果只看总量，就会很紧张：
今天怎么突然涨这么多？
是不是线上出问题了？
是不是 Key 泄露了？
是不是有人在恶意调用？
但如果有更细的维度，排查就会冷静很多。
比如先看项目维度：
prod_chat_api：正常
prod_kb_qa：上涨 20%
batch_summary_job：上涨 500%
dev_local_test：正常
这时候基本就能判断，问题大概率在 batch_summary_job。
不用把所有项目都翻一遍。
二、异常排查最好从 Top 列表开始
我后来比较喜欢先看几个 Top 列表。
比如：
今日 Token 消耗 Top 10 用户
今日 Token 消耗 Top 10 项目
今日 Token 消耗 Top 10 Key
今日失败请求 Top 10 接口
今日平均 Token 最高的任务
这些列表很简单，但很有用。
因为大多数异常，都会先在 Top 列表里露出来。
比如你看到：
user_1088：680,000 tokens
user_2033：90,000 tokens
user_7712：63,000 tokens
其他用户都在正常范围内。
那就不用先怀疑整个系统。
先看 user_1088 的请求就行。
再比如项目维度：
batch_article_summary：830,000 tokens
prod_chat_api：210,000 tokens
prod_kb_qa：180,000 tokens
admin_ai_tool：60,000 tokens
那就说明批量摘要任务消耗明显偏高。
Top 列表的意义不是为了做排行榜，而是为了快速缩小排查范围。
三、不要只看总 Token，还要看平均 Token
有时候总 Token 上涨，不一定是请求次数上涨。
也可能是单次请求变重了。
比如昨天：
请求次数：1000 次
总 Token：300,000
平均每次：300 tokens
今天：
请求次数：1000 次
总 Token：900,000
平均每次：900 tokens
请求次数没变，但平均 Token 变成了三倍。
这时候问题就不是“谁调用多了”，而是“每次调用变贵了”。
常见原因有几个：
Prompt 模板变长了
知识库检索片段变多了
历史对话轮数没有控制
用户输入内容变长了
模型输出没有限制长度
返回格式要求太复杂
所以排查 Token 异常时，我一般会同时看：
总 Token
请求次数
平均 Token
输入 Token
输出 Token
只看总数很容易误判。
四、输入 Token 和输出 Token 要分开看
AI API 成本里，输入和输出最好分开统计。
因为它们代表的问题不一样。
如果输入 Token 突然上涨，通常说明：
用户输入变长
上下文拼接太多
知识库检索片段太多
历史对话带得太长
系统提示词变复杂
如果输出 Token 突然上涨，通常说明：
模型回答太长
没有设置 max_tokens
提示词要求“详细回答”
结构化输出字段太多
批量生成内容数量变多
举个例子。
某个知识库问答项目突然变贵了。
如果你只看到：
prod_kb_qa 今天消耗 80 万 tokens
其实不知道原因。
但如果拆开看：
输入 Token：70 万
输出 Token：10 万
那问题大概率在上下文拼接。
可能是检索文档太多，也可能是历史对话太长。
如果反过来：
输入 Token：20 万
输出 Token：60 万
那可能是模型回答太长。
这时候就应该检查输出限制。
五、说一下我现在用的 API 网站
我自己后来在整理这些问题时，也做了一个统一 API 管理网站：
斑马API - AI API 中转站 - AI API Gateway
它不只是用来转发 AI API 请求，更重要的是把调用过程里的数据记录下来。
比如：
哪个用户调用了多少
哪个 Key 消耗最多
哪个项目突然上涨
输入 Token 和输出 Token 分别是多少
失败请求集中在哪些接口
响应耗时有没有异常
模型调用分布怎么样
这些数据平时看起来只是报表。
但一旦出问题，它就是排查入口。
如果你现在的 AI API 还是散落在多个项目里，各自写 Key、各自调模型、各自记日志，后面排查问题会很累。
我的建议是：
先不用一口气做很复杂。
至少先把调用统一收口，把请求日志和 Token 数据记录下来。
六、失败重试也是隐藏消耗
还有一个很容易被忽略的问题：失败重试。
很多人会觉得，失败请求应该没什么成本。
但实际不一定。
如果请求已经发给模型，只是后端超时、网络中断、或者客户端没有等到返回，这次调用可能已经消耗了 Token。
更麻烦的是，系统可能会自动重试。
比如：
第一次请求超时
自动重试一次
第二次又超时
再重试一次
最后用户又手动点了一次
这样原本一次调用，可能变成了三四次。
如果每次输入都很长，消耗会很明显。
所以日志里最好记录：
是否重试
重试次数
原始请求 ID
失败原因
是否已经调用上游模型
是否已经产生 Token 消耗
否则排查时很容易只看到失败率，却看不到失败背后的成本。
七、请求 ID 很重要
做 AI API 网关时，我觉得每次请求都应该有一个 request_id。
这个 request_id 要贯穿整个链路：
前端请求
后端业务服务
API 网关
上游模型请求
日志记录
用量统计
这样出了问题才能串起来查。
比如用户反馈：
刚才那次生成失败了。
如果没有 request_id，只能按时间、用户、接口去猜。
但如果有 request_id，就可以直接查：
这个请求是谁发起的
用了哪个 Key
调用了哪个模型
输入 Token 多少
输出 Token 多少
有没有命中缓存
有没有重试
失败在哪一层
耗时多少
这对排查非常重要。
八、异常告警不要只按总量触发
很多系统一开始做告警，只会写一个简单规则：
今天 Token 超过 100 万就告警。
这个规则有用，但不够细。
因为不同项目的正常范围不一样。
比如：
prod_chat_api 每天 200 万 tokens 很正常
dev_local_test 每天 20 万 tokens 就不正常
batch_summary_job 周末突然跑 50 万可能正常
test_ai_api 凌晨跑 50 万就很奇怪
所以告警最好按不同维度设计。
比如：
某个用户 1 小时内消耗超过平时 5 倍
某个 Key 当日消耗超过预算 80%
某个项目失败率超过 10%
某个模型平均耗时超过 5 秒
某个接口平均 Token 突然翻倍
某个测试 Key 夜间大量调用
这样告警才更接近真实问题。
九、排查流程可以固定下来
我现在看 Token 异常，一般会按这个顺序排查：
先看总 Token 是否真的上涨
再看请求次数有没有上涨
再看平均 Token 有没有上涨
再拆输入 Token 和输出 Token
再看 Top 用户
再看 Top 项目
再看 Top Key
再看失败请求和重试次数
再看最近有没有上线新功能
再看是否有批量任务或定时任务
这个流程固定下来以后，排查会快很多。
不然每次出问题都靠临时猜，很容易漏掉关键线索。
十、最后总结
AI API 的异常排查，最怕只有一个总数。
比如只知道：
今天消耗变高了。
这个信息太粗了。
真正有用的是继续往下拆：
哪个用户变高了？
哪个项目变高了？
哪个 Key 变高了？
输入变高还是输出变高？
请求次数变多还是单次请求变贵？
是不是失败重试导致的？
是不是批量任务跑飞了？
是不是知识库上下文变长了？
当这些数据都能看到时，AI API 网关就不只是一个转发层，而是一个真正的管理入口。
接口能调通只是第一步。
长期跑得住、查得清、控得住，才是后面更重要的事情。