> ## 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/zh-Hant/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/zh-Hant/faq/cache-billing.md)；Claude 快取引數見 [Claude 快取計費](https://docs.apiyi.com/zh-Hant/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/zh-Hant/groups.md)
>
> 全部分組、倍率、折扣與按廠商/按模型的選組建議

> [card] [令牌與分組](https://docs.apiyi.com/zh-Hant/faq/token-and-groups.md)
>
> 令牌怎麼建、預設分組與兜底分組怎麼設

> [card] [什麼是分組？](https://docs.apiyi.com/zh-Hant/faq/groups-explained.md)
>
> 使用者分組與令牌分組的區別

> [card] [快取計費](https://docs.apiyi.com/zh-Hant/faq/cache-billing.md)
>
> Claude、OpenAI、Gemini 的快取機制與計費口徑

> [card] [GPT Image 官轉 vs 官逆](https://docs.apiyi.com/zh-Hant/api-capabilities/gpt-image-2/vs-gpt-image-2-all.md)
>
> 圖片側官轉與官逆的引數、價格與畫質差異

> [card] [模型價格](https://docs.apiyi.com/zh-Hant/models/index.md)
>
> 全部模型的價格與規格


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