2026 统一 LLM API 与 AI Gateway 对比：OpenRouter、LiteLLM、Portkey、Cloudflare 与 TheRouter

30 秒结论： 如果你最看重模型市场和覆盖面，先看 OpenRouter；如果你要 self-hosted proxy，先看 LiteLLM；如果 gateway policy 和 observability 是核心，先看 Portkey；如果应用已在 Cloudflare 控制面里，先看 Cloudflare AI Gateway；如果你想要 OpenAI-compatible endpoint、provider/model routing、fallback，以及已实现路径上的 unified billing/accounting surfaces，就看 TheRouter。 2026 年的问题不是有没有 gateway，而是你愿意运维哪一种 control plane。

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model， 并返回 OpenAI 形式的流式响应。

Sources: OpenRouter Quickstart, retrieved 2026-07-25; OpenRouter Model Routing, retrieved 2026-07-25; LiteLLM Router docs, retrieved 2026-07-25; LiteLLM GitHub, retrieved 2026-07-25; Portkey Fallbacks, retrieved 2026-07-25; Portkey Gateway GitHub, retrieved 2026-07-25; Cloudflare AI Gateway, retrieved 2026-07-25; Cloudflare AI Gateway Features, retrieved 2026-07-25; TheRouter Quickstart, retrieved 2026-07-25; TheRouter Model Fallbacks, retrieved 2026-07-25.

TL;DR — Unified LLM API Gateways Compared

The table is deliberately operational rather than promotional. A gateway choice changes your incident response path, not just your SDK import.

什么才算 Unified LLM API Provider？

A unified LLM API provider accepts one request shape, then routes it to one or more upstream model providers. Most teams standardize on the OpenAI Chat Completions shape because many SDKs and coding tools already expose a configurable base_url.

The minimum useful gateway does three things:

1. Normalizes the request path so clients do not need a separate SDK for each provider.
2. Routes across models or providers based on model name, fallback policy, cost, latency, health, or a manual rule.
3. Leaves an audit trail so operators can explain which upstream served a request, how much it cost, and why fallback did or did not happen.

If a product only proxies one provider and does not expose routing or fallback semantics, we would not treat it as a gateway for this comparison.

集成方式：同一个 OpenAI SDK Pattern

The integration pattern is similar across managed gateways: change the API key and base_url, then use provider/model-style model IDs.

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.therouter.ai/v1",
  apiKey: process.env.THEROUTER_API_KEY,
});

const completion = await client.chat.completions.create({
  model: "anthropic/claude-sonnet-4.5",
  messages: [{ role: "user", content: "Summarize this release note." }],
});

OpenRouter documents the same base-URL idea against https://openrouter.ai/api/v1; TheRouter documents https://api.therouter.ai/v1; LiteLLM and Portkey can expose OpenAI-compatible proxy endpoints; Cloudflare places gateway controls in front of supported providers. For a buyer, the question is no longer "can my SDK call it?" but "who owns the routing policy?"

Routing 和 Fallback：产品真正拉开差距的地方

OpenRouter separates model routing from provider routing. Its documentation describes explicit model fallback arrays, provider preferences, price ceilings, and default provider selection. That makes sense for teams that want a managed marketplace with many upstream routes.

LiteLLM exposes routing as infrastructure you can run yourself. Its router supports load balancing, retries, cooldowns, timeouts, fallbacks, and strategies such as rate-limit-aware, latency-based, least-busy, and lowest-cost routing. The trade-off is ownership: your team runs the proxy, Redis, secrets, and upgrade path if you self-host.

Portkey treats fallback as a gateway config. You define prioritized targets, optionally trigger fallback only on status codes such as 429 or 503, and trace fallback chains by config ID or trace ID. That is attractive when incident review and policy explanation matter as much as the request itself.

Cloudflare AI Gateway adds routing to the edge-control plane: analytics, caching, rate limits, spend limits, guardrails, DLP, dynamic routing, request retry, and model fallback. It is strongest when the application already uses Cloudflare controls and wants AI traffic governed beside the rest of the app.

TheRouter exposes an OpenAI-compatible API and documents model fallback through a models array plus provider-level controls such as allow_fallbacks. Our truthful claim is narrow: TheRouter routes OpenAI-compatible requests through configured providers and supports provider/model routing and fallback when the live product path supports it. We do not claim support for every model, guaranteed cheapest routing, or zero downtime.

Pricing 和 Billing：不要只比 Token 单价

Token rates matter, but gateway cost is a three-layer calculation:

OpenRouter emphasizes one account with access to many models and optional BYOK paths. LiteLLM can reduce vendor lock-in but shifts more runtime cost to your infrastructure. Portkey and Cloudflare add value through policy, logs, and controls. TheRouter's value is the combination of OpenAI-compatible routing and unified billing/accounting surfaces where implemented — useful when teams want fewer provider accounts and clearer cross-provider ledgers.

跨供应商比较 API 价格时，统一到美元每百万 token口径，并区分输入与输出。多数供应商的输出 token 价是输入的 2–5 倍，所以"补全长度大" 的负载与"检索为主"的负载在同样的标称单价下成本会差很多。

• 统一货币（USD）——发表日按汇率折算并标注。
• 区分输入/输出——永远不要给单一"混合价"。
• 每行引到供应商自己的价格页 + 抓取日期。
• 注明长上下文阶梯价——长上下文常常单独跳一档。

可观测性与 Control Plane 匹配

This is where a head-to-head checklist helps:

A common mistake is choosing by model count alone. Model count is useful, but day-two operations depend on whether the gateway can answer: who called which model, which provider actually served it, what fallback happened, and where the spend landed.

决策矩阵：按工作选择 Gateway

Pick OpenRouter if you mainly need fast access to many models, provider fallback, and a managed endpoint your app can call quickly.

Pick LiteLLM if you need self-hosting, want routing code close to your infrastructure, or must integrate custom provider adapters that a managed gateway does not yet expose.

Pick Portkey if policy, guardrails, request logs, and traceable fallback chains are first-class requirements for your team.

Pick Cloudflare AI Gateway if AI traffic should live inside an existing Cloudflare security, analytics, caching, DLP, and rate-limit control plane.

Pick TheRouter if your team wants to keep OpenAI-compatible clients, route across configured providers, use fallback chains, and consolidate billing/accounting surfaces without maintaining your own proxy. Start with the OpenAI-compatible router page, then verify fallback behavior in the model fallback guide and browse available providers.

切换前的生产检查清单

• Confirm the exact endpoints you need: chat, responses, embeddings, images, audio, or provider-native paths.
• Test streaming shape and provider-specific response fields before assuming full compatibility.
• Decide whether fallback should trigger on all errors, only rate limits, or only upstream outages.
• Log the final served model/provider for every production request.
• Compare total cost across token rates, gateway fees, and operational ownership.
• Keep a direct-provider rollback path for at least the first deployment window.

结论

Unified LLM gateways are converging on the same developer entry point: one OpenAI-compatible client and a configurable routing layer behind it. The differences are now about operating model. OpenRouter optimizes breadth, LiteLLM optimizes ownership, Portkey optimizes policy and traceability, Cloudflare optimizes edge control, and TheRouter optimizes a managed routing-and-billing path for teams already standardizing on OpenAI-compatible requests.

The safest choice is the one whose control plane matches your operating style. If your team does not want to run proxy infrastructure, a managed gateway is usually the better starting point. If your team needs every routing decision in your own code and network, self-hosting LiteLLM may be worth the extra work.