Gemini Omni 1.2 Flash 對決 Nano Banana 2.1：三十一張靜態圖換一段影片

為一支三十秒的產品廣告編列預算，你會需要兩個 Google 模型，而不是一個。Nano Banana 2.1 是靜態影像機器——端點為 gemini-nano-banana-2.1，自 2026 年 10 月 6 日起正式可用，1K 影像為 $0.0336，2K 為 $0.0504，4K 為 $0.113。Gemini Omni 1.2 Flash 則是動態影像機器：自 2026 年 11 月 5 日起正式可用，720p 影片每秒約 $0.07，換算下來一支十五秒短片接近 $1.05。把兩者相除，單次十五秒算圖的成本大約等於三十一張 1K 靜態圖的成本。這個比例就是整個決策的核心，而這正是大多數團隊搞反的比例，因為他們是為模型定價，而不是為交付成果定價。

兩者都是 Google 的產品、都按用量計費、都帶有 SynthID，而且都有一個會讓整合出錯的命名怪癖：顯示名稱和端點 ID 的格式並不是你預期的那樣。Nano Banana 是 Google 為 Gemini 原生圖像生成所取的產品名稱，最新一款對應的是 gemini-nano-banana-2.1，而前一代則是 gemini-3.1-flash-image。Omni 的最新款對應的是 gemini-omni-1.2-flash。這兩個名稱都沒告訴你買的是哪一種模態。

每一個各自交回的內容

Nano Banana 2.1 可接受文字、圖像、影片和 PDF 輸入，並輸出圖像和文字，解析度為 1K、2K 或 4K，思考等級分為最低、中等或高。它最多可容納 14 張參考圖像進行多圖融合——足以在十個物件之間維持四個角色和物件的保真度——並且具備 Google 搜尋和圖片搜尋的基礎依據。其 Token 上限為輸入 131,072、輸出 32,768。

Gemini Omni 1.2 Flash 可接受文字、圖像和影片輸入，並回傳帶有原生同步音訊的影片，長度為三到十五秒、每秒 24 幀，解析度為 360p、720p、1080p 或 4K，其中最高的兩種是經由升頻處理。每次請求最多可容納六張參考圖像，以及長度最多三秒的參考影片。它接受與先前相同的 131,072 個輸入 token，並最多回傳 65,536 個。

• 輸出 — 圖片與文字，對比含原生音訊的影片。

• 持續時間 — 一幀對比三到十五秒，可延長至總計 30 秒。

• 參考圖片 — 最多 14 張對比最多 6 張。

• 解析度 — 1K、2K、4K 原生等級，對比 360p、720p、1080p、4K，其中最高兩項為升頻處理。

• 思考控制 — 最小、中等、高，對比無；Omni 完全不提供 temperature、top_p 或系統指令。

• 輸入類型 — 文字、圖片、影片與 PDF 對比文字、圖片與影片。

• 價格 — 每 1K 張圖片 $0.0336，相較於 720p 每秒約 $0.07。

三十秒廣告的算術

採用貼近真實的工作流程，而不是基準測試。你有八個鏡頭要填滿三十秒，每個鏡頭兩到四秒，而你想在付費生成動態之前，先挑出最有賣相的那一格畫面。

在靜態影像方面，每顆鏡頭以 2K 生成四張候選圖：三十二張影像，每張 $0.0504，共 $1.61。審閱這些影像，挑出八張，將獲選者放大至 4K，每張 $0.113：再花 $0.90。你這個專案目前投入約 $2.51，並取得八張核准的畫面。

現在開始製作動畫。八個鏡頭每個約三秒，就是 24 秒的 720p，再加上重試——而 Omni 的對話式編輯意味著重試是正常流程，而非例外。以每個鏡頭兩次來算：48 秒的輸出以 $0.07 計，約 $3.36。然後將最終成品升頻：1080p 以每秒 $0.104 計、24 秒約 $2.50，4K 則是兩倍。

算下來總共是 8 到 9 美元，其中大約三分之一花在靜態圖上。這才是真實帳單的樣貌，也是為什麼若把「每支影片 31 張靜態圖」的比例當成建議，會產生誤導。靜態圖並不是影片的替代品。它們是便宜的那一部分，卻決定這支影片值不值得做。

比例真正產生影響的地方是另一個問題：這項交付物是一張圖片，還是一段動態序列？500 張產品圖的型錄，是 25 美元的 Nano Banana 工作，或 525 美元的 Omni 工作，而在這項比較中，勝負毫無懸念。錯誤在於因為提示詞描述了會動的東西，就生成影片。

參考圖片，其中較便宜的模型反而是能力更強的那一款

這是這項比較中反直覺的發現，而且在兩份文件中都能查證。Nano Banana 2.1 最多可接受 14 張參考圖像。Gemini Omni 1.2 Flash 最多可接受六張。

Google 對 Omni 六項參照的官方說法很具體：每個角色最多三張圖像，最多兩個角色，再加上產品與風格參照。模型卡稱其為「在最多 6 張參照圖像下，改善角色與主體的一致性」，發布文章則描述能在不同角度下保持臉部、服裝、包裝字體與品牌色彩一致。參照影片的路徑則是獨立的，並依時長分級——十一至十五秒的輸出可採用一段最長三秒的參照影片，三至十秒的輸出最多可採用三段——而參照影片僅適用於全新生成，不適用於編輯或延伸。

Nano Banana 2.1 的十四個則針對另一個問題：把多個主體融合進同一個場景，其規格卡宣稱能保真處理四個角色與十個物件。那是合成能力，而非連貫性能力，適合型錄作業——把同一個包放進十個不同的房間，而不必重畫那個包。

實際後果是：如果你的工作是「同一個角色、多個鏡頭」，Omni 的六個參照、每個角色三張取景，就是規格更明確的工具。如果你的工作是「多個物件、單一畫面」，那就是 Nano Banana 的十四個。只數參照數量就宣布誰勝出，會完全搞錯重點。

文字渲染，而這正是這些模型真正有所差異的地方

兩款模型在清晰易讀的字型方面都異常出色，而對兩者來說，這項能力最能改變你能推出的產品。

Nano Banana 2.1 相較於 Nano Banana 2 所列出的進步包括視覺品質、提示詞遵循度、多輪角色一致性與文字渲染，另外還修正了寬幅全景比例的問題——1:4、4:1、1:8 與 8:1 在 2K 和 4K 下不再出現平鋪拼接。若你的交付成果是資訊圖表、海報或 UI 模擬稿，那這些改進組合起來就是整個產品。

Omni 1.2 相對應的主張，是關於動態畫面中的文字：標籤可讀性、圖表動畫、螢幕上的標註。Google 的發表素材大力強調這點，而目前唯一可取得的獨立實測——由 Segmind 的 Rohit Rao 進行二十次生成、花費 16.17 美元額度——發現模型表現最好的地方，是根據提供的最终影格製作有標籤的說明影片與圖表動畫，而從零開始生成逼真人物則是它失敗的地方。他的總結是，它是「我測試過最精確遵循指令的影片模型」，但附帶一點：大約每四項指令就有一項被略過。

注意這對組合意味著什麼：Omni 1.2 最強且有記錄的用途，是把你已經設計好的圖形製作成動畫。而這正是 Nano Banana 2.1 的工作。

解析度、升頻，以及「4K」到底值不值得

兩者都標榜 4K，但所指的並不是同一回事。

Nano Banana 2.1 可選擇以 1K、2K 或 4K 作為輸出等級，而 Google 分別為它們定價：每張圖片 $0.0336、$0.0504 和 $0.113。代幣計算反映實際像素——1K 圖片為 1,120 個代幣，2K 為 1,680 個，4K 為 3,780 個。

Gemini Omni 1.2 Flash 的指南明確指出，1080p 和 4K 都是經過升頻處理的。其定價依 token 消耗量而非原生渲染計算，1080p 每秒 8,688 個 token，4K 每秒 17,376 個 token，而 720p 則為 5,792 個。因此，一支十五秒的 4K 影片約需 $3.14，而最高規格其實是將較小尺寸的渲染結果放大，並非在拍攝當下擷取的細節。用於社群媒體交付沒問題。若要用於廣播，請先測試，再做出承諾。

兩者都屬於的工作流程

Google 自己建議的 Omni 準則，是先低成本打草稿、反覆迭代，再把勝出的版本升頻：用 360p 或 720p 探索，用 1080p 或 4K 做最終版。Nano Banana 的對應做法，則是以 1K 生成、再把挑中的版本升頻。把這些步驟串成一系列，流程自然就成形了：先做靜態圖，確定構圖與文字；再對通過審查的影格加上動態；最後把兩者一起做最終升頻。

有一條硬性界線。Omni 不接受將圖片作為影片交付物，Nano Banana 也不接受將影片作為圖片交付物。兩個模型的輸出都無法回饋給對方進行同模態編輯——Omni 可以延伸並以對話方式編輯自己的片段，Nano Banana 可以編輯自己的靜態影像，兩者互不相通。

透過 OrcaRouter 購買任一項

這兩個端點目前都不在我們的目錄中。google/gemini-nano-banana-2.1 和 google/gemini-omni-1.2-flash 在 OrcaRouter 的模型頁面上都回傳 404，因此兩者都得走供應商 API。我們確實在同一系列中提供的是先前的圖像生成端點，google/gemini-3.1-flash-image-preview——Nano Banana 2——以及 Nano Banana Pro 和 Gemini 3.8 Flash 文字模型，這表示未鎖定最新檢查點的圖像管線，可以用同一把金鑰執行其規劃、提示詞擴展和 QA 步驟。

這就是它誠實的樣貌：媒體呼叫直接進行，而圍繞它們的文字呼叫則不必如此。OrcaRouter 以 0% 加成計費，並直接轉嫁供應商的定價，因此若 Google 調整 Nano Banana 或 Omni 的費率，變動會在同一天出現在我們這邊，就像出現在他們那邊一樣；而自動容錯移轉能在某個供應商效能下降時，讓提示擴充步驟繼續運作。

實際上該選什麼

如果交付物是有人會實際查看的畫面——包裝照、資訊圖表、主視覺圖、UI 模擬稿——Nano Banana 2.1 每份產出的成本便宜三十倍，可接受的參考素材多出一倍以上，支援 PDF，還具備 Omni 未提供的思考控制。無論從哪個角度來看，這項決策中 Omni 都無法憑實力勝出。

如果交付成果是動態影像，Nano Banana 2.1 無論價格多高都做不出來，比較也就到此為止。

陷阱在於中間那種情況：一個專案想要「影片廣告」，但它真正的難題全在構圖、字體排版與一致性。那些仍然是難題。用每幀只要三分錢的模型來解決它們，並讓 Omni 為八個已核准的影格製作動畫，而不是三十二個推測性的影格。三十一比一的比例並不是支持靜態圖像模型的理由。它是支持先使用該模型的理由。