[Bug]: Incorrect TPM limiting for virtual keys

快速结论：这个报错通常出现在 LiteLLM Proxy 给虚拟 Key 同时配置了 TPM 与 RPM 限流时，实际限流触发点明显低于配置值（如配置 500k TPM，实际在 300k–350k 触发），并伴随 2–5 分钟的冷却期。优先检查虚拟 Key 是否同时设置了 RPM 和 TPM，以及代理版本是否仍在旧限流逻辑上。

适用环境：LiteLLM Proxy v1.82.3、v1.82.3-stable.patch.2、v1.86.2；Issue 中另提到在 current main（v1.91.0）默认代理配置下无法复现。后端出现过 Bedrock。Issue 未明确给出操作系统、Python、CUDA、显卡信息。

最快修复方案：暂无确认的一步修复方案。Issue 中未给出被验证过的固定修复步骤；可优先尝试升级到默认启用 TPM reservation 的较新版本（讨论中提到 v1.91.0 默认路径已可能修复）。

注意事项：“v1.91.0 默认路径已修复”来自复现者的观察，并非维护者确认的最终结论，且需要确认你的代理确实启用了 TPM reservation。若仍同时配置 RPM 和 TPM，旧版本上的共享窗口计数问题仍可能触发误限流。

问题场景

在 LiteLLM Proxy 中为虚拟 Key 配置 TPM（每分钟 token 数）限制，并同时设置 RPM（每分钟请求数）限制。用户正常以较低速率调用模型时，却提前触发 429 限流。Issue 中给出的复现方式为：配置一个带有 TPM 上限的 API Key（例如 500k），使用后限流在约 300k–350k 就触发。另有复现者用 200 TPM 限制、每 10 秒发送一次 20 token 请求，约 20 次请求后触发限流；移除 RPM 后该复现不再出现。

报错原文

[Bug]: Incorrect TPM limiting for virtual keys

429: Rate limit exceeded for team: ... Limit type: tokens. Current limit: 2000000

原因分析

可能原因与限流窗口的计数器重置逻辑有关。讨论中指出 parallel_requests_limiter_v3.py 中存在类似 if window_start is None or (now_int - int(window_start)) >= window_size: 的判断，TPM 和 RPM 各自有窗口，但 60 秒窗口计数器可能被共享。当 TPM 先被检查并触发窗口重置时，循环可能不会继续执行到 RPM，导致 RPM 窗口重置被跳过；反过来说，在同时设置 RPM 与 TPM 时，窗口重置时序会造成 TPM 计数无法按预期清零，从而提前触发限流。

需要注意，复现者观察到仅设置 TPM、不设置 RPM 时不一定复现；但原报告者表示在只有 TPM 限制的 Key 上也观察到过该行为。因此上述共享窗口逻辑可能是主要原因，但未必是唯一原因。

环境排查

确认 LiteLLM Proxy 版本：问题在 v1.82.3、v1.82.3-stable.patch.2、v1.86.2 上出现；讨论提到 current main v1.91.0 默认配置下未复现。
确认虚拟 Key 的限流配置：是否同时设置了 RPM 和 TPM，以及具体数值。
确认是否使用默认 rate limit type 和默认配置。
确认代理是否启用默认的 TPM reservation（讨论中提到这是当前默认配置）。
确认后端模型：Issue 中提到 Bedrock 在该时段 TPM 约稳定在 500k。
确认触发限流后的冷却行为：是否持续约 2 分钟，极端情况下达到 5–7 分钟。

解决步骤

记录当前代理版本，确认是否在 v1.82.3、v1.82.3-stable.patch.2 或 v1.86.2 这类旧版本上。
检查出问题虚拟 Key 的限流配置，确认是否同时存在 RPM 与 TPM；这是复现者认为最容易触发问题的组合。
可优先尝试升级到默认启用 TPM reservation 的较新版本，例如讨论中提到的 v1.91.0 附近或更高版本；升级后按原复现方式验证是否还会提前 429。
如果升级后仍复现，检查代理配置中 TPM reservation 是否确实处于启用状态，避免使用与默认路径不同的旧限流配置。
临时规避时，可尝试在复现环境中移除 RPM 限制，仅保留 TPM，观察是否还提前触发限流；但该规避并非对所有报告者都有效，只能作为排查手段。
如果问题仍存在，使用 Issue 中给出的脚本（每 10 秒一次 20 token 请求、TPM 设为 200、同时设置 RPM）进行对照记录，便于向维护者提供窗口边界附近的计数日志。

验证方法

在配置了 TPM 与 RPM 的虚拟 Key 上，以明显低于两个限制的速率持续调用（例如每 10 秒一次小请求），观察是否仍在约 3 分钟或约 20 次请求后收到 429: Rate limit exceeded ... Limit type: tokens。同时确认 token 计数是否在每 60 秒窗口边界正常重置，以及触发限流后冷却时间是否恢复到预期范围，而不是持续 2–7 分钟。若在 v1.91.0 默认 TPM reservation 路径下长时间运行均不再出现 false 429，可视为该问题已改善。