Gateway Comparisons2026年7月1日Big Y

多提供商 LLM 路由器比较：计费、日志、配额和回退机制

从账户所有权、计费、请求日志、配额、回退行为、迁移便利性和 Flatkey 契合度等维度，比较不同的多提供商 LLM 路由器选项。

一个多提供商 LLM 路由器只有在能回答运营问题，而不仅仅是模型数量问题时才有用。比较路由器的团队需要知道谁拥有提供商访问权限、使用量如何计费、哪些日志能证明请求路径、配额在哪里执行、回退尝试如何记录，以及迁移现有 SDK 或工作流程的难度有多大。

此比较于 2026 年 7 月 1 日（亚洲/上海时间）核对，参考了 Flatkey 的公共主页、定价页面、实时定价 API 快照，以及来自 LiteLLM、OpenRouter、Portkey、Cloudflare 和 Vercel 的官方文档。请将模型行、端点系列、产品措辞、路由行为和计费语言视为特定时间点的证据。在通过任何路由器发送生产流量之前，请验证当前的仪表板、模型行、提供商控制台和请求日志。

快速解答：多提供商 LLM 路由器应证明什么

对于一个团队来说，最好的多提供商 LLM 路由器并非提供商列表最长的那一个。而是与您的所有权模型相匹配的那一个。如果财务部门希望只有一个预付余额和一张发票，那么路由器必须使计费审查变得简单。如果平台工程部门希望控制提供商密钥，那么路由器必须清晰地展示凭证所有权和路由规则。如果产品团队需要弹性，那么回退日志必须显示第一个提供商失败后发生了什么。

路由器模式	最适合	选择前需验证的内容
托管式单密钥网关	希望获得模型访问、计费、路由、使用分析、请求日志、配额控制，并减少独立提供商账户的团队。	当前的模型行、端点系列、价格单位、配额行为、请求日志字段、回退证据和发票路径。
提供商市场路由器	希望拥有广泛的模型目录、提供商偏好、回退模型以及可选的自带密钥 (BYOK) 路径的团队。	积分与 BYOK 行为、提供商路由顺序、回退触发器、数据策略偏好、速率限制所有权以及响应模型归属。
自托管或可配置代理	希望拥有提供商密钥、路由配置、Redis 或数据库状态、自定义回调和内部策略逻辑的平台团队。	谁来运营代理、如何跟踪支出、如何保留日志、如何处理升级以及如何同步提供商限制。
云或平台 AI 网关	已经投资于该云或部署平台，并寻求分析、日志、速率限制、重试、回退或统一模型访问的团队。	支持的提供商、BYOK 支持、使用量导出、计费实体、路由控制、应用归属和配额边界。

Flatkey 符合托管式单密钥网关模式。其当前主页称 Flatkey 是一个面向生产级 AI 团队的 API 网关，并表示它统一了模型访问、路由、计费、使用分析和运营控制。该页面还提到，团队可以获取一个 API 密钥并调用连接的 AI 模型，而无需单独向每个提供商申请；可以通过自动切换和负载均衡来路由多个上游账户；按实际使用量计费；设置配额限制；并保持团队消耗清晰可见。

多提供商 LLM 路由器比较矩阵

请将此多提供商 LLM 路由器矩阵用作购买者清单。它不是排名。正确的选择取决于您的团队是优先考虑托管访问、直接的提供商所有权、代理控制、云原生可观察性，还是框架级别的便利性。

选项	账户和计费状况	日志和配额	回退和路由	实际适用性
Flatkey	Flatkey 公开页面描述了单一 API 密钥、减少的独立提供商账户、预付余额、基于用量的计费、用量分析、成本控制、企业发票、采购支持以及跨提供商的单一发票。	Flatkey 公开页面描述了请求日志、用量分析、配额限制和清晰的团队消耗。本文的实时定价 API 快照返回了 227 个模型行、23 个供应商以及包括 `anthropic`、`gemini`、`image-generation`、`openai` 和 `openai-video` 在内的端点系列。	Flatkey 公开页面描述了跨多个上游账户的路由，具有自动切换和负载均衡功能。请为您的工作流程验证确切的回退日志和模型行行为。	当目标是单一密钥、统一的计费审查、用量证明以及减少提供商账户工作时，这是一个很好的商业选择。从定价开始，然后获取密钥进行范围测试。
LiteLLM	当团队需要可配置的路由器/代理层和提供商密钥控制时，通常会评估 LiteLLM。其官方路由器文档描述了跨部署和提供商的负载均衡。	LiteLLM 文档称，Redis 可在生产环境中用于跟踪冷却服务器和 TPM/RPM 限制的用量。文档还展示了用于跟踪 API 密钥、API 端点、所用模型和响应成本的自定义回调。	LiteLLM 官方路由文档描述了跨部署和提供商的负载均衡、冷却、回退、超时、重试和路由策略。	当平台工程团队希望进行更深层次的代理控制，并准备好运营网关状态、配置、密钥和升级时，这是一个很好的选择。
OpenRouter	OpenRouter 文档描述了 OpenRouter 积分和 BYOK（自带密钥）。BYOK 文档称，提供商密钥允许通过您的提供商账户直接控制速率限制和成本，而 OpenRouter 积分的提供商速率限制则由 OpenRouter 管理。	OpenRouter 提供商路由文档公开了请求级别的提供商偏好设置，例如提供商顺序、允许的提供商、回退权限、数据收集偏好、ZDR 路由、提供商排序和最高价格。	OpenRouter 文档描述了提供商负载均衡、备用提供商、按价格、吞吐量或延迟对提供商进行排序，以及通过 `models` 数组实现模型回退。	当团队需要广泛的模型路由、明确的提供商偏好以及在积分和 BYOK 之间进行选择时，这是一个很好的选择。当计费所有权是决定性因素时，请与 OpenRouter 替代方案进行比较。
Portkey	Portkey 文档称，旧的虚拟密钥概念已移至模型目录，其中一个 Portkey API 密钥可以访问多个提供商和模型，而提供商凭据则集中存储。	Portkey 模型目录文档描述了组织级管理、精细预算、速率限制、模型允许列表、凭据管理和访问控制。	Portkey 回退文档描述了优先的提供商/模型目标、默认情况下在非 2xx 响应时回退、自定义状态码触发器，以及通过配置 ID 或跟踪 ID 跟踪回退请求。	当团队需要一个具有模型目录治理、提供商凭据管理和可追溯回退链的网关时，这是一个很好的选择。
Cloudflare AI Gateway	Cloudflare AI Gateway 文档将该产品定位为为 AI 应用程序提供可见性和控制，支持的提供商包括 Workers AI、Anthropic、Google Gemini、OpenAI、Replicate 等。	Cloudflare 文档将分析、日志记录、成本/令牌指标、缓存和速率限制列为 AI Gateway 的功能。	Cloudflare 文档将请求重试和模型回退列为在发生错误时增强弹性的功能。	当应用程序已存在于 Cloudflare 生态系统中，或者当边缘相邻的可观察性和控制是核心需求时，这是一个很好的选择。
Vercel AI Gateway	Vercel 文档称，AI Gateway 提供单一密钥、数百个模型、统一的 API、支出监控，并且对令牌不加价，包括 BYOK。	Vercel 文档指出了跨提供商的用量、延迟和支出的可观察性，以及用于定价和指标的用量和计费文档。	Vercel 文档称，如果一个提供商失败，AI Gateway 会自动向其他提供商重试请求，并提供用于路由、回退和偏好设置的提供商选项。	对于以 Vercel 为中心的团队来说，这是一个很好的选择，他们希望以框架友好的方式访问多个模型并获得内置的支出可见性。

计费：从付款实体开始

一个多提供商 LLM 路由器在改变代码之前，首先改变的是财务运营。难题不是“我们能否调用 Claude、GPT、Gemini 和图像模型？”，而是“谁为请求付费，我们以后能否证明这笔费用？”

Flatkey 当前的定价页面称，团队可以从预付余额开始，跨顶级模型进行路由，并扩展用量，而无需固定的月度套餐。该页面还描述了按模型、令牌类型和请求日志计量的用量，以及用量分析、成本控制、企业发票、采购支持和跨提供商的单一发票。当购买者希望路由器能减少分散的提供商计费时，这些声明使 Flatkey 尤为重要。

OpenRouter 的 BYOK 文档划定了不同的界限。他们表示 OpenRouter 同时支持积分和自带提供商密钥。使用 OpenRouter 积分时，提供商的速率限制由 OpenRouter 管理。而使用提供商密钥时，用户可以通过其提供商账户直接控制速率限制和成本。这是一个有意义的区别：积分通过路由器集中支付，而 BYOK 则保留了更直接的提供商账户所有权。

Vercel 的 AI Gateway 文档也明确了其计费立场。他们表示，令牌的成本与直接从提供商处获得的成本相同，没有任何加价，包括 BYOK。Portkey 的文档强调通过 Model Catalog 集中存储提供商凭据，以及预算和速率限制等治理控制。LiteLLM 的路由器文档强调可配置的控制，但运营团队仍必须决定提供商账单、密钥所有权和退款记录的存放位置。

日志：索取请求级别的证据链

一个有用的多提供商 LLM 路由器日志不应止步于状态码和延迟。对于模型流量，日志应能帮助开发人员调试失败的响应，并帮助财务部门解释成本项目。这意味着请求日志需要包含应用密钥、路由、模型、提供商、端点系列、令牌或单位用量、状态、重试或回退尝试，以及可用时的成本记录。

日志字段	重要性	需索取的证明
应用密钥或项目	将使用情况与工作流、团队、环境或客户关联起来。	从应用密钥追溯到模型使用情况和计费记录的单个请求。
模型和提供商	显示实际路由，而不仅仅是请求的别名。	在同一条记录中显示请求的模型、服务的模型、提供商和端点系列。
令牌、图像、视频或请求单位	解释不同模态的成本基础。	清晰显示输入、输出、缓存、图像、视频或请求单位。
回退尝试	显示第一个提供商是否失败以及路由器接下来尝试了什么。	跟踪 ID、尝试顺序、状态码和最终服务的路由。
成本或余额影响	为财务部门提供对账路径。	请求成本、余额扣减、发票分组或可导出的使用记录。

Portkey 的回退文档是索取此类证据的一个很好的例子。他们表示，Portkey 会记录回退链中的所有请求，并建议通过 Config ID 和 Trace ID 进行筛选，以检查单个请求的所有尝试。Cloudflare AI Gateway 文档称，分析功能可以显示请求、令牌和成本，而日志记录则可以深入了解请求和错误。LiteLLM 文档展示了可以捕获 API 密钥、API 端点、所用模型和响应成本的自定义回调。

配额和速率限制：了解哪个限制导致了失败

在多提供商 LLM 路由器中，配额很容易被误解。一个工作流可能会受到应用密钥配额、团队预算、网关的速率限制、提供商账户的 RPM/TPM 限制、预付余额或特定模型的可用性条件的约束。这些限制是不可互换的。

Flatkey 的公开主页上说，团队可以设置配额限制，并保持团队消耗清晰可见。Cloudflare AI Gateway 文档将速率限制列为通过限制请求数量来控制应用程序扩展的一种方式。Portkey Model Catalog 文档提到了精细的预算、速率限制和模型允许列表。LiteLLM 文档提到使用 Redis 在生产环境中跟踪使用情况和 TPM/RPM 限制。OpenRouter BYOK 文档称，使用提供商密钥可以直接控制提供商账户的速率限制和成本，而 OpenRouter 积分则将提供商速率限制的管理转移给了 OpenRouter。

在选择路由器之前，请使用一个特意设置的小限制来运行配额测试。确认会出现哪种错误，日志是否能识别配额来源，达到速率限制后是否允许回退，以及财务部门是否能将受阻请求视为已使用、未使用或使用失败。

回退机制：在信任路由器之前定义触发器

回退机制是多提供商 LLM 路由器可能悄悄制造意外的地方。回退可以提高可用性，但它也可能改变模型行为、延迟、价格单位、数据处理、工具调用支持或响应形式。路由器必须让回退触发器和最终路由可见。

OpenRouter 的模型回退文档称，如果主模型的提供商宕机、达到速率限制或因审核而拒绝回复，models 参数允许请求尝试其他模型。同一文档还说，请求将按照最终使用的模型定价，该模型会在响应正文中返回。Portkey 文档称，回退可以使用优先的提供商/模型目标，并可以在特定状态码（如 429 或 503）上触发。Cloudflare 文档将请求重试和模型回退列为弹性功能。

在进行生产评估时，不要只问“是否存在回退机制？”而应问以下这些问题：

触发器：回退是否在所有非 2xx 响应、仅选定的状态码、提供商停机、速率限制、审核或超时时发生？
兼容性：备用模型是否支持相同的工具、结构化输出、上下文长度、流式行为和模态？
成本：回退模型是否使用不同的价格单位或提供商账户？
日志记录：团队能否在一次跟踪中看到每一次尝试？
响应归属：最终响应是否揭示了实际处理请求的模型？
回滚：操作员是否可以在事件发生时禁用回退或固定某个提供商？

迁移：更改基础 URL 只是第一步

许多路由器迁移始于简单的基础 URL 和 API 密钥更改。但这并非完整的迁移。多提供商 LLM 路由器迁移应证明 SDK 请求、响应形态、流式路径、工具调用行为、使用记录、配额行为和回滚路径仍然有效。

选择一个类似生产环境的工作流：不要从所有模型开始。选择一个具有真实提示、预期响应形态和已知成本基础的路由。
映射模型别名：记录请求的模型名称、提供商路由、端点族和回退候选模型。
运行十个可跟踪的请求：包括一次正常调用、一次流式调用（如果使用）、一次工具调用（如果使用）、一次配额测试、一次故意的提供商或模型故障，以及一次重试/回退测试。
比较日志：确认应用密钥、路由、模型、提供商、令牌或单位计数、状态、延迟、回退尝试和成本记录。
审查计费：将这些相同的请求追溯到预付余额、积分、提供商账户、发票或内部费用分摊。
编写回滚规则：记录在路由器行为异常时如何返回直接提供商访问或固定已知路由。

要了解更多迁移背景信息，请将此页面与 LiteLLM 替代方案和企业 AI API 网关清单进行比较。路由器的决策部分是技术性的，部分是财务性的，部分是运营性的。

Flatkey 在路由器候选名单中的定位

当购买者希望减少提供商账户工作并获得更清晰的使用操作时，Flatkey 在这次多提供商 LLM 路由器比较中表现最为出色。为本文核查的公开证据支持 Flatkey 的以下声明：

一个面向生产 AI 团队的 API 网关。
一个 API 密钥即可连接 AI 模型，无需单独向每个提供商申请。
减少了独立的提供商账户、分散的 API 密钥、不一致的路由和碎片化的使用跟踪。
跨多个上游账户进行路由，具有自动切换和负载均衡功能。
基于使用量的计费、预付余额、请求日志、使用分析、成本控制、配额限制、企业发票、采购支持以及跨提供商的统一发票。
2026 年 7 月 1 日的实时定价 API 快照，返回 227 个模型行、23 个供应商以及端点族 anthropic、gemini、image-generation、openai 和 openai-video。

这些证据并不能证明每个模型行都对您的账户可用，也不能证明任何特定的提供商路由都有永久价格，或者回退机制将与您确切的生产行为相匹配。正确的下一步是进行范围明确的验证运行：打开 Flatkey 定价，确认当前的模型行和端点族，然后获取密钥并运行上述的十个请求迁移验证。

路由器决策记录模板

在批准将多提供商 LLM 路由器用于生产工作流之前，请使用此模板。

决策字段	记录
工作流所有者	团队、应用、环境和业务所有者。
主模型路由	请求的模型、服务的模型、提供商、端点族以及账户或网关凭证来源。
计费所有者	预付余额、网关积分、BYOK 提供商账户、直接发票或内部费用分摊路径。
所需日志	应用密钥、模型、提供商、使用单位、状态、延迟、回退跟踪和成本记录。
配额来源	应用密钥配额、团队预算、网关速率限制、提供商 RPM/TPM、预付余额或账户级限制。
回退策略	触发器、备用路由、兼容性检查、最大尝试次数、成本预期和回滚开关。
验收证明	十个可跟踪的请求、计费审查、回退测试、配额测试和回滚测试。