如何使用 Gemini 4 Carbon：API 設定、參數與費用

Gemini 4 Carbon 是 Google Gemini 4 系列中的多模態模型，在 OrcaRouter 上只需一組金鑰即可存取：模型 ID 是 google/gemini-4-carbon，定價為每百萬輸入 token $2.00、每百萬輸出 token $10.00，而 Gemini 4 Carbon API 頁面會顯示即時數據。以下會按你實際會依序遇到的順序，說明真正可行的設定：端點、請求格式、參數集、成本，以及在你把它放到使用者面前之前應預留的延遲數字。

模型接受什麼

首先必須內化的是：上下文視窗為 1,048,576 個 token，而每個回應的輸出上限為 65K 個 token；這表示極大型文件可以放進提示中，但回答長度會遠低於輸入。輸入模態包括文字、圖像、音訊、視訊與文件；輸出則為文字。支援原生工具使用與函式呼叫，也支援結構化 JSON 輸出，這正是它能在代理迴圈中使用，而不只是聊天框的原因。

零資料保留（Zero Data Retention）功能已可在此模型上使用。啟用 ZDR 後，請求只會傳送至持有零保留協議的上游供應商；因此，若您的採購團隊需要書面確認，這屬於路由設定，而非另立一份合約。

端點一：OpenAI 相容路徑

如果你已經有程式碼在對任何 OpenAI 用戶端執行，這就是你要採用的做法。將 SDK 指向 OrcaRouter、保留模型 ID，請求中的其他內容都不用變更。下方的範例就是完整的程式：

將基底 URL 設為 https://api.orcarouter.ai/v1，從環境變數讀取金鑰，而不是寫死在程式碼中的字面值，並傳入 google/gemini-4-carbon 作為模型。同樣這三行程式碼在 Python、TypeScript 與 Go SDK 中都能運作，因為傳輸格式是 Chat Completions。

端點二：原生 generateContent

如果你的技術堆疊是建立在 Gemini SDK 而非 OpenAI 用戶端之上，Carbon 仍會在相同主機上透過 /v1beta/models/{model}:generateContent 原生回應。有意思的結果是，你可以一次遷移一個請求的工作負載：對與其他供應商共用程式碼的服務，使用 OpenAI 相容路徑；在你已依賴 Gemini 特定欄位的地方，使用原生路徑。兩者都會對同一個金鑰與同一筆餘額計費，這正是採用閘道而非一組供應商帳戶的理由。

會被遵循的參數

模型頁面明確列出支援的集合：include_reasoning、max_tokens、reasoning、response_format、seed、stop、structured_outputs、temperature、tool_choice、tools 與 top_p。這份清單就是契約。如果你要從其他供應商移植請求，發布前先檢查，因為你出於習慣會用到的參數——懲罰項、logit 偏差、十幾個取樣旋鈕——並不在這份清單上。

其中兩個比其他更為重要。structured_outputs 加上 response_format，能把一份 20 萬 token 的文件轉換成一筆記錄，讓你的下游程式碼無需自行撰寫解析器即可讀取。而 include_reasoning 則讓你得知模型在回答之前做了什麼；在正式環境中把它關掉，就等於把結構描述交給一個不透明的步驟。

請求的成本為何

輸入為每百萬個 token $2.00，輸出為每百萬個 token $10.00，快取讀取則為每百萬個 $0.100。一個實例：一份 40,000 個 token 的合約加上 2,000 個 token 的結構化擷取，會計費 $0.08 的輸入與 $0.02 的輸出，也就是每份文件十美分。同樣的 40,000 個 token 從快取讀取則改為計費 $0.004，這就是為什麼對於任何會重複讀取同一語料庫的工作流程，快取那一行很重要。

作為規模參照，同一份 40,000 個 token 的文件使用 Gemini 3.1 Pro，輸入成本相同，但輸出成本高出 20%；使用 Gemini 3 Flash 時，兩項成本都只有四分之一——兩者之間的選擇取決於模態與上下文，而非輸入價格，因為 Carbon 與 3.1 Pro 的輸入價格完全相同。免費 LLM API 解析正是將這一點與目錄其餘部分進行比較的地方。

兩個含義不同的延遲數值

OrcaRouter 自家的模型頁面報告過去七天的即時流量：首個 token 時間的 p50 為 6.89 秒，p95 為 10.00 秒，輸出速度為每秒 226 個 token，期間共服務 960 萬個 token。這就是互動式呼叫端透過閘道所體驗到的情況。

Artificial Analysis 回報，同一個模型產生首個 token 需 64.7 秒，而每項任務的實際耗時為 28.4 分鐘。這兩者並不衝突；它們是不同的測量方式。AA 執行一套固定的評估測試框架，要求模型在九項困難基準測試上自行決定要思考多久，因此計時包含推理時間，而不只是網路與 prefill。如果你只引用其中一個數字而沒有引用另一個，你要嘛會過度承諾互動性，要嘛會嚇跑原本覺得沒問題的買家。

坦白說，營運上需留意的是錯誤率：在那七天期間，所有上游供應商合計有 39.7% 的請求傳回非 2xx 狀態，相較之下，Claude Fable 5.2 同期為 10.8%。請在上線前就建好重試與備援路徑，而不是等第一次事故後才做，並閱讀Gemini 4 Carbon 發行說明，了解它上線時有哪些變更。

Carbon 開始運作後適合放在哪裡

值得採用這套方案的工作負載，是那些需要 1M 視窗且涉及不只一種模態的情境：完整程式碼庫、含多位講者的長逐字稿、掃描 PDF 及其擷取文字。如果你是在 Google 模型之間做選擇，Gemini 4 Carbon vs Gemini 3.1 Pro是直接比較；如果替代方案完全來自其他廠商，GPT-6.1 Sol vs Gemini 4 Carbon則從另一側涵蓋同一個決策。

如果你還在組裝一套技術堆疊，而不是遷移單一工作負載，LLM 模型清單提供目前的目錄與 ID、價格；在寫死任何內容之前，請先確認頁面頂端連結的模型頁面——價格和端點都會變動。

檢查清單

將金鑰存放在環境變數中，不要放在儲存庫裡。選擇與你已經發布的 SDK 相符的端點。只傳送支援清單中的參數，並在輸出會餵給程式碼時使用 response_format 加上 structured_outputs。將輸出預算設為 65K 個 token，並對任何超過 20K 且你讀取超過兩次的內容進行快取。預期 p50 接近七秒，並為少數會回傳錯誤的呼叫做好準備。然後用自己的流量來衡量，因為基準圖表只是起點，而你的請求分布才是唯一決定這是否為正確選擇的因素。