API 网关对比OpenRouterPortkeyLiteLLM

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

AIHO 编辑部 · 2026-06-21

TL;DR

维度	OpenRouter	Portkey	LiteLLM (自建)
模式	托管聚合	Gateway + 托管	开源自托管
接入成本	极低（一个 key）	低（改 base URL）	中（部署 + 配置）
模型数	数百	上千	取决于你接几家
Fallback	✅ 基础	✅ 高级	✅ 可配
成本透明	透传 + 路由费	透传 + 按量	纯透传
数据隐私	过第三方	过第三方	完全自有
适合	个人 / 试水	生产团队	企业 / 合规

为什么需要 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

延迟对比

方案	P50 延迟	P95 延迟	说明
直连 OpenAI	320ms	850ms	基准
OpenRouter	380ms	1100ms	+60ms 路由开销
Portkey	350ms	900ms	+30ms，缓存命中更快
LiteLLM	340ms	880ms	+20ms，自建网络近

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

可靠性对比

2 周内记录的故障：

方案	故障次数	平均恢复	影响
OpenRouter	2 次（限流）	约 15 分钟	请求排队
Portkey	0 次	—	Fallback 生效
LiteLLM	1 次（OOM）	约 5 分钟	重启恢复

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

选型决策树

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

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

踩坑记录

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