Universal LLM API Proxy：给 AI 工具装一个「万能钥匙」

想象一下：你的团队里有的人用 Claude Code，有的人用 Cursor，有的人用国产大模型，每个工具都要单独配置 API Key。如果能只维护一套凭证，通过一个统一入口访问所有大模型——LLM-API-Key-Proxy 就是来解决这个问题的。

图1：项目作者头像

背景故事：API 碎片化之痛

大模型江湖诸侯割据：OpenAI 的 GPT 系列、Google 的 Gemini、Anthropic 的 Claude、DeepSeek 的性价比路线……每个提供商都有独立的 API 端点、认证方式和限流策略。开发者如果想在应用里同时调用多个模型，往往需要写大量适配代码来处理各种格式差异。当某个 Key 触发限流时，应用就会卡住，用户体验直线下降。

个人开发者 Mirrowel（GitHub @Mirrowel）自己先用 Claude Code 写代码，又想接入 Gemini 的免费额度，还想用 DeepSeek 降低成本——但每个工具只认自己对应的 API Key。在这种需求驱动下，他决定写一个本地代理层，把所有大模型的接口统一成 OpenAI 和 Anthropic 的兼容格式。

核心功能：一套 API，访问 100+ 大模型

LLM-API-Key-Proxy 由两个组件构成，共同组成一个完整的解决方案：

1. API 代理层（FastAPI 应用）

这是用户直接交互的部分，一个自托管的 FastAPI 服务器。它提供两类兼容端点：

• OpenAI 兼容：/v1/chat/completions、/v1/embeddings 等标准端点，应用不需要任何改造，只需把 base URL 指向本地代理。
• Anthropic 兼容：/v1/messages、/v1/messages/count_tokens 等端点，让 Claude Code 等只认 Anthropic SDK 的工具也能使用 Gemini、DeepSeek 等第三方模型。

路由方式极为直观——在模型名里加提供商前缀，例如 gemini/gemini-2.5-flash 走 Gemini 路由，deepseek/deepseek-chat 走 DeepSeek 路由。所有 100+ LiteLLM 支持的提供商均可用这种方式接入。

2. 弹性密钥库（rotator_library）

这是底层引擎，负责所有复杂工作。rotator_library 维护一个 API Key 池，支持：

• 密钥轮转：多个 Key 时自动轮换，单个 Key 触发限流自动切换下一个，保证请求不中断。
• 冷却管理：每个 Key 有独立的冷却计时器（cooldown），被限流的 Key 不会被立即重用，而是等待冷却期满。
• 并发控制：可对单个 Key 设置最大并发数，避免超出服务商限制。
• OAuth 支持：内置 OAuth 凭证管理器，支持 Gemini CLI 等需要 OAuth 认证的提供商。
• 批量优化：batch_manager 对高容量 embedding 请求做合并优化，减少 API 调用次数。
• 用量追踪：usage 模块持续记录每个 Key 的使用量、窗口限流、并发使用情况，并支持持久化到本地 JSON 文件。

rotator_library 采用 LGPL-3.0 许可证，是一个独立可复用的 Python 库，不绑定 proxy_app 使用。

技术架构：分层解耦的清晰设计

项目代码结构分为两大块：

目录	许可证	职责
src/proxy_app/	MIT	FastAPI 网关、请求路由、TUI 启动器
src/rotator_library/	LGPL-3.0	API Key 管理、错误处理、用量追踪

proxy_app 通过 RotatingClient 类调用 rotator_library，两层之间通过清晰接口解耦。provider 层采用工厂模式（provider_factory.py），新增一个 Provider 只需实现 ProviderInterface 并注册即可，目前内置支持的提供商包括：

• OpenAI / Azure OpenAI：官方 API
• Google Gemini：含 Gemini CLI Provider（支持 OAuth）和标准 Provider
• Anthropic：Claude API
• DeepSeek：性价比路线
• Groq / Mistral / Cohere / NVIDIA NIM / Perplexity / OpenRouter 等
• 自定义：通过环境变量配置 PROVIDER_UPPER_API_BASE 接入任意 OpenAI 兼容端点

核心依赖方面，FastAPI + Uvicorn 驱动 Web 层，LiteLLM 作为统一的 provider abstraction 层，Python-dotenv 管理配置，Rich 提供终端 UI 渲染，CustomTkinter 提供图形化模型过滤界面。

上手体验：TUI + Docker 双轨并行

项目提供了极为平缓的上手曲线，无论技术背景如何都能快速启动：

方式一：Docker 一键部署（推荐）

git clone https://github.com/Mirrowel/LLM-API-Key-Proxy.git
cd LLM-API-Key-Proxy
cp .env.example .env
# 编辑 .env 填入 API Key
docker compose up -d

docker-compose.yml 配置了完整的多层日志（JSON 文件滚动）、OAuth 凭证持久化目录和用量统计目录。另有 docker-compose.tls.yml 支持 TLS 终端加密，docker-compose.dev.yml 用于本地开发调试。

方式二：本地 TUI 启动器

git clone https://github.com/Mirrowel/LLM-API-Key-Proxy.git
cd LLM-API-Key-Proxy
python src/proxy_app/main.py

无参数运行会自动进入 TUI 模式（基于 Rich 库的彩色终端界面），提供交互式菜单引导配置 API Key、启动代理、查看用量等操作，全程不需要手动编辑配置文件。

接入 Claude Code 示例：在 Claude Code 的 settings.json 中配置代理地址即可，proxy 层自动把请求翻译成目标提供商的格式。

局限性：不回避的问题

项目并非没有短板，部署和使用时需要注意以下几点：

1. 自托管运维成本：需要自己维护代理服务器，如果 API Key 泄露或代理服务宕机，应用就会中断。生产环境需要额外的负载均衡和监控方案。

2. 安全边界：PROXY_API_KEY 是保护代理访问的唯一屏障，官方文档也承认未设置时是"INSECURE"状态，需要用户自行妥善管理。

3. 密钥暴露风险：虽然不需要给每个应用都配置所有 Key，但如果代理本身被攻破，所有 API Key 都会暴露，需要在内网或 VPN 环境下使用。

4. 功能复杂度带来的学习曲线：rotator_library 的配置项较多（冷却时间、并发数、选择策略等），TUI 界面虽降低了门槛，但高级用法仍需阅读文档。

5. 双许可证风险：proxy_app (MIT) 和 rotator_library (LGPL-3.0) 使用不同许可证，在将 rotator_library 作为独立库集成到商业项目时需要关注 LGPL 的传染性条款。

行业意义：本地 AI 基础设施的「瑞士军刀」

LLM-API-Key-Proxy 的走红反映了 2025-2026 年 AI 开发领域的一个显著趋势：从追求单一最强模型，转向多模型协同与成本优化。开发者不再执着于 GPT-4o，而是根据任务类型选择最合适的模型——简单任务用 Gemini Flash，免费量大；复杂推理用 Claude；代码任务用 DeepSeek Coder。

这个项目让这种「模型组合拳」的策略变得前所未有的简单。一个代理层，把所有的复杂性都封装在内，开发者只需要记住一套 endpoint。而且 rotator_library 的设计本身是可复用的，未来可以应用到更多场景，不仅仅是这个代理项目。

截至目前，项目已获得 511 颗 GitHub Stars，支持 100+ 提供商，活跃维护中。