中转站渠道类型：官转、号池、逆向、Kiro 分别是什么

在中转站后台，同一个 claude-sonnet 往往有好几个分组，价格能差五六倍。差价不是折扣，是来源不同。这篇讲清六类来源各是什么、成本从哪来、有什么绕不开的限制，以及其中哪些痕迹是你能在响应里直接看到的。

最后更新 2026-08-15 · 阅读约 9 分钟

为什么要先搞懂分组

大多数关于「哪家中转站好」的争论，其实是在比较不同分组。同一家站，官转分组和逆向分组可能是两种完全不同的服务，只是共用一个域名和一个余额。你说「这家很稳」，别人说「这家垃圾」，你们可能都对。

更麻烦的一种情况是：你买的分组标着一种来源，实际跑出来是另一种。 这就是「资源声明与行为不一致」——渠道标注 CCMax，请求却表现出 Kiro 的特征。要能判断这件事，你得先知道这些词各指什么。

六类来源

类型	它实际是什么	成本从哪来	固有限制
官转官方直连、直连克劳德	中转站持有厂商的正式 API key，收到请求转发到官方端点	批量采购折扣、企业额度转售	基本没有，行为就是官方文档写的样子。最贵
一方云 AWS / GCP / Azure	走云厂商托管的同款模型（如 Bedrock、Vertex）	云厂商的定价与承诺用量折扣	模型版本上线时间可能滞后于官方；部分 API 特性支持进度不同
号池 Max / Pro / Plus 切片	买一批个人订阅账号，把订阅内含的额度按 token 拆开转卖	订阅制包月价 ÷ 实际用量，压榨订阅的性价比	订阅本身有官方的用量上限和重置窗口，多个用户共用后再叠一层；部分只允许官方客户端访问
逆向 / 2api	逆向网页版或 App 的通信协议，把聊天界面包装成 API 对外提供	几乎为零，成本是账号和绕过防护的工程量	官方一改防护就可能集体失效；能力覆盖不完整；账号有被封风险
IDE 额度反代 Kiro、AWS-Q、各类编程 IDE	逆向 AI 编程工具的内部接口，把它订阅里含的模型调用转卖	薅工具方的订阅补贴	受工具方的系统提示、上下文策略和能力裁剪影响；ToS 风险高
试用额度拼装	批量注册新账号，用赠送额度撑服务	拉新补贴	额度用完即失效，站点寿命通常很短

一个粗略的排序：官转和一方云是「买来的」，号池和试用额度是「拆开卖的」，逆向和 IDE 反代是「拿来的」。 价格大致按这个顺序递减，可预期性也按这个顺序递减。

这些词没有官方定义 「官转」「号池」「逆向」「CCMax」都是社区用语，不同群、不同时期用法会漂移，商家也会把它们当营销词用。上表描述的是这些词通常指代的技术来源，不是行业标准。更简短的对照见中转站黑话词典。

哪些痕迹是你真能看到的

这一节是这篇文章的重点。上面那张表讲的是「它是什么」，属于你无法直接验证的部分—— 中转站不会告诉你真话，你也进不去它的后台。你能做的，是看协议层藏不住的东西。

下表每一条都标了证据等级：官方文档指厂商文档里写明的行为； 可直接观察指你发一个请求就能看到的事实；社区观察指多方反馈但没有权威来源，只能当线索。

可观察的东西	怎么看	它能说明什么	证据等级
`request-id` 响应头	打印响应头，看有没有 `req_` 开头的值	官方每个响应都带这个头。中转站没透传，说明它重新组装了响应——不等于有问题，但你失去了一条追溯线索	官方文档
AWS 的双 request id	看有没有 `x-amzn-requestid`	官方文档说明走 AWS 的响应会同时带 AWS 和 Anthropic 两个 request id。透传时这是一条链路线索	官方文档
错误体的 `type`	触发一次错误，看 `error.type` 的取值	官方的 429 是 `rate_limit_error`、529 是 `overloaded_error`。取值对不上或缺失，说明错误是中转站自己造的	官方文档
缓存字段是否生效	带 `cache_control` 发两次，看第二次的 `cache_read_input_tokens`	字段被丢弃时缓存永远不命中。逆向和部分反代链路常不支持这一层	可直接观察
关掉 thinking 后是否仍出现	按文档关闭思考，看响应里还有没有 thinking 内容	请求配置和实际响应对不上，说明中间有人改写了你的请求	可直接观察
`stop_reason` 的取值分布	跑一批固定请求，统计取值	出现文档里没有的取值，或者分布明显异常，说明响应经过了重新拼装	可直接观察
限流的节奏	记录 429 出现的时间点，看是否呈周期性	号池受订阅的重置窗口约束，限流往往有节奏；官转的限流更贴近你自己的用量曲线	社区观察
系统提示残留	问它当前的系统提示或身份设定	IDE 反代链路可能带着工具方的系统提示。这条最不可靠——模型对自身的陈述本来就不可信	社区观察

反过来推不成立 上面每一条都是「如果渠道是 X，可能观察到 Y」。反过来说「观察到 Y 所以渠道是 X」是错的：官转的中转站也可能因为自己的实现不透传 request-id，缓存不命中也可能只是你的 prompt 没到最小缓存长度。 这些是线索，不是判定。能确定的只有一件事：请求配置和实际响应对不上，中间一定有人动过手。

低价分组真的更容易出问题吗

这个问题第一次有了同行评议之外的量化答案。2026 年 5 月的一篇论文（KBF）做了一个 同一平台内部的对比：在 7 个同时提供低价分组和升级分组的平台上，用知识边界指纹分别审计两个分组。

模型	低价分组被标记	升级分组被标记
Claude Opus 4.6	7 个平台里 5 个	7 个平台里 1 个
Claude Sonnet 4.6	7 个平台里 2 个	7 个平台里 1 个

平均不匹配率：低价分组约 16%，升级分组约 5%。论文作者指出，这种同一平台内部的对比 很难用提示词格式或部署噪声解释掉——如果是环境差异，两个分组应该一起偏。

这不是「低价分组一定有问题」的证明，样本也只有 7 个平台。但它至少说明：分组标签和实际行为之间确实存在系统性的差距，而且差距和价格档位相关。这批研究的完整方法、数字和它们各自的局限，见学术界怎么审计中转站掉包模型。

你自己能跑的三个对比

不需要复杂工具。买了同一家站的两个分组之后，用同一段固定 prompt 分别打，对比这三样：

看响应头。

curl -sS -D - -o /dev/null "$BASE_URL/v1/messages" \
  -H "x-api-key: $KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-4-5","max_tokens":16,
       "messages":[{"role":"user","content":"hi"}]}'

两个分组的响应头集合是否一致？有没有 request-id？

看缓存是否真的命中。同一段长 prompt 带 cache_control 连发两次，比较第二次的 cache_read_input_tokens。一个分组命中、另一个永远是 0，说明两条链路不一样。
看错误长什么样。故意发一个坏请求（比如模型名写错），比较两个分组返回的 error.type 和状态码。官方的取值是固定的，自己造的错误往往对不上。

这三个对比不告诉你分组「是」什么，但能告诉你两个分组是不是同一条链路。如果站方声称只是「同一资源的不同限速档」，而三项对比都不一样，那声明和行为就对不上了。

为什么这些对比要重复跑

分组是后台配置，改一次几秒钟。今天验证过的分组，明天可能换了上游。更麻烦的是， 换上游不需要全量换——把一部分请求分流到便宜的后端，你抽检的那一次很可能正好是老实服务的那一部分。

这不是猜测，是可以算的：按 IRIS 那篇论文测出来的规模，掺假比例越低，需要的样本越多， 5% 左右的掺假在他们的实验里需要几十次探测才有把握区分。一次手工验证，本来就不在这个量级上。

分组换了上游，你需要的是历史，不是又一次抽检

LinkyMonitor 对每个分组持续发起已知请求，响应头、缓存行为、Token 用量与错误特征一旦偏离历史基线，变化过程会留在记录里。

申请试用