内网大模型网关落地用 LiteLLM 管控第三方服务与强制代理【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm当企业内部的 AI 应用从体验 Demo走向生产服务时一个无法回避的问题随之而来代码里散落着各个云厂商的 SDK 与直连密钥每引入一个新模型就要改一遍调用链账单模糊、权限失控、流量不可审计。LiteLLM 之所以在网关赛道频繁被点名是因为它把统一接入这件事做成了产品级能力——上游对接 100 大模型 API下游统一暴露 OpenAI 兼容接口中间夹着鉴权、路由、限流、计量与观测。本文结合社区真实落地案例与仓库源码拆解一套典型的内网部署形态本地 vLLM 承接主力推理、网关强制代理出网流量、虚拟 Key 收敛权限、Postgres Prometheus 沉淀可审计的账本。一、内网网关架构数据面与控制面分离的请求链路在进入配置细节之前先理解 LiteLLM 代理的服务模型。仓库根目录的 ARCHITECTURE.md 给出了完整请求链路客户端OpenAI SDK / Anthropic SDK / 任意 HTTP 客户端→ AI Gatewaylitellm/proxy/→ LiteLLM SDKlitellm/→ LLM API。网关负责鉴权、限流、预算、路由SDK 负责实际的供应商调用、请求/响应转换与流式适配。对于企业级内网部署仓库已经给出了控制面 / 数据面分离的参考实现数据面入口 gateway/main.py复用litellm.proxy.proxy_server的 FastAPI 应用只保留 LLM 数据面路由即/v1/chat/completions、/v1/embeddings这类业务流量控制面入口 backend/main.py同样复用该应用但按 backend/routes/allowlist.py 中定义的路径前缀白名单只暴露管理面——/key/、/team/、/user/、/budget/、/spend/、/audit、/model/等。allowlist.py的模块注释写得很直白后端组件只承载管理/审计流量任何 LLM 数据面流量都被丢弃交由网关组件处理。这意味着你可以把管理端口如 4001收敛到运维网段把数据面端口如 4000暴露给业务应用两层互不干扰。文件注释也印证了数据面与控制面在演进上解耦——控制面正在统一收敛到/management/v1/前缀下。而数据面请求内部ARCHITECTURE.md 的时序图展示了每一步的职责归属一次请求的账在响应阶段即被结算成本通过x-litellm-response-cost响应头返回同时异步批量写入 Postgres——这是后面可观测与预算能力的地基。二、vLLM 等本地后端接入统一 OpenAI 兼容接口内网网关的第一诉求是把本地 GPU 集群vLLM 部署和第三方云模型收进同一套路由体系。LiteLLM 的模型注册表用model_list声明每个条目包含对外暴露的model_name即业务侧见到的模型名和内部litellm_params真实后端、密钥、base_url。参考 litellm/proxy/example_config_yaml/oai_misc_config.yaml 的写法本地 vLLM 与云端模型可以共存于一张表model_list: - model_name: gpt-5-mini-end-user-test litellm_params: model: gpt-5-mini region_name: eu model_info: id: 1 - model_name: * litellm_params: model: openai/* api_key: os.environ/OPENAI_API_KEY # provider specific wildcard routing - model_name: anthropic/* litellm_params: model: anthropic/* api_key: os.environ/ANTHROPIC_API_KEY需要注意model:字段的前缀约定openai/*、anthropic/*这类 provider 前缀决定请求按哪个供应商的协议翻译。对于 vLLM 这类 OpenAI 兼容后端仓库在 litellm/proxy/common_request_processing.py 的注释中明确指出LiteLLM 内部会为hosted_vllm/...这类部署标识补充前缀同时 litellm/proxy/pass_through_endpoints/llm_passthrough_endpoints.py 还注册了/vllm/{endpoint:path}原生透传路由litellm/proxy/_types.py 中也有/vllm/*与/anthropic/*等原生协议路径的说明——也就是说客户端既可以走 OpenAI 兼容格式也可以直接透传 vLLM 的原生接口。多部署负载均衡同样在配置层解决。参考 litellm/proxy/example_config_yaml/load_balancer.yaml同名model_name挂多个后端即可启用路由器的负载均衡与自动降级每个部署可单独声明tpm/rpm上限model_list: # use the same model_name for using the litellm router - model_name: gpt-3.5-turbo litellm_params: model: gpt-3.5-turbo api_key: sk-uj6F tpm: 20000 rpm: 3 - model_name: gpt-3.5-turbo litellm_params: model: gpt-3.5-turbo api_key: sk-Imn tpm: 20000 rpm: 3 - model_name: gpt-3.5-turbo litellm_params: model: openrouter/gpt-3.5-turbo当同一个model_name对应多个部署时litellm/router.py 负责执行重试与 fallback 策略num_retries、按错误类别授权的retry policy等本地 vLLM 宕机时流量可平滑降级到云端备用模型这是直连 SDK 时代需要业务代码自行实现的逻辑。三、网络策略隔离与强制代理网关落地的第二个关键动作是强制代理让业务代码无法绕过网关直连第三方 API。社区方案普遍采用网络层配合——网关作为内网唯一的出网出口原生端口在网络策略层面被隔离。落地手段通常分两层安全组 / 防火墙层业务子网仅放通到网关端口云模型 API 的原生域名与端口被网络策略封禁所有出网 LLM 流量只能经过网关网关侧加固LiteLLM 本身的密钥全部收敛在网关上业务侧只持有虚拟 Key。参考 docker/docker-compose.quickstart.yml生产部署要求在环境变量中注入LITELLM_MASTER_KEY用于签名/校验虚拟 Key与LITELLM_SALT_KEY用于加密库中存储的密钥且注释明确警告重新生成 SALT_KEY 会使数据库里已存的密钥凭据不可读——这也是密钥生命周期管理的底线约束。services: litellm: image: docker.litellm.ai/berriai/litellm:main-stable environment: LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY:?set it in .env} LITELLM_SALT_KEY: ${LITELLM_SALT_KEY:?set it in .env} DATABASE_URL: postgresql://litellm:${POSTGRES_PASSWORD:-litellm}db:5432/litellm STORE_MODEL_IN_DB: True depends_on: db: condition: service_healthyIP 白名单网关支持general_settings.allowed_ips在 litellm/proxy/auth/auth_utils.py 中实现——未配置时默认放行一旦配置则校验客户端 IP 是否在白名单内litellm/proxy/proxy_server.py 中该选项被标记为企业版Enterprise能力需要LITELLM_LICENSE。此外仓库还提供了/add/allowed_ip、/delete/allowed_ip管理路由见 backend/routes/allowlist.py支持运行时动态调整访问控制。如果企业对鉴权有更特殊的要求例如对接内部统一登录LiteLLM 提供自定义鉴权钩子参考 litellm/proxy/example_config_yaml/custom_auth_basic.py实现user_api_key_auth(request, api_key)即可返回任意自定义的UserAPIKeyAuth对象把内部身份体系接入网关。四、虚拟 Key 鉴权与请求/Token 计量强制代理解决了流量从哪走虚拟 Key 解决谁能用、能用多少。虚拟 Key 是网关签发的、与上游真实密钥完全解耦的访问凭据业务侧永远接触不到云厂商密钥。虚拟 Key 的持久化模型在 schema.prisma 的LiteLLM_VerificationToken表中字段设计直接对应配额能力model LiteLLM_VerificationToken { token String id key_name String? spend Float default(0.0) total_spend Float default(0.0) expires DateTime? models String[] user_id String? team_id String? max_parallel_requests Int? blocked Boolean? tpm_limit BigInt? rpm_limit BigInt? tpd_limit BigInt? max_budget Float? budget_duration String? model_max_budget Json default({}) budget_fallbacks Json default({}) allowed_routes String[] default([]) }tpm_limit/rpm_limit/tpd_limitToken 每分钟、请求每分钟、Token 每天的硬限额max_budgetbudget_duration预算窗口如30d内消费上限model_max_budget按模型拆分的预算models/allowed_routes模型与路由的访问范围。创建虚拟 Key 的请求体定义在 litellm/proxy/_types.py 的GenerateRequestBase中与上述字段一一对应max_budget、tpm_limit、rpm_limit、budget_limits多窗口并发预算、guardrails等通过/key/generate管理端点下发路由实现在 litellm/proxy/management_endpoints/key_management_endpoints.py并对budget_limits做了有限性与预算委派上限的校验。团队维度同样有配额LiteLLM_TeamTableschema.prisma 第 181 行起将多个 Key 归组管理配合budget_duration实现团队级预算。计量侧的完整数据落在LiteLLM_SpendLogs表schema.prisma 第 706 行起model LiteLLM_SpendLogs { request_id String id call_type String api_key String // Hashed API Token. Not the actual Virtual Key spend Float total_tokens Int prompt_tokens Int completion_tokens Int startTime DateTime endTime DateTime model String model_group String custom_llm_provider String? api_base String? user String? team_id String? end_user String? requester_ip_address String? status String? index([api_key, startTime]) }注意api_key列存储的是哈希后的 Token而非明文虚拟 Key这保证了即使数据库泄露也无法逆向还原可用的访问凭据。每行日志记录调用类型、模型、Token 拆分、费用、归属用户/团队/最终用户与请求来源 IP并按api_key startTime建索引——这正是按 Key、按团队、按时间窗口聚合账单的查询基础。请求账目还会通过响应头如x-litellm-response-cost回传给调用方供业务侧实时感知成本。五、可观测、可审计、可预算的企业级管理网关价值最终落在三层管理能力上而这三层都有源码层面的支撑。可观测。仓库在 litellm/proxy/example_config_yaml/enterprise_config.yaml 中给出最简配置——litellm_settings.callbacks: [prometheus]一行即可接入 Prometheus 指标体系。指标实现在 litellm/integrations/prometheus.py包含litellm_requests_metric请求计数、litellm_proxy_total_requests_metric、litellm_proxy_failed_requests_metric、litellm_deployment_total_requests、litellm_deployment_latency_per_output_token等按模型/部署/Key 打标的指标可对接 Grafana 面板做实时容量与延迟监控。若企业已自建可观测栈oai_misc_config.yaml还示范了按团队绑定 Langfuse 回调success_callback/failure_callback实现链路级追踪。可审计。管理面的每一次配置变更都会被记录。LiteLLM_AuditLog表schema.prisma 第 838 行起记录changed_by、changed_by_api_key、actioncreate/update/delete、table_name、object_id以及变更前后的 JSON 快照before_value/updated_values。加上控制面白名单中的/audit路由backend/routes/allowlist.py管理员可以直接查询谁在什么时候改了什么配置。社区实践里这条链路通常与内部 SIEM 或合规报表对接构成改了谁、建了哪个 Key、批了多大预算的完整证据链。可预算。预算执行不依赖事后对账而是在请求前实时判定。请求链路中的user_api_key_authlitellm/proxy/auth/user_api_key_auth.py在放行前会核对 Key 的预算与限流状态Redis 缓存承担 Key 信息与限流计数器的读写见 ARCHITECTURE.md 时序图保证高并发下预算判定的吞吐。分布式部署时litellm/proxy/example_config_yaml/spend_tracking_config.yaml 展示了coordination_redisuse_redis_transaction_buffer的用法把消费写入缓冲到 Redis 再批量落库避免多实例并发写 Postgres 造成热点。LiteLLM_DailyUserSpendschema.prisma 第 851 行起则按天、按用户、按模型聚合 Token 与费用直接支撑预算看板的日粒度视图。六、落地路径与避坑清单综合社区实践与仓库源码一套典型的内网网关落地顺序可以归纳为部署底座参考docker/docker-compose.quickstart.yml起网关 Postgres务必同时生成并妥善保存LITELLM_MASTER_KEY与LITELLM_SALT_KEY注册模型在model_list中登记本地 vLLMhosted_vllm/...或/vllm透传与第三方云端模型同名多部署开启负载均衡收敛流量网络策略封禁出网直连业务侧统一指向网关的 OpenAI 兼容端点开启allowed_ips或自定义鉴权钩子加固入口签发虚拟 Key按团队/用户/项目拆分 Key配置tpm_limit、rpm_limit、max_budget把上游密钥彻底从业务侧移除接通观测开启callbacks: [prometheus]接入现有监控spend 数据落库后按 Key/团队/天聚合出成本视图。几个常见的坑需要提前规避一是LITELLM_SALT_KEY变更会导致存量凭据不可读必须纳入密钥管理流程二是预算真正生效的前提是配置了DATABASE_URLlitellm/proxy/proxy_server.py 中有明确注释未设置数据库时预算不会被强制执行三是网关自身的管理面/key/、/spend/、/audit与数据面应分开暴露避免管理端口被业务网络触达。LiteLLM 的价值不在于多一层转发而在于把模型接入从每家一个 SDK收敛为一张配置表 一套治理规则。对内网场景而言它同时回答了三个问题流量如何强制收敛、权限如何细粒度下发、成本如何逐笔可查——这正是直连 SDK 无法给出的企业级答案。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考