低价 AI 模型 API 能不能用？给创始人的 Token 中转站尽调门槛

一项针对「token 中转站」市场的调查在本周末重新引发关注。调查记录了这样一类服务：它们汇集不同来源的凭证，再以极低折扣转售知名 AI 模型的访问能力。报道涉及的来源既包括可能存在的正规批发安排，也包括消费订阅、免费试用、暴露的客服机器人、共享会话、被盗凭证和支付滥用。它足以证明这类市场确实存在，但不能证明每一个低价网关都使用相同手段，更不能直接判定所有经销商都未经授权。

这个边界对 AI app builder 很重要。一个兼容接口完全可能返回质量不错的模型回答，同时把最关键的问题藏起来：上游账户属于谁、模型是否真是所声称的版本、prompt 保存在哪里、数据受哪份合同约束，以及原厂吊销凭证后产品会发生什么。一次便宜且成功的 completion，不等于供应链已经核验。

非技术创始人和小型产品团队真正要判断的，不是「这个 API 能不能调用」，而是：供应商能否充分证明其法律身份、转售权限、凭证路径、数据路径、运行控制和退出方案，从而配得上产品要交给它的信息与客户承诺？

本文把当前热点转成一套创始人可执行的决策门槛，包括清晰术语、九项供应商收据、阻断规则、60 分钟核验、一个虚构的文档助手案例、决策矩阵、事故处置步骤，以及网关或经销商可能适用的边界。它不是法律意见，不提供涉嫌违规的供应商名单，也没有对原始调查中的任何服务进行 YBuild 实测审计。

Token 中转站调查究竟证明了什么

Vectoral 的原始调查描述了一个由比价网站、返佣计划、网关软件、凭证池和超低价模型访问组成的生态。作者称，其追踪到的流量最高的十个中转站，月访问量合计约 360 万。文章的主要证据来自 V2EX 上的运营者讨论，另有中转站目录、产品页面、截图和作者自己的追踪数据。

调查列出了低价容量可能来自的多条路径：正式购买的 API 资源、消费订阅凭证、免费试用、计量薄弱的客服或编码产品、遭入侵的账户，以及支付欺诈。这些类别在法律、安全和可靠性上的含义完全不同。开源网关软件本身也不能证明滥用；团队可以合法地用网关统一 API、在自己拥有的账户之间路由、设置预算，或在已获授权的供应商之间做故障切换。

Simon Willison 在 7 月 26 日的评论让这项调查进入更广泛的讨论。他强调的是应用层风险：公开的 AI 功能可能被接入转售链条，使一个暴露的凭证或没有硬上限的功能，迅速变成高额账单。

阅读这项调查时，必须保留三条证据边界：

• Vectoral 报告的是市场和观察到的模式，不能据此认定每个中转站所售 token 的来源。
• 低价是风险信号，不是盗窃、欺诈或违约的证明。
• 回答「看起来像某个模型」，不能证明供应商真的调用了该模型、使用了授权账户，或执行了所承诺的数据控制。

因此，正确的产品动作既不是「所有网关都是骗局」，也不是「prompt 测试通过就可以上线」，而是根据数据和业务影响，留下一个可审计的接入决定。

先定义供应商，再比较价格

团队经常把所有 OpenAI-compatible 接口都叫作「经销商」。这个模糊称呼会掩盖最关键的差异。

授权经销商是能够拿出有效协议或官方计划证明，说明自己有权按照约定转售服务的具名企业。经销商并不天然可疑。OpenAI 的服务协议在定义订单时，明确承认客户可能通过 reseller 购买。即使如此，买方仍要确认由谁开票、适用哪份条款，以及支持和数据责任由谁承担。 网关（gateway）是接收请求并将其转发给一个或多个上游模型的软件或服务。网关可能使用客户自己拥有的账户，也可能使用经授权的自有账户，还可能使用来源不明的凭证池。「兼容 OpenAI 接口」描述的是 API 形状，不是商业授权。

本文所说的中转站（relay），是指通过并非直接签发给最终买方的凭证或账户提供模型访问的中间层。它可能获得授权，也可能未经授权，或者尚未核验。这个词描述的是路径，不是法律结论。

消费会话代理会把面向个人应用或订阅的访问能力转换成类似 API 的服务。它可能依赖浏览器 cookie、登录会话、自动化脚本或共享账户，而不是原厂签发的企业 API 凭证。 凭证来源链（credential provenance）是从你的请求回溯到上游授权的可检查路径，包括凭证类型、账户所有者、原厂或授权渠道、权限范围、运行环境、谁能轮换和吊销，以及允许这样使用的证据。 数据路径是能够接收或保存 prompt、文件、metadata、response、日志和衍生数据的全部实体与系统。它和模型名称不是一回事。

这些定义可以避免一种常见采购错误：把原厂 API 与中转站报价当成完全相同的商品，而忽略双方在身份、合同、隐私、可观测性、支持和业务连续性上的差异。

为什么接口可用，依赖仍可能不合格

一次 smoke test 只能回答很窄的问题：接口是否接受了请求，并返回了看似合理的结果。它无法回答以下六个生产问题。

身份。 收款并承担责任的注册实体是谁？一个域名、Telegram 账号或付款钱包，不等于具有法律主体、通知地址和签约人的交易对手。 授权。 什么证据允许该实体交付所声称的上游服务？「我们有很多账户」不是授权链。以 OpenAI 当前协议为例，客户不得买卖或转让 API key，也不得绕过 rate limit、限制或保护措施。这不能代替对其他厂商和具体安排的判断，却足以说明：凭证来源会直接改变风险。 认证方式。 原厂 API key、受限 OAuth 授权、共享浏览器 cookie 与消费账户登录会话并不等价。IETF 的 OAuth 2.0 安全最佳实践 RFC 9700重点处理 token 重放防护、最小权限、客户端认证和更安全的授权流程。如果供应商要求你的个人 session cookie 或不受限凭证，它接管的可能不只是一次模型推理权限。 数据处理。 Prompt 可能经过中转站的边缘服务、应用日志、消息队列、滥用检测、可观测系统、上游账户和客服工具。你与原厂之间的 DPA 不会自动覆盖一个未具名中间商。OpenAI 的数据处理附录会为适用的客户关系说明双方角色、子处理方、安全措施、删除与事故处理。如果你只和中转站签约，就必须从中转站取得相应答案，并确认哪些上游条款真正适用。 连续性。 如果容量来自账户池，一次上游吊销就可能在没有正常下线通知的情况下移除大量资源。中转站也可能为了维持「在线」而静默切换模型、地区或厂商。页面没有宕机，不代表质量、安全、延迟和数据位置没有变化。 事故响应。 供应商能否指出哪些请求经过了受影响凭证，停止该路径，删除留存数据，保全日志，并在约定时间内通知你？如果做不到，团队在出事后也无法向客户说明发生了什么。

问题不在于中间商必然不可靠，而在于每增加一个中间环节，就多出一组必须用证据回答的主张。

使用这份九项模型接口接入收据

不要把销售演示当成审查记录。每接入一个原厂、经销商、网关或中转站，都应在生产数据进入之前完成一份收据。

NIST 在 2026 年 7 月发布的网络安全供应链尽调快速指南，把供应商审查组织为来源、韧性、基础网络安全实践、供应链层级，以及所有权或控制等维度。三人创业团队不需要复制政府采购部门，但可以沿用同一逻辑：识别供应商，画清其背后的参与方，核验关键控制，并预先设计失败方案。

OWASP 的大模型供应链指南也指出，条款和数据政策含糊、来源薄弱、第三方平台与过时组件，都可能带来安全、隐私、许可证和可用性问题。中转站又在这些模型供应链风险之上，增加了一层账户与身份风险。

把收据放在产品的模型配置旁边，写明负责人和复审日期。营销页面会变，合同、上游合作计划、host 和凭证路径也会变。「去年审过」不能证明今天的路径。

试用前先应用五条阻断规则

有些证据缺口可以在受限 pilot 中继续核验，另一些则应在真实 prompt 发出之前直接停止。

1. 阻断个人或共享会话凭证

不要把创始人的登录 cookie、消费会话 token、浏览器 profile 或共享密码交给中转站。也不要接受供应商在缺少书面授权时替你这么做。会话凭证可能暴露历史记录和模型推理之外的账户功能；它一旦被吊销，所有依赖流量也会同时中断。

2. 阻断无法证明的模型转售权限

供应商不一定要公开有商业敏感性的进货价，但必须提供可信证据，说明自己可以交付所售服务。证据可以是原厂合作伙伴目录、具名经销计划、有违约救济的合同陈述，或按云市场条款完成的采购。把多个厂商 logo 放在一起不算证据。

3. 数据路径不完整时，阻断客户数据和敏感数据

在处理方、留存、地区、客服访问、删除和事故响应尚不清楚之前，只使用合成输入。脱敏可以降低暴露，却无法修复一份不存在的合同。如果产品涉及健康、金融、就业、儿童、法律、认证信息或商业机密，应增加专门的隐私和安全审查。

4. 阻断不受限凭证与无限费用

Anthropic 的 API key 指南要求不要共享 key，并建议按用途隔离、监控、使用加密 secret 存储和定期轮换。Google Cloud 的 API key 最佳实践建议限制服务和应用、隔离凭证、监控用量、删除闲置 key 并轮换。如果网关使用你自己的 key，就应给它最小权限、独立项目、硬费用上限和快速吊销路径。在供应商与 secret 处理设计通过审查之前，不要把 key 粘贴到网页表单。

5. 阻断无法核验的静默替换

多模型网关可以合理地在不同模型之间路由，但产品必须知道这种切换何时发生。要求日志记录实际 route 或可验证的 route 类型，明确允许哪些替代，并把未披露的模型切换视为事故。JSON 字段兼容，不能保证安全行为、tool use、context 上限、延迟与输出质量相同。

这些是采购门槛，不是指控。供应商可以通过补充充分证据或更改设计来消除 blocker。

用合成数据完成一次 60 分钟核验

文档门槛通过后，再使用合成数据核验运行主张。目标不是逆向供应商，而是确认正常使用中能否取得所需证据。

第 0–10 分钟：冻结报价。 保存法律实体、定价页、模型名称、endpoint host、条款版本、隐私说明、支持联系人和所声称的留存周期，并记录日期。确认最终出现在发票和银行卡账单上的公司名称。 第 10–20 分钟：检查凭证流程。 确认你拿到的是项目级 key、通过 OAuth 连接账户、使用自有原厂 key，还是经过供应商账户池。记录谁能轮换和吊销每个凭证。若流程要求个人 cookie、共享账户、导出浏览器 profile、关闭证书验证或安装来源不明的软件，立即停止。 第 20–30 分钟：检查身份与路由。 解析文档指定的 endpoint，确认 HTTPS 使用预期域名，然后发送无害的合成请求。保存 request ID、response header、返回的 model ID、可用时的地区信号、延迟、用量单位和错误格式。不要凭写作风格认定模型身份。 第 30–40 分钟：检查限制与可见性。 设置很小的费用或用量上限。确认 dashboard 或导出中能看到使用记录，不同环境可以使用不同凭证，并验证被吊销的测试 key 确实失效。不要压测服务或绕过控制；只使用文档允许的范围和极小预算。 第 40–50 分钟：检查数据权利。 发送一个唯一的合成标记，再按文档申请删除。供应商未必能立即给出自助结果，但必须说明删除哪些系统中的数据、需要多久，以及会返回什么证明。 第 50–60 分钟：检查支持与退出。 提一个具体事故问题：「如果某个上游凭证在处理我们的请求后被吊销，你们如何定位受影响 request ID、通知我们并确认删除？」随后用非敏感测试执行一次 fallback 配置。

最终只能做出四类记录：进入试用、等待证据、拒绝或仅限原厂直连。「prompt 可以工作」不算决策。

具体场景：便宜 90% 的合同文档助手

设想一家虚构的两人创业公司，正在为小企业开发供应商合同摘要助手，产品仍处于 private beta。一家模型中转站提供团队首选模型，价格只有原厂 API 的 10%，并承诺五分钟完成 OpenAI-compatible 接入。

创始人先用公开合同样本试跑。摘要质量不错，延迟可接受，JSON schema 也正常解析。如果审查到此为止，这家供应商就会通过。

接入收据改变了结论。发票将由个人收款账户开出，而不是网站上写的公司；卖方拒绝说明任何上游经销计划；开发和生产共用一个 bearer key；隐私页面只说「通常不保存 prompt」，却没有留存周期、子处理方列表、地区、删除路径和事故联系人；model 字段则原样回显客户端传入的名称。客服还建议，如果共享 key 不稳定，可以改用浏览器 cookie。

这些事实不能证明中转站偷了凭证，也不能证明它虚报了每一次请求。它们已经足以说明，创业团队无法核验授权、凭证来源链、模型身份、数据处理和恢复能力。客户合同不能进入这条路径。

团队记录的决定是：合成数据试用不通过；仅限原厂直连。随后，它通过缩小证据包、使用 cache、按 workload 路由和限制输出长度来降低原厂成本。如果以后有授权市场以清晰合同和数据路径提供同一模型，团队可以把它当作新的报价重新评估。

现在把条件换一下：卖方出现在模型厂商的合作伙伴目录中；合同写明所有商业实体；凭证按项目隔离；prompt 受 DPA 覆盖；route 可以从日志核验；删除流程清楚；团队也能随时切回直连。这时，折扣可能来自承诺用量、区域分销、云 credits 或打包基础设施。接口形态仍是网关，但证据不同，结果也可以不同。

按数据敏感度与业务影响做决定

不是每个实验都需要企业级采购流程，也不是每个 endpoint 都值得生产信任。选择与后果相匹配的最小决策。

只有满足所在行的要求后，价格才进入比较。不可接受路径上的 90% 折扣不是节省，而是一笔尚未定价的责任。原厂同样可能无法满足你的安全或可靠性要求，所以「直接购买」也不能取代评估。

FTC 的小企业供应商安全指南给出了通用原则：把数据用途、共享、留存、删除、安全措施及控制更新写进合同；不要只听口头承诺，要实际核验；限制供应商访问；发生 breach 后要能切断权限。即使没有直接适用的 AI 专门法规，这些步骤仍然成立。

批准之后，继续监控这条依赖

批准是一种有版本的状态，不是永久标签。团队要持续观察路径是否发生变化。

需要追踪的字段包括：签约实体、endpoint 域名、证书、文档中的上游 route、model ID、价格、错误格式、延迟、用量计费、数据条款、子处理方列表和状态页。价格突然大幅下降、host 变化、发票主体不一致、模型行为无法解释，或要求把项目 key 换成会话凭证，都应触发复审。

设置三类产品告警：

• 经济告警： 观察到的上游用量与供应商账单明显不一致，或承诺的硬上限没有停止请求。
• 身份告警： 模型、厂商、endpoint、凭证类型或开票实体没有按约定提前通知就发生变化。
• 数据告警： 留存、地区、训练使用、子处理方、删除或事故条款发生变化。

保留一条不含敏感信息的 canary 请求，其输出应具有稳定、可机器检查的属性。它无法证明模型身份，却能暴露 route 变化、schema 漂移、tool 行为缺失和延迟回归。还必须把它与合同和运行证据配合使用。

高风险供应商至少每季度复审一次，发生任何实质变更后也要复审。原型阶段则应在「合成数据转内部数据」和「正式面向客户」之前分别复审。记录「谁在什么日期依据哪些证据批准了什么」，不要只写「工程看过」。

当中转站路径变得可疑时如何响应

如果你得知供应商可能使用未经授权、遭入侵或被错误陈述的凭证，不要先在公开渠道争论责任。先隔离产品并保全事实。

1. 停止新的敏感流量。 切到已经核验的 fallback、降级为非 AI 流程，或暂停功能。不要为了调查而继续发送 prompt。
2. 吊销你能控制的凭证。 轮换网关 key、原厂 key、OAuth grant、webhook 和集成可触及的 secret。中转站凭证与自有上游凭证是不同的处置对象。
3. 保全证据。 保存合同、发票、条款版本、request ID、时间、endpoint host、model 字段、route header、通知和客服消息。不要保留超出事故所需的客户内容。
4. 划定暴露范围。 确认哪些用户、tenant、prompt、文件、secret 和 action 经过了该路径，以及对应时间窗。把确认事实与可能性分开记录。
5. 联系供应商与相关上游厂商。 要求提供凭证来源链、隔离结果、受影响请求、留存、删除和通知，并使用官方 security 或 abuse 渠道。
6. 评估通知义务。 如果可能涉及个人、机密、受监管或客户控制的数据，请合格的法律与安全专业人士参与。
7. 验证恢复。 换一个新 key 还不够。确认旧路径已经失效、受影响数据得到处理、fallback 正常，并更新接入收据。

不要私自探测不属于你的账户，不要为了测试而购买可疑凭证，也不要尝试识别其他客户。产品团队的职责是控制自己的依赖，并通过授权渠道配合调查。

哪些情况下网关或经销商仍然值得使用

本文的结论不是「永远不要使用中间商」。治理良好的网关可以减少集成工作、集中预算和观测、执行统一策略、支持区域路由，并为小团队提供可信 fallback。授权经销商也可能提供本地结算、支持、采购流程和原厂自助账户没有的承诺用量价格。

在以下条件成立时，可以考虑使用中间层：

• 法律身份和商业授权已有记录；
• 凭证与数据路径可以检查；
• 合同覆盖产品的数据与预期用途；
• 模型替换规则明确且有边界；
• 提供项目级 key、限制、日志、删除和事故处理；
• 直连或替代路径已经测试；
• 把支持、基础设施与用量承诺计入后，折扣仍然合理。

如果唯一优势是依赖保密、共享消费访问、无限制凭证、绕过地区限制或无法核验的模型标签，就不应接入。如果产品根本不需要多模型路由或集中控制，也不必额外增加网关；每一层依赖都会带来复审与事故成本。

这套尽调门槛无法证明供应商永远不会失败。它能做的是把授权、数据路径、控制和退出承诺写清楚、测出来，并让团队在客户数据替不确定性买单之前说「不」。

创始人的 48 小时检查清单

第 1 小时： 冻结报价；确认法律实体和开票实体；把供应商归为原厂、授权经销商、网关、中转站或尚未核验；阻断个人会话、共享 cookie、转让 key、不明 host 和客户数据。 第 4 小时前： 索取九项收据字段；把拟议凭证路径与上游条款对照；画出处理方、地区、留存、训练使用、删除和事故联系人；确定哪些缺项是 blocker。 第 8 小时前： 完成 60 分钟合成核验；创建项目级 key 和极小额度；保存 request ID 和实际 route 证据；吊销测试凭证；执行 fallback。 第 24 小时前： 完成数据与业务影响矩阵；需要时取得专业审查；指定供应商负责人；依据证据记录进入试用、等待、拒绝或仅限原厂直连。 第 48 小时前： 如果批准，只向已命名的数据类别和流量上限开放；启用经济、身份和数据告警；安排下次复审；把收据与退出步骤存放在模型配置旁。

无论折扣多大，都应保留一条规则：绝不能用 API 兼容性替代供应商身份、凭证来源链、可知的数据路径与测试过的退出方案。

参考资料

1. Vectoral，An Inside Look at the Relay Market Powering Token Resellers and Fraud。
2. Simon Willison，An Inside Look at the Relay Market Powering Token Resellers and Fraud。
3. OpenAI，Services Agreement。
4. OpenAI，Data Processing Addendum。
5. Anthropic，API Key Best Practices。
6. Google Cloud，Best Practices for Managing API Keys。
7. IETF，RFC 9700: Best Current Practice for OAuth 2.0 Security。
8. NIST，Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide。
9. OWASP GenAI Security Project，LLM03:2025 Supply Chain。
10. 美国联邦贸易委员会，Cybersecurity for Small Business: Vendor Security。