AI SaaS 如何控制 API 调用成本和异常流量？

成本失控的三种形态

形态	表象	真正的归因
账单型	月末账单翻倍，但 DAU 平稳	爬虫或薅额度产生的调用不体现在活跃用户上
单租户型	少数账号吃掉大部分额度	免费额度无上限，或配额只按请求数不按成本计
端点型	某个高成本接口消耗异常	视频/高清图像/长上下文接口的单次成本是普通接口的数十倍

三种形态对应的控制点不同，但根因是同一个：你按「请求数」计费，而成本按「token 与算力」发生。只要度量口径和成本口径不一致，成本就一定会失控。

为什么按请求数限流在 AI 接口上会失效

维度	传统 Web 接口	AI 接口
单次请求成本	基本恒定	相差可达数十倍（取决于上下文长度、分辨率、步数）
合理频率	用户操作决定，有天然上限	脚本可无限循环，无天然上限
重试放大	影响小	一次失败重试可能重复消耗整段上下文

一个「每分钟 60 次请求」的限流规则，在传统接口上等于 60 次廉价查询；在 AI 接口上可能是 60 次最长上下文推理。把限流的计数单位从「次」换成「成本单位」，是 AI 场景成本治理的第一步，也是最容易漏掉的一步。

五个控制点

1. 按成本维度计数。 给每类请求折算一个成本点数（文本补全按输入+输出 token 折算，图像按分辨率×步数折算，视频按秒数折算），让限流规则统计点数而不是请求数。

能落在 Cloudflare 上的部分：Enterprise + Advanced Rate Limiting 提供「复杂度计分」计数模型——由你的源站在响应头里返回一个代表本次请求开销的分值（要求 1–1,000,000 之间），边缘按配置的周期累加，超过设定的「每周期总分」就执行规则动作。这与 AI 场景天然吻合。 两个坑：一是源站必须真的返回这个响应头且取值合规，否则计数器不更新，规则形同虚设；二是请把它当成第二道闸门而不是唯一闸门。

2. 分层配额。 三层同时存在：租户层（每个客户的总预算）、端点层（高成本接口单独限次）、模型层（贵模型单独配额）。缺任何一层，成本都会从缺口漏出去。

落地的现实约束：Cloudflare 的限流规则条数按套餐限制（Free 1 条、Pro 2 条、Business 5 条、Enterprise 通常 100 条），计数维度也受限：Free/Pro 只能按 IP 计数；要按请求头、JWT 声明、JSON 正文字段或表单字段计数需要 Enterprise 或 Advanced Rate Limiting。所以「租户层配额」这类强业务属性的计数，通常应该放在你的应用层，边缘只保留少数几条高价值规则（登录、领额度、生成类端点）。

3. 异常流量识别与降速。 限流只能限制速率，不能区分好坏。要先识别再降速：来源集中、无浏览器环境、请求节奏机械、只调用生成接口从不读取结果的流量，优先降级到便宜模型或直接挑战，而不是一律 429。这条路依赖 bot 信号，而细粒度 bot score（1–99，1 表示高度确定是自动化流量）需要 Enterprise 的 Bot Management 订阅；低套餐只能在 Bot Analytics 里看到分组。

4. 缓存与去重。 完全相同的请求（同参数图生图、同 prompt 的补全）直接返回缓存结果，是最便宜的成本优化。若你的模型调用统一收口，Cloudflare AI Gateway 提供缓存、日志、限流、重试与模型回退能力，并且对所有套餐开放——它是把「模型侧花了多少钱」变成可治理指标的最快方式，参考 Workers AI 与 AI 相关能力。注意 AI Gateway 的限流控制的是通往模型厂商的这一跳，不等同于面向终端用户的业务配额。

5. 账单级告警与熔断。 把「按目录/租户/端点的消耗」接入告警，并设硬熔断：达到阈值后自动降级到低档模型或排队。没有熔断，告警只是通知你钱已经花出去了。

配额阈值怎么反推

参数	反推方式	示例
单租户月额度	该套餐毛利 ÷ 单位调用成本 × 可承受成本占比	月费 100 元、毛利 60%、单位成本 0.02 元、可承受 30% → 900 次
单端点限次	按该端点单次成本是基准接口的倍数缩放	视频接口单次成本≈文本 40 倍 → 限次取 1/40
每分钟速率	正常用户峰值节奏 × 1.5，再按数据中心数量折算	人工峰值 20 次/分 → 单机房限 30 次/分；若流量分散到 4 个机房，边缘阈值应更紧
熔断阈值	月度预算的 80% 触发告警，100% 触发降级	预算 5000 元 → 4000 元告警

关键是阈值来自单位经济模型，而不是拍脑袋或抄默认值。同一套参数在不同毛利结构下的最优解完全不同。

Cloudflare 能力 vs 应用层职责

事项	Cloudflare 能给到的	应用层必须做的
异常频率抑制	Rate limiting rules（按套餐的条数与维度）	精确的全局速率上限（边缘计数跨机房不合并）
按成本限流	复杂度计分（ARL，需源站返回分值）	成本单位的折算逻辑与口径维护
租户/机制配额	可按请求头计数（高套餐）	权威配额账本：扣减、退还、跨服务一致
模型侧观测	AI Gateway 的请求/token/成本分析与缓存	把成本归因到具体租户、端点与功能模块
熔断与降级	规则动作（Block / 挑战 / 限流）	降级到低档模型或排队，且保证幂等不重复扣费

相关套餐明细见 AI SaaS 如何防止 API 被恶意调用？，其中列出了限流规则条数、计数维度与 bot 能力的完整对照表。

边界与不适用情况

• 长任务异步接口（视频生成、批量推理）不适合用每分钟速率限制，应该按「并发队列长度」限制，否则正常排队任务会被误判。
• 合作方集成的调用节奏由对方系统决定，速率限制容易误伤，应改为总额度 + 单独告警。
• 免费试用必须有硬上限，且上限要低于获客成本，否则增长越多亏得越多。
• 只靠边缘限流做止损是不够的：官方文档明确说 rate limiting rules 不是用来保证精确通过请求数的；真正兜底的是应用层账本 + 账单熔断。
• 不要忽视 429 之外的选项：对被限流的 AI 请求，返回可重试的排队语义、降级模型或缓��结果，往往比直接 429 更符合业务目标。

FAQ

限流返回 429 会不会伤害真实用户？ 会，所以 429 应该是最后一道。正确顺序是：缓存命中 → 识别后降级/排队 → 挑战 → 最后才是拒绝。把 429 当前置手段说明前四层没做。

复杂度计分（按成本限流）一定要 Enterprise 吗？ 是的。按官方文档，复杂度计分只对购买了 Advanced Rate Limiting 的 Enterprise 客户开放。如果你的套餐不在这个范围，等价做法是：在应用层把请求折算成成本点数并自行计数，边缘仍按 IP/路径做粗粒度抑制。

需要什么套餐？ 边缘限流的基础能力在免费档即可用，但只有 1 条规则、计数维度仅为 IP、计数周期固定为 10 秒；Pro 为 2 条规则、最长 1 分钟周期，Business 为 5 条、最长 10 分钟且支持请求头维度，Enterprise 通常为 100 条、最长 65,535 秒并开放全部计数维度。按 JSON 正文字段、表单字段或 JWT 声明计数，以及按成本限流，都需要 Enterprise + Advanced Rate Limiting。规模化的判断标准是「能否按业务维度（套餐、租户）计数」，而不是规则条数。

异常流量和正常高峰怎么区分？ 看三个不变量：请求来源分布是否与历史一致、请求节奏是否符合人类操作间隔、调用端点组合是否合理。高峰期这三个特征仍然成立，攻击期至少有一个不成立。

已经超支了怎么办？ 先熔断（切降级模型或排队）止血，再按端点维度拆账单定位消耗源头，最后补配额。顺序反了会一边修一边继续烧钱。

相关阅读

• AI SaaS 如何防止 API 被恶意调用？
• API Key 泄露后如何防止被滥用？
• AI 应用如何防止批量注册和刷免费额度？
• 如何区分正常访客与恶意 Bot？
• 完整解决方案