API 中转站、官方直连、自建网关：三条路怎么选

一个四个人的团队要同时接两三家模型，讨论了一下午，最后有人拍板：「我们自己搭一套 new-api，自主可控，也不用担心中转站跑路和合规的事。」这句话里有一半是对的，另一半是把两个完全不同的问题混成了一个。搭网关确实能让你不再受某个第三方控制台的摆布，但它一个字都没回答「模型的额度从哪儿来、这个额度的授权链条站不站得住」。这篇就把这三条路的边界划开，再逐个维度过一遍它们各自的隐性成本。

一、三条路不是同一层的三个选项

先把词对齐，否则后面每一句都会串味。

官方直连，是你的服务直接把请求发给模型厂商自己的接口，中间没有第三方转发方。你拿的是厂商发给你的凭证，账单是厂商开的，出了问题只有一个对话对象。

API 中转站，是一个第三方站点持有上游额度，你把请求发给它，它转发给上游再把结果回传给你。你手里的凭证是它发的，不是模型厂商发的。它替你解决了三件事：国内的可达性、海外支付方式的门槛、以及多家模型用一把凭证。

自建网关，是 one-api / new-api 那一类你自己部署的路由与计量层。它把多个上游收敛成一个统一入口，帮你做分流、配额、日志、成本归集。

把这三个放在一起看，会发现它们回答的不是同一个问题：官方直连回答的是供给，中转站回答的是供给加管理，自建网关只回答管理。绝大多数选型讨论跑偏，都是拿自建网关去回答供给问题。关于自建与托管在运维层面的取舍，站内另有一篇自建聚合与托管服务的对比专门讲，这里只谈它在选型语义上的位置。

二、自建网关解决的是管理问题，不是供给问题

这是本文最想让你带走的一句话，值得拆开讲。

你把 new-api 部署好了，界面打开，准备接上游——这时候你需要填一把上游凭证。这把凭证从哪儿来？只有三个来源：

一是你自己在模型厂商那里注册账号申请的。那么你做的事情，本质上是给官方直连加了一层自己的管理面。供给还是官方的，授权还是你自己的，网关只是把路由和账目收到了自己手里。这是最干净的一种，但它没有解决可达性和支付门槛——你的服务器在境内，出境访问的问题还在那儿，只是从应用里挪到了网关里。

二是你从某个中转站买来的凭证。那么你把中转站的全部不确定性原封不动继承了过来，还额外给自己加了一台要运维的机器。上游是否偷换模型、余额能不能退、明天还在不在，这些和你自建与否毫无关系。

三是来路不明的号或者别人的订阅账号。有调查报道记录过，一个按月付费的 Claude 订阅账号被拆卖给数十个使用者共用——这种供给方式天然不稳定，任何一个共用者的行为都会连带到你，而你对此没有任何控制力。

所以「我自建了网关」并不构成合规论证。真正约束你的是上游的服务条款，它不看你请求从哪台机器发出。OpenRouter 的服务条款第 7 节在禁止行为里明确写了 access the Site or Service for purposes of reselling API access to Models or otherwise developing a competing service，第 5.2 节还要求用户及其客户遵守适用的 Model Terms，也就是把上游模型厂商的限制继续往下传。硅基流动的用户协议写得同样直白：授权是非排他性的、不可转让的，仅限个人使用或所代表实体的内部业务目的，未经事先书面同意不得购买、出售或转让 API 密钥，也不得出租、出售、转让、许可、转售或分发本服务的任何部分；它的充值协议里另有一条，用户若委托第三方代充值，平台一旦被第三方告知该充值未经其同意，有权立即封禁账户。这些条款的约束对象是账号持有者的行为，跟你有没有自己的网关是两件不相干的事。

有一个很朴素的自检办法：把「我们自建了网关」这句话从你写给客户或法务的说明里删掉，剩下的句子还站得住吗？如果站不住，说明你原本想论证的是「我有授权」，而自建没有给你授权。自建改变的是数据经过谁、计量在谁手里、切换成本由谁控制；它不改变授权链条，也不改变监管对你这个服务提供者的要求。

唯一真正脱离上游平台用户协议的做法是自部署开源模型——那时候约束你的只有模型自身的开源许可。但这条路把模型许可的核对、内容安全过滤、以及算法与模型备案、安全评估这些义务全部转到了你自己头上，是换了一套负担而不是卸下负担。海外模型这一侧的合规要点，站内的海外模型合规注意事项里另有展开。

三、七个维度逐条过

可达性。 国产厂商的官方接口在境内本来就可达，这个维度对它不成立问题。中转站的可达性是它最实在的卖点之一。自建网关不解决可达性，前面已经说过，它只是把问题挪了个位置。

支付与发票。 这是很多团队真正卡住的地方，也是最容易被忽略的一条。官方直连走的是正规采购流程，有合同、有发票、有可追溯的付款主体；而合同与发票对需要过财务和审计的团队本来就是硬要求，不是加分项。中转站这一侧，第三方报告采集到的情况是：充值门槛普遍设得极低，但只有一小部分站点公开披露自己的支付方式。门槛低对个人开发者是便利，对需要走账的团队是障碍——收款主体是谁、能不能开票、合同跟谁签，这几个问题问不清楚，后面的技术评估就没有意义。具体的金额与费率变动太快，这里不复述，你自己去对方页面上核当时的口径。

模型广度。 中转站的广度是真的。第三方报告的采集结果里，GPT 与 Claude 在这些站点上几乎是标配，Gemini 的覆盖要低一档，报告把是否支持 Gemini 当成一条技术能力的分水岭。但广度的另一面是身份不确定：有测评论文对 28 个中转站的端点做过测试，结论是其中 45.83% 的端点存在模型身份不匹配，也就是付的是高价模型的钱、实际响应可能来自更便宜的模型。请注意这是论文的测评结论，不是我们自己跑出来的数。官方直连只有一家的模型，广度最窄，但你至少确定自己调的是什么。自建网关的广度完全等于你自己拿到的上游数量，网关本身不带来任何模型。

稳定性的责任归属。 这一条比可用率数字重要。官方直连出问题，责任方唯一，有状态页、有工单、有可引用的口径。中转站多了一层，而这一层的供给方式你看不见，它上游可能是号池拆分，也可能是另一家中转站。自建网关的责任在你自己：磁盘写满、进程被杀、证书过期，半夜没人管就是没人管。选型时该问的不是「谁更稳」，而是「出事那天，我要向谁要一个解释，以及我能不能在半小时内绕过它」。

数据流经几方。 官方直连是一方。中转站至少两方，而且有调查报道记录过，部分超低价站点的隐蔽利润来源正是倒卖 prompt 与输出用于微调训练。自建网关这里有个反直觉的点：它不减少数据流经的方数，反而多出一个你自己的日志库，请求与响应的明文很可能就落在你那台机器上，之后的泄露面归你负责。上了日志就要同时想好保留期限、访问控制和脱敏，不然是把风险从别人家搬回自己家。

合规负担。 在国内向公众提供生成式人工智能服务，需要符合《生成式人工智能服务管理暂行办法》，内容安全过滤这项义务是存在的——这里只说这个要求存在，具体怎么落地不在本文范围。转售平台 API 是把上游服务条款的约束和国内监管义务叠在一起。合规供给路径公开存在的例子也有：阿里云百炼平台除了自研模型 API，也展示来自云市场、由第三方推理服务供应商提供的三方模型 API 服务，云市场服务商入驻就是该生态里第三方供给的合规路径。反过来，已有经营者因非法转卖 API 被刑事拘留，法律分析的一致判断是：凡产品卖点仍落在「国内直连」「无需海外卡」「无需官方账号」「低价 Claude」这些点上的，合规空间极窄。本文只陈述条款原文与法规名称，不构成法律意见，真要商业化请把条款交给律师看。

切换成本。 这条决定了前面所有判断错了之后的代价。把 base_url、凭证、模型 id 三样收成配置项而不是写进代码，是成本最低的一次性投入，站内base_url 的接入与排错一篇里有具体写法。另外一个实践是小额多次充值而不是一次充大额——它不能防止任何风险发生，只能限制单次损失的上限。自建网关在这一条上确实有优势：换上游的动作被收到网关里，应用侧零改动，new-api 的部署与使用可以作为起点；而 OpenRouter 这类聚合服务则是把切换成本压到改一个模型名，代价是多一层条款要读。

四、什么情况选哪条

下面这张表不排名次，也不存在「推荐」那一栏，只给场景与倾向的对应，以及你该提前确认的事。

你的情况	倾向的路	必须提前确认的事
只用一家模型，公司能走正规采购	官方直连	采购主体、发票、并发配额怎么申请扩容
只用一家模型，但采购流程走不通	官方直连仍优先，先想办法解决付款	是否真的无解，还是只是没人去推
要同时评测多家模型，短期、小量	中转站可以作为评测通道	模型身份能否自测、余额处置条款、收款主体
多个业务线共用额度、要按线归集成本	自建网关 + 自有上游凭证	谁保管凭证、日志保留多久、账单口径对不对得上
对外提供生成式 AI 服务	授权链条必须先理清，再谈技术路线	上游条款是否允许你这种用法、监管义务谁承担
数据不允许经过第三方节点	官方直连或自部署开源模型	自部署后模型许可、内容安全、备案义务由你承担

真实项目里这三条路多半是混着用的：主力模型走官方直连，前面架一层自建网关做统一入口和配额，少数暂时拿不到官方渠道的模型走第三方并明确接受它的不确定性。这种组合没问题，但要清楚每一层带来的额外成本都是实的——网关的运维与凭证保管、第三方的尽调时间、以及三方计量口径不一致时对账单的那种慢性折磨。

按本文的维度，力达云的网关属于「第三方转发」那一层：它是一个独立运营的第三方模型接入服务，接收按 OpenAI 或 Anthropic 格式发出的请求，转发给上游模型服务商再返回结果；它与 DeepSeek 及其他任何模型厂商没有官方合作、代理或授权关系，也不是它们的关联方；模型的生成质量、可用性与响应速度最终取决于上游服务；现阶段一期只接 DeepSeek，模型的增减、计费规则与频率限制的变化以站内公告和控制台的模型列表为准。也就是说，它能帮你省掉的是接入与账目上的麻烦，不能替你解决授权与合规的问题——这一点和本文对整个品类的判断是同一套标准。上游关系的自我披露写在网关服务条款里，建议你自己点进去核一遍，用同样的问题去问其他任何一家。

五、把话说直白

如果你只用一家模型，而且公司能正规采购，官方直连几乎总是最优的一条——中转站和自建网关都是在解决你可能并不存在的问题。多花的钱是有的，但你换回来的是唯一责任方、可追溯的账单、以及不需要向任何人解释授权链条。

另外两条路轮得到，只在几个具体条件成立的时候：你确实需要多家模型的横向对照，或者采购这条路在你公司短期内真的走不通，或者你有多个业务线要按线切分额度和成本。这三个条件里一个都不成立，却已经在写网关的部署脚本，那大概率是在为一个还不存在的规模做准备。

还有一句不太受欢迎的话：这三条路的选择不能替你承担判断。中转站这一侧的风险是公开有记录的，自建这一侧的义务是明文写在上游条款里的，官方直连的代价是流程上得多花时间、也得有人去推。哪个代价你付得起，只有你自己能算。