做大模型应用,"中转站"几乎绕不开:不用折腾海外支付、不用逐个申请账号、一个 key 调多家模型、还能开票。但它同时是整个技术栈里信息最不对称的一环——你看到的是一个兼容 OpenAI 的地址,看不到的是它背后接了什么、有没有被降级、明天还在不在。
一、先分清三种"中转站"
市面上叫"中转"的服务,底层差别极大:
| 类型 | 上游来源 | 典型价格 | 主要风险 |
|---|---|---|---|
| 官方转发型 | 官方 API、云厂商渠道 | 官方价 +10%~60% | 价格不便宜,但供给稳定 |
| 逆向 / 号池型 | 网页版逆向、共享账号池 | 官方价 5%~30% | 随时封禁、模型降级、上下文串号 |
| 混合型 | 官方为主、逆向往兜底 | 随负载浮动 | 高峰期限流、故障时悄悄降级 |
判断方法很简单:价格低到不合常理时,通常不是"渠道优势",而是"成本转移"——把稳定性、合规性和数据安全转移给了你。
二、五个必须问清的问题
对方答不上来,或者只肯口头保证的,直接排除。
- 上游是官方 API,还是逆向 / 共享账号?要求书面回答,最好写进报价单。这不是技术细节,是风险定价。
- 模型版本能不能指定?"GPT-4 级别""Claude 同款效果"这类说法不算数。要能明确到具体型号与版本号。
- 计费口径是什么?输入和输出是否分开计价?缓存命中是否降价?失败请求、流式中断、重试是否计费?按 token 还是按"倍率"?
- 限流与 SLA 是多少?RPM、TPM、并发上限、可用性承诺、故障赔偿方式。没有 SLA 的服务,等于把可用性风险全部转给你。
- 请求数据留存吗?留存多久、存在哪里、是否用于训练、能否签署数据处理协议。涉及境外模型时,还要评估数据出境。
三、10 分钟技术验收
不用等合同,先跑一轮测试。以下六项按顺序做,基本能筛掉八成不合格的。
Step 1 模型指纹测试
准备 3 个固定 prompt:
- 知识边界:问一个该模型训练截止之后的事件,看它是否"知道"。
- 格式遵循:要求输出严格 JSON、固定字段、固定长度。
- 精确推理:一道需要多步计算的应用题。
同一个 prompt 在官方渠道和中转各跑一次,比对风格、长度、拒答边界。风格突变、能力明显下降,基本可以判定被替换或降级。
Step 2 usage 真实性
请求里加上:
"stream_options": { "include_usage": true }
检查返回的 prompt_tokens 是否与你用分词器估算的一致。误差超过 20% 就要警惕。
常见的 usage 造假有三种:返回固定值、按字符数粗略折算、把缓存命中按全价计。单价便宜但 token 虚高,真实成本反而更贵。
Step 3 长上下文测试
塞一段 3 万字的材料,提问其中第 2 万字处的细节。
被截断、答非所问、或者直接报错,说明上下文窗口被砍过——这对做知识库、合同审阅、长文档分析的业务是致命的。
Step 4 能力项逐项验证
不要只看"能不能对话",要逐项确认:
- 流式输出是否完整(结尾是否有
[DONE]) - JSON mode 是否真的约束格式
- function calling / tool use 是否可用
- 多模态(图片输入)是否真实支持
max_tokens是否被静默限制
Step 5 错误码与延迟
- 触发限流时,是否返回规范的
429并带Retry-After - 5xx 报错是否暴露上游信息(暴露了说明是简单二次封装)
- 连续 50 次请求,记录 p50 / p95 延迟
Step 6 并发压测
按你预估峰值的 1.5 倍压 5 分钟,观察限流阈值、错误率和恢复速度。很多中转站在低并发下一切正常,一上量就开始超时。
| 验收项 | 通过标准 |
|---|---|
| 模型指纹 | 与官方渠道无明显差异 |
| usage 偏差 | 小于 20% |
| 长上下文 | 3 万字材料可准确检索 |
| 能力项 | 流式 / JSON / 工具调用全部可用 |
| 错误码 | 符合 OpenAI 规范,不泄露上游 |
| p95 延迟 | 在你的业务可接受范围内 |
| 并发 | 1.5 倍峰值下错误率低于 1% |
四、"便宜"的四种来源
看到明显低于市场价的报价,先想想便宜从哪来:
- 逆向渠道——绕过官方计费,成本最低、封禁风险最高,随时可能一夜归零。
- 共享号池——多人共用一个账号,限流、封号、甚至上下文串号。
- 模型降级——用便宜模型冒充贵模型,价格看着低,效果打对折。
- 虚标 token——单价低但用量虚高,你以为省了 40%,实际多付了 20%。
正确比价方式:拿你自己的真实流量跑一周,算 单价 × 实际 token 消耗 = 真实月成本。只比单价,一定会被"低价高量"收割。
五、合同与合规:别省这一步
- 主体与发票:能否签正式合同、开增值税发票、对公转账。个人收款的中转,出问题基本无法追责。
- SLA 与赔偿:可用性承诺、故障响应时限、赔偿方式(代金券还是退款)。
- 余额与退款:有效期、是否可退、超额是否自动扣费。
- 数据合规:数据是否出境、是否留存、能否删除;面向公众提供生成式 AI 服务时,是否履行了相应备案义务。
- 内容安全:生成内容的责任边界,最好在合同里写清楚。
六、架构上,永远给自己留一条退路
再靠谱的供应商也可能出问题。真正有效的风控不是"选对一家",而是"随时能换"。
- 只依赖 OpenAI 兼容协议,不要用某家中转的私有字段。
- base_url 和 key 放配置中心,不硬编码在业务代码里。
- 加一层统一网关:重试、超时、熔断、降级、双通道切换。
- 主备双通道:主通道故障时自动切备用,哪怕备用贵一点。
保留切换能力,本身就是最强的议价能力。
七、验收清单
采购前逐项打勾:
- 书面确认上游来源(官方 / 逆向 / 混合)
- 明确模型型号与版本,不接受"级别"描述
- 拿到完整计费公式与一份真实账单样例
- 确认失败请求、重试、流式中断的计费规则
- 确认 RPM / TPM / 并发上限
- 完成模型指纹与 usage 真实性测试
- 完成长上下文与能力项测试
- 完成 1.5 倍峰值并发压测
- 合同写明 SLA、赔偿与退款条款
- 确认发票类型与开票周期
- 确认数据留存策略与出境情况
- 代码层已实现 base_url 可配置与双通道切换
结语
中转站不是不能用,而是不能闭眼用。
它本质上是把"接入复杂度"换成"供应链风险"。风险本身不可怕,可怕的是不知道风险在哪。把上面这份清单走一遍,你至少能在出问题之前知道问题会出在哪。