早上打开控制台，发现昨天的消耗是平时的十倍。第一反应通常是「被黑了」，第二反应是「上游涨价了」，然后改密码、翻公告，两小时过去账还是没对上。用量暴涨有自己的排查顺序：先分清形态，再按维度下钻，最后才谈处置。顺序对了，多数情况十分钟内能定位。
先把「暴涨」拆成四种形态
数字上行不等于事故。同样是翻十倍，成因至少分四类：真实业务增长（新功能上线、投放带来的自然量）；自己的定时任务跑飞（循环没有退出条件、失败重试叠加、分页拉全量）；客户端 bug（页面挂了一夜，每次渲染都发一次请求）；以及密钥泄露（有人拿着你的 Key 在别处跑批量任务）。
判别的关键不是总量，而是分布。请求集中在你认识的 IP、你自己写的 task 名下，多半是自己人的锅；散落在一批陌生 IP、深夜时段、单一模型、输入极短输出极长，就高度疑似泄露。前者是代码问题，后者是安全问题，处置方式完全不同。
一句话记：先看分布再看总量——分布对得上你的机器，是 bug；对不上，才是事故。
把当日调用按小时画出来，形态往往一眼可辨：定时任务跑飞是规整的锯齿，每小时都差不多；客户端 bug 跟着人上下班的峰谷走；而泄露是凌晨三点依然平稳的一条直线——那个时段本来不该有人在干活。
三层下钻：账号 → 密钥 → 请求特征
形态确认之后，用三个维度收敛来源。第一层看账号：站内如果有多个成员，先问是不是同事在压测或跑批。第二层看密钥：同一账号下往往挂着好几个 Key（网页端一个、脚本一个、交付客户一个），按 Key 分别拉用量，暴涨通常只落在其中一个上——多数排查到这就定案了。第三层看请求特征：来源 IP、User-Agent、模型分布、平均输入输出长度。批量任务的特征很明显：模型单一、输入极短、输出极长、并发平稳。
站内日志不够时，直接调管理接口按天取用量。AIGC微风 的控制台和接口同域（https://api.aigcbreeze.cn），调用日志里带时间、模型、token 数与来源，足够支撑上面三层判断。顺手核对一下计费口径：有些暴涨是量真的涨了，有些只是把按次计费的模型换成了按 token 计费的模型，账单自然换了个量级。
确认泄露后的处置顺序：止血 → 换新 → 封堵 → 溯源
一旦判定是泄露，顺序不能反。第一步止血：把涉事 Key 禁用或删除，先让出血停下——别一边查日志一边放着它继续跑。第二步换新：生成新 Key，改到所有在用它的地方（脚本、客户端、CI 变量、同事本机），旧 Key 保持删除。第三步封堵：给新 Key 设额度上限与模型白名单，万一再泄，损失有天花板。第四步溯源：回日志找第一个异常请求的时间点，往前推它是从哪个环节出去的。
最常见的泄露路径都是「图省事」：把 Key 硬编码在前端 JS 或移动端安装包里，任何人打开开发者工具就能看到；或者提交进公开仓库，被自动化爬虫在几分钟内扫走。这类泄露五分钟就足够。
一句话记：止血永远排第一——日志慢慢看，Key 必须先停。
预防：把「万一」变成「最多损失多少」
事后补救的成本远高于事前设限，三条措施几乎零成本：按用途分发 Key，网页端、脚本、对外服务各一个，出问题只停一个；每个 Key 设日额度上限与模型白名单，泄露的最坏结果是撞上限额而不是余额；设用量告警，按过去七天均值定线，日用量超过均值 1.5 倍就通知。告警要发到你每天都看的地方，别发进三个月不打开的邮箱。
常见问题
用量涨了，但我确认没泄露，还要处理吗？
要，但方向不同。确认来源是自己的机器后，去查循环与重试：最常见的是失败重试没有上限，一次上游抖动就触发无限重试，日志里同一请求重复几百次；其次是分页拉取缺少终止条件，或轮询间隔被写成 0。这类属于代码问题，改完即止，不必动密钥。
怎么区分自然增长和异常？
看比值不看绝对值：日活、请求数、消耗一起看。消耗涨十倍而请求数只涨一倍，说明单请求变贵了（换模型或输入变长）；三个数同比例上涨，大概率是真实增长。再把窗口拉到七天，确认是不是只有某一天尖峰。
额度上限设多少合适？
按「正常峰值 × 1.5」起步，跑一周再校准。设得太紧会误伤正常业务，设得太松等于没设。对内网脚本这类不对外暴露的调用，可以直接按日均值设，超了人工提额——它们不需要弹性。