生成式媒體的路由層，先從成本、延遲與可追溯性開始

生成式媒體應用過去常把模型選擇寫死在程式裡。模型一旦改版、漲價或出現更快的替代方案，團隊就得重新測試與調整整合。當影像與影片選項愈來愈多，「每次請求該送往哪裡」已經成為需要持續維運的產品能力。

多模型入口不等於已經有自動路由

Runway API 參考文件列出多個影像與影片模型，請求格式也把 model 設為必要欄位，開發者必須明確指定接受的型號。官方現行文件沒有提供一個可核實、能直接按成本、延遲或品質自動選模的通用路由介面，因此不能把多模型目錄直接寫成平台已替所有請求完成選擇。

這個區別很實際。集中 API 的確降低了驗證金鑰、提交工作與取得結果的整合成本，但模型選擇仍需要產品方建立規則。若團隊要做自動路由，就必須自行決定不同任務的品質門檻、允許的供應商、預算上限與失敗後的替代路徑。

成本與延遲不是同一個旋鈕

Runway 的定價文件顯示，不同影片模型以每秒不同 credits 計價，影像模型也會依解析度與品質層級改變成本。以行銷素材配方為例，官方文件還列出低、中、高品質的大致等待時間，較高品質通常需要更久。

因此，「最便宜」不一定能滿足即時預覽，「最快」也不一定適合交付成品。路由策略至少要分開測量任務類型、輸出品質、端到端延遲與實際花費，不能只用單一綜合分數掩蓋取捨。

降級策略必須保留產品語意

模型服務會遇到限流、過載與內容安全拒絕。Runway 錯誤碼說明建議對部分 429、502、503 與 504 回應重試並採用退避與 jitter，但安全拒絕不應重試。這意味著路由器不能把所有失敗都視為「換一個模型再試一次」。

同一提示送往不同模型，也可能改變角色一致性、畫面節奏與品牌風格。產品方應為每種降級路徑保留自己的驗收資料，記錄實際使用的模型與參數，並讓敏感工作可以禁止跨供應商切換。可用性提升若犧牲可預測性，最終只會把錯誤藏得更深。

生成完成後，證據還要留得住

輸出格式文件提醒，任務完成後取得的結果網址會在 24 至 48 小時內失效，使用者應下載並保存到自己的儲存空間，而不是直接把臨時連結暴露在產品中。這項細節與模型路由同樣重要：若結果、參數與來源無法長期對應，事後就難以重現一次生成。

控制層的價值來自可驗證，而不是神祕選擇

多模型平台確實讓切換更容易，但可靠路由仍需要透明規則：什麼情況選哪個模型、品質如何評估、成本如何計算、失敗何時重試，以及結果如何保存。這些條件若只藏在平台內部，團隊就很難知道自動化究竟改善了什麼。

較務實的做法，是先建立可測量、可切換與可追蹤的控制層，再決定哪些判斷適合自動化。路由器不該只是把複雜度藏起來，而要把每次選擇轉成能被檢查與改進的產品決策。