Appearance
API 中转站怎么选？2026 年价格、模型、稳定性与隐私避坑指南
第一次接触 API 中转站，最容易被两类信息绕晕：一类是 0.2 倍、0.5 倍 之类的价格标签，另一类是“官方线路”“高速池”“Plus 池”“Max 池”“满血线路”等名称。
这些名称本身不等于上游来源，也不代表长期质量。真正需要确认的是模型身份、真实成本、高峰期稳定性、协议兼容性、隐私边界和售后路径。
指南信息
- 适用场景： 准备使用 API 中转站，希望判断真实成本、模型一致性、稳定性和数据风险
- 阅读时间： 约 15～20 分钟
- 更新日期： 2026 年 7 月 18 日
披露说明
本文发布在天衍汇官方文档站，由天衍汇维护。文中提供的是通用筛选框架，可用于评估包括天衍汇在内的 API 服务；不提供固定推荐名单，也不因一次测试通过而对某个站点作长期背书。
中转站市场变化很快，同一站点也可能调整上游或路由。更稳妥的方法是：先排除信息不透明的候选，再核算成本，最后用少量额度和真实工具复测。
60 秒结论：先看信息透明度，最后才看倍率
选择中转站时，建议按以下顺序判断：
- 信任边界： 运营主体、价格页、余额规则、隐私说明和售后入口是否公开。
- 线路构成： 上游来源、转接方式和协议兼容是否分别说明。
- 模型一致性： 协议、能力、用量和官方基线是否存在明显异常。
- 稳定性： 近 24 小时和 7 天的可用率、样本量、TTFT、TPS 与错误类型如何。
- 真实成本： 输入、输出、缓存写入和缓存读取分别如何计费。
- 小额复测： 首次只使用最低可测试额度或可承受损失的少量额度，不长期留存大额余额。
一分钟检查表
| 检查项 | 通过标准 |
|---|---|
| 价格口径 | 能查到基准价来源、到账比例、分组倍率及缓存价格。 |
| 线路说明 | 上游来源、转接方式、协议兼容分开描述。 |
| 余额规则 | 最低充值、有效期、赠送额度与退款规则清楚。 |
| 运行数据 | 有近 24 小时或 7 天数据，并展示样本量和错误类型。 |
| 用量记录 | 请求级 usage、缓存读写和余额变化可复查。 |
| 隐私说明 | 说明日志内容、保存期限、访问权限和上游去向。 |
| 售后路径 | 有工单、客服、订单页、邮件或公开反馈入口。 |
| 首次验证 | 已用真实客户端完成短请求、长输出、工具调用和连续请求测试。 |
核心原则
任何一项缺失都不等于站点一定有问题，但信息越少，用户承担的不确定性越高。
调研数据：用户最关注什么
以下数据来自前期需求调研的多选题统计，比例之和可能超过 100%。结果只反映这批样本，不用于推断整个市场。
| 用户看重什么 | 占比 |
|---|---|
| 真模型，不掺假 | 89.3% |
| 价格低、倍率低 | 73.5% |
| 稳定可用，不经常报错 | 63.8% |
| 用户担心什么 | 占比 |
|---|---|
| 假模型、掺假或能力降级 | 88.3% |
| 站点停止服务 | 73.5% |
| 扣量或余额消耗异常 | 49.0% |
| 使用一段时间后失效 | 32.1% |
| 隐私泄露 | 25.0% |
数据边界
正式引用这组数据时，还应同时提供招募渠道、调研起止时间、有效样本数、题目原文和匿名统计口径，方便读者判断数据适用范围。
API 中转站到底是什么
官方 API 可以理解为“原厂入口”：开发者直接向 OpenAI、Anthropic、Google 或云服务商申请凭据，并按其公开规则计费。
API 中转站位于用户与上游之间。它通常把多个模型或上游包装成统一的 Base URL 和 API Key，帮助用户接入 Claude Code、Codex、Cursor、Cline、OpenCode、SDK 或自建脚本。
它可能带来接入便利、统一账单和备用路由，也会增加一层信任边界：
- 中转层可以看到哪些请求数据？
- 模型名称和请求参数是否被改写？
- 多个上游是否会动态切换？
- 用量统计和实际扣费如何对应？
- 上游异常时由谁处理？
因此，选择中转站不是简单判断“通不通”，而是判断它是否把关键事实讲清楚，并允许用户复查。
第一关：判断基本可信度
优先查看以下公开信息：
| 信息 | 为什么重要 |
|---|---|
| 运营信息和长期入口 | 方便确认服务主体，并在域名或群组变化时找到公告。 |
| 公开价格页 | 用户可以复查模型、分组和倍率，而不是依赖私聊截图。 |
| 到账比例和最低充值 | 便于计算每一支付单位能获得多少站内额度。 |
| 模型分组说明 | 避免被“全站最低倍率”掩盖不同线路的差异。 |
| 余额有效期 | 余额过期会改变长期使用成本。 |
| 隐私和日志规则 | 说明请求、文件、usage 和错误日志分别如何处理。 |
| 售后与退款规则 | 让用户在调用、扣费或充值异常时有明确预期。 |
| 状态页和历史记录 | 可用率、错误、延迟和维护记录比口头承诺更有参考价值。 |
如果一个站点只强调“全网最低”“稳定满血”“不限量”，却没有公开价格口径、线路说明、余额期限和售后入口，应把它列为高不确定性候选，只做最小规模测试。
第二关：把线路来源、转接方式和兼容性分开看
中转站最常见的概念错误，是把“官方 API”“Max 池”“Claude Code 接入”“OpenAI 兼容”放进同一类。它们实际属于三个不同维度。
1. 上游来源：能力从哪里来
| 上游来源 | 需要确认的重点 |
|---|---|
| 模型厂商 API | 价格基准、模型版本、区域、限流及功能是否与厂商文档一致。 |
| 云服务商 | 具体平台、区域、模型版本、协议差异和功能支持。 |
| 订阅产品或账号权益 | 订阅产品不等同于 API 产品；重点关注共享方式、容量、条款变化和长期稳定性。 |
| 第三方产品能力 | 可能附带系统提示、功能限制或独立的用量规则。 |
| 来源未披露 | 用户缺少复查路径，应提高测试频率并降低余额暴露。 |
2. 转接方式：请求如何到达上游
| 转接方式 | 需要确认的重点 |
|---|---|
| API Key 转发 | 参数是否完整透传，是否保留原始 usage、错误和流式事件。 |
| 账号池 | 池容量、并发、切换策略、共享风险和高峰期拥堵。 |
| 网页或非公开接口包装 | 协议兼容、版本变化、工具调用、流式输出和统计准确性。 |
| 二级分销 | 是否说明真实上游，以及上游变化如何通知用户。 |
| 混合路由 | 是否公开路由规则，用户能否固定分组或查看实际命中线路。 |
3. 客户端与协议兼容：用户如何接入
Claude Code 接入、Codex 接入、OpenAI 兼容协议、Anthropic 兼容协议 等标签，只说明接入方式或兼容目标，不直接证明上游来源。
购买前应分别确认：
- 支持哪些 endpoint 和请求字段？
- 工具调用、结构化输出、图片、PDF、长上下文是否完整？
- SSE 流式事件和 usage 字段是否与目标客户端兼容？
- 客户端更新后，站点是否有兼容记录和回滚方案？
第三关：算清真实成本，不只看一个倍率
真实成本至少由五部分组成：
text
站内额度消耗
= 输入 tokens ÷ 1,000,000 × 输入基准价 × 输入倍率
+ 输出 tokens ÷ 1,000,000 × 输出基准价 × 输出倍率
+ 缓存写入 tokens ÷ 1,000,000 × 缓存写入价 × 写入倍率
+ 缓存读取 tokens ÷ 1,000,000 × 缓存读取价 × 读取倍率
实际支付成本
= 站内额度消耗 ×（支付金额 ÷ 到账额度）这里的“站内额度”只是计费单位，不代表现金、存款或可提现资产。
一个简化算例
假设某模型公开标价为：
- 输入：
3 USD / 100 万 tokens - 输出：
15 USD / 100 万 tokens - 某分组的输入和输出倍率均为
0.5x - 每 1 个支付单位到账 1.2 个站内额度
- 本次请求使用 10 万输入 tokens 和 2 万输出 tokens，暂不计缓存
则：
text
基准额度消耗 = 0.1 × 3 + 0.02 × 15 = 0.6
应用分组倍率 = 0.6 × 0.5 = 0.3
实际支付成本 = 0.3 ÷ 1.2 = 0.25 个支付单位这个例子说明：倍率、到账比例、输入输出占比都会影响最终成本。只比较 0.2x 和 0.3x 没有足够意义。
缓存价格必须单独看
| 计费项 | 含义 |
|---|---|
| 输入 tokens | 系统提示、历史对话、文件文本、工具定义等输入内容。 |
| 输出 tokens | 模型生成的回复；部分模型的推理用量也可能计入。 |
| 缓存写入 | 首次把可复用前缀写入缓存。 |
| 缓存读取 | 后续请求命中相同前缀并复用缓存。 |
| 缓存命中率 | 可复用内容中真正以缓存读取口径计费的比例。 |
缓存规则会随模型代际变化。截至本文更新日：
- OpenAI 的 Prompt Caching 对符合条件的请求自动生效；GPT-5.6 系列及后续模型家族的缓存写入按未缓存输入价格的
1.25x计费，更早的模型规则不同。应以目标模型价格页和 usage 字段为准。 - Anthropic 的公开文档将缓存拆为基础输入、5 分钟写入、1 小时写入、缓存命中与输出；公开倍率分别为
1.25x、2x和0.1x，仍应以目标模型当期价格页为准。
用于 Claude Code、Codex、Cursor、Cline、OpenCode 等开发工具时，长系统提示、工具定义和项目上下文可能反复发送。此时应查看：
- 目标模型和分组是否支持缓存；
- 写入与读取分别按什么价格和倍率扣费；
- usage 是否展示缓存写入和读取；
- 近 24 小时或 7 天的命中率是多少；
- 数据来自站方报告、公开监控还是独立实测。
第四关：测试稳定性，而不是只发一句“你好”
能成功一次只说明当时可访问，不代表适合长期使用。
| 指标 | 它说明什么 | 怎么看 |
|---|---|---|
| 可用率 | 一段时间内请求成功的比例。 | 同时看近 24 小时和 7 天。 |
| 样本量 | 可用率背后有多少次检测。 | 样本过少时，不对高百分比作强结论。 |
| TTFT | 从请求发出到首个 token 返回的时间。 | 影响流式交互的等待感。 |
| TPS | 稳定输出阶段每秒生成的 token 数。 | 影响长回答和代码生成速度。 |
| 错误类型 | 429、超时、空响应、流式中断等。 | 用于区分限流、拥堵、协议和上游异常。 |
| 限流规则 | RPM、TPM、并发数和 Key 级限制。 | 决定是否适合自动化或多任务。 |
最小复测方案
- 创建独立测试 Key，设置较低额度或消费上限。
- 发送一个短请求，确认基本连通、模型名、usage 和余额变化。
- 发送一个长输出请求，观察 TTFT、TPS 和流式中断。
- 用真实客户端测试工具调用、结构化输出或文件能力。
- 连续发送 10 至 20 次低成本请求，记录成功率、错误和限流。
- 在不同时段重复一轮，避免只测到低峰期。
- 将站内用量与本地估算对比，检查输入、输出和缓存是否大致一致。
测试时保持提示、模型、参数和客户端版本一致，否则不同批次数据缺少可比性。
第五关：判断模型一致性，不要只问“你是谁”
直接询问模型身份属于弱证据，因为系统提示或中转层可以影响回答。更有效的检查应分层进行：
| 检测层 | 看什么 | 可以发现什么 |
|---|---|---|
| 协议字段 | ID、model、usage、错误格式和 SSE 事件。 | 粗糙套壳、字段改写或异源协议。 |
| 能力探针 | 工具调用、结构化输出、图片、PDF、长上下文。 | 参数未透传、能力缺失或兼容不完整。 |
| Token 审计 | 输入输出、缓存读写、流式与非流式 usage。 | 隐藏提示、异常扣量或统计不一致。 |
| 固定任务对比 | 同一套任务下的结果、延迟和工具行为。 | 能力降级或路由变化的疑点。 |
| 官方基线 | 同一请求对比官方 API 或云服务商。 | 字段、能力、用量和错误形状差异。 |
| 历史复测 | 跨时段重复同一套检测。 | 混池、降级和路由切换。 |
Claude 的 extended thinking 响应可能包含 thinking、redacted_thinking 或 signature 等字段。signature 用于保持 thinking block 的连续性，是有价值的一致性信号，但单个字段不应被当作完整身份认证。
检测结论建议使用以下表述：
- 一致性较高： 多层信号与目标模型基线接近。
- 存在异常： 字段、能力、用量或行为出现可重复差异。
- 证据不足： 样本量太少，或目标能力本身不适用于当前模型。
任何一次检测都只代表当次模型、线路、请求和时间。对混合路由尤其需要长期复测。
第六关：明确隐私边界
中转站多了一层可以处理请求内容的服务。HTTPS 保护传输过程，但中转服务本身仍可能读取请求正文，因此应关注：
- 是否公开隐私政策和日志规则；
- 是否记录请求正文、文件、响应或仅记录 usage 与错误；
- 日志保存多久，哪些角色可以访问；
- 请求会被发送到哪些上游和区域；
- 是否支持删除记录或关闭正文日志；
- 是否要求提交其他平台的账号密码、Cookie 或长期凭据。
实用做法包括：
- 为每个站点创建独立 Key，并设置较低额度和并发限制；
- 不在请求中放入私钥、Cookie、登录凭据、个人证件或未公开商业数据；
- 对源代码、客户资料和内部文档先脱敏，再按组织的数据要求处理；
- 定期轮换 Key，出现异常调用后立即撤销；
- 保存请求 ID 和 usage，不在售后截图中暴露完整 Key 与敏感正文。
第七关：售后、余额和证据链
遇到调用失败、余额异常、充值未到账、模型不符或站点失联时，建议按以下顺序处理：
- 保存证据： 订单号、支付记录、价格页快照、调用时间、请求 ID、错误响应和余额变化。
- 联系原站： 优先使用工单、客服、订单页、邮件或公开售后群。
- 记录处理过程： 保存回复时间、处理结论和补偿或退款记录。
- 使用支付平台争议入口： 按订单页面提供的正式流程提交材料。
- 撤销凭据： 站点失联或出现异常访问时，立即停用相关 Key 和客户端配置。
公开反馈应尽量附上可核对证据，同时隐藏 Key、订单隐私和请求正文。一次故障不直接代表长期质量，但持续故障、拒绝说明和删除公开记录是更强的负面信号。
正向信号与警惕信号
相对正向的信号
| 信号 | 为什么有价值 |
|---|---|
| 商品和模型描述清楚 | 用户知道购买的是哪种上游、转接和兼容能力。 |
| 价格口径可复查 | 基准价、到账比例、倍率和缓存价格都有记录。 |
| 运行数据带样本量 | 可用率不脱离检测次数和时间范围。 |
| 价格与线路有历史记录 | 用户可以追踪购买前后的规则变化。 |
| 售后入口明确 | 出现问题时有固定处理路径。 |
| 承诺措辞克制 | 不使用“永远稳定”“绝对满血”等不可验证表述。 |
| 上游类型有证据等级 | 区分站方声明、公开资料和独立实测。 |
| 用户反馈得到回应 | 问题、解释和处理结果能够被追踪。 |
需要警惕的信号
| 信号 | 为什么要谨慎 |
|---|---|
| 只宣传最低倍率 | 低倍率可能基于自定义基准价或不同上游。 |
| 把客户端标签当作上游证明 | “支持某客户端”并不等于来自对应厂商 API。 |
| 不公开分组和缓存价 | 难以计算真实成本或复查扣费。 |
| 不展示样本量 | 高可用率可能只来自极少请求。 |
| 不说余额期限和退款规则 | 长期使用成本与问题处理缺少预期。 |
| 极低倍率配合较高最低充值 | 用户为获得低价承担了更高余额风险。 |
| 价格和线路频繁变化且无记录 | 购买时的规则和实际路由难以追踪。 |
| 要求提交长期账号凭据 | 凭据泄露和关联账号风险显著增加。 |
最后：用五步做决定
- 用一分钟检查表排除信息明显缺失的候选。
- 选择两到三个候选，按同一口径计算一组真实任务的成本。
- 只投入少量测试额度，用同一客户端和同一组请求复测。
- 比较模型一致性、成功率、延迟、扣费和售后响应，而不是只比较倍率。
- 保留至少一条备用线路，定期复测，不把大量余额长期留在单一站点。
没有长期不变的“最佳中转站”。更现实的目标是找到一个 信息透明、成本可算、能力可测、风险可控，并且适合当前使用场景 的服务。
术语速查
| 术语 | 含义 |
|---|---|
| Base URL | 客户端发送 API 请求的基础地址。 |
| TTFT | Time to First Token，从请求发出到首个 token 返回的时间。 |
| TPS | Tokens Per Second，稳定输出阶段每秒生成的 token 数。 |
| RPM | Requests Per Minute，每分钟请求数限制。 |
| TPM | Tokens Per Minute，每分钟 token 数限制。 |
| SSE | Server-Sent Events，常见的流式响应形式。 |
| usage | API 响应中的用量统计，通常包含输入、输出和部分缓存信息。 |
| 混合路由 | 同一模型名可能按规则转发到多个上游。 |
参考资料
- OpenAI：Prompt caching
- OpenAI：Your data
- OpenAI：API pricing
- Anthropic：Prompt caching
- Anthropic：Extended thinking
- Anthropic：API and data retention
时效说明
价格、模型、缓存和数据政策会持续变化。引用具体倍率或功能时，应同时标注核对日期，并以目标模型当期官方页面为准。
活动通知与联系方式
- QQ 群：天衍会消息发布群 2；
- 微信：it_mg_668；
- 中转站：https://kktyh.com。
社群会发布活动倍率、线路状态和服务通知。遇到充值、兑换或分组问题时，建议同时提供订单号、报错时间和错误提示，便于快速查询。