> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 官转 API 和逆向 API 有什么区别？

> API易 默认官转；本文从稳定性、协议兼容、缓存、并发和可持续性对比官转与逆向 API，并说明 Claude_Reverse、Codex_Reverse、Gemini_Reverse 怎么选。

## 简短回答

**官转**是经由厂商官方 API 或官方云市场转发的资源；**逆向（官逆）**是通过非官方接口获取的调用能力。两者调用同一个模型时，单轮回答可能很接近，但真正拉开差距的是**稳定性、协议兼容、功能完整性、缓存效率、并发能力和长期可持续性**。

* **API易 默认走官转**，官逆是面向个人学习、成本敏感和非关键任务的补充。
* 生产环境、编程 Agent、企业客户：优先官转。
* 个人学习、简单聊天/翻译/摘要、成本敏感场景：可以用逆向。
* API易 的文本/编程逆向分组目前只有 `Claude_Reverse`、`Codex_Reverse`、`Gemini_Reverse` 三个；其他厂商的文本模型默认走 `Default` / `SVIP` 官转。
* 图片侧的 `-all` / `-vip` 是另一套官逆型号，主要走 `Default`；需要 URL 输出时部分型号走 `image2_OSS`，具体以控制台为准。
* API易 会在分组名和文档里标明来源，不把逆向宣传成官方直连。

> [!NOTE]
>
> 这是典型情况，不是“所有官转都优于所有逆向”。官转也会遇到官方容量不足；优质逆向资源池在速度、并发或某些业务稳定性上，可能阶段性更好。判断要看具体渠道、时段和实测。

本文讨论的是 API易 平台上的官转分组与官逆分组，不针对某一个具体模型；模型级差异请结合对应的模型文档和实测。

## API易 上的官转与官逆分组

先把“分组”和“型号”分开看：分组是令牌上的通道，型号是请求里的 `model`。API易 用分组聚合来源和用途，但同一个通用分组里可能同时有官转和图片官逆型号。

**API易 默认走官转。** 以官转为主的分组包括 `Default`、`SVIP`、`ClaudeCode`、`Claude_Enterprise`、`CodexResponses`、`image2Enterprise`、`NB-Enterprise`，以及视频组的 `SeeDance2`、`Wan&HappyHorse`。完整的分组、折扣和覆盖模型见 [分组介绍](https://docs.apiyi.com/groups.md)。

### 官逆分组（补充渠道）

| 逆向分组 | 覆盖范围 | 倍率 | 适合 |
| - | - | - | - |
| `Claude_Reverse` | 24 个 Claude 型号，不含 `claude-fable-5-2`、`claude-haiku-5-5` 等最新款 | 0.5 | 个人学习、非生产 |
| `Codex_Reverse` | `gpt-5.6-*`、`gpt-6-*`、`gpt-6.1-*` 等 9 个型号 | 0.5 | Codex 成本敏感、非生产 |
| `Gemini_Reverse` | Gemini 2.5–3.8 等 11 个型号，不含 Gemini 4 | 0.5 | Gemini CLI、学习、非生产 |

官逆是补充渠道，不承诺与官转相同的 SLA、并发和功能完整性。

> [!NOTE]
>
> `Default` / `SVIP` 以官转为主，但也包含 `gpt-image-2-all`、`gpt-image-2.6-all`、`-vip` 等图片官逆型号。选模型时要同时看分组和型号，不能只看分组名。

## 核心差异：不只看模型智商

### 稳定性与性能

| 维度 | 官转 | 逆向 | 对业务的影响 |
| - | - | - | - |
| 模型表现 | 官方原生，行为一致 | 大部分时候接近，偶有差异 | 单轮问答差距通常不大 |
| 模型真实性 | 来源可验证 | 依赖供应商透明度 | 建议用固定用例抽样验证 |
| 首 Token | 较低且可预测 | 可能多一层代理或排队 | 实时交互、打字机效果更敏感 |
| 整体速度 | 受官方负载影响 | 波动取决于资源池 | 批量任务要留重试和超时余量 |
| 并发与高峰 | 有明确 RPM / TPM 或配额 | 取决于账号池与调度 | 高峰更容易遇到 429 或排队 |
| 缓存 | 官方机制完整 | 可能不透传缓存控制参数 | 长对话、固定前缀场景成本上升 |

### 协议与功能

| 维度 | 官转 | 逆向 | 对业务的影响 |
| - | - | - | - |
| 参数兼容 | 官方参数与结构完整 | 部分参数可能不兼容或被忽略 | 复杂调用要做回归测试 |
| 流式输出 | 原生支持，行为规范 | 通常支持，可能有缓冲或格式差异 | 首字体验和客户端超时要调 |
| Tool Calling / MCP | 原生支持，结构可靠 | 调用结构或顺序问题概率更高 | Agent 任务成功率下降 |
| 结构化 JSON | 按官方能力保证 Schema | 可能无法严格满足 Schema | 下游解析要容错 |
| 多模态 | 官方支持的功能完整 | 图片、音频、视频等可能缺失 | 多模态业务先小流量验证 |
| 上下文长度 | 官方标称上限，约束明确 | 可能受逆向链路限制 | 长文档、长对话要压测 |
| Thinking / 推理控制 | 支持官方推理参数与返回格式 | 可能无法完全复现 | 推理预算和思维链处理受影响 |
| Usage 与错误码 | 官方计量口径，错误类型明确 | 可能估算或映射不准 | 计费对账和自动重试要容错 |

### 版本、合规与可持续性

| 维度 | 官转 | 逆向 | 对业务的影响 |
| - | - | - | - |
| 模型版本更新 | 跟随官方版本和生命周期 | 可能滞后，甚至无预警变化 | 版本锁定要留回退方案 |
| SLA 与故障定位 | 可通过官方支持渠道排查 | 依赖逆向供应商的排障能力 | 企业采购重点看保障 |
| 资源与风控 | 合规使用时相对可控 | 存在上游账号池、风控和接口变更风险 | 关键业务要准备备用通道 |
| 商业合规 | 厂商商业 API 条款覆盖 | 不属于厂商官方 API 条款范围 | 企业正式生产前评估合规要求 |
| 价格与长期成本 | 价格透明，可用采购折扣优化 | 可能更便宜，但隐性运维成本高 | 算总成本，不只看单价 |
| 长期可持续性 | 相对更强 | 依赖非官方链路的持续可用性 | 长期项目优先官转 |

> [!NOTE]
>
> 逆向资源不属于厂商官方 API 的商业使用条款范围。本文只做技术说明，不构成法律意见；企业采购和正式生产前的合规判断请结合自身要求。

## 为什么单轮质量接近，Agent 仍要优先官转

编程 Agent 的任务成功率不是由单轮回答决定的。一次工具调用参数错位、一个 JSON 字段缺失、一次流式输出中断，都可能让整段任务失败重跑；单轮看起来“智商一样”，多轮累计的成功率可能差很多。

三类问题在 Agent 场景会被放大：

* **工具调用结构**：逆向链路可能改写或忽略部分参数，函数名、参数顺序、嵌套结构出错的概率更高。
* **缓存前缀**：多轮对话的 system prompt、工具定义、历史消息构成长前缀；逆向链路如果不能完整透传 `cache_control`，缓存命中下降，成本和延迟都会上升。
* **错误码与重试**：错误码映射不准，自动重试逻辑可能把可恢复错误当成致命错误，或者反过来。

> [!TIP]
>
> Claude Code、Codex、Gemini CLI、OpenClaw 这类工作流，默认建议官转；逆向只作为成本补充或非关键任务。

## 什么时候优先官转，什么时候可以用逆向

| 场景 | 建议 | 原因 |
| - | - | - |
| 编程 Agent（Claude Code / Codex / Gemini CLI） | 官转优先 | 工具调用和多轮任务对协议一致性要求高 |
| 长上下文、多轮复杂对话 | 官转优先 | 缓存前缀和上下文透传更完整 |
| 简单聊天、翻译、摘要 | 逆向可用 | 单轮质量接近，成本更低 |
| Tool Calling / MCP 工作流 | 官转优先 | 参数结构、执行顺序、错误码更可靠 |
| 高并发批量生成 | 官转优先；逆向需压测 | 并发取决于官方配额或逆向资源池 |
| 图片生成 | 官转/企业组；成熟逆向可测试 | 输出格式、成功率、4K 稳定性差异大 |
| 企业正式生产 | 官转 | 合规、SLA、排障链路更完整 |
| 价格特别敏感 | 算总成本后再选 | 重试、失败损耗、运维成本要一起算 |

## 缓存不能只看命中率

官方 Claude 缓存有明确的前缀匹配、`cache_control` 标记和 5 分钟/1 小时有效期；请求里的 `cache_creation_input_tokens` 和 `cache_read_input_tokens` 能直接看出写入和命中。OpenAI 是全自动前缀缓存，Gemini 是隐式缓存、命中率一般。

逆向链路如果只做请求转发、不能完整透传缓存控制参数，命中率会下降；长对话、固定 system prompt、工具定义很多的场景，成本差距会被放大。选渠道时不要只看“有没有缓存”，要看相同前缀下的实际缓存读取占比。

缓存机制和计费口径见 [API易支持缓存计费吗？](https://docs.apiyi.com/faq/cache-billing.md)；Claude 缓存参数见 [Claude 缓存计费](https://docs.apiyi.com/api-capabilities/claude-prompt-caching.md)。

## 怎么验收一条渠道：5 项指标

如果你要在官转和逆向之间做选择，建议用固定测试集跑一遍，记录这 5 个数：

| 指标 | 怎么算 | 注意 |
| - | - | - |
| 请求成功率 | 成功请求 ÷（总请求 − 客户侧 4xx） | 排除自身参数错误 |
| 有效缓存命中率 | 缓存读取 tokens ÷ 输入 tokens | 同模型、同前缀、同分组 |
| P95 响应延迟 | 分别统计首 Token 和总时长 | 不看平均值 |
| Agent 任务完成率 | 固定任务集里最终交付成功的比例 | 比单轮质量更接近真实 |
| 单次有效任务成本 | （请求成本 + 重试成本 + 失败损耗）÷ 成功任务数 | 把失败算进去 |

不同厂商的缓存字段不同：Claude 用 `cache_read_input_tokens`，OpenAI 用 `prompt_tokens_details.cached_tokens` 一类字段，按实际响应取数。

> [!TIP]
>
> 单轮问答跑分只能说明“模型会不会答”，上面 5 项才说明“这条渠道能不能用来做业务”。

## API易 的渠道原则

* **默认官转**：API易 默认使用官方 API / 官方云市场资源；官逆是成本补充，不是默认渠道。
* **明示来源**：`Claude_Reverse`、`Codex_Reverse`、`Gemini_Reverse` 在分组名和文档里都标明是逆向，不写成官方直连。
* **生产优先官转**：`Default`、`SVIP`、`Claude_Enterprise`、`CodexResponses`、`image2Enterprise`、`NB-Enterprise` 承接生产流量；图片型号按具体来源选择。
* **复杂 Agent 优先官转**：工具调用、多轮任务、长上下文对协议一致性要求高。
* **逆向用于学习和成本优化**：不承诺与官转相同的 SLA、并发和功能完整性。
* **企业客户**：需要保障时走 `Claude_Enterprise`、`image2Enterprise`、`NB-Enterprise`；具体 SLA 和采购方案联系客服。
* **渠道会变**：上游资源、模型版本和分组倍率都可能调整，以控制台和 [实时动态](https://docs.apiyi.com/live.md) 为准。

如果只看单轮回答，官转和优质逆向可能很接近；官转真正值钱的是**行为一致性、稳定性可预期、功能完整和长期可持续性**。对生产业务来说，这四项决定的是售后成本和客户留存，而不只是单价。

## 相关文档

> [card] [分组介绍](https://docs.apiyi.com/groups.md)
>
> 全部分组、倍率、折扣与按厂商/按模型的选组建议

> [card] [令牌与分组](https://docs.apiyi.com/faq/token-and-groups.md)
>
> 令牌怎么建、默认分组与兜底分组怎么设

> [card] [什么是分组？](https://docs.apiyi.com/faq/groups-explained.md)
>
> 用户分组与令牌分组的区别

> [card] [缓存计费](https://docs.apiyi.com/faq/cache-billing.md)
>
> Claude、OpenAI、Gemini 的缓存机制与计费口径

> [card] [GPT Image 官转 vs 官逆](https://docs.apiyi.com/api-capabilities/gpt-image-2/vs-gpt-image-2-all.md)
>
> 图片侧官转与官逆的参数、价格与画质差异

> [card] [模型价格](https://docs.apiyi.com/models/index.md)
>
> 全部模型的价格与规格


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.