如果你过去两年在国内挑过 LLM API，你一定遇见过它们：跑得很快的小平台，转售海外模型，价格漂亮，支持微信、支付宝或者 USDT，注册几分钟就能开始调。做 demo、做副业项目，体验毫无摩擦。
问题在把它放进生产负载的那一刻冒出来。账号无预警被封。月中账单结构突然变了。请求失败找不到人。模型输出质量下滑，但你没法确认刚才答你的到底是不是你付费的那个模型。响应回来之后，你的 prompt 去了哪里，你也说不清。
这篇文章不是要点名任何一家平台。我想描述的是国内"非官方 LLM API 中转"这一层的共性结构，以及一家承担生产负载的网关，必须在哪些维度上做出不同的选择。语气克制是故意的——把维度并排摆出来之后，结论应该自己浮现。
如果你已经读过 Router One vs OpenRouter China，本文是一个补充。那篇比较的是两家合规网关之间的差异。这一篇比较的是任何一家合规网关，与下面那一层"非官方中转平台"之间的差距。
什么是"非官方中转 API 平台"
模式相似到可以一般化描述。你通常会看到以下若干组合：
- 一个上游 provider 账号池，平台在中间轮转使用，账号往往由代理充值方维护
- 转售他人 API key，加价藏在按 token 单价或包月套餐里
- 没有明确法律主体——收款落到个人微信、支付宝个人账号或者 USDT 钱包
- 没有公开的服务条款、退款政策、故障公告页、SLA
- 控制台只能看到余额和用量计数，没有每请求 trace，没有任何关于每次调用实际去了哪里的拆分
这些做法单独看不一定违法，而且这类平台确实帮了大量个人开发者解决"先调通"的问题。问题在于你开始依赖它之后会发生什么。下面五个维度，每一个都对应着你迟早要在生产环境里见到的一种事故。
维度 1：主体与合规边界
生产服务需要知道自己在付钱给谁，以及出问题时谁要为此负责。
生产级 LLM 网关的标配是：注册公司主体、公开 ToS、公开退款政策（/refund）、公开安全边界声明（/security）、公开可引用事实页（/trust/facts）。支付走公开可查的通道——卡支付和受支持的稳定币充值流程——结账前展示条款和费用边界。你有一个明确的对手方。
非官方中转一般做不到这一点。收款落到个人钱包，条款要么没有要么只在注册时一闪而过，没有任何可以开票、申诉、升级的公开主体。对一个跑爱好项目的独立开发者来说，这点风险是可接受的；对一个迟早要被财务或法务问到"我们付钱给谁，对方对我们有什么义务"的团队来说，不可接受。
维度 2：SLA 与故障补偿
生产负载不只是要求服务"大部分时间能用"，还要求服务"不能用的时候有人负责"。
Router One 在 /sla 公开可用性测算方式，在 /status 提供公开故障入口，并在 fallback 发生时保留请求级 trace。年度企业合同可包含未达合约可用性目标时的 service credit 补偿。测算方式你可以质疑，签进合同的条款也可以拿来追责。
非官方中转这一层一般没有这套东西。没有可用率承诺，没有故障公告页，上游账号池被封导致整体下线一天的时候也没有补偿。经济模型决定了它没法做：一家靠"共享账号套利"维持利润的平台，账号被封的时候没办法给客户退钱。
这是实际跑下来最贵的一种"惊喜"。平台账面便宜，直到某天凌晨三点你的 agent 不响应了，你能拿到的解释是群里一句"上游被封了，明天处理"。
维度 3：每请求可观测（trace）
你之所以要在 LLM 调用前面放一个网关，最初的理由就是想知道每次调用到底发生了什么。
Router One 在每请求 trace 中包含：实际命中的模型、路由决策、token 数、延迟、成本——方法论写在 /routing-methodology。你可以回答"这条请求为什么花了这么多钱"、"fallback 链跑到了哪一步"、"p99 延迟上升来自单个上游还是所有上游"。你可以按项目、按 API key、按 agent 做成本归因。
非官方中转一般只给你一个余额和一个聚合用量。响应是黑盒。如果模型输出质量下滑，你无从判断平台是不是悄悄把路由降级到了便宜的变体。如果成本飙升，你无从判断是哪一类调用拉起来的。你付费的对象是仪表盘上的一个数字，不是一份可审计的记录。
跑 demo 时这点无所谓。需要向上司或者客户解释的任何场景里，这件事很重要。
维度 4：计费透明度
合规网关按公开的 token 费率计费。费率写在模型市场 /models 上。FX 和通道费在结账时显示，不藏。背后的方法论写在 /pricing-methodology。你可以逐项和上游 provider 自己公布的费率做比对。
非官方中转的常见结构不一样：包月套餐 + 不透明的上游费率倍率 + 只在付款时才出现的汇率 + 取消比订阅难得多的自动续费。这些谈不上欺诈，只是"转售商最大化利润"自然演化出来的定价结构。但它让你没法做容量规划——你没法在一个每月都在变形的数字上建模你的单位经济。
维度 5：数据留存与安全边界
最后一个维度，是团队最晚才意识到，也最容易后悔的。
Router One 的立场写在 /security 和 /data-retention：我们不留存 prompt/completion 正文，只留计费和运营所必须的元数据，留存窗口公开。如果你需要向安全团队论证"我们的 prompt 没躺在别人的数据库里"，你有文档可以指。
非官方中转一般没有任何留存声明。数据在平台基础设施上中转一圈再到上游，对它落在哪里、待多久、有没有备份，你没有任何合同约束。个人探索 OK，凡是涉及客户数据、代码仓库、内部文档的场景，就不是一句"我信任运营方"能托付的事了。
并排对比
| 维度 | 生产级网关 | 典型非官方中转 |
|---|---|---|
| 法律主体 | 注册公司、公开 ToS、退款政策 | 个人钱包收款，无公开主体 |
| SLA | 公开测算方式、公开故障入口、企业合同可含 credit 补偿 | 无 |
| 每请求可观测 | trace 含模型、路由、token、延迟、成本 | 聚合余额和用量计数 |
| 计费结构 | 公开 token 费率、checkout 显示 FX、方法论可查 | 包月套餐、不透明倍率、隐藏 FX |
| 数据留存 | 公开留存窗口，不留 prompt/completion 正文 | 未公开 |
| 故障时的追责通道 | 故障页、客服通道、企业合同 credit 补偿 | 群消息，无补偿 |
| 上游来源 | 走 provider 官方 API channel | 账号池、转售 key |
一份采购方 checklist
把任何一家中转平台放进生产负载之前，请运营方书面回答以下八个问题。一家合规网关一分钟之内能答完八条。如果你目前的提供方多数题答不上，关于"它适不适合跑你的生产流量"，你已经有答案了。
- 你的法律主体是什么？注册在哪里？营业执照号能否提供？
- 服务条款、退款政策、可接受使用政策的链接？
- 公开的可用率目标是多少？未达成时的补偿机制是什么？
- 你调用上游模型走的是 provider 官方 API channel，还是消费者账号或第三方账号池？
- 单条请求能否看到实际命中的模型、token 数、延迟、成本？
- 是否留存 prompt 或 completion 正文？留多久？存在哪里？
- 按 token 费率是否公开？FX 和通道费是否在 checkout 显示？
- 是否公开故障公告页与历史可用率？
什么时候用中转层 OK，什么时候不 OK
本文不是说所有便宜中转平台都不能用。周末项目、demo、学习、一次性实验场景里，非官方中转往往是最短的"能跑通"路径，缺乏结构本身不构成真实成本。
主张是更窄的：当一个负载开始对你的用户、团队、财务部门或客户数据负责的那一刻，缺主体、缺 SLA、缺 trace、缺公开费率、缺留存声明这五件事就不再抽象了。每一项对应着一种你迟早要解释的具体事故。
如果你准备把网关放在真实流量前面，参考 Router One vs OpenRouter China 看合规网关层的差异，或者打开产品对比页做快速并排比较，或者前往 router.one 注册开始使用。