Gemini Omni Flash 1.2 對上 Gemini Omni 1.1 Flash：兩份排行榜說可以，一份說還不行

自 2026 年 12 月 3 日起，所有傳送至 G​emini Omni 1.1 Flash 的請求，都會開始改為落至 G​emini Omni Flash 1.2，並依新費率計費，而您的承載資料不會有任何變更。G​oogle 在同一則更新日誌條目中公布了該路由日期，而該條目也讓 1.2 版於 11 月 5 日正式推出。所以，版本問題不在於您是否要遷移，而在於您能否在切換降臨到您身上之前完成衡量；而支持這麼做的獨立證據，比降價所暗示的更為分歧。

同一週的投票實際上揭示了什麼

Artificial Analysis 在其三個影片評測榜單上分別測試了這兩個版本，並在幾天內先後發布了這兩份結果。這是罕見的情況：版本比較不必從兩個不同時間、兩場不同的測量活動中拼湊而成。

在 AA-Video-I2V v2.1 上，此事已成定局。Gemini Omni Flash 1.2 以 1,086 分位居其間，95% 區間為 1,071 至 1,101；Gemini Omni 1.1 Flash 則為 1,044 分，區間為 1,030 至 1,058。相差四十二分，區間不重疊，第 14 名對上第 18 名。無論這個新模型還有什麼其他不確定之處，其圖像轉影片輸出在可量測程度上比前代更受偏好，且此幅度有樣本支持。

在 AA-Video-T2V v2.1 上，這個情況仍懸而未決。26 分的差距——1,154 對 1,128——伴隨的區間分別是 1,140 至 1,168 與 1,115 至 1,141。兩者只共享一個點。在 AA-Video-Editing v1.1 上，差距是 18 分，1,164 對 1,146，而區間重疊了四個點。兩個排行榜都把 1.2 排在 1.1 之上。兩者都無法區分它們。

那個模式比任何單一數字都更有價值。一個新檢查點若在一項任務上明顯勝出，可能在第二項上也勝出，而在第三項上僅略勝一籌，這正是小版本更新的常見樣貌。這不是 15 秒短片與加倍速率限制可能暗示的那種世代躍進的樣貌。

價格是那個沒有誤差線的部分

影片輸出從每百萬個 token 的 $17.50 降至 $12.00，降幅 30%，而且是該發布中唯一不需要信賴區間的主張。Google 以每秒影片固定 token 費率計費，所以算術不是偏好問題：在 720p、每秒 5,792 個 token 下，成本從每秒約 $0.10 降至約 $0.07。在 1080p 搭配升頻取樣時，約為每秒 $0.104；4K 則約為 $0.209。Artificial Analysis 將兩個版本標準化為每分鐘 1080p 的 $9.12 與 $6.26，這正是從同一計量器另一端看到的相同 30%。

文字、圖像和影片的輸入價格維持在每百萬個 token $1.50，文字輸出則維持在 $9.00。Batch、Flex 或 Priority 欄位都沒有任何變動，因為 1.2 版完全沒有這些項目——只有標準層級，而且兩個版本都沒有免費層級。

在路由日期之前先算好短片成本，而不是等到之後才算。在 1.2 上以 720p 輸出十五秒，輸出 token 成本約為 $1.05。同樣的十五秒無法在 1.1 上以單次呼叫產生，因為 1.1 上限是十秒；誠實的比較是十秒約 $1.00。降幅是真的，但其中很大一部分是用來換取多出的五秒；而從不需要更長片段的團隊，看到的帳單變動會比該百分比所暗示的更小。

當十五秒不再免費的那一刻

這次延長伴隨一些有明文記載、而非靠實際遇到才發現的邊界情況，其中三個會改變請求允許包含的內容。

• 插值 — 首尾幀控制在兩個版本上皆支援三至十秒；在 1.2 上要求十一秒以上並搭配兩個參考幀時，會回傳無效引數錯誤。

• 參考影片 — 三到十秒的輸出可接受三段參考影片，每段最長三秒；而十一到十五秒的輸出則只接受一段。延長鏡頭可能會在無聲無息中，使原本以三段影片通過的請求失效。

• 延伸 — 延伸每輪執行三到十秒，並有十秒回溯，總計上限為 30 秒，且僅在片段結尾進行。在 1.1 中，編輯與延伸的上限是十秒輸入。

• 參考圖片——每次請求最多六張，涵蓋全部三種模式；這是 Google 在發表說明中，針對角色與主體一致性所主打的一項變更。

• 地區 — 在歐洲經濟區、瑞士與英國，無法編輯及延長上傳的影片，此限制已載明於指南中。若你的使用者位於這些市場，對話式編輯的宣傳訴求對他們完全不適用。

• 未改變的限制——沒有系統指令、沒有 temperature、沒有 top_p、沒有負面提示、沒有佈建輸送量、沒有 YouTube 來源、沒有多影片推理。每個輸出都帶有 SynthID 浮水印。

一個「Text」輸出列，但它的意思並不是看起來那樣

模型卡將 1.2 的輸出列為「Video with native Audio, Text」，而 1.1 僅列為「Video」，這項差異被解讀為新增了文字通道。其實並非如此。Omni 指南並未描述 1.2 有任何文字輸出模式；文字是渲染在畫面內的——標籤、招牌、座標軸——而請求形態仍然是影片回應。REST 回應帶有一個 steps 陣列，其中的「thought」項目是推理軌跡，不是答案。如果管線需要 API 回傳字幕字串，兩個版本都不會回傳；該列的差異描述的是模型畫出什麼，而不是它給你什麼。

音訊那一列確實是實質的改變，但改變的是品質，而非本質。兩個版本都會生成原生的同步音訊。Google 在發表時宣稱對話更流暢、嘴型同步更清晰，並具備明確的多講者調控能力，還說參考素材可以帶有音訊提示與一秒鐘的語音樣本——這些參考路徑在 Google Cloud 上必須列入允許清單，此版本中模型本身並不支援音訊輸入，參考影片中的音訊會被忽略，而且不提供語音編輯功能。你可以用提示詞指定聲音，但事後無法編輯。那些品質宣稱全都沒有獨立測試佐證，而上述三個排行榜衡量的是視覺偏好，而非文字是否對得上嘴型。

那個會弄壞下游的，是遷移，不是請求

由於承載資料不會改變，失效面就是請求所送入的一切。12 月 3 日前要檢查的四個地方，依它們通常出錯的順序如下：

時長預設值。省略時長的請求以往會被限制在十秒，如今仍預設為十秒，因此未經改動的呼叫行為完全一致。真正會出問題的，是把十秒當成上限的驗證邏輯。

影格配對調理。任何將插值與超過十的時長配對的程式碼路徑，現在都會報錯，而不是悄悄截斷——行為更好，失敗更明顯。

成本模型。每個由 1.1 費率推算出的每秒常數，在 720p 下都高估了 30%。如果你按每次渲染進行內部計費，這就是趁舊價格仍正確時要修改的那一行，因為切換之後，這個數字會朝美化你利潤率的方向出錯。

篩選行為。編輯看板上 1.2 的那一列附有註記，說明模型透過著作權與安全篩選機制婉拒了部分測試集，而公布的分數反映的是留存下來的提示。若生產流程原本假設每個請求都會回傳檔案，就必須特別針對新版本設計拒答處理路徑。這則註記只出現在 1.2 那一列，1.1 那一列並沒有。

兩種轉換方式，以及哪一種適合你

如果你的內容有經過衡量，而且你喜歡產出結果，就提早遷移，並利用這三週在你自己的素材上重新衡量。降價和時長增加值得享有，圖像轉影片的落差確實存在，而另一個選擇是在12月3日被遷移，卻兩邊都沒有數據。

如果你的內容量很大，而且自上次變更後就沒再檢視過，務實的做法是兩者並行。趁 1.1 仍可個別定址，讓它繼續留在生產路徑上，並將一定比例的流量以影子模式導向 1.2，然後用排行榜未衡量的軸線來比較——影片片段能存活到交付的頻率，而不是它在兩兩比較投票中獲勝的頻率。這是路由問題，不是模型問題，而路由正是我們營運的層級。目前 Omni 的兩個端點都不在 OrcaRouter 的目錄中，所以這不是我們在推銷由我們來服務它們；這正是版本升級對只有單一路徑、無法在旁邊跑第二條路徑的管線傷害最大的原因。我們真正能贏得這個定位的地方，是周邊的文字工作：供應渲染流程的提示詞擴充與鏡頭清單呼叫，可以透過單一端點、以供應商牌價對多個模型進行組合，並具備其中一個模型效能下降時的自動容錯轉移，而且路由規則可以將一部分請求送到另一個模型，無須部署。

千萬別做的一件事，就是把 1.1 版釘選超過 12 月 3 日，然後才從發票上發現這項變更。無論你的設定怎麼寫，端點都會照常路由。

版本比較，以版本比較的形式陳述

1.2 每秒更便宜、每段影片更長，在影像轉影片方面更好，且領先幅度足以超出其自身誤差範圍；在文字轉影片與剪輯方面可能也更好，但現有證據尚無法將它與 1.1 明確區分。它帶有安全篩選器，會移除部分剪輯基準測試，也將移除你的一部分剪輯工作量，而且會在 Google 已公布的日期承接 1.1 的流量。

會被引用的比較會是排名變動，因為十二到六看起來像躍升，而四十二 Elo 看起來只是個數字。能預測下一季走勢的比較，則是帶有區間的那一個，而它說的是：一項明確的勝利、兩項可能的勝利，以及三者底下更便宜的計量方式。