LLM 网关对比LiteLLM、Portkey 和自研网关的算账一、LLM 多模型接入不是加个 Proxy那么简单当团队从调用单个模型如 OpenAI GPT-4o扩展到同时接入 5-8 家模型厂商的 20 多个模型时直接调 API 的模式立刻崩塌。每家厂商的 API 格式不同、计费口径差异巨大token vs character vs request、限流策略千差万别。更关键的是生产环境还需要一套机制来保证某个模型挂了自动切换备用模型、每个租户的 token 用量可追踪、以及敏感请求被拦截。LLM 网关就是为解决这些问题而生。LiteLLM 把 100 模型厂商的 API 统一成 OpenAI 格式Portkey 在网关之上叠加了可观测性、缓存和护栏功能自研网关则给了团队完全的控制权。三种路线的选择本质上是时间成本与定制能力的交换。二、协议适配 vs 全栈平台 vs 完全控制三种路线的架构分化LiteLLM 的定位它不是一个全功能的 API 网关而是一个模型协议翻译层。核心能力是把 Anthropic 的 Messages API、Google 的 Generative AI API、Cohere 的 Chat API 等全部映射为 OpenAI 的 Chat Completion 格式。代价是超出 OpenAI 格式的能力如 Anthropic 的 extended thinking、Google 的 grounding无法通过 LiteLLM 透传。Portkey 的全栈路线Portkey 在网关之外提供了完整的可观测性和管理面板。包括每个 API Key 的 token 消耗、延迟分布、错误率趋势、以及语义缓存命中率。护栏Guardrails模块可以在请求到达模型之前在网关上做 PII 检测和敏感词过滤。但全栈意味着锁入——团队的网关配置、Prompt 模板、缓存策略全部托管在 Portkey 平台上。自研网关的取舍自研意味着完全的控制权——限流策略可以按 GPU 池的可用容量动态调整、缓存策略可以和业务 RAG Pipeline 深度耦合、计费模型可以精确到部门级别。但代价也是明确的模型 API 升级时如 OpenAI 的 structured output、Anthropic 的 Prompt Caching需要手动跟进适配而 LiteLLM/Portkey 通常会在一周内适配新特性。三、从总拥有成本算账假设一个 10 人团队月均调用 5000 万 token同时接入 5 个模型厂商。3.1 直接成本对比成本项LiteLLM自部署PortkeySaaS自研网关运行成本~$200/月1 台 4C8G 服务器免费层 $0.3/1K 请求超免费配额后~$200/月服务器开发接入成本2-3 人天修改代码适配 OpenAI 格式1-2 人天SDK 直接接入15-20 人天完整开发后续维护成本低社区维护 100 Provider零SaaS 托管中需要跟踪多厂商 API 变更月度综合费用~$200~$150-$500按请求量浮动~$200 持续人力LiteLLM 在成本上对 10 人团队来说是最优的——自部署的透明度加上社区维护的 Provider 覆盖。Portkey 的免费层每月 10 万请求足够大多数小型团队使用但超过后费用上升明显。3.2 隐性成本类型LiteLLMPortkey自研模型 API 适配延迟1-3 天1-3 天按人力排期迁移成本如果想换方案低OpenAI 格式标准中配置 Prompt 都托管高完全定制故障排查难度中open source可调试低管理面板可视化取决于自身能力安全合规风险低数据不经过三方中数据经过 Portkey 服务器低完全内网安全合规是需要特殊关注的点。如果团队处理的 prompt 包含用户敏感信息金融、医疗场景Portkey 的 SaaS 模式意味着请求内容会经过第三方服务器。即使 Portkey 声称不存储数据也需要在合规评估中考虑这一点。LiteLLM 自部署方案不会有这个问题。四、每种路线的边界条件LiteLLM 不适合的场景强依赖 OpenAI 之外模型特有能力的场景。比如需要利用 Anthropic 的 Computer Use、Google 的 Grounding with Google Search这些能力超出 OpenAI 格式的表达范围。对延迟极度敏感P99 50ms overhead。LiteLLM 的协议转换层有约 5-20ms 的额外延迟对大部分场景无感但对延迟敏感的实时应用需要衡量。需要复杂的条件路由和自定义 Provider 逻辑。LiteLLM 的路由策略least-busy、latency-based足够常规使用但特化场景可能需要自研。Portkey 不适合的场景数据合规要求严格、不允许请求内容出内网的场景。Portkey 提供私有部署方案但价格是 SaaS 版的数值倍。预算敏感、月请求量过千万的团队。按请求计费的模式在千万量级下的月费可能超过 $3000自研方案有明显的成本优势。团队已经建立了自己的可观测性体系Prometheus Grafana 自建日志Portkey 的管理面板带来的增量价值有限。自研不适合的场景团队规模和业务增速不匹配自研维护成本的情况。一个 5 人团队既要开发业务又要维护网关投入产出比值得考量。初期阶段、接入的模型厂商还不确定、API 格式还在快速变化。自研网关在这种情况下的适配成本会快速累积。尚未遇到开源方案无法满足的需求。在确实遇到 LiteLLM 做不到的事情之前不要为了未来可能需要而自研。结论实践路线图阶段一团队 5 人、月 token 1000 万直接使用 LiteLLM 自部署。成本最低一台服务器、接入最广100 Provider 开箱即用、未来迁移成本最低OpenAI 格式是事实标准。阶段二团队 5-20 人、月 token 1000 万-1 亿如果需要可视化监控和护栏评估 Portkey。如果数据必须在内部流转继续用 LiteLLM 自建监控把 LiteLLM 的 callback 机制接入已有的 Prometheus/Grafana 栈。阶段三团队 20 人、多部门多租户、定制计费此时自研网关的收益开始显现。但不是从零自研——基于 LiteLLM 的源代码做定制扩展保留其 Provider 适配能力在此基础上增加自定义的路由、计费和权限逻辑。LLM 网关是基础设施组件。衡量它的标准不是功能多不多而是出问题时你能不能快速定位、上线后会不会成为新的单点故障。基础设施不需要漂亮话它需要在凌晨三点的告警中表现得稳定可靠。