GPROXY v2：一个网关，连接所有大模型

一把万能钥匙，告别 API 切换的烦恼

想象一个这样的场景：你正在开发一个 AI 应用，最初接入了 OpenAI 的 GPT-4，效果不错。但某天 OpenAI 突然限流了，或者 GPT-4o 的价格涨了，你的应用面临两个选择：要么接受更高的成本，要么承担切换 Provider 的巨大改造成本。

GPROXY 就是来解决这个问题的。它是一个用 Rust 编写的 LLM（大型语言模型）代理网关，允许你同时接入 OpenAI、Anthropic Claude、Google Gemini、DeepSeek、GROQ、OpenRouter 等十余家大模型服务商，向应用程序暴露一个统一的 OpenAI 兼容 API。你只需改动一行配置，就能让应用从 GPT-4 切换到 Claude-3.5，而应用代码完全不用改。

图1：GPROXY 官方文档首页

背景故事：从痛点中诞生的基础设施

LLM API 路由并不是一个新概念。2023-2024 年间，随着 OpenAI API 独霸天下到 Anthropic、Google DeepMind 群雄并起，大量团队开始面临「多 Provider 管理」的需求。商业解决方案如 Bearly、PortKey、Neutral API 相继出现，而开源社区也涌现出 LiteLLM、FastChat 等项目。

GPROXY 的作者 LeenHawk 显然深度使用了 Claude Code 和 Codex 等开发工具，在 v1 版本的基础上大刀阔斧重写了 v2，核心目标是：高性能 + 强可观测性 + 零前端部署。

v2 的设计哲学非常明确——不做臃肿的平台级产品，而是做一个开箱即用的「盒子里的代理」。它用 Rust 实现保证性能，用单一二进制文件替代复杂的微服务依赖，用内置 React 控制台替代独立部署的 Web UI。这在同类开源项目中属于较独特的设计选择。

核心能力：不止于路由

GPROXY 的功能远不止「把请求转发给另一个 API」这么简单。它的能力矩阵可以分为四层：

第一层：协议转换。 这是 GPROXY 最核心的差异化能力。传统 LLM Proxy 只能做「透明代理」，GPROXY 实现了真正的跨协议转换——一个使用 OpenAI SDK 的应用，可以直接向 Claude 或 Gemini 发起请求，GPROXY 会自动将请求体转换为上游需要的格式，并将响应转回 OpenAI 兼容格式。这对于需要混合调用多个 Provider 的应用来说意义重大。

第二层：多租户与访问控制。 GPROXY 内置了完整的用户、API Key、权限体系。支持 glob 模式匹配模型权限（例如 gpt-4* 可访问哪些模型）、RPM/RPD/token 多维度限速，以及 USD 配额控制。这意味着你可以在 GPROXY 上为不同客户或团队开设独立账号，并精确控制其用量。

第三层：可靠性保障。 内置熔断器（circuit breaker）和凭证故障转移机制。当某个 Provider 超时或报错时，可以自动切换到备用 Provider，对于生产级应用非常重要。

第四层：可观测性。 完整的请求审计日志，支持 SQLite、PostgreSQL、MySQL 三种存储后端。可选对存储数据做静态加密，满足合规要求。

部署体验：真的可以「三分钟上手」

GPROXY 的部署体验在同类开源项目中属于顶尖水平。它提供三条部署路径：

路径一（最推荐）：Docker。 一行命令即可运行：

docker run -d -p 8787:8787 -e GPROXY_ADMIN_PASSWORD=change-me ghcr.io/leenhawk/gproxy

GPROXY 官方提供了多平台预编译镜像（glibc 和 musl 两种），容器基于 Google Distroless 镜像，仅包含运行时，镜像体积极小（估算 < 30MB）。数据卷挂载到 /data 即可持久化存储。

路径二：直接下载二进制。 无需 Docker 的环境，直接从 GitHub Releases 下载对应平台的压缩包，解压运行即可。GPROXY 会自动内嵌 React 控制台资源，无需额外安装 Node.js。

路径三：Edge 部署。 支持 Cloudflare Workers、Deno Deploy 和 Netlify Edge Function，这使得 GPROXY 可以部署在边缘节点，实现极低延迟的 API 代理。

所有路径的统一入口是 GPROXY 内置的 React 管理控制台，地址是 /console。首次登录需要设置管理员密码，之后可以在控制台中配置 Provider、添加用户、设置限速策略、查看审计日志。

图2：GPROXY 内嵌管理控制台

技术架构：Rust 写的它，强在哪？

GPROXY 采用了 Rust 语言实现，这是它区别于 LiteLLM（Python）、FastChat（Python）等主流开源 LLM Proxy 的显著特征。

性能优势。 Rust 的内存安全特性和零成本抽象让它在网络 I/O 密集型场景中表现出色。GPROXY 作为 API 网关，需要处理大量并发 HTTP 请求，Rust 的 async runtime（Tokio）配合高效 HTTP 库，可以实现远高于 Python 的吞吐量和更低的延迟。

架构设计。 GPROXY v2 采用 Workspace 架构，项目根目录包含主程序，三个核心子 crate 分别负责协议处理（gproxy-protocol）、Token 计费（gproxy-tokenize）和响应转换（gproxy-transform）。这种模块化设计让各功能职责清晰，也便于后续扩展新的 Provider 支持。

关键依赖。 从 Cargo.toml 可以看到，GPROXY 使用了：axum（HTTP 框架）、serde（序列化）、jsonwebtoken（JWT 鉴权）、chacha20poly1305（数据加密）、blake3（哈希）、rust_decimal（精确金额计算，用于 USD 配额计费）。没有引入重型 ML 依赖，保持了二进制体积的精简。

Web 前端。 控制台采用 React + TypeScript 实现，通过 Deno 工具链构建，最终产物以静态资源形式嵌入二进制文件。Dockerfile 中明确标注了构建流程：Rust 二进制先在 CI 中编译好，再传给 Dockerfile 作为构建阶段输入，最终镜像只包含运行时。

许可证： AGPL-3.0，开源但有传染性。如果要将 GPROXY 集成到商业产品中需要关注这一限制。

适用场景与局限

GPROXY 最适合的场景：

• 团队同时使用 2+ 个 LLM Provider，需要统一管理 API Key 和用量
• 需要为不同客户/项目分配独立 API Key 并精确计量费用
• 对 API 响应延迟敏感（Rust 性能优势）
• 希望部署简单，不想要复杂的微服务依赖

需要注意的局限：

• AGPL-3.0 许可证限制了部分商业使用场景
• 不支持本地模型（Ollama 等），只做远程 API 代理
• Edge 部署（Cloudflare Workers）依赖特殊的 WASM 构建，当前仅支持基础路由功能
• docker-compose 并非开箱即用，需要自行编写（deploy/ 目录未提供 compose 文件）

行业意义

GPROXY 所在的 LLM Gateway 赛道正在快速成熟。GitHub Topics #llm-proxy 下已有数十个活跃项目，而 TrueFoundry、Gravitee 等商业平台也在今年相继推出了类似功能。GPROXY 的独特价值在于：用 Rust 的性能 + 单一二进制的简洁 + 内嵌控制台的省心，填补了轻量级开源 LLM Proxy 市场的空白。

对于个人开发者和小型团队来说，GPROXY 提供了一条几乎零成本的多 Provider 管理路径；对于需要高吞吐量的生产环境，Rust 实现也提供了足够的性能保障。随着 v2 版本的成熟和更多 Provider 的接入，这个项目有潜力成为 AI 应用基础设施的重要组成部分。