LLM Gateway：企业级 LLM 请求路由与治理平台

想象一下：你的团队同时在使用 OpenAI GPT-4、Anthropic Claude、Google Vertex AI 等多个大模型服务，每个服务都有独立的 API Key、计费账单和使用监控。当业务快速发展时，这种分散管理的混乱程度不亚于管理 10 个没有统一报表的银行账户——你根本不知道钱花在哪里，也不知道谁用得最值。 LLM Gateway 正是为解决这个痛点而生的开源项目。它是一个专门面向 LLM 请求的 API 网关，核心功能是：把所有大模型的 API 请求汇总到一个入口，通过统一接口转发到不同 provider，同时自动记录每一次请求的 token 用量、响应延迟和成本开销。 图1：LLM Gateway 架构概览——统一入口，多 provider 路由

背景：LLM 工具碎片化的行业痛点

2023-2024 年是大模型应用爆发期，企业普遍采用多 provider 策略：主力模型用 GPT-4，代码场景用 Claude，处理长文档用 Gemini，同时 A/B 测试新模型。这种策略带来了显著的管理负担——每个 provider 有独立的 API Key 管理、日志记录、预算控制和性能监控。 TheOpenCo 团队在内部实践中意识到这一点，决定将 LLM 网关能力抽取为独立开源产品。LLM Gateway 的 GitHub 仓库于 2024 年初创建，迅速获得 1200+ stars，体现了开发者社区对「LLM 统一治理」解决方案的强烈需求。

核心功能：从请求到账单的全链路管控

统一 API 接口

LLM Gateway 实现了与 OpenAI API 格式的完全兼容，开发者只需将代码中的 https://api.openai.com 替换为 LLM Gateway 的地址，即可无缝切换到多 provider 路由模式。这意味着现有基于 OpenAI 的应用无需修改代码，就能自动获得多模型切换、成本追踪等能力。对于正在评估不同模型效果的研发团队，这大幅降低了实验成本。

多 Provider 路由

支持的 provider 包括：OpenAI（GPT 系列、Codex）、Anthropic（Claude 系列）、Google Vertex AI（Gemini 等）。路由策略可以按模型名称静态配置，也可以通过中间件动态选择。split 部署模式下，Gateway 和 API 服务分离，支持更高并发的生产环境。

用量分析与成本追踪

每一次 LLM 请求的 token 消耗、响应延迟、错误率都会被记录到 PostgreSQL 数据库。通过 playground（独立 Web UI）可以直接查看各模型的成本效益对比图——例如「GPT-4o 单 token 成本是 Claude 3.5 Sonnet 的 3 倍，但在这类任务上速度仅快 15%」。这种量化对比让决策者可以科学地选择模型组合，而不是凭感觉。

API Key 统一管理

不再需要在每个微服务里分散配置多个 provider 的 API Key。所有密钥统一存放在 Gateway 侧，应用层只需持有 Gateway 的一个访问令牌即可。这不仅降低了密钥泄露风险，也简化了 key 轮换的操作流程。

技术架构：Monorepo + 微服务设计

LLM Gateway 采用了 pnpm monorepo + Turborepo 构建方案，整个项目包含 7 个应用和 8 个共享包：

前端技术选型

Web UI 基于 Next.js（TypeScript）构建，UI 组件库细节未完全公开但从 postcss.config.mjs 和 components.json 可推断使用 Tailwind CSS。整体采用 React Server Components 模式，Next.js 15 版本。Playground 使用独立 Next.js 实例，方便单独部署。

数据库设计

使用 Drizzle ORM 作为类型安全的数据库抽象层，schema 存储在 packages/db/migrations。从 sql/ 目录可见有 mapping_history、blended_score 等分析相关表结构，说明用量分析是核心功能模块。

部署方式：灵活的三层部署选择

LLM Gateway 提供了三种部署路径，适合不同规模和使用场景： 统一镜像部署（推荐个人/小团队）：使用 ghcr.io/theopenco/llmgateway-unified:latest 单镜像，包含所有服务，通过 docker-compose.unified.yml 启动。一个命令即可拥有完整功能，端口映射到宿主机（3002-4002 各端口）。 分离架构部署（生产推荐）：Gateway、API、UI 等服务分离部署，通过 docker-compose.split.yml 编排，各服务独立扩缩容，适合高并发生产环境。 Helm K8s 部署：提供官方 Helm Chart，发布在 GitHub Container Registry 的 OCI 仓库。企业可通过 helm install llmgateway oci://ghcr.io/theopenco/charts/llmgateway 一键部署到 Kubernetes 集群。

安全与隐私

LLM Gateway 是纯本地部署方案，所有 API 请求日志、token 用量数据都存储在用户自己的 PostgreSQL 数据库中，不会外传。这是与 llmgateway.io 托管版本的关键区别——自托管版本适合对数据主权有严格要求的企业。 API Key 管理通过哈希加秘密（hash secret）保护，初始化时需通过环境变量配置双密钥：AUTH_SECRET 和 GATEWAY_API_KEY_HASH_SECRET，生产部署必须更换默认值。

局限与挑战

作为一个活跃开发中的项目（63 个 open issues），LLM Gateway 也面临一些现实挑战。首先，分离架构部署的学习曲线相对陡峭，需要理解 Gateway 与 API 服务的分离设计。其次，文档中提到的 Web UI 截图和 playground 截图未在仓库中公开，导致潜在用户无法直观评估界面体验。 此外，当前版本对 provider 的支持主要聚焦在头部三家（OpenAI/Anthropic/Google），对开源模型（如 Ollama 本地部署）的路由支持未在核心功能中体现。随着本地运行开源模型的需求增长，这可能成为未来路线图的重点。

行业意义

LLM Gateway 的出现反映了 LLM 应用进入「生产化治理」阶段的大趋势。2024 年下半年开始，LLM 网关/代理类工具（如 Portkey、LiteLLM、BoringLLM）开始密集涌现，LLM Gateway 作为开源替代方案，填补了 self-hosted 场景下的空白。 其 1200+ stars 和 145 forks 的数据表明，社区对这个方向的认可度较高。关键差异化在于它提供了完整的 Web UI（dashboard + playground），而不只是 API 转发层，这让它对非技术用户也更友好。 从技术趋势看，多 provider 路由、token 成本追踪、性能对比仪表盘正在成为企业 LLM 基础设施的标配。LLM Gateway 的架构设计对这一趋势给出了很好的开源实现参考。