39 用令牌桶算法实现RT-DETR推理API的速率限制与配额管理开篇故事上周三凌晨2点，我正在睡觉，手机突然疯狂震动——生产环境的RT-DETR推理API告警了。我迷迷糊糊爬起来一看，监控面板上GPU利用率从30%瞬间飙到98%，P99延迟从80ms暴涨到2.3秒。赶紧登录服务器，发现有个用户用脚本在疯狂并发调用，每分钟请求量从正常值50次飙到了3000多次。更糟糕的是，这个用户用的是我们刚上线的OAuth2.0认证系统（上篇的内容），他的JWT Token是合法的，所以认证网关放行了所有请求。但我们的推理服务没有做任何速率限制，GPU直接被冲垮，导致其他正常用户的请求全部超时。第二天早上，我收到了3个付费客户的投诉邮件。痛点拆解很多人在做推理API时，只关注了认证和授权，却忽略了速率限制这个关键环节。我见过太多错误实现，最典型的是下面这种：# 错误实现：在应用层做全局计数器importtimefromcollectionsimportdefaultdict