摘要： OpenRouter 在 6 月 23 日推出 Unified Image API，以單一請求格式存取 30 多個模型，並用可查詢 schema 描述各模型能力、參數、endpoint 與價格。各模型的解析度、比例、批次、參考圖與串流支援不同，計費仍分每張、每百萬像素與每 token，因此要先換算預估再用 usage 成本對帳。既有模型可續用 completions/responses，但新增 image 模型只會進專屬 Image API。
圖片生成 API 最難搞的地方，表面上是各家請求格式不一致，實際更深一層的麻煩是模型能力本身就對不齊：支援的解析度、比例、參考圖數量、單次輸出張數、能否串流，每個模型各有一套。只統一欄位名稱、不處理能力落差，結果不過是把一種 400 Error 換成另一種。OpenRouter 在 6 月 23 日推出的 Unified Image API 走的是另一條路：除了單一請求格式，還把各模型的能力、參數與價格全數整理成可查詢的 schema。依官方公告，這個專用 API 一站存取 30 多個模型，供應商名單包含 Google、OpenAI、Black Forest Labs、Recraft、ByteDance、Sourceful、Microsoft 與 xAI，而且名單還在增加。
先把能力查清楚，再動手
分工方式很直接：模型會什麼，問 /api/v1/images/models；要產圖，就打 POST /api/v1/images（以 Bearer API key 驗證）。前者會替每個模型回傳 typed capability descriptors——支援哪些解析度與比例、單次上限幾張、參考圖數量天花板、有無 seed、能否串流——通通是結構化欄位，而非宣傳文案。
能力落差比多數人預期的更明顯。公告寫到：Seedream 4.5 提供 18 種 aspect ratio，Gemini 3.1 Flash Image 是 14 種，兩邊有交集但清單不同；單次請求的產圖上限，部分模型可達 10 張，其餘只有 1 張；input references 的上限同樣各有不同，公告正文的說法是「有的 16 張、有的 4 張」。還有個值得停一下的細節：同一份公告裡，Seedream 4.5 的 descriptor 範例把 input_references 的範圍標成 0 到 14——正文與範例數字對不上，引用時請註明出自哪個段落。別猜了，直接讀 descriptor：
{
"resolution": { "type": "enum", "values": ["1K", "2K", "4K"] },
"n": { "type": "range", "min": 1, "max": 10 },
"input_references": { "type": "range", "min": 0, "max": 14 },
"seed": { "type": "boolean" },
"supports_streaming": false
}上面這段是公告中 bytedance-seed/seedream-4.5 descriptor 的節錄——id、supported_parameters 外層與 aspect_ratio 略去未列，留下的數值與原始檔案相同。有了它，程式或 coding agent 就能在送出請求之前先做本地檢查，不必把各供應商的限制寫死在各自的 adapter，也不必靠送錯請求來換 400 Error。模型清單持續變長，寫死的限制表只會加速失效；descriptor 把 adapter 邏輯收斂成一次查詢搭配一份快取。
單一請求格式，三套計費尺度
請求端把 resolution、aspect_ratio、quality、輸出格式、背景透明、input references 與 streaming 統一成正規化欄位，跨供應商通用；Black Forest Labs 的 steps、guidance 這類專屬參數則走 provider.options，以 provider slug 作為 key 帶入。另外，每個 endpoint 都會公布 allowed_passthrough_parameters 清單，寫明收下哪些 passthrough keys——過不過得了，查清單就知道，不必再試。
同一個模型可能同時由多家 provider 供應；/api/v1/images/models/{id}/endpoints 會回傳各 endpoint 實際接受的參數、串流支援狀況與細粒度定價。endpoint 回應裡附有 pricing 陣列，Seedream 4.5 的條目是 {"billable": "output_image", "unit": "image", "cost_usd": 0.04}——計費標的、單位與單價擠在同一行，要估成本就讀數字，不用翻說明文件。定價堪稱這個 API 最坦白的部分，因為計費單位從頭到尾沒有統一：
| 模型（依公告） | 計費單位 | 價格 |
|---|---|---|
| Seedream 4.5 | 每張 | $0.04 |
| FLUX.2 Pro | 每百萬像素 | $0.03，解析度直接決定帳單金額 |
| GPT-5.4 Image 2、Gemini 3.1 Flash Image | 按 token | 按實際用量收 |
三種單位對應三條成本曲線：按張計費與解析度無關，最好預估；按百萬像素計費隨解析度等比放大——公告只公布單價，1K 到 4K 會差幾倍得自己算，那不是官方數字；按 token 計費則取決於生成實際耗用的量，事先只能抓一個區間。要打造成本感知的路由，第一步是把三種單位換算成可比較的預估再來排序；接著，每個回應的 usage object 都帶有以 USD 計的精確成本，事後對帳不必猜測。
串流預覽，以及誰該遷移
串流的支援同樣不是一套標準套到底。依公告，OpenAI GPT Image 系列——GPT-5 Image、GPT-5 Image Mini、GPT-5.4 Image 2——原生提供 SSE streaming，設好 stream: true，渲染進行中就會陸續送出未完成的部分圖片預覽；對耗時較久的渲染任務，這些預覽把「還在處理」化為看得見的進度，產品端不必再靠 spinner 撐完整段等待。其餘模型一律以 supports_streaming 欄位為準，別自行假設。
官方給的 migration 指引只有一條明確的線：既有的 image 模型照舊能透過 completions/responses 產圖，但往後新增的 image 模型只會進專屬 Image API。官方同時建議 openai/gpt-5-image、gpt-5-image-mini、gpt-5.4-image-2 的用戶改用 dedicated image 模型——這些版本經由 LLM 產圖，參數集不完整，還可能多出額外的 inference 成本。產品如果還依賴舊路徑，這次改版正是切換的時機——繼續留在 completions 的代價不只是參數不足，未來所有新的 image 模型也都與這條路無緣。
統一的是管線，不是畫面品質
預期要先擺正：統一 API 解決的是整合與維護負擔，不是視覺上的一致。同一句 prompt 換個模型，風格就變了，reference image 的解讀方式也各家一套。產品仍須替關鍵模型自備評測集——構圖、文字渲染、人物一致性、安全政策——這些問題不會有 API 替你作答。
換個角度說，capability descriptor 讓「切換模型」變得可靠，卻沒有把模型變成可互相替換的零件。選型與品質驗證依舊是產品自己的功課——本節的論述框架屬作者觀點，並非公告內容。
Builder 的行動清單
三件今天就能做的事。第一，程式啟動時先查 /api/v1/images/models，把能力 schema 快取下來做本地驗證，別把 runtime 呼叫浪費在試錯上。第二，要按成本路由，先把計費單位換算成可比較的預估，再以每次回應的 usage 成本對帳。第三，如果目前還在 chat completions 上產圖，照官方建議轉往 dedicated image 模型——拿齊完整參數集，也省下多餘的 inference 成本。想開始體驗，從 playground 進入，細節請查官方文件。