LLM 应用的速率限制与滥用防护：别让人刷破产你

贴在门口的信用卡

传统 Web 应用的滥用防护再差，单次请求的成本也只有几毫秒 CPU——刷垮你的是带宽与算力。LLM 应用的性质完全不同：每一次调用都对应真实的推理成本（一次长上下文的调用可能花掉几块钱）——没有滥用防护的 LLM 应用，等价于把一张不设限额的信用卡贴在门口。安全事件不再只是「服务变慢」，是「财务报表直接出血」。

这篇把 LLM 应用的速率限制与滥用防护讲成一门工程学：限流算法的选型、配额的分层设计、滥用模式的识别，以及「成本攻击」这种 LLM 特有威胁的防御。

限流算法的选型：四种武器

固定窗口（Fixed Window）：单位时间内的请求数上限（每分钟 60 次）——实现最简单，缺陷是窗口边界的双倍突刺（第 59 秒 60 次+第 61 秒 60 次=两秒 120 次）。滑动窗口（Sliding Window）：滚动统计最近 N 秒的请求数——消除边界突刺，实现稍复杂（Redis 的 ZSET 实现是主流方案）。令牌桶（Token Bucket）：桶容量（突发上限）+恒定注入速率（平均速率）——允许短时突发、约束长期平均——这是 LLM API 限流的主流选型（真实用户的突发模式友好、滥用者的持续消耗被平均速率卡住）。漏桶（Leaky Bucket）：恒定流出速率——请求被匀速处理——适合保护下游（推理服务的吞吐是刚性的——漏桶保护 GPU 队列不被突发打爆）。

LLM 特有的限流维度：传统限流数「请求次数」，LLM 限流还要数「token」——一次请求的成本与输入输出 token 数成正比——按 token 限流才是成本对齐的限流（每用户每小时的 token 总预算——「你这一小时用了 50 万 token，超出部分拒绝」——请求次数限不住「一次塞 10 万上下文」的滥用，token 预算限得住）。

graph TD
    A[限流算法四选型] --> B[固定窗口<br/>最简单 · 窗口边界双倍突刺]
    A --> C[滑动窗口<br/>消除突刺 · Redis ZSET 主流]
    A --> D[令牌桶<br/>允许突发 · LLM API 主流选型]
    A --> E[漏桶<br/>恒定流出 · 保护下游 GPU 队列]
    F[LLM 特有维度] --> G[按 token 限流<br/>成本对齐 · 请求次数限不住大上下文]

分层配额的设计：谁可以烧多少

限流的维度之上是配额的体系设计——「谁、在什么边界内、可以烧多少」的三层结构：

账户层配额：注册用户的免费额度与付费档位（免费用户每天 N 次调用、付费档位解锁更高配额——配额与商业模式的对齐：免费额度是获客成本，上限的设定要卡住「薅羊毛的规模化」——一个手机号注册一万个号的对抗，靠的是配额外的设备指纹与支付验证）。会话层限制：单次对话的上下文上限、单日会话轮数——「单会话的失控」（一个用户开着对话让模型无限续写——会话层的轮数与 token 上限是最后一道闸）。系统层保护：全局的并发上限与降级开关（所有用户共享的推理资源池——全局限流保护的是平台自己——突发流量（产品爆火的那一夜）的排队与降级机制——「排队优于宕机，降级优于破产」）。

多租户的配额隔离：B 端场景的租户配额（每个企业客户的独立预算——「吵闹邻居」问题（一个租户的滥用拖垮所有租户——按租户的令牌桶+租户间的公平调度——多租户 RAG 篇的隔离逻辑在限流维度的延伸）。

滥用模式的识别：四类敌人与它们的指纹

敌人一：成本攻击（cost attack）——恶意消耗你的推理费用（注册大量账户刷免费额度、构造超长上下文的请求——指纹：新账户的异常调用模式、上下文长度的异常分布、支付方式与设备的关联性——防御：设备指纹+支付验证+新账户的渐进配额（新号先给小额度，行为正常再提升）。敌人二：数据窃取——通过大量查询提取训练数据或系统提示词（模型窃取篇的攻击在应用层的形态——指纹：查询的覆盖模式（系统性的枚举式提问）、对同一模板的变体轰炸——防御：异常检测（查询分布的漂移告警）+输出过滤（敏感内容的出站过滤）。敌人三：内容滥用——用你的产品生成违规内容（钓鱼文本、诈骗话术——指纹：输出的内容特征（滥用检测的分类器）+输入的模式（批量生成的模板化输入）——防御：输出的内容安全审查（入库前的分类器）+滥用内容的用户封禁。敌人四：资源占用的机器人——爬虫式的大规模调用（爬取你产品的输出做数据集——robots 协议对 API 无效——指纹：请求的规律性（固定间隔、固定 UA）、无真实用户的交互模式——防御：行为验证（异常时的 captcha/验证）、以及「蜜罐标记」（响应中埋入独特的不可见标记——数据被爬走后可溯源）。

成本攻击的纵深防御清单

把上述内容收敛成一份防御清单（按纵深排列）：第一道：入口验证（注册的验证强度、设备指纹、支付验证——把「匿名滥用」的门槛抬高）。第二道：配额硬限制（账户/会话/系统三层配额——超限的默认动作是拒绝而不是告警——告警需要人，拒绝是机器的自动防线）。第三道：异常检测（调用模式的实时监控——token 消耗的异常告警（某用户本小时消耗是基线的 100 倍）、查询分布的漂移检测）。第四道：成本的熔断（全局成本的熔断开关（今日推理花费超阈值——自动降级或停止非核心服务——「花钱的熔断器」与「宕机的熔断器」并列——财务安全也是可用性安全）。第五道：审计与追偿（滥用的日志留存（追责与封禁的证据）、以及「滥用者的成本追偿」（ToS 中的滥用条款——重大滥用的法律追偿—— deterrence 的最后防线）。

限流的工程实现与「限流的新维度」

速率限制的落地工程与 LLM 带来的新维度。工程实现的技术栈：Redis 的分布式限流（ZSET 的滑动窗口实现、令牌桶的 Lua 原子脚本——「原子性」是分布式限流的命门（多节点的限流状态同步——Redis 的单线程原子操作保证「检查-扣减」不被并发击穿——「竞态条件」的经典漏洞（先查后扣的两步操作在并发下被击穿——Lua 脚本把「检查+扣减」原子化——一个细节决定限流是否真的有效。网关层的限流（API 网关的限流插件——「限流的位置」（网关层挡量、应用层挡质量——网关限「请求」、应用限「token」——两层的分工）。LLM 的新维度一：按 token 的多维限流：输入 token 与输出 token 的分别限制（输出的 max_tokens 的硬上限——「输出的失控」（模型的超长输出（没有 max_tokens 限制的长回答——token 消耗失控——max_tokens 的强制默认值（应用层强制设置、用户不可调——「模型的自我克制」是成本控制的第一道。维度二：按「成本权重」的限流：不同模型/功能的成本差异（高端模型×20 的成本系数——「成本加权的配额」（用户的配额是「成本额度」而非「次数」——选高端模型扣 20 倍额度——「额度制优于次数制」的成本对齐。维度三：流式响应的特殊处理：SSE 流式的限流（流式输出的中途取消——「流式的成本核算」（流式响应的成本在结束时才确定——流的中断与异常的处理（半途而废的流的 token 计账——「流式计账」的细节坑。降级的设计艺术：超限时的用户体验（硬拒绝的生硬 vs 降级的柔性——「降级的阶梯」（超限→排队→缩小上下文→切换便宜模型→最终拒绝——「切便宜模型」的降级（额度用尽的用户降级到低成本模型——服务继续但质量降档——「降级不降服」的用户体验设计——降级的设计决定「超限用户」是流失还是付费升级——限流的设计终点是商业模式：把「拒绝」变成「升级的理由」。

高频问答：速率限制的边界

收尾前回答三个高频问题。「限流该按用户还是按 IP？」——按用户为主、IP 为辅：「按用户」的正当性（真实用户跨 IP 使用、NAT 后多用户共享 IP——按 IP 限流误伤 NAT 用户——「按用户+设备指纹」的组合——IP 限流作为兜底（无登录场景——「场景决定维度」：登录产品按用户、公开 API 按 IP+Key。「限流要不要支持超额付费？」——要，且是商业模式的一部分：「超额付费」的设计（超限后的按量计费（预充值扣款——「超额的柔性拒绝」（预充值耗尽才硬拒绝——「付费墙的顺滑」——限流的终点是变现——「限流即定价」的产品观。速率限制的问答收束：限流工程的终极检验是「恶意用户烧不穿你、付费用户玩得爽」——两句话，四个字：防得住，放得开。

小结

LLM 应用的滥用防护是一门用「元」计价的工程学：限流算法的选型（令牌桶为主流、按 token 限流才是成本对齐）、配额的三层设计（账户/会话/系统——配额与商业模式对齐）、四类滥用敌人的指纹（成本攻击、数据窃取、内容滥用、资源占用）与纵深防御的五道清单（入口验证、配额硬限、异常检测、成本熔断、审计追偿）。传统安全里「滥用」是可用性问题，LLM 时代它是可用性+财务+合规的三重问题——每一次没防住的滥用都是三本账同时出血。检查你的 LLM 应用有没有把「信用卡贴在门口」：问三个问题——免费额度能被批量薅吗？token 消耗有全局熔断吗？异常的调用模式有人看吗？三问都过不了，先补这道防线再谈其他安全。

限流 protecting 的不只是你的服务器，是你的利润表——在 LLM 的世界里，安全工程与财务工程已经合流。