北京
周二上午十点，你的企业客户CEO正在向董事会演示AI功能。两分钟后，页面弹出429错误。原因？某个免费用户在后台用脚本批量处理支持邮件，耗尽了整分钟的API额度。
这不是假设。一个团队告诉我，他们第一次遇到这事后加了"每租户每分钟20请求"的限制。然后月底有租户做报表 burst 到40次，被限流后投诉。他们提到100。另一个租户跑脚本。循环到第三轮，单租户限额已经高到20个租户加起来仍能打爆上游密钥。那个"简单限制"成了YAML里的摆设。
问题出在单位选错了。LLM SaaS的稀缺资源是上游每分钟token数，不是请求数。一次32K上下文摘要调用，相当于60次分类请求。按请求计费、排队或限流，你的桶在撒谎。
Token预算在限流层之上。它回答的是：给定有限的上游token供给，怎么分才能让吵闹的租户饿不死安静的，付费的不排在免费的后面。
桶的形状很简单：每个租户有tokens_remaining计数器和refill_rate。请求按预期token成本（prompt + max_tokens）扣减；桶以每秒refill_rate refill，到上限封顶。预期成本定义上就是错的——模型实际输出通常更少——但误差跨请求平均掉，桶的形状是对的。
下面这个模式从上到下，每个解决上一层制造的问题。
最底层：扔掉"每分钟N请求"。它惩罚突发、无视token成本、把200 token分类和40K token摘要同等对待。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
