当一个团队从「试用某个大模型」升级到「在多个项目里稳定使用多个大模型」，迟早会遇到这个问题：每个项目各自维护一套模型接入代码，换个模型或者改个 API Key 要改五个地方，还有人在 .env 文件里直接写密钥......这个时候，一个 LLM 网关的价值就出来了。
一、 LLM 网关 的核心职责
先列清楚一个网关应该做什么，这样设计的时候不会漏：
· **统一接口：**不管底层是 GPT、Claude 还是 DeepSeek，上层应用只调用一个标准接口，不关心底层差异
· **凭证管理：**API Key 集中存储，有权限管控，不散落在各个项目里
· **路由策略：**根据任务类型、成本、延迟，把请求路由到最合适的模型
· **限流与配额：**按用户、部门或应用设置 Token 消耗上限，防止单个来源打爆配额
· **可观测性：**记录每次调用的 token 消耗、延迟、错误，聚合成账单和报告
· **降级与重试：**主模型挂了，自动切到备用模型；超时重试，避免请求直接失败
二、统一接口的设计
主流大模型厂商的接口格式其实大同小异，基本都是 messages 数组 + 参数。设计统一接口时，核心决策是「抽象到哪一层」：
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| // 统一请求格式（对上层应用透明） POST /v1/chat/completions { 'model': 'gpt-4o', // 或 'claude-3-5-sonnet', 'deepseek-chat' 'messages': ..., 'max_tokens': 1000, // 可选：指定路由策略 'routing': { 'strategy': 'cost_first', // 或 'speed_first', 'quality_first' 'fallback': true } } |
网关内部做模型适配：不同厂商的参数名、认证方式、响应格式各有差异，统一在适配层处理，不暴露给上层。
|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| class ModelAdapter: adapters = { 'openai': OpenAIAdapter(), 'anthropic': AnthropicAdapter(), 'deepseek': DeepSeekAdapter(), 'qwen': QwenAdapter(), } def route(self, request): provider = self.resolve_provider(request.model) adapted = self.adaptersprovider.transform(request) return self.adaptersprovider.call(adapted) |
三、路由策略的实现
路由策略决定「这个请求给哪个模型处理」。几种常见策略：
3.1 基于成本的路由
不同模型 token 单价差异很大。对于不需要最强能力的任务，可以自动降级到便宜的模型。实现方式是给每个任务类型打标签，不同标签对应不同的成本预算。
3.2 基于能力的路由
代码生成任务路由到代码能力强的模型，长文档处理路由到大 context window 的模型，图像理解路由到多模态模型。需要维护一张模型能力矩阵。
3.3 基于负载的路由
同一个模型，主供应商有限流时，自动切换到备用供应商。或者多个 API Key 轮转，平摊请求量。
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| def select_model(task: Task, budget: TokenBudget) -> str: candidates = MODEL_CAPABILITY_MATRIXtask.type # 过滤：当前负载可接受的模型 available = m for m in candidates if not rate_limiter.is_throttled(m) # 排序：在预算内，选质量最高的 return min( m for m in available if cost_table\[m <= budget.per_token], key=lambda m: -quality_scorem ) |
四、 Token 计量与费用归因
这是网关里最容易被忽视、但对企业最重要的功能。要做到可用的费用报告，需要在每次请求里传入归因标识：
|--------------------------------------------------------------------------------------------------------------------------------------|
| // 请求头携带归因信息 headers: { 'X-Department': 'legal', 'X-User-Id': 'u_12345', 'X-App-Id': 'contract-review', 'X-Project-Id': 'proj_abc' } |
网关在响应返回时记录：模型名称、input_tokens、output_tokens、延迟、归因标识。定期聚合生成报告，支持按部门、用户、应用、项目多维度查看。
五、安全与合规
· API **Key 不能明文传输：**用 KMS 或 Vault 管理密钥，网关内部解密，不暴露给调用方
· **请求内容审计：**对于合规要求高的行业，需要记录请求和响应内容（注意脱敏）
· **敏感信息过滤：**在请求发出前，扫描是否有手机号、身份证等 PII 数据，按策略屏蔽或警告
|------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 实践参考 自建 LLM 网关的开源选项：LiteLLM 提供了不错的多模型统一接口；One API 在国内有较多使用案例。如果需要与企业权限体系（LDAP/SSO）集成、按组织层级管理配额，并和 Agent 编排流程打通，ZGI（zgi.cn）的网关模块是一个集成度更高的选择，底层基于 Golang 实现，支持私有化部署。 |