前面一篇聊了为什么 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_1088680,000 tokensuser_203390,000 tokensuser_771263,000 tokens其他用户都在正常范围内。那就不用先怀疑整个系统。先看 user_1088 的请求就行。再比如项目维度batch_article_summary830,000 tokensprod_chat_api210,000 tokensprod_kb_qa180,000 tokensadmin_ai_tool60,000 tokens那就说明批量摘要任务消耗明显偏高。Top 列表的意义不是为了做排行榜而是为了快速缩小排查范围。三、不要只看总 Token还要看平均 Token有时候总 Token 上涨不一定是请求次数上涨。也可能是单次请求变重了。比如昨天请求次数1000 次总 Token300,000平均每次300 tokens今天请求次数1000 次总 Token900,000平均每次900 tokens请求次数没变但平均 Token 变成了三倍。这时候问题就不是“谁调用多了”而是“每次调用变贵了”。常见原因有几个Prompt 模板变长了知识库检索片段变多了历史对话轮数没有控制用户输入内容变长了模型输出没有限制长度返回格式要求太复杂所以排查 Token 异常时我一般会同时看总 Token请求次数平均 Token输入 Token输出 Token只看总数很容易误判。四、输入 Token 和输出 Token 要分开看AI API 成本里输入和输出最好分开统计。因为它们代表的问题不一样。如果输入 Token 突然上涨通常说明用户输入变长上下文拼接太多知识库检索片段太多历史对话带得太长系统提示词变复杂如果输出 Token 突然上涨通常说明模型回答太长没有设置 max_tokens提示词要求“详细回答”结构化输出字段太多批量生成内容数量变多举个例子。某个知识库问答项目突然变贵了。如果你只看到prod_kb_qa 今天消耗 80 万 tokens其实不知道原因。但如果拆开看输入 Token70 万输出 Token10 万那问题大概率在上下文拼接。可能是检索文档太多也可能是历史对话太长。如果反过来输入 Token20 万输出 Token60 万那可能是模型回答太长。这时候就应该检查输出限制。五、说一下我现在用的 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 网关就不只是一个转发层而是一个真正的管理入口。接口能调通只是第一步。长期跑得住、查得清、控得住才是后面更重要的事情。