现场是这样的。用 Envoy 1.30 的 local_ratelimit 给上游模型接口限流，配置写 100 次每秒，实际 8 个 Pod 合计能打到 800 次每秒，上游直接 429。
中间走过弯路，把「没有接全局限流服务」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。本地限流按实例生效 不共享状态；token_bucket 的 max_tokens 设成了 100；上游配额按组织而不是按实例。
上来先确认限流是本地还是全局
grep -n local_ratelimit deploy/envoy.yaml接着按 Pod 数折算单实例阈值
python -c "print(100//8)"随后接入全局限流服务统一计数
grep -n ratelimit_service deploy/envoy.yaml压测看总 QPS 与 429 比例
hey -z 30s -q 200 -c 50 http://gw.example.com/v1/chat同事提醒我看一下最近一次发布，时间点确实对得上。
命令输出我都留了记录，免得改完记不清原来的值。
怎么算真的好了，看的是同一批现象。8 个 Pod 合计 QPS 稳定在 100 附近，上游 429 比例降到 1% 以下。
提醒一点。本地限流适合兜底防雪崩，不能当配额管理用，真正的总量控制要放在共享存储或限流服务上。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。