企业级 LLM Gateway 选型 2026：自建、LiteLLM、Portkey、Helicone 与 ofox 怎么选
TL;DR — 2026 年企业级 LLM Gateway 不是单选题。5 人内的小团队直接用聚合平台（ofox 一个 API key 覆盖近 100 个模型，国内付款 + 国内访问最省事）；20-100 人的工程团队选 LiteLLM 自托管（开源免费，数据面在自己手里）；监管严的大企业选 LiteLLM Enterprise 或 Portkey 企业版（SOC 2、SSO、审计日志齐全）；observability 需求可以考虑 Langfuse 等替代方案——Helicone 已被 Mintlify 收购、转入维护模式。“自建网关”在 2026 年几乎只剩两个理由：要做路由层差异化，或者监管完全不允许第三方介入数据面。其他场景至少先看完本文再决定要不要造轮子。
自建网关的边际收益为什么塌了
2024 年底，多模型路由还能算 “差异化”。到了 2026 年，OpenAI 兼容协议已经事实上成为行业标准（OpenAI / Anthropic / Google / 国产模型几乎全部支持），路由本身不值钱。值钱的是路由之外的配套：成本可视化、配额管理、密钥轮换、guardrails、审计日志、灰度发布、跨地域容灾。
一年前一个自建网关大概要写 3000 行路由代码。现在 Portkey 的 OSS 版本（GitHub Portkey-AI/gateway）开箱即用支持 1600+ 模型，LiteLLM 5 月 17 日发的 v1.85.0（Realtime GA、MCP Gateway 扩展、多租户加固）+ 5 月 21 日的 v1.85.1 补丁，企业级特性也基本齐了。问题不再是”能不能做”，而是”该不该自己做”。
下面把 4 类方案的真实差异、隐性成本、适用场景讲清楚，最后给一个能直接抄的决策矩阵。
四类方案的真实差异
方案 A：完全自建
你自己写网关。Go 或 Python 都行，typical 架构是 nginx → 业务网关 → 模型适配层 → 上游。
你需要解决的问题（不完整清单）：
- 协议适配：OpenAI / Anthropic / Google Gen AI / 国产厂商各自的字段差异（
max_tokensvsmax_output_tokens、tool calling 格式、streaming chunk 拼接逻辑） - 重试与熔断：哪些错误码可重试、退避策略、上游超时与你客户端超时的协调
- 鉴权与配额：虚拟 key、按 team/user/project 的预算、RPM/TPM 限制
- 可观测性：每次请求的 token 用量、延迟、成本归因、错误率
- 缓存：精确缓存 + 语义缓存（embedding 比对）
- 高可用：多地域部署、上游故障切换、灰度发布
真实成本估算：一个高级工程师 8-12 周做到能上生产，后续每月 20-30% 工时维护。按国内一线城市高级工程师月薪 4 万算，第一年成本 25-35 万人民币，还没算上线后第一次大故障的代价。
什么时候值得自建：监管不允许任何第三方介入数据面；或者路由策略本身就是商业机密（比如多智能体编排、特定行业的成本优化算法）；或者已经有平台团队，多一个网关只是边际工作量。
其他场景，2026 年都不建议自建。
方案 B：开源自托管（LiteLLM / Helicone）
OSS 网关跑在你自己的 K8s 上，数据面（token 流量）经过你的基础设施，但你不用写路由逻辑。
LiteLLM OSS（GitHub BerriAI/litellm）是 Python 实现，proxy 模式起步只要一条 litellm --config config.yaml。OSS 版本已经包含 OpenAI 兼容协议、虚拟 key、spend tracking、预算、fallback、请求和响应日志，100+ 模型的适配代码也都现成。
Helicone OSS（GitHub Helicone/helicone）起家是 observability，AI Gateway 能力（智能负载均衡、语义缓存、自动故障转移、限流）也已具备。Proxy 模式只要改 base URL。自托管早在 2025 年 5 月就引入，目前提供 helicone-all-in-one 单镜像 Docker 部署方案（一条 docker run 命令拉起前端、Jawn API、MinIO、PostgreSQL、ClickHouse 五个服务）。但要注意：2026 年 3 月被 Mintlify 收购后已进入维护模式，只继续发布安全补丁、新模型支持和性能修复，活跃功能开发已结束——新项目慎选，可考虑 Langfuse 等仍在积极迭代的替代方案。
自托管的隐性成本经常被低估。你要管 K8s 或 Docker、要做监控、要写 runbook、半夜要起来处理故障。升级时机自己定，但破坏性升级也要自己接（LiteLLM 月度发版节奏比较快）。还有一类容易踩坑的：OSS 版本看起来基础的某些功能其实放在 Enterprise 里收费，比如 SSO、审计日志、密钥自动轮换、SOC 2 报告。
适合 20-100 人的工程团队，有 SRE 文化、对数据面控制权有要求，但还没到要花 SaaS 钱的规模。
方案 C：SaaS 网关（Portkey / LiteLLM Enterprise）
把网关交给厂商，数据面经过厂商的基础设施。换来一站式服务和合规背书。
Portkey 自己的定位是”production stack for Gen AI builders”，功能面铺得最广：AI Gateway、Observability、Guardrails（60+ 检查，含 prompt injection、PII 泄露等）、Prompt 管理、MCP Gateway。合规拿了 SOC 2、HIPAA、GDPR、CCPA。定价 Developer 免费 / Production $49/月 / Enterprise 定制。Production 版本按 Recorded Logs、Retention、Advanced Features 计费，重度使用时要先算清楚账单结构再签。
LiteLLM Enterprise 在 OSS 基础上加了 SSO（Okta / Azure AD / Google Workspace / OIDC / SAML）、JWT 鉴权、审计日志（带保留策略）、RBAC（organizations / teams / users）、IP ACL、密钥自动轮换、secret manager 集成，合规 SOC 2 Type 2 + ISO 27001。它的部署模式比较特别：你拿 Docker 镜像跑在自己机器上，但用 license key 解锁企业特性。既能要求”数据不出我们机房”，又能拿到企业级支持。官方压测到 1000 RPS。
Helicone Cloud 历史上的优势是 observability 起家的细节：session 级指标、LangGraph 集成、UI 比另两家干净。但被 Mintlify 收购后已进入维护模式，不建议作为新项目的首选——如果痛点主要是”模型调用看不清楚、排查问题靠 log”，可优先评估 Langfuse、Arize Phoenix 等仍在积极迭代的 observability 工具。
适合：监管要求明确（金融、医疗、出海合规），需要 SOC 2 / HIPAA 报告挂在采购合同上的企业。
方案 D：聚合平台（ofox / OpenRouter / 硅基流动）
聚合平台不是 gateway，是 aggregator。区别在账单和数据面：gateway 通常只透传 token，账单还是你跟 OpenAI、Anthropic 各算各的；aggregator 把账单合并到一个账户里。你和聚合平台结算，聚合平台再和上游厂商结算。
对国内团队来说，ofox 在企业场景里的几个实际优势：
一个 API key 直接覆盖近 100 个模型，GPT-5.x（5.5/5.4 Pro/5.4/5.3/5.2 等）、Claude Opus 4.7 & Sonnet 4.6、Gemini 3.5 Flash 与 3.1 Pro/Flash Lite、Grok 4.20、DeepSeek V4 Flash & V4 Pro、Qwen 3.7 Max、Kimi K2.6、MiniMax M2.7、Doubao Seed 2.0 系列全在一个账户里。
国内访问加国内付款这一点其他方案解决不了：支付宝 / 微信付款、人民币结算、国内直连不用科学上网。LiteLLM、Portkey 自身没法替你处理”国内主体给海外厂商付款”的合规链路。
企业 SLA 99.9%（Pro 档）到 99.99%（Enterprise 档），多地域边缘节点。开源模型最多 7 折，常用模型也有阶梯定价。企业版可以谈 SSO/SAML、私有或混合云部署、专属客户成功经理。
多模态覆盖目前以图像生成 + 语音转录为主：图像有 OpenAI GPT Image 2 / GPT Image 1.5、Google Gemini 3.1 Flash Image Preview、Doubao Seedream 5.0 Lite；语音转录有 GPT-4o Mini Transcribe。视频生成与 TTS 暂未上架，对该类需求的团队仍需另接专用厂商；但相对于 LiteLLM、Portkey 这类只透传纯文本协议的 Gateway，图像/转录场景已经能在一个 API key 下完成。
聚合平台也有边界。复杂 guardrails、企业级 RBAC 精细度、自定义 prompt 模板管理这些治理面功能，ofox 给的够用但不如 Portkey 深。如果你要做的是 AI 安全工程层级的能力（多层 PII 检测、内容审核、输出格式校验全要），通常还是 ofox 加 Portkey OSS 自托管层叠加来用。
延伸阅读：OpenRouter vs ofox 对比与迁移、硅基流动 vs ofox 深度对比。
决策矩阵
按 5 个维度打分，每个维度按 0-3 分给四类方案打分，你按自己业务的优先级加权即可。
| 维度 | 自建 | LiteLLM 自托管 | Portkey/LiteLLM Enterprise | ofox |
|---|---|---|---|---|
| 启动成本（越低越好） | 0 | 2 | 2 | 3 |
| 数据面控制权 | 3 | 3 | 2（自托管 LiteLLM Enterprise 可拿到 3） | 1 |
| 国内访问 + 国内付款 | 1（自己解决） | 1 | 1 | 3 |
| 模型覆盖广度 | 看自己投入 | 3 | 3 | 3 |
| 合规背书（SOC 2 / HIPAA） | 自己审计 | 0 | 3 | 2（Enterprise 可谈） |
| 企业治理（RBAC / 审计 / SSO） | 自己造 | 1 | 3 | 2 |
| Guardrails 深度 | 自己造 | 1 | 3 | 1（基础） |
| 多模态覆盖（图像/语音转录，视频暂缺） | 0 | 1 | 1 | 2 |
典型决策路径：
- 5 人以内、做产品 demo 或 MVP：直接 ofox。省下的工程师周期价值高于任何 gateway 能给你的优化
- 5-50 人、国内开发、要快速试多模型：ofox 主力，在自己业务层做基础 fallback；需要 prompt 版本管理时再叠加 Portkey OSS 自托管
- 20-100 人、有平台团队、对数据面有要求：LiteLLM 自托管，需要 SSO 或审计时升级 Enterprise
- 100+ 人、监管严（金融/医疗/政府）：LiteLLM Enterprise 自建机房 + Portkey OSS guardrails 层；或者直接 Portkey、LiteLLM Enterprise 的全套 + 私有部署
- 国内出海企业：ofox 走国内业务通道、LiteLLM 走海外通道，按地域分流
能不能叠用？
可以，而且很多团队就是这么做的。常见的有几种组合。
聚合平台 + 自托管 gateway：业务代码 → LiteLLM 自托管（做企业治理） → ofox（做模型聚合 + 国内通道） → 各上游模型。这样保留了 LiteLLM 的虚拟 key、RBAC、审计、spend tracking，同时通过 ofox 拿到国内付款、国内节点、多模态完整覆盖。
observability 旁路：业务代码 → 你的 gateway（同步路径） → 异步发到 Helicone（observability 旁路）。observability 不在关键路径上，故障不会影响主流量，但能拿到细粒度的会话级追踪。
双 gateway 灰度：老系统留 Portkey SaaS、新系统切 LiteLLM 自托管，业务侧用 feature flag 灰度切流。这样能拿到迁移过程中的对比数据，而不是一刀切迁过去再后悔。
决策前先问自己 5 个问题
付款方在哪？国内主体收人民币付款 → ofox 优先；海外主体已经有 Stripe → Portkey 或 LiteLLM Enterprise 都行。
数据出境合规怎么定？严格不出境 → 自托管（LiteLLM 或 Helicone）；可出境但要合规报告 → SaaS（拿 SOC 2、HIPAA 的）。
峰值 RPS 多少？100 以下任何方案都能扛；100 到 1000 之间 LiteLLM Enterprise 和 Portkey 都压测过；超过 1000 自己做性能 PoC，别只听厂商单方面数据。
多模态需求？只用文本任何方案都行；要图像、视频、TTS 全要 → ofox 覆盖最完整，其他方案要单独接厂商。
团队有几个能 oncall 的工程师？0 个用 SaaS 或 aggregator；1-2 个自托管开源；3 个以上专职平台工程师才考虑自托管 Enterprise 或自建。
几个真实的”自建陷阱”
下面是见过的真实案例，细节做了脱敏。
协议差异比想象的多。某团队自建 6 周后发现，Anthropic 的 tool calling streaming 和 OpenAI 不一样，重写适配层又花了 3 周；过两个月 Google 又改了 Gen AI SDK 的 streaming 格式。协议适配是持续工作量，不是一次性投入。
成本归因如果不一开始就埋好就完了。自建网关如果没在第一天就埋好 per-team、per-user、per-feature 的 token 维度，后面财务追溯成本时要重写整套埋点。LiteLLM 和 Portkey 自带这套抽象，省的不是写代码的时间，是 6 个月后回头补数据的时间。
故障切换没真测试过几乎是必踩的坑。“我们写了 fallback 啊”，但从来没在真实流量下断过上游。生产故障第一次发生时往往才发现 fallback 配置错了，或者超时阈值不合理。SaaS gateway 这块经过多家客户在生产上验证。
语义缓存的账要算清楚。听起来很美，但 embedding 调用本身也要钱，命中率不到 30% 时反而亏。Portkey 和 LiteLLM 自带可观测的缓存命中率统计，自建要自己埋点。
相关延伸：企业 AI API 接入避坑指南、AI API 高可用与 fallback 实战、Claude API streaming 与批量调用企业级实战。
选型清单（动笔前 10 分钟过一遍）
签字前过一遍这份清单，能省下后悔：
- 模型清单确认：业务必需的模型在每家方案的覆盖列表里？（特别注意国产模型在海外 gateway 上往往缺失）
- 计费维度确认：按 token / 按请求数 / 按月固定？峰值场景下账单上限在哪？
- SLA 数字确认：99.9% 在你的业务里意味着每月 43 分钟停机——能接受吗？
- 数据保留策略确认：日志保留多久？能不能配置零保留模式？
- 退出成本确认：API 兼容协议是否标准 OpenAI？切换到下一家要改多少代码？
- 合规文件确认：SOC 2 Type 2 报告能拿到完整 PDF 吗？审计期是什么时候？
- 国内访问确认：测试机房在哪？延迟到 200ms 以内吗？
总结
2026 年的 LLM Gateway 选型本质上是问一个问题：你愿意把哪些复杂度外包出去？
自建意味着所有复杂度留在自己手里，只有监管不允许或者路由本身是商业机密时才划算。自托管 OSS 是中间方案，基础设施在自己机器上但路由逻辑借开源社区的力，20-100 人工程团队的最优解。SaaS 网关把治理与合规外包出去，匹配监管严、预算到位的大企业。聚合平台把国内通道和多模型对接外包出去，对国内团队和需要多模态、国产模型完整覆盖的场景启动成本最低。
很多团队最终的答案不是”选哪一个”，而是”叠加哪几个”。先想清楚团队规模、合规边界、付款场景，再回头看决策矩阵，能让你少走 6 个月的弯路。
如果你正在做这个选型，可以直接在 ofox 控制台注册一个免费账户先跑通端到端的多模型链路，半小时就能拿到第一组真实延迟和成本数据。之后再决定要不要叠加自托管 gateway 或 SaaS 网关。
