用途：解决 LangChain 1.0 调用模型提供商时的限流问题，尤其是多 worker 部署下 InMemoryRateLimiter 按进程计数导致集群整体超限（P29）的场景。
主要能力：给出从测量需求到选择限流方案的完整流程。先用 BaseCallbackHandler 记录 input_tokens、output_tokens、cache_read_input_tokens，收集 24-48 小时流量后按 p95 的 70% 设定限流值；单进程开发用 InMemoryRateLimiter，多 worker 生产必须改用 Redis 后端限流器（滑动窗口 Lua 或 CL.THROTTLE GCRA），并可用 asyncio.Semaphore 限制单 worker 在途并发；同时强调 with_fallbacks 的 exceptions_to_handle 必须收窄为 RateLimitError、APITimeoutError、APIConnectionError、InternalServerError，避免捕获 Exception；max_retries 建议设为 2 而非默认 6，防止一次调用被计费 7 次。还梳理 RPM、ITPM、OTPM、并发、缓存读写等提供商限额类型，并给出 Anthropic 缓存写入同样计入 RPM 的提醒。
使用方式：安装 langchain-core 1.0.x 及对应提供商包，多 worker 场景需 redis>=4.5 客户端与可访问的 Redis 服务；将 rate_limiter 参数挂到 ChatAnthropic/ChatOpenAI 等模型上，配合 Semaphore 与收窄的 fallback 异常元组。
适用场景：Cloud Run、K8s、ECS 等多副本部署，多租户 SaaS 的按租户与全局两级限流，以及缓存密集型 Anthropic 工作负载。
限制：InMemoryRateLimiter 仅适用于单进程；Redis 不可用时需在 fail-open 与 fail-closed 间取舍；提供商限额会变动，需在发布前重新核对官方控制台。具体实现代码与完整异常白名单见原文引用资料。