LLM Denial of Service怎么防：长上下文、递归工具和批量任务都要限形

AI系统的DoS经常长得不像攻击

OWASP LLM风险里提到模型拒绝服务，本质是让系统消耗过多上下文、计算或工具资源。在真实业务里，它可能不是恶意压测，而是一个用户上传超大文件、一个Agent反复检索、一个工具递归调用失败重试。结果一样：延迟上升、账单放大、正常用户被挤掉。

限制请求形状，而不只是限制次数

只按请求数限流不够。AI请求的成本取决于输入Token、输出Token、上下文窗口、工具调用次数、检索文档数量和重试次数。更实用的做法是给不同任务设形状上限：单次最多读多少页、最多调用几次工具、最多生成多少Token、最多保留多少历史轮次。

递归和批量要单独治理

Agent最容易失控的是递归：搜索结果不满意继续搜、工具失败继续修、代码测试失败继续改。批量任务也类似，一个看似普通的导入动作可能触发几百个模型调用。网关侧应识别任务ID，把同一任务下的累计消耗算在一起，而不是把每次调用当孤立请求。

中转站的作用

通过 https://top-api.cc 这样的统一入口，团队可以把Token、模型、工具调用和项目预算放到同一张账里看。业务系统不用分别适配每个供应商的计费字段，也能在任务级别设置上限、告警和降级策略。

检查清单

• 是否限制输入、输出和历史上下文长度
• 是否限制单任务工具调用次数和递归深度
• 是否按任务ID累计成本，而不是只按单请求
• 批量任务是否有排队、暂停和取消能力
• 失败重试是否有最大次数和退避策略
• 超限时是否返回可解释错误，而不是继续烧钱

结语

LLM DoS防护不是把所有用户挡在门外，而是给每类任务定义可承受的资源形状。先限形，再限流，才能同时保护体验和账单。