Gemini Omni 1.1 Flash 深度解析：40 秒延伸、首尾影格與 4K 真相（2026）

2026 年 8 月 27 日，Google DeepMind 產品經理 Anish Nangia 與 Alisa Fortin 發布〈Gemini Omni 1.1 Flash lets you build with more control〉。這次 Gemini Omni 1.1 Flash 最值得看的，不是又多一支漂亮示範片，而是 Google 把「延伸、首尾影格、參考影片、低解析度草稿、放大輸出」放進同一套可反覆調整的生成流程。

消息發布後很快引起討論；截至 2026 年 8 月 28 日 06:21（台北時間），Hacker News 討論串已有 161 分與 115 則留言。不過，熱度不能回答最重要的問題：40 秒到底怎麼來？4K 是原生生成還是後製放大？控制功能是否已經等於穩定的製作能力？本文會先忠實還原發布內容，再用技術文件與外部資料逐項核對，最後給出可執行的判讀方式。

---

一、核心變化：AI 影片生成器開始長出「剪輯狀態」

早期文字轉影片比較像抽獎：輸入提示詞、等待一段完整片段，不滿意就整段重來。Gemini Omni 1.1 Flash 的產品方向不同，它把創作者的決策拆成幾個節點：

• 延伸場景：每次最多接續 10 秒，累積總長度最高 40 秒。
• 首尾影格：指定起點與終點，讓模型補出中間的運動與轉場。
• 影片參考：可提供短片作為角色、物件或動作條件。
• 360p 草稿：先用較低解析度探索構圖與方向，再決定哪些結果值得往後處理。
• 1080p／4K：把結果放大到較高解析度輸出；官方文件稱兩者都是 upscale。

這些功能未必讓每一格畫面都突然變得更真實，卻改變了失敗成本。創作者不再只能對整支影片說「再來一次」，而能對時間邊界、構圖端點、參考素材與預覽成本分別下決定。這也是本文所說的「開始可被導演」：不是模型已經完全服從，而是人類多了可觀察、可修改的控制面。

---

二、40 秒是延伸鏈，不是一鏡到底生成

Google 發布文對長度的原句是：

“You can extend videos in 10-second increments up to a total cumulative length of 40 seconds.”

中文：「你可以每次延伸 10 秒，累積總長度最高 40 秒。」

— Google，〈Gemini Omni 1.1 Flash lets you build with more control〉

關鍵詞是 cumulative。依照Gemini API 技術指南，原生生成仍是 3 至 10 秒；40 秒來自多輪延伸，而且每一輪讀取前一段影片最後 10 秒作為脈絡。文件也提醒，模型可能改動輸入尾端的部分影格，讓接縫看起來更連續。

所以這不是「一次生成 40 秒」，更不是「額外增加 40 秒」。它比較像把四段局部決策串起來：下一段能看到最近的 10 秒，卻沒有完整 40 秒的全域記憶保證。角色衣著、空間位置、光線、運鏡與敘事因果只要每輪偏一點，誤差就可能沿著延伸鏈累積。Google 宣稱新版本比先前只看最後 1 秒的方式更能維持脈絡；這個歷史比較出自發布方，截至 2026 年 8 月 28 日，本次查核未找到同條件的外部連續延伸實驗可驗證幅度。

---

三、首尾影格很重要，但不是「確定性控制」

首尾影格插值讓使用者把兩個畫面當成時間邊界：第一張定義從哪裡開始，最後一張定義要走到哪裡，中間的動作與鏡頭由模型補完。這比只靠文字描述「最後鏡頭轉向電視」更具體，特別適合 logo reveal、角色進出畫、產品變形或兩個分鏡之間的過場。

但「端點固定」不代表「路徑確定」。模型仍要自己解出人物如何移動、鏡頭如何轉、物體如何保持一致。官方文件沒有把這項功能描述成 deterministic，Gemini Omni Flash 模型卡也把複雜動作、編輯一致性與文字準確度列為仍可能失敗的區域。

影片參考同樣有清楚邊界。API 最多接受三段參考影片，每段最長 3 秒，參考片的音訊會被忽略；官方限制頁甚至直接寫道：

“Referencing or reasoning across multiple videos is not supported.”

中文：「目前不支援跨多段影片進行參照或推理。」

— Gemini API，Gemini Omni 使用指南

這使 Google 發布文裡的多角色參考示範更適合被理解為概念案例，而不是「三段影片可以穩定合成同一場戲」的保證。音訊參考與語音編輯也不在目前支援範圍內；若成片必須配合既有節拍、台詞或口型，聲音仍要當成獨立製作層處理。

---

四、360p 草稿省的是探索成本；4K 是放大輸出

低解析度草稿看似不起眼，卻可能是這次最實用的產品設計。生成影片的浪費常發生在「構圖根本不對，卻先付了最終畫質的成本」。360p 讓使用者先比較鏡位、動作方向與節奏，再把資源放在少數入選片段。

Google 在 8 月 27 日的發布圖表中，把 360p 定價列為每秒 0.03 美元、720p 列為每秒 0.10 美元；「最高快 60%」比較的也是 360p 與 720p 的系統吞吐量，不是與競爭模型的使用者實測延遲。這是一張發布日價格快照，適合用來理解產品定位，不宜當成不會改變的長期報價。

同樣需要拆字看的是 4K。官方規格把 1080p 與 4K 都列為 upscaled，不是原生 4K 取樣。較高輸出解析度可以改善交付格式與邊緣觀感，卻不能自動補回原始生成裡不存在的材質、文字或幾何細節。Google Flow 的新控制功能描述了「先選草稿、再放大」的介面流程；評估其他 API 或第三方入口時，仍要確認它是否保留同一支入選片段，而不是只把相同提示詞重新生成一次。

---

五、外部證據：短片偏好有訊號，長片控制仍未被測到

截至發布前最近一個快照，Arena 的匿名兩兩投票是目前最有用的外部訊號。Text-to-Video 榜在 2026 年 8 月 25 日 18:00 UTC 的 cutoff 中，把 Omni 1.1 列為第 1 名：分數 1514.81、95% 信賴區間 1499.27–1530.35、1,762 票、名次範圍 1–3。前代 Omni 的分數是 1512.39，區間高度重疊，因此這組資料不能證明文字轉影片品質已明顯跳升。

Image-to-Video 榜的差異比較明顯：Omni 1.1 以 1488±11、3,720 票排第 2，前代是 1463±6、排第 5；名義第 1 是 MiniMax H3。Arena 會以匿名別名測試尚未公開的模型，再於發布後揭露名稱，因此 8 月 25 日快照早於 8 月 27 日發布並不構成矛盾。

但 Arena 問的是「兩支短片，你比較喜歡哪支？」它沒有測四輪延伸後角色是否仍一致、尾端影格被改了多少、首尾影格是否精準到位、360p 草稿能否無損升級、4K 是否增加真實細節，也沒有測失敗率、延遲與大量任務的吞吐穩定度。換句話說，外部資料支持的是短片視覺偏好具競爭力，不是 Google 發布文裡所有製作能力都已獨立成立。

---

六、Google 真正想推動的，是從生成模型變成製作環境

發布文把 Adobe、Figma Weave、GMI Cloud 與 Runway 的合作說法放在很顯眼的位置，也列出 Google AI Studio、Enterprise Agent Platform、Flow 與 Gemini app 等入口。這些內容能證明 Google 正把模型接進開發者與創作者工作流，卻仍屬 Google 選擇呈現的第一方示範與合作夥伴證詞，不是獨立的品質稽核。

可對帳的近期命題因此不是「它能不能做出一支漂亮影片」，而是：同一個角色、物件與場景狀態，能否在延伸、首尾影格、參考素材、草稿與高解析度交付之間被保留下來？如果答案逐步變成肯定，影片模型競爭就會從單次生成美感，移向版本管理、素材連續性與可恢復的製作流程。

供應狀態也要分層看。Gemini Developer API 模型目錄把 gemini-omni-1.1-flash列為 Stable／GA；但 Enterprise Agent Platform使用的 gemini-omni-1.1-flash-preview仍是 Preview／Pre-GA。Gemini API 價格頁把它列為 paid tier、Free Tier unavailable；部分上傳影片的編輯與延伸功能在歐洲經濟區、瑞士與英國也有限制。所謂「已上線」是真的，卻不能被壓縮成每個入口、每個地區、每種承諾都完全相同。

---

七、AlphaLab 的判讀

1. 真正的進步是「可修改的狀態」，不是更多像素

一個生成工具能進入專業流程，關鍵不是最佳案例有多驚豔，而是錯誤能否被局部修正。提示詞控制整支影片時，每次失敗都可能迫使使用者重抽；首尾影格、延伸與草稿解析度把一次大賭注拆成多個小決策。這比單純宣布 benchmark 多幾分，更可能降低每秒「可用成片」的成本。

2. 40 秒反而讓一致性問題更容易被看見

局部 10 秒看起來連續，不等於四輪之後仍保持全域一致。當模型只以最近一段作為條件，微小偏差會像複印多次的圖像逐步放大。Gemini Omni 1.1 Flash 讓長片實驗更可行，也同時把評測標準提高：下一輪測試不該只看接縫是否平滑，而要追蹤角色、空間、道具、動作因果與鏡頭語法是否跨輪保存。

3. 4K 是交付選項，不是品質結論

放大可以讓輸出符合播放器、投影或後製管線的尺寸需求，但品質上限仍受原始生成限制。真正有意義的 4K 測試要比較同一個入選片段在放大前後的細線、文字、皮膚、反射與快速運動，而不是拿兩支不同提示或不同隨機結果並排。把 upscale 說成 native 4K，會讓解析度標籤替內容細節背書。

4. GA 是介面承諾，不是電影製作驗收

Stable／GA 說明開發者可以依正式 API 介面與計價規則整合；它不會自動證明每種人物、語言、鏡頭和延伸鏈都可靠。反過來，缺少發布日的完整獨立壓力測試，也不能證明模型不可靠。較誠實的結論是：功能存在、規格可查、短片偏好有外部訊號，但長片連續性、編輯忠實度與高解析度細節仍要等待可重複的公開測試。

我同意的部分：Google 把影片生成從一次性輸出推向可反覆導演的流程，低解析度草稿與時間邊界尤其實用。我存疑的部分：發布文把「studio-quality」與產品控制放在同一個敘事裡，但目前最強的外部資料只覆蓋短片偏好，還不足以替 40 秒連續性、精準控制或原生高細節背書。

---

八、怎麼評估 Gemini Omni 1.1 Flash，才不會被展示片帶著走？

1. 先固定一支母片與角色設定。不要每次換題材；同一角色連續延伸三輪，逐輪記錄臉、服裝、左右位置、光線與道具漂移。
2. 把首尾影格拆成難度階梯。先測小幅運鏡，再測人物轉身、物體交接與遮擋；分別記錄端點命中與中途合理性。
3. 分開算草稿成本與可用成片成本。360p 便宜不等於專案便宜；要把重抽次數、放大後淘汰率和人工修補時間一起計入。
4. 用同一片段驗 720p、1080p、4K。檢查高解析度是否真的改善可用細節，而不只增加檔案尺寸或銳化邊緣。
5. 先核對入口與限制。確認使用的是 Stable Developer API、Preview 企業端點、Flow 還是 Gemini app，並把區域、音訊、參考片長度與吞吐條件寫進測試紀錄。

如果目標是實際建立可重跑的 AI 影片製作流程，可以把這套驗收接到Claude Code AI 影片工作室的六階段流程；如果想比較另一條「延伸＋局部編輯」路線，則可對照Seedance 2.5 可編輯影片工作流。模型名稱會換，但母片、版本、成本與失敗案例的紀錄方式可以留下來。