LLM API 中转站行业分析

一、概述

1.1 什么是 LLM API 中转站

LLM API 中转站（Relay Station / API Gateway）是一种中间层服务，它在用户与多家大模型厂商（如 OpenAI、Anthropic、DeepSeek、Google 等）的 API 之间充当中介。用户通过一个统一的 API 端点即可访问数百个模型，无需分别注册各家厂商的账号、管理多套 API Key、处理不同的计费体系。

这个定义同时覆盖两类形态：面向开发者与长尾模型的社区型中转站（OpenRouter、B.AI、ZenMux 等），以及面向企业的云厂商 MaaS 平台（阿里云百炼、腾讯云 TokenHub、火山方舟、百度千帆、华为云 MaaS 等，见 3.3）。后者在国内企业市场才是主流渠道。

从技术角度看，中转站本质是一个反向代理 + API 网关：

• 统一接入：提供 OpenAI 兼容的 API 端点，一个 Key 调用所有模型
• 协议转换：在 OpenAI、Anthropic、Google Vertex 等不同协议间自动翻译
• Key 聚合：批量采购上游 API Key，池化分发给下游用户
• 负载均衡：多上游渠道自动切换，保证高可用
• 计费与配额：Token 级用量追踪、计费、限流

1.2 为什么需要中转站

LLM API 中转站的出现源于以下核心痛点：

• 厂商碎片化：全球有 80+ 模型提供商、500+ 模型，每家注册流程、计费方式、API 协议各不相同
• 跨境访问门槛：部分模型厂商对特定地区访问受限，中转站提供间接访问通道
• 成本优化需求：批量采购可获折扣，中转站将折扣传递给终端用户
• 高可用需求：单厂商故障时自动切换到备选渠道，保证业务连续性
• 统一管理：用量统计、费用审计、权限控制集中化

二、产品组成与工作原理

本节通过 UML 图从行为到结构逐步解析 LLM API 中转站的组成与工作机理。

2.1 用例图：角色与功能

下图展示了中转站系统中不同角色（参与者）与系统功能之间的关系。三种核心角色分别是：终端开发者（直接调用 API 构建应用）、企业管理员（管理团队用量与权限）、平台运营者（维护上游渠道与系统配置）。

图 1：用例图 — LLM API 中转站角色与功能

用例说明

2.2 时序图：API 调用流程

下图以一次典型的聊天补全请求为例，展示从用户应用发出请求到收到响应的完整生命周期。关键步骤包括：认证鉴权、协议转换、路由选择、上游调用、结果缓存、用量计费。

图 2：时序图 — 一次 API 请求的完整调用流程

流程说明

1. 用户应用以 OpenAI 兼容格式向中转站统一端点发起 POST 请求
2. API 网关验证 API Key 的合法性、权限和配额
3. 路由模块根据请求的模型名映射到对应上游渠道，支持多提供商负载均衡
4. 协议转换器将 OpenAI 格式请求转换为目标提供商的原生格式（如 Anthropic Messages、Gemini 格式等）
5. 查询缓存层是否有相同请求的缓存结果（适用于重复请求场景）
6. 将转换后的请求发送到上游提供商，等待响应
7. 上游返回结果，中转站写入缓存、记录 Token 用量计费
8. 将响应转回 OpenAI 兼容格式返回给用户

2.3 部署图：系统架构

下图展示了中转站系统的物理部署架构。系统通常部署在云基础设施上，利用 CDN 边缘加速、多区域部署、分布式缓存等来保证全球低延迟。

图 3：部署图 — 中转站系统物理部署架构

部署说明

• 用户端：通过 HTTPS 连接到中转站的 CDN 边缘节点或直接连接到 API 网关
• 网关层：负载均衡器分发请求到多副本 API 网关实例，保障高可用
• 服务层：认证服务、路由服务、协议转换器、计费服务等核心业务逻辑
• 数据层：Redis 缓存加速、PostgreSQL 持久化用户/账单数据、ClickHouse 存储用量日志
• 上游提供商：通过 HTTPS 连接 80+ 模型提供商，支持多渠道故障转移

2.4 组件图：内部模块

下图展示了中转站系统内部的软件组件及其依赖关系，从网关层到底层存储层，逐层分解。

图 4：组件图 — 中转站内部模块结构

组件说明

三、行业生态全景

3.1 产业链包图

LLM API 中转站处于产业链的中间层，连接上游模型提供商与下游终端用户。下图展示了完整的行业生态格局。

图 5：包图 — LLM API 中转站行业生态全景

上游：模型提供商

模型提供商是产业链的源头，掌握核心模型技术和定价权。2026 年 DeepSeek 的激进定价策略（V4.1-Flash 闲时输入 ¥1/百万 Token、缓存命中 ¥0.02/百万 Token）成为行业"价格锚点"，迫使所有模型必须证明其溢价的合理性。

• 国际厂商：OpenAI、Anthropic、Google、xAI、Meta（开源）
• 国内厂商：DeepSeek、智谱 AI、阿里通义、月之暗面、字节跳动、美团、腾讯
• 云厂商推理：Tencent Cloud、Google Vertex、Amazon Bedrock、Azure —— 既是上游算力/托管方，也直接下场做中游（见 3.3）

中游：中转站平台

中游是"把多家模型聚合成一个 API 端点"的一层，按商业模式与技术路线分为四类：

• 商业聚合平台：OpenRouter（全球最大）、OpenCode Go/Zen（生态型）、ZenMux（差异化保险赔付）、B.AI（国内区域型）、Crun（多模态型）、EasyRouter（云厂商合作）
• 云厂商 MaaS 平台（企业级中转）：阿里云百炼、腾讯云 TokenHub、火山方舟、百度千帆、华为云 MaaS、硅基流动 —— 面向企业客户，把模型服务做成云产品线，详见 3.3
• 开源基础设施：LiteLLM（企业自建网关）、New API / One API（国内中转站标准后端）
• 灰色渠道：号池类（88code 等），共享账号/逆向 Key，极低价高风险

需要特别说明：云厂商既在上游也在中游。它们一方面出租算力/提供模型托管（上游），另一方面把 DeepSeek、GLM、Kimi、MiniMax 等第三方模型与自研模型聚合起来，对外提供统一 API、统一计费、统一配额与合规承诺（中游）。在"国内企业要开发票、要私网、要数据不出境"的场景里，云厂商 MaaS 才是事实上的主流中转渠道，其份额远大于社区认知中的 OpenRouter / B.AI 一类平台。

下游：终端用户

• 个人开发者：独立开发、自由职业，核心诉求是用一个 API 调用所有模型
• 企业用户：SaaS 产品集成、内部工具，关注成本控制和合规
• 政企 / 信创客户：要求开票、私网、等保、数据不出境，是云厂商 MaaS 的核心客群（见 3.3）
• AI 应用平台：OpenRouter 平台上有 250K+ 应用接入，触达 4.2M+ 用户

3.2 开源基础设施

开源项目是 LLM API 中转站生态的重要基础设施，以下按 GitHub Stars 排序：

专有名词解释：

• API Gateway：API 网关，位于客户端和后端服务之间的中间层，负责请求路由、认证、限流、计费等横切关注点。
• Reverse Proxy：反向代理，代表客户端向服务器发起请求，对外隐藏后端架构。
• Key Aggregation：Key 聚合，将多个上游 API Key 集中管理、池化分配，实现负载均衡和故障转移。
• Protocol Translation：协议转换，在不同厂商的 API 协议之间自动翻译。
• Load Balancing：负载均衡，将请求分发到多个上游渠道，避免单点过载。
• Rate Limiting：速率限制，控制用户或 API Key 在单位时间内的请求次数，防止滥用。

3.3 国内云厂商 MaaS 平台（企业级中转）

MaaS（Model as a Service，模型即服务）是云厂商的标准产品线：把"调用大模型"包装成一项云服务，提供统一的 API 网关、多家模型聚合、云内私网接入、云账号统一结算、企业级权限与审计。从产业链角色看，云厂商同时身处上游与中游——既出租算力、托管模型权重，又把模型聚合成统一端点对外售卖。

讨论"中转站"时若只想到 OpenRouter / B.AI 这类社区型平台，会严重低估市场结构：国内企业市场的 LLM API 调用，绝大部分走的是云厂商 MaaS，而不是社区型中转站。企业采购的不是"最便宜的 Token"，而是发票、合同、私网、等保、数据不出境与 SLA。

3.3.1 与社区型中转站的定位差异

3.3.2 三种供给形态（决定价格结构）

同样是"卖 DeepSeek"，云厂商的采购方式不同，成本结构与风险归属完全不同：

3.3.3 主要平台盘点

图 6：类图 — 云厂商 MaaS 平台的核心领域对象

类图说明

该图刻画了云厂商 MaaS 平台内部的领域模型，也是理解"为什么云厂商能被算作中转站"的关键：一个 Key 背后挂着的不是一个模型，而是模型广场条目 → 模型服务 → 分时价格策略 → 推理接入点 → 配额 → 用量记录 → 账单这一整条可配置、可计量、可审计的链路。

专有名词解释：

• MaaS：Model as a Service，模型即服务，云厂商把模型推理能力封装为按量计费的云服务。
• TokenHub / Model Studio / Ark / 千帆：各家云厂商 MaaS 产品线的具体名称（腾讯云 / 阿里云 / 火山引擎 / 百度智能云）。
• 原厂直供：云厂商不自建推理集群，直接转售模型原厂 API，价格与时限口径沿用原厂，但 SLA 通常由原厂承担、云厂商不额外承诺。
• 私网接入 / VPC：Virtual Private Cloud，虚拟私有云。请求走云内网而非公网，降低延迟与数据外泄风险。
• SLA：Service Level Agreement，服务等级协议，对可用性、延迟、成功率的书面承诺，是云厂商相对社区型中转站的核心差异点。
• 信创 / 等保：信息技术应用创新与网络安全等级保护，政企采购的硬性合规门槛。
• Token Plan：云厂商的预付费 Token 额度套餐，本质是订阅制（见 4.2）与积分制（见 4.3）的混合形态。

四、商业模式分析

LLM API 中转站的商业模式多样，核心都在于"赚取差价或服务费"，但具体形式各有不同。

4.1 加价转售（Markup）

最常见模式。中转站以官方价或批发价向上游采购，再以一定溢价（通常 5-30%）转售给下游用户。部分平台在促销期甚至以低于官方价的价格获客。

但在 DeepSeek 这类"官方价已压到极限"的模型上，加价空间几乎归零：腾讯云、B.AI 标准价、OpenCode Go、OpenRouter 官方端点均已与官方直连同价（详见 5.2）。中转站的低价更多来自第三方量化端点（如 OpenRouter 上 $0.032/百万 Token 的 fp4 端点，约为官方价 1/5）与限时补贴（如 B.AI 的 6 折），而非持续的渠道成本优势。

• 代表：OpenRouter、B.AI、ZenMux（标准价）
• 优势：模式简单，用户按量付费，无 commitment
• 劣势：价格透明化趋势下利润空间压缩，尤其是 DeepSeek 等低价模型

4.2 订阅制（Subscription）

用户按月/年支付固定费用，换取一定额度的 API 调用量。本质是"预付费额度包"。

• 代表：OpenCode Go（Go $10/月、Go Plus $40/月，含额度，超出按量兜底）、ZenMux（订阅套餐）
• 优势：收入可预测，用户粘性高，适合中等用量开发者
• 劣势：需要精确控制额度分配，不同模型成本差异大，容易亏损

4.3 积分制（Credits/Points）

用户预充值购买积分，不同模型消耗不同数量的积分。批量购买可获得折扣。

• 代表：Crun（$5/$50/$500/$1250 档位，高档次折扣更高，最高省约 70%）
• 优势：用户预充值锁定资金流，批量折扣激励大额消费
• 劣势：用户承担预充值风险（平台跑路损失余额）

4.4 免费+付费（Freemium）

通过免费额度吸引用户注册试用，再通过付费转化盈利。

• 代表：B.AI（DeepSeek V4.1 Flash 限时 6 折、历史上曾限时免费）、OpenCode（deepseek-v4.1-flash-free 免费模型）、OpenRouter（部分免费模型）
• 优势：低门槛获客，快速积累用户基数
• 劣势：免费用户成本高，需精准控制免费额度与付费转化率

4.5 开源+企业支持（Open Source + Enterprise）

核心代码开源免费，通过企业版的高级功能（SSO、审计日志、多区域部署、24/7 支持）收费。

• 代表：LiteLLM（YC W23，企业版按年请求容量定价）
• 优势：社区驱动，信任度高，数据不出境（自托管）
• 劣势：需要自建运维能力，不适合个人开发者

五、主要玩家对比

5.1 平台综合对比

以下按公开可查的使用量排序（数据来源见各平台官网及 OpenRouter 公开数据 API）：

5.2 价格对比

价格对比必须锁定同一个模型、同一个时间口径。本节以 DeepSeek-V4.1-Flash（2026-09-10 上线，官方模型名 deepseek-flash，已取代 V4 Flash 成为 DeepSeek 系列事实上的主力）为标的，横向对比官方直连、跨模型中转站与国内云厂商托管渠道。（美元按 1 USD ≈ 7.2 CNY 换算）

5.2.1 官方基准价（价格锚点）

DeepSeek 官方采用分时计价：忙时价格为闲时的 2 倍，且缓存命中价仅为未命中价的 1/50，不单独收取缓存写入费用。

忙时 = 北京时间周一至周五 09:00–12:00、14:00–18:00（不含中国法定节假日）；其余全部时段（含周末、节假日全天）为闲时。上下文字段：1M 上下文 / 384K 最大输出。

5.2.2 各渠道价目对比（元 / 百万 Token）

官方挂牌价是整条产业链的定价基准。中转站的价值就在于"官方价 ± 服务费/折扣"，因此下表以官方价为 1.0× 基准。

OpenRouter 同一模型名 deepseek/deepseek-v4.1-flash 下挂着 20+ 个上游端点，价格从 $0.032/$0.144 到 $0.27/$1.15 不等。选 DeepSeek 官方端点时与官网同价；选最低价端点时价格约为官方闲时价的 1/5，但通常为 fp4 / 非官方算力，存在质量与合规差异。

未纳入上表的渠道：ZenMux（加价转售 + 保险赔付，DeepSeek 系列按官方价 + 服务费）、Crun（积分制，以多模态为主，LLM 非核心）、EasyRouter（云厂商合作渠道，活动期约 8.5 折）、号池类灰色渠道（共享账号 / 逆向 Key，价格极低但稳定性与合规风险最高）。

5.2.3 关键差异一：闲时时段定义并不统一

这是最容易被忽略、但对账单影响最大的一点 —— 各渠道给出的"单价"看似一致，但"闲时"覆盖的时间完全不同。

5.2.4 关键差异二：缓存命中价

编码 / Agent 场景中，缓存命中输入通常占全部输入 Token 的 90% 以上（OpenCode 公开数据：DeepSeek V4.1 Flash 缓存占比 97%）。因此缓存命中价对总成本的影响远大于输入单价本身。

5.2.5 同口径成本示例

假设一次典型编码会话的用量结构：1M 缓存未命中输入 + 10M 缓存命中输入 + 1M 输出（美元计）。

结论：在 DeepSeek 这类"低价 + 高频缓存"模型上，中转站的加价空间已被极度压缩 —— 腾讯云、B.AI 标准价、OpenCode Go、OpenRouter 官方端点与官方直连完全同价（1.0×），真正的价差来自（a）闲时时段的覆盖范围、（b）缓存命中价、（c）是否走第三方量化端点。国内云厂商（阿里云百炼）单价与官网一致但缓存价贵 5 倍、闲时窗口窄，实际总成本约为官方的 1.1–2.3 倍。

专有名词解释：

• Cache Hit：缓存命中，请求前缀与已缓存的 KV Cache 匹配，输入 Token 按极低价（官方为未命中价的 1/50）计费。
• Cache Miss：缓存未命中，输入 Token 需完整参与前向计算，按标准输入价计费。
• Off-Peak / Peak：闲时 / 忙时，模型厂商按 GPU 负载设置的错峰定价，各平台时段定义不同（见 5.2.3）。
• 原厂直供：云厂商不自建推理集群，直接转售模型原厂的 API（如腾讯云 TokenHub 的 DeepSeek-V4.1-Flash 原厂直供），因此价格与 SLA 均沿用原厂口径。
• 量化端点（fp4 / fp8）：第三方推理服务商以低精度权重部署开源模型以降低成本，价格更低但输出质量与官方全精度版本存在差异。
• 价格锚点（Price Anchor）：行业中具有定价示范效应的基准价，DeepSeek 的激进定价即扮演此角色。

5.3 云厂商 MaaS 平台对比

云厂商对外报价普遍"贴着"模型官方挂牌价，单看单价表几乎没有差异（详见 3.3 的供给形态分析）。真正的成本差异来自三个隐性变量：优惠时段是否与官方一致、缓存命中价、是否必须开票 / 私网 / 合规。下表以 DeepSeek-V4.1-Flash 为例（元 / 百万 Token）。

两个反直觉结论：① 阿里云百炼与华为云 MaaS 的挂牌输入/输出价与官方完全一致，但其缓存命中价是官方的 5 倍，且优惠时段窗口比官方窄得多 —— 在缓存占比 90%+ 的编码 / Agent 场景里，实际总成本约为官方的 1.5–2.3 倍；② 火山方舟（自建推理）最贵，约为官方 2 倍，说明"云厂商 = 便宜"是误解，便宜与否取决于它是原厂直供还是自建推理。

5.3.1 Token 成本之外的隐性成本

5.3.2 云厂商 MaaS 选型建议

5.4 差异化定位

5.5 多模态模型支持对比

不同中转站平台对多模态模型（图片生成、视频生成、语音/音频）的支持差异较大。以下基于各平台官网公开数据整理：

5.5.1 图片生成模型

5.5.2 视频生成模型

OpenRouter 和 ZenMux 均提供异步视频生成 API（提交任务→轮询→下载），切换模型只需改 model 参数。

5.5.3 语音/音频模型

六、风险与合规

6.1 模型降级 / 注水

付旗舰模型的钱，实际拿到的是廉价模型或"蒸馏版"。"注水"手段包括：用轻量模型冒充旗舰、低精度量化版本替代全精度、请求路由到更便宜的替代模型。OpenRouter 和 ZenMux 明确承诺"no proxies, no degraded copies"，但小型/灰色平台缺乏透明度。

防范：使用模型指纹检测工具，优先选择透明平台。

6.2 数据泄露

所有 API 请求明文经过中转站服务器，Prompt 与输出内容对运营方可见。OpenRouter Providers 页面标注各 provider 的数据保留策略——旗下 83 个 provider 中，79 个不训练数据，46 个零保留策略。（来源：openrouter.ai/providers）

防范：选择标注"Zero retention"的 provider，企业敏感数据建议自建 LiteLLM 网关。

6.3 合规风险

未经授权转售境外 API 涉及跨境数据出境与生成式 AI 监管红线。New API 的 README 明确警告：用户必须遵守适用法律，包括生成式 AI 服务的备案/许可要求。国内大量小型中转站处于灰色地带运营。

防范：优先官方/授权渠道，企业用户需做合规审查。

6.4 跑路 / 资金风险

预充值型平台（积分制、预付费）的典型风险——平台可能随时关闭，预付款无法追回。号池类平台风险最高。

防范：小额先试，不要大额预充；优先选择按量后付或订阅制的平台。

6.5 延迟 / 稳定性

中转站多一跳网络传输，必然增加延迟。实测 OpenCode Go 的 DeepSeek V4 Flash 首字节耗时 2.8-7.5s，而官方直连约 0.3s。（来源：大模型 API 费用对比 实测数据）

防范：延迟敏感场景优先官方直连，或选择有全球边缘加速的平台。

6.6 云厂商 MaaS 的隐性成本与责任边界

云厂商看起来是"最稳妥"的渠道，但有三处需要提前确认：

• 缓存命中价陷阱：部分云厂商（自建推理形态）的输入/输出单价与官方一致，但缓存命中价是官方的 5 倍（如 ¥0.2 vs ¥0.04）。在缓存占比 90%+ 的编码 / Agent 场景下，这会让实际账单比官方高 1.5–2.3 倍。
• 优惠时段口径不同：官方闲时覆盖"除工作日 9-12、14-18 外的全部时段（含周末）"，而云厂商常自定为深夜窗口（如 22:00–08:00、02:00–08:00），白天的调用基本按常规价计费。采购前应按时段分布实测折算，而不是直接比较挂牌单价。
• SLA 责任主体：原厂直供模式下，云厂商通常声明不对该模型服务提供 SLA（责任回推原厂），出现故障时排障链路反而更长；自建推理模式下虽由云厂商承担 SLA，但模型版本会滞后于原厂官方版本。

防范：把"闲时时段占比 × 缓存命中率"代入自己的真实用量做一次折算（见 5.2.5 / 5.3 的算法），并书面确认 SLA 与模型版本更新策略。

七、选购指南

7.1 按场景推荐

7.2 选择 Checklist

1. 数据安全：平台/上游 provider 的数据保留策略是什么？（Zero retention? 30 天? 训练用?）
2. 模型真实性：平台是否承诺"no proxies, no degraded copies"？是否有验证机制？
3. 计费透明度：价格是否公开可查？是否有隐藏费用？
4. 延迟要求：你的应用对首字节延迟的容忍度是多少？是否需要全球加速？
5. 合规要求：是否有数据出境要求？是否需要 SOC 2/GDPR 认证？
6. 资金安全：是否支持按量后付？预充值是否有退款保障？
7. 故障转移：平台是否有多上游渠道自动故障转移机制？
8. 技术支持：是否有完善的文档、SDK、社区支持？

（注：部分内容可能由 AI 辅助生成，数据来源以各平台官网最新公开信息为准。）