LLM API 网关实测：OpenRouter vs Portkey vs 自建 LiteLLM

TL;DR

为什么需要 LLM 网关

一旦你的应用同时调多家模型（Claude 写文案、GPT 做推理、Gemini 处理长文档），就会撞上一堆重复劳动：每家 API 格式不同、key 管理分散、某家挂了没有兜底、成本散落在各个控制台看不清。LLM 网关就是在你的代码和各家模型之间加一层，统一成一套接口（通常是 OpenAI 兼容格式），顺带做 fallback、缓存、限流、可观测。

三种方案对应三种取舍：托管省事但数据过第三方、自建可控但要运维。下面用真实负载比一比。

测试环境

• 应用：多模型 Agent，同时调 Claude / GPT / Gemini
• 调用量：日均约 10K 次请求
• 时长：2 周，每种方案各跑 4-5 天
• 关注指标：延迟、成本、可靠性、运维负担

各方案实测

OpenRouter：最省心

import openai
client = openai.OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="or-xxx",
)
# 一个 key 调数百个模型，model 字段写 "anthropic/claude-sonnet-4" 之类
resp = client.chat.completions.create(
    model="anthropic/claude-sonnet-4",
    messages=[{"role": "user", "content": "hi"}],
)

体验：

• 接入 5 分钟，一个 key 通吃所有模型
• 自带模型路由和基础 fallback（一个 provider 挂了自动换下一个）
• Dashboard 看消耗明细，跨模型成本一处可见
• 多收一笔路由费（约 5%）
• 偶尔限流（高峰期热门模型请求排队）
• 所有请求过 OpenRouter 服务器，数据隐私无保障

成本：日均约 $50（模型费 + 约 5% 路由费）

Portkey：生产级控制

import { Portkey } from "portkey-ai";

const portkey = new Portkey({
  config: {
    strategy: { mode: "fallback" },
    targets: [
      { provider: "anthropic", override_params: { model: "claude-sonnet-4" } },
      { provider: "openai", override_params: { model: "gpt-5" } },
    ],
  },
});
// 主模型挂了自动切备用，对调用方透明

体验：

• Fallback 逻辑强大——主模型挂了几乎无感切备用
• 负载均衡——多个 API key 轮询，突破单 key 限流
• 语义缓存——相似请求命中缓存，省钱省延迟
• 可观测——每个请求有 trace、成本、延迟记录
• 配置比 OpenRouter 复杂，要理解 config/strategy 概念
• 托管版数据仍过第三方
• 无中国区节点，国内访问要自己解决网络

成本：日均约 $48（模型费 + 缓存命中省了一点）

自建 LiteLLM：完全可控

# 部署（Docker 一行起）
docker run -p 4000:4000 \
  -e ANTHROPIC_API_KEY=xxx \
  -e OPENAI_API_KEY=xxx \
  ghcr.io/berriai/litellm:main

client = openai.OpenAI(
    base_url="http://localhost:4000/v1",
    api_key="anything",  # 自建网关，key 自己定
)

体验：

• 完全自托管，数据不出公司
• 纯透传，0 额外路由费
• 统一上百家 provider 到 OpenAI 格式
• Fallback / 限流 / 预算控制都能在 config.yaml 里配
• 需要自己运维（监控、备份、升级）
• Fallback 配置是 YAML，灵活性不如 Portkey 的策略系统
• 没有现成托管 Dashboard（要自己接 Prometheus / Grafana）

成本：日均约 $47.6（纯模型费）+ 服务器约 $2/天 ≈ $49.6

延迟对比

LiteLLM 延迟最低（自建、内网近），OpenRouter 最高（多一跳第三方）。差距在几十毫秒量级，对多数应用不敏感，但高 QPS 场景会累积。

可靠性对比

2 周内记录的故障：

Portkey 最稳——fallback 让上游故障对用户基本不可见。LiteLLM 的故障是自己运维问题（内存没给够），可控但要你盯。

选型决策树

数据必须不出公司 / 强合规？
├─ 是 → LiteLLM 自建（唯一选项）
└─ 否 → 要不要 fallback + 缓存 + 可观测的生产级能力？
        ├─ 要 → Portkey（开箱即用的高可用）
        └─ 不要（个人 / 试水）→ OpenRouter（5 分钟接入最快）

成本敏感 + 有运维能力 → LiteLLM（省掉路由费）

踩坑记录

1. OpenRouter 限流不分模型——所有模型可能共享同一 rate limit，高峰期一起排队。
2. Portkey 缓存要配 TTL——默认行为可能让你命中过期缓存或永远不命中，按业务调 TTL。
3. LiteLLM 内存——高并发时容易 OOM，调大容器内存或加 Redis 做队列。
4. 流式请求的 fallback 是通病——三家的 fallback 多数只在非流式请求生效，流式响应一旦主模型中途挂了，往往直接报错而非平滑切换。做流式聊天要单独处理这个边界。
5. 成本对比别只看路由费——自建省了 5% 路由费，但加上服务器和运维人力，小规模未必划算。按你的真实调用量算总账。

2026-09 补充：缓存与计费规则变了，网关的省钱逻辑要重算

本文主体写于 2026-06，此后上游厂商改了两条直接影响网关收益的规则：

1. Prompt caching 的失效条件放宽。 OpenAI 在 2026-09-22 随 GPT-6 Sol / Luna 发布调整了缓存策略：修改 reasoning effort 或工具集不再使缓存失效，并上线 Prompt Caching Dashboard 与 miss 诊断。此前「一改参数就整段重算」是长会话 agent 的隐形账单，现在这一块可以省下来了。对网关的意义：缓存键的设计空间变大了——过去为了让缓存命中，你得把 effort / 工具集钉死；现在可以更灵活地调度，缓存命中率反而更高。
2. 同日 Anthropic 把 Opus 5.5 的缓存读价从 $0.50 砍到 $0.20（−60%）。 在长 agentic 会话里超过 90% 的输入 token 按缓存价计费，所以真实的单价是缓存读价，不是输入价。网关选型时请把「谁能更好地命中缓存」提到与「路由费几个点」同等重要的位置——5% 的路由费差异，在缓存命中率差 20 个百分点面前不值一提。

示例中的模型 ID（如 anthropic/claude-sonnet-4、gpt-5）为写作当时的示意值，网关的模型列表更新极快，接入前请以网关当前的模型目录为准，不要照抄。

适合 / 不适合

同时调用两家以上模型、需要统一接口的团队；需要 fallback 兜住上游故障的生产应用；被「成本散落在多个控制台看不清」困扰的人；有数据不出境要求、必须自建的企业。

只调用单一厂商模型的团队（直连 SDK 更简单也更可靠）；没有运维能力却想靠自建省钱的小团队；把网关当「高可用保证」而不准备降级直连的人（网关本身就是一个新的故障面）。

FAQ

Q：多一层网关，值得吗？

取决于你调几家模型。只调一家就不值得——直连更简单也更可靠。调两家以上时，网关省下的是「每家 SDK / key / 错误码 / 限流策略各学一遍」的成本，以及某家挂掉时没有兜底的风险。

Q：自建真的比托管省钱吗？

小规模通常不省。本文实测：自建省掉约 5% 路由费，但要加服务器（约 $2/天）与运维人力。按真实调用量算总账，别只看路由费百分比。自建的真实理由是合规与可控，不是成本。

Q：fallback 会不会把请求切到更贵的模型？

会，而且这是最常见的账单失控来源。各网关对「可用」的定义不同（有人只看 HTTP 200，有人看延迟与错误率），自动 fallback 可能在你无感知的情况下把请求切到更贵或更弱的模型。上线前请显式锁定 fallback 链里的模型清单与价格上限。

Q：流式请求的 fallback 能用吗？

三家都不好用。 fallback 多数只在非流式请求生效；流式响应一旦主模型中途挂掉，通常直接报错而非平滑切换。做流式聊天必须自己处理这个边界（见「踩坑记录」第 4 条）。

Q：数据合规这一关怎么过？

托管网关（OpenRouter / Portkey）在中间可见全部 prompt 与响应。若你的业务有数据出境或行业合规要求，唯一选项是自建 LiteLLM，或者接受托管并先走完合规审查。这不是技术问题，是法务问题。

AI 之家 观点

其一，网关的真实价值不是「省事」，是「把上游的不确定性关进一个可控层」。 各家 API 格式、限流、错误码、模型下线的节奏都不一样；网关把这层差异吃下来，你的应用只需要面对一套接口。真正的 ROI 在上游出事的那 15 分钟里，而不是平时的 60ms 延迟差。

其二，2026 下半年选网关，第一指标应该换成「缓存命中率」。 缓存读价被砍到 $0.20 之后，长会话的成本结构变了——输入价的重要性下降，缓存命中率的重要性上升。5% 的路由费是线性成本，缓存命中率是非线性成本，省钱的顺序搞反了会白忙一场。

其三，别把网关当高可用方案。 它自己就是一个新的单点故障面（本文实测三家都出过故障）。任何把网关放进关键链路的架构，都必须准备「降级直连」这条退路——没有退路的网关，是把多个上游的故障概率换成一个更大的。

其四，fallback 要显式锁价。 自动切换是便利，也是账单风险。明确写出 fallback 链里允许出现哪些模型、单价上限是多少，否则「高可用」会在月末变成「高账单」。

来源

• OpenRouter 官方文档
• Portkey 官方文档
• LiteLLM 官方文档与 GitHub
• Announcing GPT-6 Sol and GPT-6 Luna in the API, Codex and ChatGPT（OpenAI 官方公告，2026-09-22，含缓存策略调整）
• Introducing Claude Opus 5.5（Anthropic 官方，2026-09-22，含缓存读价调整）

声明：本文实测数据基于 2026-06 的 2 周运行记录（日均约 10K 次请求），延迟与成本数字具有时效性，请以自家负载复测为准；2026-09 补充部分依据上述官方公告。

延伸阅读

• OpenRouter 工具卡 · Portkey · LiteLLM
• 什么是 Token — 计费单位扫盲，算成本必看
• 什么是 Function Calling — 多模型工具调用的兼容性差异