LLM 应用网关选型与落地：统一鉴权、限流、路由与成本核算的实践框架

公司里第二个业务接入大模型时，问题就开始显形：第一个业务的 API Key 写死在代码仓库里，第二个业务又申请了一把；月底账单一来，财务问这笔钱花在哪个项目，没人说得清。等到第三个业务想把模型从 A 厂商换成 B 厂商，发现每个服务里都散落着 SDK 调用代码，改造要横跨三四个团队。这些问题的根源是同一个：大模型调用没有被当作需要统一治理的基础设施，而是各业务各管一段的普通外部依赖。

LLM 应用网关就是把这层治理收拢的组件：所有业务方只连网关，网关统一负责鉴权、限流、模型路由、故障回退和成本核算。它解决的不是「模型能不能用」，而是「模型用量大了之后还管不管得住」。

方案对比：三种接入形态怎么选

维度	业务直连厂商 API	自研统一网关	开源网关（LiteLLM 等）
启动成本	最低	高，需自研全链路	低，部署即用
多厂商统一接口	无，各家 SDK 不同	取决于投入	内置 OpenAI 兼容格式
限流/配额/成本核算	各自为政	完全自定义	内置按 Key 配额与用量统计
灵活性上限	低	最高	中高，可二次开发
维护责任	各业务自己扛	自己团队扛	社区维护 + 自运维

直连只适合单一业务、用量很小的早期阶段。自研网关适合对数据链路、审计规则有强合规要求的团队，代价是把重试、计费、流式这些细节全接过来自己扛。对大多数团队，开源网关是性价比最高的起点：LiteLLM Proxy 把上百种模型统一成 OpenAI 兼容接口，虚拟密钥、配额、回退、成本统计开箱即用，业务侧的改造量只有换一个 base_url。下面的实操以 LiteLLM 为例。

选型时还有一个务实的判断维度：把「模型可替换性」当作独立目标来评审。很多团队自研网关的原始动机只是统一封装，结果把调用逻辑和某个厂商的 SDK 特性焊死在一起，网关建成了，换模型照样要改代码。评判任何一种方案是否合格，就看两个动作的成本：新增一个业务方要多久、把主力模型换成备选要多久——前者应该是签发一把密钥的事，后者应该只改网关配置。做不到这两点的方案，治理目标就落空了一半。

实操第一步：部署网关并接入多家模型

LiteLLM Proxy 通常以 Docker 方式部署，模型路由全部收在一个 YAML 配置里。下面的配置把 OpenAI、DeepSeek、通义千问三家的模型挂到统一入口，并设置了请求重试、超时和主备回退：

yaml

# litellm-config.yaml：模型路由与全局策略
model_list:
  - model_name: gpt-4o              # 业务方看到的名字
    litellm_params:
      model: openai/gpt-4o          # 实际路由到的厂商与模型
      api_key: os.environ/OPENAI_API_KEY
  - model_name: deepseek-chat
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY
  - model_name: qwen-max
    litellm_params:
      model: dashscope/qwen-max
      api_key: os.environ/DASHSCOPE_API_KEY

litellm_settings:
  num_retries: 2                    # 厂商侧瞬时错误自动重试
  request_timeout: 120              # 单请求超时，流式场景要重新评估
  fallbacks:
    - gpt-4o: ["deepseek-chat"]     # 主模型限流/超时时自动回退到备模型

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY   # 管理端鉴权密钥
  database_url: os.environ/DATABASE_URL        # 虚拟密钥与用量数据入库

厂商密钥从此只存在于网关的运行环境里。业务方拿到的不再是任何厂商的原始 Key，而是网关签发的虚拟密钥（Virtual Key）：每个业务方一把，配额、限流、用量全部挂在 Key 维度上。

实操第二步：为业务方签发虚拟密钥并设置配额

通过网关的管理接口为每个业务方创建虚拟密钥，按团队设置每月预算和每分钟速率：

bash

# 为「客服团队」创建虚拟密钥：每月预算 500 美元，限流每分钟 60 次、8 万 token
curl -X POST http://llm-gateway.internal:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "key_alias": "team-support",
    "max_budget": 500,
    "budget_duration": "30d",
    "rpm_limit": 60,
    "tpm_limit": 80000,
    "models": ["gpt-4o", "deepseek-chat"]
  }'

models 字段同时充当了授权清单：没写进清单的模型，持这把 Key 的业务方根本调不到。限流建议 rpm 和 tpm 双维度都设——只限请求数挡不住长输出打爆账单，只限 token 数又挡不住高频短请求拖垮上游。

实操第三步：业务方切换到统一入口

业务侧的改造几乎零成本：把 base_url 指向网关、换用虚拟密钥即可，代码继续使用 OpenAI SDK 的写法：

python

from openai import OpenAI

client = OpenAI(
    base_url="http://llm-gateway.internal:4000",
    api_key="sk-vk-team-support-xxxx",  # 网关签发的虚拟密钥，非厂商原始 Key
)

resp = client.chat.completions.create(
    model="gpt-4o",  # 名字由网关路由，换模型只需网关改配置
    messages=[{"role": "user", "content": "总结这周的客服工单趋势"}],
)

之后所有治理动作都在网关侧完成：成本报表按 Key 维度天然聚合，某业务方预算烧完自动熔断，主模型限流时 fallback 配置自动把流量切到备模型——业务代码一行不用动。

网关上线只是治理的开始，配套的观测要跟上。建议每天定时导出「Key × 模型 × 用量」的报表并同步给各业务负责人，让花钱的人看得见自己的曲线；给关键业务配额度告警，预算消耗过半就通知，而不是等熔断了才发现；对 429 限流、上游超时这类错误单独立监控，它的突增往往意味着某个业务方的调用模式出了问题。运维过常规 API 网关的团队对这些动作不会陌生——LLM 网关的本质就是网关，把它当基础设施来运营，而不是当一个昂贵的转发脚本。

避坑总结

流式响应是网关层最容易翻车的点。前置的 Nginx 类反代会缓冲流式响应导致前端「打字机」变成一次性吐出，需对网关路径关闭 proxy_buffering 并拉长读超时；网关自身的请求超时也要按流式场景单独设置。
回退策略要区分错误类型。限流、超时可以回退重试，但内容安全拦截换模型重试基本无效还会放大成本；盲目全局 fallback 容易造成双倍计费，回退触发条件要按错误类别收敛。
限流与配额必须挂到 Key 维度。全局单池限流会让一个业务方的突发流量拖垮所有人；按 Key 分池 + 全局保底的双层结构，才能既隔离又兜底。
成本核算不能只看统一均价。不同模型价差极大，同模型的长上下文区间往往另有计价，缓存命中的计费规则也不同；成本报表要落到「Key × 模型 × 计费规则」粒度，月结对账才对得上。
日志先脱敏再入库。请求体里经常带着用户对话原文，落库前做敏感字段脱敏，原始厂商密钥与 master key 永远不出网关进程，排查问题时用虚拟密钥别名关联即可。

写在最后

LLM 应用网关的价值要在用量上来之后才会显现：换模型的成本、核算成本的精度、故障时的恢复速度，都取决于当初有没有把这层治理收拢。先用开源网关把统一入口、虚拟密钥和成本报表跑起来，再按需自研增强，是大多数团队走得通的路——毕竟治理这件事，晚做三个月，还的债就多三分。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。

LLM 应用网关选型与落地：统一鉴权、限流、路由与成本核算的实践框架 ​

方案对比：三种接入形态怎么选 ​

实操第一步：部署网关并接入多家模型 ​

实操第二步：为业务方签发虚拟密钥并设置配额 ​

实操第三步：业务方切换到统一入口 ​

避坑总结 ​

写在最后 ​