--- title: "LiteLLM 生产级自托管指南：2026 架构与安全" canonical: https://wavect.io/zh/blog/self-host-litellm-production-2026/ language: zh description: "2026 年安全自托管 LiteLLM：规划 Docker 或 Kubernetes、Postgres、Redis、虚拟密钥、监控、补丁、上线成本与替代方案。" image: "https://wavect.io/img/blog/headers/header_self-host-litellm-production-2026.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年8月13日 [**下一篇**](/zh/blog/linux-for-ai-agents/) # LiteLLM 生产级自托管指南：2026 架构、安全与成本 要点速览 自托管 LiteLLM 是自己运营 AI 网关，并不等于模型也在本地推理。生产环境至少需要两个固定精确版本的网关副本、TLS、私有托管 Postgres、用于共享限流与路由状态的 Redis、最小权限虚拟密钥、Secret 管理、健康探针、指标、备份，以及经过验证的升级路径。LiteLLM OSS 没有许可证费用，但基础设施和当班运维都有真实成本。2026 年的 PyPI 供应链事件与多项代理漏洞，使精确版本锁定、镜像签名验证、网络隔离和快速补丁成为上线条件。先用 staging 容器验证，再在控制权、合规或供应商可迁移性值得运维成本时建设高可用栈。 LiteLLM 可以为每个应用提供一个兼容 OpenAI 的端点，由网关统一处理供应商凭证、虚拟密钥、预算、路由和可观测性。它的 [官方文档](https://docs.litellm.ai/) 把 Proxy 定位为平台团队运营的中心服务，并将其与嵌入单个 Python 应用的 SDK 区分开来。本文讨论的是如何把这个 Proxy 当作基础设施运营。 搜索结果里真正缺少的已经不是“能不能启动容器”，而是“团队能不能修补、扩容并恢复这个保存所有模型凭证的网关”。演示环境只需要一个进程。生产环境需要明确的负责人、私有数据层、发布策略，以及证明单点故障不会同时停掉所有 AI 功能的测试证据。 ## 自托管 LiteLLM 到底是什么意思？ **自托管 LiteLLM，指的是在你控制的基础设施中运营网关。**除非网关连接到 vLLM、Ollama 等本地推理服务器，否则请求仍会发往 OpenAI、Anthropic、Bedrock 或其他已配置供应商。你控制的是 Proxy、密钥、日志和路由策略，并不自动控制模型推理。 这也把本文与两个相邻意图分开。我们的 [2026 LLM 网关对比](/zh/blog/llm-gateway-router-comparison-2026/) 帮助你在 LiteLLM、OpenRouter、Portkey 和路由框架之间做选择。 [欧盟自托管 LLM 成本指南](/zh/blog/self-hosting-llms-eu-cost/) 讨论模型权重和 GPU 推理。本文的产品，是位于应用与任意托管或本地模型之间的网关控制平面。 ## 什么时候值得自托管 LiteLLM？ LiteLLM 表示开源网关没有许可证费用，并把虚拟密钥、预算、限流、故障回退、日志和 Prometheus 指标列入这一层级。Enterprise 增加 SSO、SCIM、审计日志等治理与支持功能。采购前请在 [LiteLLM 价格页](https://www.litellm.ai/pricing) 重新核对当前边界。 | 场景 | 建议起点 | 原因 | | --- | --- | --- | | 一个原型、一个供应商、没有平台负责人 | 直接调用供应商 | 网关会在解决实际问题前，先增加一个生产依赖。 | | 多个产品或团队共享供应商账户 | 自托管可能值得 | 范围受限的密钥、统一预算和供应商抽象形成清晰控制点。 | | 交付速度比基础设施控制更重要 | 使用托管网关 | 购买运维、升级和支持，而不是自己建设。 | | 私有网络、欧盟部署或自定义控制是硬性要求 | 评估自托管 | 你可以决定网络、区域、日志、保留期和发布节奏。 | | 还需要本地模型推理 | 把网关和推理分层运营 | LiteLLM 负责路由，vLLM、Ollama 或其他服务器负责执行模型。 | ## 生产级 LiteLLM 应采用什么架构？ 当前 [LiteLLM 生产部署指南](https://docs.litellm.ai/docs/proxy/deploy) 描述了负载均衡器后的无状态服务、保存密钥、团队、费用日志和配置的 PostgreSQL，以及共享限流、路由状态和缓存的 Redis。官方建议运行至少两个副本，并使用独立迁移 Job。这才是可信的最低生产形态，而不是把单容器 Compose 直接暴露到公网。 | 层 | 生产职责 | 故障问题 | | --- | --- | --- | | TLS Ingress 或负载均衡器 | 终止 TLS、限制路由、抑制滥用并安全摘除副本 | 一个异常客户端能否访问管理端点或耗尽服务？ | | 至少两个 LiteLLM 副本 | 使用精确固定且签名验证的镜像服务流量 | 发布或 Pod 崩溃会不会中断活动流？ | | 托管 PostgreSQL | 持久化密钥、团队、费用和配置，并提供备份 | 能否在网关演变成全公司故障前完成恢复？ | | 托管 Redis | 在副本之间共享限流、缓存和路由状态 | 流量落到不同 Pod 时，限制是否仍然准确？ | | Secret 存储 | 保存供应商凭证、Master Key 和永久 Salt Key | 一个应用能否读取另一个应用的供应商凭证？ | | 指标、日志与 Trace | 监测可用性、延迟、费用、错误和饱和度，同时避免泄露 Prompt | 值班人员能否判断故障来自 LiteLLM、数据库还是供应商？ | 除非网关、Backend 和 UI 的独立扩缩容能解决已测量的瓶颈，否则先使用单体镜像。更小的架构更容易修补和恢复。组件化适用于高流量或严格管理隔离，但也会提高版本协调成本。 ## 如何安全部署 LiteLLM？ 1. **定义网关契约。** 列出应用可调用的模型别名、供应商与区域回退顺序、每个工作负载的预算、允许的端点、保留规则，以及每条告警的负责人。没有策略的统一端点，只是在集中风险。 2. **先在 staging 证明完整路径。** 在私有端点运行固定版本容器，挂载版本化 `config.yaml` ，通过环境变量注入供应商凭证，再使用标准 OpenAI 客户端发出请求。生产中不要使用 `main-latest` ，也不要启用详细调试日志。 3. **在签发团队密钥前加入 Postgres。** 使用私有托管数据库、加密连接、自动备份和独立迁移 Job。不要让服务流量的副本执行 Schema 更新，避免扩容事件与迁移发生竞争。 4. **在第二个副本前加入 Redis。** LiteLLM 的 [生产检查清单](https://docs.litellm.ai/docs/proxy/prod) 建议多实例时使用 Redis 7 或更高版本。没有共享状态，各副本会独立执行限制，缓存命中也只在本地生效。Kubernetes 中使用每 Pod 一个 Worker，并按 CPU 扩容，不要依据进程保留内存。 5. **每个工作负载使用独立虚拟密钥。** [虚拟密钥文档](https://docs.litellm.ai/docs/proxy/virtual_keys) 要求 Postgres，并支持模型权限、预算和费用归属。显式配置模型与路由白名单。不要把 Master Key 发给应用，也不要假设空列表等于无访问权。 6. **把网关放进私有网络。** 通过 TLS 只暴露客户端需要的请求路由。Admin UI 与管理 API 应置于身份感知访问之后，或使用独立管理入口。Egress 只允许已批准的供应商与可观测性目标。 7. **让升级可以回退。** 针对生产 Schema 副本测试镜像、配置和迁移，先部署 Canary，再重放代表性请求。保留上一镜像与兼容数据库备份。 8. **执行故障演练。** 依次停用一个供应商、一个网关副本、Redis 和 Postgres。确认回退、Readiness、告警、恢复目标和客户端错误符合预期。没有演练过的回退只是文档，不是韧性。 ## 2026 年 LiteLLM 安全发生了什么变化？ 安全必须参与架构设计，因为 Proxy 可能持有模型凭证、数据库访问权和请求内容。2026 年 3 月，恶意 LiteLLM 1.82.7 和 1.82.8 被发布到 PyPI。项目的 [事件时间线](https://github.com/BerriAI/litellm/issues/24518) 称，受影响包可窃取环境变量和云凭证，而 Proxy Docker 镜像用户未受影响。安装过这些包的团队应遵循事件建议，并轮换可能暴露的凭证。 独立的 Proxy 漏洞进一步提高了要求。1.81.16 至 1.83.6 受到 API Key 验证中的关键 [SQL 注入漏洞](https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc) 影响。1.74.2 至 1.83.6 受到 [MCP 测试端点命令注入](https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g) 影响。之后的 [虚拟密钥权限提升](https://github.com/advisories/GHSA-qrc4-49gv-mv9m) 在 1.83.14 修复。这些修复版本只是历史下限，不是今天建议的部署目标。 实务答案很直接：使用当前受支持的 Stable Release，不用 Prerelease，也不用旧的最低补丁。2026 年 8 月 13 日，GitHub 将 v1.96.2 标记为 Latest，并在 [LiteLLM Releases 页面](https://github.com/BerriAI/litellm/releases) 提供 cosign 验证命令。部署当天重新核对，固定精确版本或 Digest，验证签名并扫描镜像，再把同一 Digest 推进所有环境。 ## 上线前必须满足什么条件？ - **最小权限必须显式配置。** 每个工作负载有独立虚拟密钥、命名负责人、允许模型、路由、预算和到期时间。Master Key 不进入应用。 - **Secret 分离且可恢复。** 供应商密钥与 Master Key 放入平台 Secret 存储。永久 `LITELLM_SALT_KEY` 另行备份，因为保存凭证后更改它会使凭证无法读取。 - **网络默认关闭。** 管理路由私有化，保持 TLS 验证，限制供应商 Egress，数据库与 Redis 不使用公网地址。这些控制遵循 LiteLLM 的 [安全最佳实践](https://docs.litellm.ai/docs/proxy/security_best_practices) 。 - **日志有数据政策。** 决定是否允许记录 Prompt 和响应，导出前脱敏敏感字段，设定保留期与访问权限，并测试删除。我们的 [LLM 前 PII 脱敏网关指南](/zh/blog/pii-redaction-before-llm-prompts/) 详细讨论这一边界。 - **健康检查区分不同问题。** LiteLLM 文档中的匿名 Liveness 与 Readiness 端点不调用模型，经过认证的模型健康端点会发出真实供应商请求。根据 [健康检查契约](https://docs.litellm.ai/docs/proxy/health) 分别配置编排探针与深层合成检查。 - **费用经过对账。** 把 LiteLLM 归属结果与供应商账单比较，并测试流式响应、重试、缓存命中和回退。Dashboard 估算有用，但财务需要明确对账路径。 - **负责人能快速修补。** 订阅安全公告，定义补丁 SLA，维护 staging Smoke Suite，并记录疑似泄露后的凭证轮换流程。 ## 自托管 LiteLLM 需要多少工作？ 不存在诚实的统一价格，因为网关会继承你的云、可用性目标、身份系统和合规范围。以下是 Wavect 用于前期范围评估的规划区间，不是 LiteLLM 报价或云价格承诺。 | 部署级别 | 常见工程投入 | 包括 | | --- | --- | --- | | 私有 staging 网关 | 1 至 3 个工程日 | 固定版本容器、两个供应商、配置、一个虚拟密钥、基础日志和 Smoke Test | | 单区域生产基线 | 1 至 3 个工程周 | 副本、TLS、托管 Postgres 与 Redis、Secret、预算、指标、备份、Canary 和 Runbook | | 受监管或多团队平台 | 4 至 10 个工程周 | 身份集成、租户政策、审计证据、隐私控制、灾难恢复、负载测试和支持移交 | | 持续所有权 | 指定月度容量加值班 | 补丁、供应商变更、成本映射审查、事件响应、权限审查和恢复演练 | 在中等流量下，基础设施账单通常不是决定因素，所有权才是。没有人能承担修补和恢复责任时，即使托管网关发票更高，总成本也可能更低。如果平台团队已经运营 Kubernetes、Postgres、Redis、Secret 和可观测性，LiteLLM 可以复用已有控制。 ## 应该自托管 LiteLLM，还是购买托管网关？ **当控制权是硬性要求，且运维是团队现有能力时，自托管 LiteLLM。**当速度、支持和更少值班负担比基础设施控制更有价值时，购买托管网关。对于尚未证明需要网关的单一原型，继续直接访问供应商。 有效的采购测试应该计算一年，而不是一个容器。把设计、实施、数据库与 Redis、监控、备份、升级、安全审查、值班和一次供应商迁移全部纳入，再与托管方案及不行动的成本比较。网关上线后的成本优化可参考我们的 [LLM Token 成本削减指南](/zh/blog/reduce-llm-token-costs-2026/) 。 ## 常见问题 ### 自托管 LiteLLM 免费吗？ LiteLLM 开源网关没有许可证费用。你仍需支付计算、PostgreSQL、Redis、流量、可观测性、备份、模型供应商，以及工程师修补和运营的成本。Enterprise 治理与支持另行定价。 ### 自托管 LiteLLM 会让 Prompt 留在我的服务器吗？ Prompt 会经过你的网关，但除非所选模型运行在你控制的基础设施中，否则仍会发送给托管供应商。需要审查完整路径，包括日志、Callback、供应商保留政策和备份。 ### LiteLLM 可以不用 Kubernetes，只运行在 Docker 吗？ 可以。Docker 适用于开发、staging 和部分 VM 部署。生产仍需要多进程或多副本、TLS、Postgres、Redis、健康检查、备份、监控和安全发布流程。Kubernetes 是提供这些控制的一种方式，不是目标本身。 ### LiteLLM 需要 Postgres 和 Redis 吗？ Proxy 认证、虚拟密钥和费用跟踪需要 Postgres。多个 Proxy 实例共享限流、路由状态和缓存时需要 Redis。最小无状态实验可以不运行完整数据层，但它不是多团队生产设计。 ### 应该部署哪个 LiteLLM 版本？ 使用当前受支持的 Stable Release，固定精确镜像 Tag 或 Digest，验证签名并在推进前测试。不要使用移动 Tag，也不要把旧漏洞的最低修复版本当作当前建议。 ### 什么时候应该选择托管替代方案？ 如果没有团队负责网关补丁、恢复和值班，或上市速度比私有基础设施控制更重要，就选择托管。当合规、网络、供应商可迁移性或规模形成明确商业理由时，再重新评估自托管。 ## 最终思考 自托管 LiteLLM 是一个体量小、影响半径大的服务。启动容器很容易，生产难在周围的纪律：私有网络、精确固定且签名的版本、最小权限密钥、Postgres、Redis、指标、备份、故障演练，以及能快速修补的负责人。 当一个受控网关能简化多个产品与供应商时，LiteLLM 值得使用。把模型推理当作独立架构决策。如果团队无法在事件和恢复过程中承担网关责任，就购买托管运维。如果能够承担，就从边界明确的 staging 契约开始，证明韧性，再依据证据扩大范围。 ## 你可能也喜欢.. [**2026 年 LLM 网关对比** 先比较 LiteLLM、OpenRouter、Portkey 和 RouteLLM，再选择运营模式。](/zh/blog/llm-gateway-router-comparison-2026/) [**欧盟 AI 供应商安全问卷** 把安全、隐私、保留和事件响应声明转化为证据请求。](/zh/blog/ai-vendor-security-questionnaire-eu/) 模型与基础设施 ## 继续浏览此集群 模型选择、推理经济性、本地部署、压缩与服务架构。 [从核心文章开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/) - [AI 就绪企业 Wiki：架构与实施指南](/zh/blog/ai-ready-company-wiki/) - [Claude 会给文本加水印吗？2026 API 实战解读](/zh/blog/claude-text-watermark-api-2026/) - [OpenKB 评测：知识编译器 vs RAG](/zh/blog/openkb-review-vs-rag/) - [Unsloth Desktop 评测：私有本地 AI 工作站？](/zh/blog/unsloth-desktop-local-ai-workstation-review/) - [NeMo Switchyard 0.2：无需训练的智能体模型路由？](/zh/blog/nemo-switchyard-model-router/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年8月13日 [**下一篇**](/zh/blog/linux-for-ai-agents/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/self-host-litellm-production-2026/#webpage", "@type": "WebPage", "dateModified": "2026-08-13", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-13", "url": "https://wavect.io/zh/blog/self-host-litellm-production-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "自托管 LiteLLM 是自己运营 AI 网关，并不等于模型也在本地推理。生产环境至少需要两个固定精确版本的网关副本、TLS、私有托管 Postgres、用于共享限流与路由状态的 Redis、最小权限虚拟密钥、Secret 管理、健康探针、指标、备份，以及经过验证的升级路径。LiteLLM OSS 没有许可证费用，但基础设施和当班运维都有真实成本。2026 年的 PyPI 供应链事件与多项代理漏洞，使精确版本锁定、镜像签名验证、网络隔离和快速补丁成为上线条件。先用 staging 容器验证，再在控制权、合规或供应商可迁移性值得运维成本时建设高可用栈。", "articleBody": " 博客概览/AI 与智能体/模型与基础设施 LiteLLM 生产级自托管指南：2026 架构、安全与成本 要点速览 自托管 LiteLLM 是自己运营 AI 网关，并不等于模型也在本地推理。生产环境至少需要两个固定精确版本的网关副本、TLS、私有托管 Postgres、用于共享限流与路由状态的 Redis、最小权限虚拟密钥、Secret 管理、健康探针、指标、备份，以及经过验证的升级路径。LiteLLM OSS 没有许可证费用，但基础设施和当班运维都有真实成本。2026 年的 PyPI 供应链事件与多项代理漏洞，使精确版本锁定、镜像签名验证、网络隔离和快速补丁成为上线条件。先用 staging 容器验证，再在控制权、合规或供应商可迁移性值得运维成本时建设高可用栈。 LiteLLM 可以为每个应用提供一个兼容 OpenAI 的端点，由网关统一处理供应商凭证、虚拟密钥、预算、路由和可观测性。它的官方文档把 Proxy 定位为平台团队运营的中心服务，并将其与嵌入单个 Python 应用的 SDK 区分开来。本文讨论的是如何把这个 Proxy 当作基础设施运营。 搜索结果里真正缺少的已经不是“能不能启动容器”，而是“团队能不能修补、扩容并恢复这个保存所有模型凭证的网关”。演示环境只需要一个进程。生产环境需要明确的负责人、私有数据层、发布策略，以及证明单点故障不会同时停掉所有 AI 功能的测试证据。 自托管 LiteLLM 到底是什么意思？ 自托管 LiteLLM，指的是在你控制的基础设施中运营网关。除非网关连接到 vLLM、Ollama 等本地推理服务器，否则请求仍会发往 OpenAI、Anthropic、Bedrock 或其他已配置供应商。你控制的是 Proxy、密钥、日志和路由策略，并不自动控制模型推理。 这也把本文与两个相邻意图分开。我们的2026 LLM 网关对比帮助你在 LiteLLM、OpenRouter、Portkey 和路由框架之间做选择。欧盟自托管 LLM 成本指南讨论模型权重和 GPU 推理。本文的产品，是位于应用与任意托管或本地模型之间的网关控制平面。 什么时候值得自托管 LiteLLM？ LiteLLM 表示开源网关没有许可证费用，并把虚拟密钥、预算、限流、故障回退、日志和 Prometheus 指标列入这一层级。Enterprise 增加 SSO、SCIM、审计日志等治理与支持功能。采购前请在 LiteLLM 价格页重新核对当前边界。 场景建议起点原因 一个原型、一个供应商、没有平台负责人直接调用供应商网关会在解决实际问题前，先增加一个生产依赖。 多个产品或团队共享供应商账户自托管可能值得范围受限的密钥、统一预算和供应商抽象形成清晰控制点。 交付速度比基础设施控制更重要使用托管网关购买运维、升级和支持，而不是自己建设。 私有网络、欧盟部署或自定义控制是硬性要求评估自托管你可以决定网络、区域、日志、保留期和发布节奏。 还需要本地模型推理把网关和推理分层运营LiteLLM 负责路由，vLLM、Ollama 或其他服务器负责执行模型。 生产级 LiteLLM 应采用什么架构？ 当前 LiteLLM 生产部署指南描述了负载均衡器后的无状态服务、保存密钥、团队、费用日志和配置的 PostgreSQL，以及共享限流、路由状态和缓存的 Redis。官方建议运行至少两个副本，并使用独立迁移 Job。这才是可信的最低生产形态，而不是把单容器 Compose 直接暴露到公网。 层生产职责故障问题 TLS Ingress 或负载均衡器终止 TLS、限制路由、抑制滥用并安全摘除副本一个异常客户端能否访问管理端点或耗尽服务？ 至少两个 LiteLLM 副本使用精确固定且签名验证的镜像服务流量发布或 Pod 崩溃会不会中断活动流？ 托管 PostgreSQL持久化密钥、团队、费用和配置，并提供备份能否在网关演变成全公司故障前完成恢复？ 托管 Redis在副本之间共享限流、缓存和路由状态流量落到不同 Pod 时，限制是否仍然准确？ Secret 存储保存供应商凭证、Master Key 和永久 Salt Key一个应用能否读取另一个应用的供应商凭证？ 指标、日志与 Trace监测可用性、延迟、费用、错误和饱和度，同时避免泄露 Prompt值班人员能否判断故障来自 LiteLLM、数据库还是供应商？ 除非网关、Backend 和 UI 的独立扩缩容能解决已测量的瓶颈，否则先使用单体镜像。更小的架构更容易修补和恢复。组件化适用于高流量或严格管理隔离，但也会提高版本协调成本。 如何安全部署 LiteLLM？ 定义网关契约。列出应用可调用的模型别名、供应商与区域回退顺序、每个工作负载的预算、允许的端点、保留规则，以及每条告警的负责人。没有策略的统一端点，只是在集中风险。 先在 staging 证明完整路径。在私有端点运行固定版本容器，挂载版本化 config.yaml，通过环境变量注入供应商凭证，再使用标准 OpenAI 客户端发出请求。生产中不要使用 main-latest，也不要启用详细调试日志。 在签发团队密钥前加入 Postgres。使用私有托管数据库、加密连接、自动备份和独立迁移 Job。不要让服务流量的副本执行 Schema 更新，避免扩容事件与迁移发生竞争。 在第二个副本前加入 Redis。LiteLLM 的生产检查清单建议多实例时使用 Redis 7 或更高版本。没有共享状态，各副本会独立执行限制，缓存命中也只在本地生效。Kubernetes 中使用每 Pod 一个 Worker，并按 CPU 扩容，不要依据进程保留内存。 每个工作负载使用独立虚拟密钥。虚拟密钥文档要求 Postgres，并支持模型权限、预算和费用归属。显式配置模型与路由白名单。不要把 Master Key 发给应用，也不要假设空列表等于无访问权。 把网关放进私有网络。通过 TLS 只暴露客户端需要的请求路由。Admin UI 与管理 API 应置于身份感知访问之后，或使用独立管理入口。Egress 只允许已批准的供应商与可观测性目标。 让升级可以回退。针对生产 Schema 副本测试镜像、配置和迁移，先部署 Canary，再重放代表性请求。保留上一镜像与兼容数据库备份。 执行故障演练。依次停用一个供应商、一个网关副本、Redis 和 Postgres。确认回退、Readiness、告警、恢复目标和客户端错误符合预期。没有演练过的回退只是文档，不是韧性。 2026 年 LiteLLM 安全发生了什么变化？ 安全必须参与架构设计，因为 Proxy 可能持有模型凭证、数据库访问权和请求内容。2026 年 3 月，恶意 LiteLLM 1.82.7 和 1.82.8 被发布到 PyPI。项目的事件时间线称，受影响包可窃取环境变量和云凭证，而 Proxy Docker 镜像用户未受影响。安装过这些包的团队应遵循事件建议，并轮换可能暴露的凭证。 独立的 Proxy 漏洞进一步提高了要求。1.81.16 至 1.83.6 受到 API Key 验证中的关键SQL 注入漏洞影响。1.74.2 至 1.83.6 受到 MCP 测试端点命令注入影响。之后的虚拟密钥权限提升在 1.83.14 修复。这些修复版本只是历史下限，不是今天建议的部署目标。 实务答案很直接：使用当前受支持的 Stable Release，不用 Prerelease，也不用旧的最低补丁。2026 年 8 月 13 日，GitHub 将 v1.96.2 标记为 Latest，并在 LiteLLM Releases 页面提供 cosign 验证命令。部署当天重新核对，固定精确版本或 Digest，验证签名并扫描镜像，再把同一 Digest 推进所有环境。 上线前必须满足什么条件？ 最小权限必须显式配置。每个工作负载有独立虚拟密钥、命名负责人、允许模型、路由、预算和到期时间。Master Key 不进入应用。 Secret 分离且可恢复。供应商密钥与 Master Key 放入平台 Secret 存储。永久 LITELLM_SALT_KEY 另行备份，因为保存凭证后更改它会使凭证无法读取。 网络默认关闭。管理路由私有化，保持 TLS 验证，限制供应商 Egress，数据库与 Redis 不使用公网地址。这些控制遵循 LiteLLM 的安全最佳实践。 日志有数据政策。决定是否允许记录 Prompt 和响应，导出前脱敏敏感字段，设定保留期与访问权限，并测试删除。我们的LLM 前 PII 脱敏网关指南详细讨论这一边界。 健康检查区分不同问题。LiteLLM 文档中的匿名 Liveness 与 Readiness 端点不调用模型，经过认证的模型健康端点会发出真实供应商请求。根据健康检查契约分别配置编排探针与深层合成检查。 费用经过对账。把 LiteLLM 归属结果与供应商账单比较，并测试流式响应、重试、缓存命中和回退。Dashboard 估算有用，但财务需要明确对账路径。 负责人能快速修补。订阅安全公告，定义补丁 SLA，维护 staging Smoke Suite，并记录疑似泄露后的凭证轮换流程。 自托管 LiteLLM 需要多少工作？ 不存在诚实的统一价格，因为网关会继承你的云、可用性目标、身份系统和合规范围。以下是 Wavect 用于前期范围评估的规划区间，不是 LiteLLM 报价或云价格承诺。 部署级别常见工程投入包括 私有 staging 网关1 至 3 个工程日固定版本容器、两个供应商、配置、一个虚拟密钥、基础日志和 Smoke Test 单区域生产基线1 至 3 个工程周副本、TLS、托管 Postgres 与 Redis、Secret、预算、指标、备份、Canary 和 Runbook 受监管或多团队平台4 至 10 个工程周身份集成、租户政策、审计证据、隐私控制、灾难恢复、负载测试和支持移交 持续所有权指定月度容量加值班补丁、供应商变更、成本映射审查、事件响应、权限审查和恢复演练 在中等流量下，基础设施账单通常不是决定因素，所有权才是。没有人能承担修补和恢复责任时，即使托管网关发票更高，总成本也可能更低。如果平台团队已经运营 Kubernetes、Postgres、Redis、Secret 和可观测性，LiteLLM 可以复用已有控制。 应该自托管 LiteLLM，还是购买托管网关？ 当控制权是硬性要求，且运维是团队现有能力时，自托管 LiteLLM。当速度、支持和更少值班负担比基础设施控制更有价值时，购买托管网关。对于尚未证明需要网关的单一原型，继续直接访问供应商。 有效的采购测试应该计算一年，而不是一个容器。把设计、实施、数据库与 Redis、监控、备份、升级、安全审查、值班和一次供应商迁移全部纳入，再与托管方案及不行动的成本比较。网关上线后的成本优化可参考我们的LLM Token 成本削减指南。 常见问题 自托管 LiteLLM 免费吗？ LiteLLM 开源网关没有许可证费用。你仍需支付计算、PostgreSQL、Redis、流量、可观测性、备份、模型供应商，以及工程师修补和运营的成本。Enterprise 治理与支持另行定价。 自托管 LiteLLM 会让 Prompt 留在我的服务器吗？ Prompt 会经过你的网关，但除非所选模型运行在你控制的基础设施中，否则仍会发送给托管供应商。需要审查完整路径，包括日志、Callback、供应商保留政策和备份。 LiteLLM 可以不用 Kubernetes，只运行在 Docker 吗？ 可以。Docker 适用于开发、staging 和部分 VM 部署。生产仍需要多进程或多副本、TLS、Postgres、Redis、健康检查、备份、监控和安全发布流程。Kubernetes 是提供这些控制的一种方式，不是目标本身。 LiteLLM 需要 Postgres 和 Redis 吗？ Proxy 认证、虚拟密钥和费用跟踪需要 Postgres。", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "官方文档", "url": "https://docs.litellm.ai/" }, { "@type": "WebPage", "name": "LiteLLM 价格页", "url": "https://www.litellm.ai/pricing" }, { "@type": "WebPage", "name": "LiteLLM 生产部署指南", "url": "https://docs.litellm.ai/docs/proxy/deploy" }, { "@type": "WebPage", "name": "生产检查清单", "url": "https://docs.litellm.ai/docs/proxy/prod" }, { "@type": "WebPage", "name": "虚拟密钥文档", "url": "https://docs.litellm.ai/docs/proxy/virtual_keys" }, { "@type": "WebPage", "name": "事件时间线", "url": "https://github.com/BerriAI/litellm/issues/24518" }, { "@type": "WebPage", "name": "SQL 注入漏洞", "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc" }, { "@type": "WebPage", "name": "MCP 测试端点命令注入", "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g" }, { "@type": "WebPage", "name": "虚拟密钥权限提升", "url": "https://github.com/advisories/GHSA-qrc4-49gv-mv9m" }, { "@type": "WebPage", "name": "LiteLLM Releases 页面", "url": "https://github.com/BerriAI/litellm/releases" }, { "@type": "WebPage", "name": "安全最佳实践", "url": "https://docs.litellm.ai/docs/proxy/security_best_practices" }, { "@type": "WebPage", "name": "健康检查契约", "url": "https://docs.litellm.ai/docs/proxy/health" } ], "dateModified": "2026-08-13", "datePublished": "2026-08-13", "description": "自托管 LiteLLM 是自己运营 AI 网关，并不等于模型也在本地推理。生产环境至少需要两个固定精确版本的网关副本、TLS、私有托管 Postgres、用于共享限流与路由状态的 Redis、最小权限虚拟密钥、Secret 管理、健康探针、指标、备份，以及经过验证的升级路径。LiteLLM OSS 没有许可证费用，但基础设施和当班运维都有真实成本。2026 年的 PyPI 供应链事件与多项代理漏洞，使精确版本锁定、镜像签名验证、网络隔离和快速补丁成为上线条件。先用 staging 容器验证，再在控制权、合规或供应商可迁移性值得运维成本时建设高可用栈。", "headline": "LiteLLM 生产级自托管指南：2026 架构与安全", "image": "https://wavect.io/img/blog/headers/header_self-host-litellm-production-2026.svg", "inLanguage": "zh", "keywords": "LiteLLM, AI 基础设施, LLM 网关, 自托管", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/self-host-litellm-production-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/self-host-litellm-production-2026/", "wordCount": 443 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/models-infrastructure/", "name": "模型与基础设施", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/self-host-litellm-production-2026/", "name": "LiteLLM 生产级自托管指南：2026 架构与安全 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "LiteLLM 开源网关没有许可证费用。你仍需支付计算、PostgreSQL、Redis、流量、可观测性、备份、模型供应商，以及工程师修补和运营的成本。Enterprise 治理与支持另行定价。" }, "name": "自托管 LiteLLM 免费吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Prompt 会经过你的网关，但除非所选模型运行在你控制的基础设施中，否则仍会发送给托管供应商。需要审查完整路径，包括日志、Callback、供应商保留政策和备份。" }, "name": "自托管 LiteLLM 会让 Prompt 留在我的服务器吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "可以。Docker 适用于开发、staging 和部分 VM 部署。生产仍需要多进程或多副本、TLS、Postgres、Redis、健康检查、备份、监控和安全发布流程。Kubernetes 是提供这些控制的一种方式，不是目标本身。" }, "name": "LiteLLM 可以不用 Kubernetes，只运行在 Docker 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Proxy 认证、虚拟密钥和费用跟踪需要 Postgres。多个 Proxy 实例共享限流、路由状态和缓存时需要 Redis。最小无状态实验可以不运行完整数据层，但它不是多团队生产设计。" }, "name": "LiteLLM 需要 Postgres 和 Redis 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "使用当前受支持的 Stable Release，固定精确镜像 Tag 或 Digest，验证签名并在推进前测试。不要使用移动 Tag，也不要把旧漏洞的最低修复版本当作当前建议。" }, "name": "应该部署哪个 LiteLLM 版本？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "如果没有团队负责网关补丁、恢复和值班，或上市速度比私有基础设施控制更重要，就选择托管。当合规、网络、供应商可迁移性或规模形成明确商业理由时，再重新评估自托管。" }, "name": "什么时候应该选择托管替代方案？" } ] } ```