API 中转站的合规边界：上游条款与监管要求分别管什么

技术群里隔几天就会冒出一个同款问题：我手上有个平台的 key，额度自己用不完，卖给几个同事分摊成本，行不行？问得再大一点就是：我把中转能力做成一个小站对外收费，能不能做？

这两个问题的答案不在技术层。它落在三份文件里：你跟上游签的服务条款、模型厂商通过上游条款下传给你的条款、以及你向公众提供服务时对应的国内监管规定。这篇文章只做一件事——把公开可以核到的条款原文和法规名称摆出来，说清每一层各自管什么。结论不在这里，判断也不在这里；判断要你带着这些原文去找律师。

如果你还不清楚中转站在这条产业链上是个什么位置、钱和请求分别怎么流，先看 API 中转站是什么 那篇再回来读这篇会顺一些。

一、先把三层拆开，别混着讨论

群里这类争论之所以常常吵不出结果，是因为把三件不同性质的事塞进了一个问题里：

第一层是合同关系。 你注册上游平台账号时接受的服务条款，是你和平台之间的约定。它管的是”平台允许你怎么用它的服务”，违反的后果首先是合同层面的（封号、停服、余额处置）。

第二层是模型厂商的条款。 你调的模型往往不是上游平台自己训的。平台通过条款把模型厂商的限制下传给你，所以你受约束的条款可能不止你签过的那一份。

第三层是行政义务。 国内向公众提供生成式人工智能服务要遵守的规定，跟你和谁签合同没关系。哪怕上游条款里一个字都没禁止，这一层该做的事照样要做。

这三层不能互相替代，也不能互相抵扣。上游允许不等于监管这边没事，监管义务做全了也不等于没违约。下面分层说。

二、上游条款原文：OpenRouter 的第 7 节与第 5.2 节

OpenRouter 的服务条款（openrouter.ai/terms）里有两处跟转售直接相关，英文原文照抄如下。

第 7 节禁止行为清单里的第 4 项：

access the Site or Service for purposes of reselling API access to Models or otherwise developing a competing service

值得留意的是这一项的写法：reselling API access to Models 和 otherwise developing a competing service 被并列写在同一项里面。有人会自辩”我只是把额度转给别人用，并没有做一个竞品”——这句自辩成不成立，取决于这一项在合同解释上怎么划边界，那是律师的活，不是技术群能定的事。你能做的是把这句原文原样复制下来，连同你实际的业务描述一起拿去问。

第 5.2 节的作用是把上游厂商的限制往下传：它要求用户及其客户遵守 applicable Model Terms。这句话的含义是，你不能只读 OpenRouter 的条款就以为读完了。你在这个平台上调了哪几家的模型，那几家各自的 Model Terms 说了什么，是另外要去核的东西。这一层最容易被漏掉，因为它不在你点”我同意”的那个页面上。

三、国内平台的条款：硅基流动的用户协议与充值协议

国内平台这边，硅基流动的用户协议（docs.siliconflow.cn）把授权的边界写得相当直白：授权是”非排他性的、不可转让的”，仅限个人使用或所代表实体的内部业务目的；未经事先书面同意不得购买、出售或转让 API 密钥；并且不得复制、出租、出售、贷款、转让、许可或意图转授、转售、分发本服务的任何部分。

这里有两个细节值得单独指出来。

一个是”购买”这个词也在禁止之列。大量讨论只盯着卖方的风险，但原文里买和卖是并排写的。如果你是从别人手里拿到 key 的那一方，这条同样落在你头上——这意味着你该去确认的不只是”对方有没有权利卖”，还有”我有没有资格买”。

另一个是”仅限个人使用或所代表实体的内部业务目的”里的”内部”。公司把模型能力包进一个对外售卖的产品，这算不算内部业务目的？这句话在你的场景里怎么落地，是典型的需要拿原文去问的问题，不是按字面直觉就能定的。

充值协议里还有一条经常被忽略的：用户如委托第三方代充值，若平台被第三方告知该充值未经其同意，平台有权立即封禁账户，封禁期间暂停 API 请求等全部服务。这条解释了为什么”找人代充省事”不是一个纯粹的便利问题——处置后果是写在协议里的，不是平台临时起意。

四、监管这一层：先知道要求存在

国内向公众提供生成式人工智能服务，需要符合《生成式人工智能服务管理暂行办法》，其中包括对内容做安全过滤的要求。这篇不展开具体怎么做，只说这个要求存在，以及它跟前面两层是并行的。

有一个判断你不要靠直觉下：你在这条链上处于什么位置、算不算办法里所说的”提供者”。这取决于你怎么对外呈现、服务对象是谁、由谁承担面向用户的责任，要按办法本身的定义去核，而不是按”我只是个转发层”这种自我描述。想清楚这件事的顺序应该是：先确认自己的角色定性，再看对应角色要承担哪些义务。

涉及境外模型时，还会叠上数据流向那一层的问题，这部分在 海外模型接入的合规边界 里另有梳理。

五、公开存在的两条路，各自把义务放在谁头上

讨论到这一步通常会有人问：那有没有把这件事做得不别扭的路径？有两条是公开存在的，各有各的代价。

一条是走平台生态的入驻流程。 阿里云百炼的服务协议里写明，平台既展示自研模型 API，也展示来自云市场、由第三方推理服务供应商提供的”三方模型 API 服务”。也就是说，“第三方对外提供模型 API 服务”这件事本身在平台生态里是被承认的，区别在于走没走入驻这道流程。这条路的代价是流程本身——资质、审核、分成、结算，都要按平台的规则来。

另一条是自部署开源模型。 自部署不受上游平台用户协议的约束，因为你不再是谁的 API 客户，只受模型自身开源许可的约束。但它不是把义务消掉了，而是换了一组：模型许可怎么用、内容安全谁来做、算法与模型备案以及安全评估这些事，全部转到你自己头上，而且转过来的这组必须有人真的接。

顺带纠正一个常见的算错：自建网关（one-api / new-api 那一类）解决的是管理问题，不是供给问题。你还是得有上游 key，上游条款照样约束你，所以”我自建了所以我不算转售”这个推理是断掉的。这两件事的边界在 自建网关与托管服务怎么选 里讲得更细。

第三种是转售平台 API。 它的特点是叠加：上游服务条款的约束在，国内监管义务也在，两边都不减。

六、已经发生过的事，以及法律分析的一致判断

有调查报道与法律分析记录过：已有经营者因非法转卖 API 被刑事拘留；也有不少站点在关停时无力退还用户的剩余余额。这些是报道与分析的结论，不是我们亲历，具体商家报道里没有点名，我们也不点名。资金与数据侧更完整的风险记录在 API 中转站的风险清单 那篇。

法律视角上有一个判断是相当一致的：凡产品卖点仍然落在”国内直连""无需海外卡""无需官方账号""绕过 KYC""低价 Claude/OpenAI”这些点上的，合规空间极窄。同一批分析还指出一件事——合规化不是补一份隐私政策就完事，而是要把业务本质从”规避访问限制的转售通道”换成”有授权、有资质、有透明模型来源的 AI 服务”。这两句话我原样转述，不加解释。

还有一个可观察的市场信号：有实力的平台现在也不再自称中转站，而是叫”token 聚合平台”，并公开说明其上游供应商是 AWS / GCP / Azure 这类官方云厂商。这是别人的选择，不构成我们对谁的评价，但它至少说明市场里做过法务功课的那一部分人在往哪个方向挪。

七、你该去确认的清单

这一节给的是问题，不是答案。分两组，看你是哪一方。

如果你是使用方： 我用的这家站点，上游到底是谁，它说得出来吗？我现在这个用法，在上游平台的条款里落在哪一条上——尤其是”个人使用或所代表实体内部业务目的”这句，我有没有越过去？我的请求内容会流经几方？余额和停服的条款是怎么写的，写没写清？把模型来源和条款透明度当成尽调项来查的具体动作，在 六条可自己验的判据 里列成了清单。

如果你打算做经营方： 上游条款的原文允不允许我现在设想的这个商业模式（这句要拿原文去问律师，别自己判）？我调的几家模型，各自的 Model Terms 说了什么？我的服务对象构不构成”公众”，我这个角色怎么定性？内容安全、备案与安全评估这些义务，具体由谁来接、接得住吗？我自己的用户协议里，余额、停服、模型变更分别怎么写？

八、按同一套标准，力达云该被问什么

既然上面全是让读者去查别人，那这个站自己也得摊开。这些是 /api-terms/ 里的原文：

网关是一个独立运营的第三方模型接入服务——接收你按 OpenAI 或 Anthropic 格式发出的请求，转发给上游模型服务商，再把结果返回给你。我们与 DeepSeek 及其他任何模型厂商没有官方合作、代理或授权关系，也不是它们的关联方。模型的生成质量、可用性与响应速度最终取决于上游服务，我们不对模型输出本身作出保证。我们不会把你的请求内容用于训练模型，也不会出售或与无关第三方共享。可用模型的增减、上下线时间、计费规则与价格的调整、频率限制的变化，均以站内公告与控制台的模型列表为准。

限制也一并说：一期只接 DeepSeek，模型广度上没什么可比的；身份上是独立第三方，前面那句”无官方授权关系”就是这个意思。写这一段不是为了说我们更合规——这个判断不该由我们自己下。是为了让上面那两组问题能原样用在我们身上，条款原文在 /api-terms/，你自己去核。

九、这篇不能替代法律意见

最后这句必须说明白：这篇文章不构成法律意见，也替代不了法律意见。

上面每一条都是公开可查的条款原文或法规名称，它们的作用是帮你把问题问对——知道该翻哪一份文件、该确认哪一句话。但它们不构成对你具体业务的判断。条款怎么解释、你的业务本质怎么定性，取决于你实际怎么做、卖给谁、数据往哪儿流、对外怎么呈现，这些细节我看不到，也不该替你猜。

还有一种情况是这篇文章对你基本没用：你就是一个人拿一个 key 自己写代码，不转给任何人，不对外提供服务。那上面大半内容跟你无关，你真正只需要确认一句话——“仅限个人使用或所代表实体的内部业务目的”这句，你有没有越过去。

但如果你打算把它做成收钱的产品，别省那一步。把上游条款的原文、你自己的用户协议、以及你实际的请求流向图一起拿给律师看一遍。这一步省下来的钱，跟事后的代价比起来不是一个量级。