圖片生成 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 的 range 是 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 計的精確成本，對帳不用再猜。
Streaming 預覽與該搬家的用戶
串流支援也不是齊頭式。依公告，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 開始，細節查官方文件。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。