AI API 子 Key 被下游贴进小程序刷爆，2026年先限额还是先挂告警才收得住？

2026年做 AI API 聚合、网关或分销，子 Key 被下游贴进小程序或前端后刷爆，常见主因不是上游模型被攻破，而是 Key 暴露面没有收口、配额和告警没有分层。更稳的顺序通常是先做入口限流与配额分层止血，同时挂一个粗糙告警，再补 Key 轮换和日志口径；只加一道总限额，要么在并发突刺时被绕过，要么把正常客户的批量任务一起误伤。按项目交付经验，这套动作通常要落在能力层、业务层、载体层、数据与风控四层里，而不是只改网关一个参数。

为什么子 Key 被刷爆，往往不是「加一道总限额」就能解决

在 AI API 分销里，子 Key 常被下游嵌进网站、小程序或 APP 的前端代码，抓包即可拿到。2026年常见的主因不是上游模型被攻破，而是 Key 暴露面没有收口、配额和告警没分层。只加总限额的问题是，它按整体调用量算，刷子可以用慢速并发绕开，正常客户却可能在集中跑任务时被顶掉。

更有效的判断标准是看三个维度有没有分开管：谁在用（子账号）、从哪来（IP 或来源标识）、用哪个模型（Token 单价）。三者只做其一，通常都留有缺口。按 2026 年常见做法，限额至少要做到「子 Key + 模型 + 时间窗」的组合，而不是只在网关入口卡一个 QPS。

• 只按子 Key 做总限额，刷子用一个 Key 慢速刷，绕开突刺检测。
• 只在网关边缘限 QPS，不按 Token 消耗限额，单价高的模型仍会被薅。
• 告警只发到群里，没有自动降级或临时限速动作，等人工看到已经跑掉一批额度。
• Key 已经贴到前端，只改限流不换 Key，等于留着后门等下一次。

上线交付现场：一次子 Key 泄露后，我们按什么顺序收口

在项目交付里常见的情况是，预算有限、上线周期只剩几天，下游客户又不愿意改前端。按我们在 API 与建站交付里的习惯，做法是先把前端直连改成服务端中转，再给每个子 Key 加上「分钟级 QPS + 日 Token 配额」两层限额，同时把用量突增告警接到值班侧。代价也明显：切换当天有客户正在跑的批量任务被限流，客服要逐个解释，第二天按真实峰值把阈值往上调了一档。这类收口通常要预留 1-2 天的观察期，不能一次性卡死。按常见区间，前端中转改造大约 1-2 天，配额和告警联调再加 1 天左右。

可命名的四层落地方案：能力层 → 业务层 → 载体层 → 数据与风控

把这件事拆成四层，是为了把「模型调用」和「谁能调用、能调多少、出问题能不能查」分开。能力层决定可用模型范围，业务层决定配额与计费，载体层决定 Key 暴露在哪里，数据与风控层决定能不能在事中止损、事后复盘。四层缺一层，限流和告警都会变成补丁。

1. 能力层：接入 GPT、Claude、Gemini、通义、DeepSeek 等模型族时，先按输入、输出 Token 分别记录消耗；不确定具体版本号的，走别名映射，不要在下游写死模型名。
2. 业务层：把子账号、子 Key、配额、价格版本、路由规则放在同一层管；按「子 Key + 模型 + 日/月」做 Token 配额，按「子 Key + IP」做分钟级 QPS。
3. 载体层：网站、小程序、APP、H5 尽量走自家服务端中转，不把子 Key 写进前端；如果是开放 API，至少用短时效 Token 或签名，别发长期有效的 Key。
4. 数据与风控：日志至少落下子 Key、账号、模型、Token 数、价格版本、来源 IP；告警阈值按历史峰值上浮一个经验区间设置，触发后先降级到低单价模型或临时限速，而不是直接封号。字段口径可按所用网关与上游平台的官方文档核对。

每层要注意的点不一样：能力层别把上游模型名写死，业务层别把售价和成本混在一个字段，载体层别在前端留长期 Key，数据与风控层别让日志缺项目或子账号标识。做到这四条，后面查一笔异常用量通常能在几分钟内定位到子 Key。

先限额还是先告警？两种起手顺序的对比

如果只选一个起手动作，2026年更常见的是先限额止血，同时挂一个粗糙告警；因为告警只能告诉你「已经在被刷」，限额能直接减少损失。但如果调用方以服务端为主、用量平稳，先做告警反而更合适，能避免误伤。

• 先限额：止血快，通常能在数分钟到一小时内收住；配置周期常见半天到一天。但阈值没调准容易误伤正常客户，适合前端已暴露 Key、调用量波动大的分销场景。
• 先告警：误伤少，配置周期常见几小时到一天，适合内部系统或固定客户；但从发现到处理之间有时间差，可能已经跑掉一批 Token 额度。
• 组合做法：分钟级 QPS 先卡住突刺，日/月 Token 配额后置，告警阈值按历史峰值上浮一个经验区间；先观察一两天再收紧。整体联调周期常见 1-3 天。

判断是否合格，可以看三条：突刺能被限住、正常批量任务能跑完、告警不天天响。三条都满足，限额和告警的配合才算到位；只满足其中一条，通常还得回看日志字段和配额粒度。

适用场景与边界

适合上的情况比较集中：对外做 AI API 分销，下游有多个子账号或子 Key；子 Key 会被嵌到网站、小程序、APP 前端，抓包可得到；调用量波动大，批量任务和实时对话混跑。这几类场景里，限流和告警基本是上线前就该补的项。

不适合或不必上复杂多级限流的情况也要说清：如果子 Key 从不出前端、调用方都是自家服务端，那么优先补日志和账单口径，而不是先堆多级限流。客户数量很少、调用量平稳时，把精力放在对账、日志完整性和 Key 轮换周期上，可能比铺一套限流组件更划算。

• 适合：多客户分销、前端暴露 Key、用量波动大、需要按子账号出账。
• 不必先上：纯内部系统、Key 不出内网、调用量平稳、客户数很少。
• 折中：先用服务端中转加基础 QPS，再按真实峰值逐层加配额和告警。

常见问题

子 Key 已经贴到前端了，必须马上换 Key 吗？

通常先换 Key 或改成服务端中转再谈限流；只限流不换 Key，被抓到的旧 Key 仍可能被反复利用。

限流会不会误伤正常客户？

会，尤其在批量任务和实时对话混跑时；常见做法是按子 Key 分开配额，先用告警观察一两天再收紧阈值。

告警阈值怎么定才不吵？

按历史峰值的经验区间上浮一档，区分分钟级突刺和日级用量；只对持续超阈值的子 Key 发告警，避免单次波动刷屏。

按 IP 限流对移动端用户是不是不公平？

移动网络出口 IP 可能共用，按 IP 卡太死会误伤；更稳的是以子 Key 加账号为主，IP 作为辅助维度。

下游客户坚持要前端直连，2026年有没有折中办法？

可以让前端拿短时效 Token 或走签名中转，子 Key 不落地到前端；这会增加一点联调量，但比事后封 Key 代价小。

如果正在做 AI API 聚合、网关或分销，建议先把子 Key 从前后端分离出来，再按「分钟级 QPS + 日 Token 配额 + 用量告警」三层补上。适合前端曾暴露 Key、下游客户较多的场景；如果调用方都是自家服务端、Key 不出内网，优先补日志和对账口径即可，不必先上多级限流。