Gemini Omni Flash 是 Google 全新的任意輸入影片模型，可透過聊天進行編輯 — 每秒 0.10 美元、約 10 秒影片。了解它的功能、實際 API 程式碼，以及 Omni 與 Veo 的比較。
大多數 AI 影片模型都只給你一次機會。你寫下提示詞，取得一段影片，如果後半段不對，就得重新開始 — 也得再次付費。Gemini Omni Flash 是 Google 嘗試打破這個循環的成果。你先生成一段影片，接著透過對話持續重新塑造它：替換角色、重新打光、變更攝影機角度，而模型會以上一次編輯為基礎逐步修改，而不是從零開始重新生成。
這是 Google 全新 Gemini Omni 系列中的第一個模型 — Google 稱其為首款「任意到任意」（any-to-any）多模態模型 — 並於 2026 年 7 月 1 日左右進入公開預覽。以下將以淺白易懂的方式說明它是什麼、費用多少、實際該如何呼叫，以及它目前仍有哪些不足。
一句話總結：Gemini Omni Flash 可接受文字、圖片、音訊和影片作為輸入，並輸出具同步音訊的高解析度影片 — 同時允許你透過來回對話編輯這段影片。
最後這句話就是它的完整賣點，因此值得將它與展示影片區分開來。Veo 或 Sora 這類模型，是根據單一提示詞產生一段高品質影片。Omni Flash 則建立在「你的第一段影片只是草稿」這個假設上。Google 的說法是，模型會「推理接下來應該發生什麼」，而不只是繪製像素 — 它依靠 Gemini 的世界知識，以及對「重力、動能和流體動力學等力量的直覺理解」，來判斷場景應如何延續。請將這些視為 Google 的說法，而非獨立研究結果：模型卡將基準測試列為 即將推出，因此目前還沒有人為其推理能力評分。
Omni Flash 要解決的問題並不是「生成更漂亮的影片」，而是編輯成本。在單次生成模型上，每次變更都要重新渲染 — 一段影片已經有 90% 正確，只想要求一個不同的手勢，卻得將整段影片重新生成，並祈禱原本正確的 90% 能保留下來。這既緩慢又昂貴，而且結果不可預測。
Omni Flash 的答案是具狀態的多輪循環。你先生成、檢視，接著說「把背景改成夕陽」或「讓她轉過身」 — 模型會延續先前的場景，而不是重新建構場景。Google 透過讓開發者在每一輪傳入 previous_interaction_id，將這項功能公開給開發者使用，因此編輯可以串接起來。在 Gemini 應用程式內，這種對話式操作介面正是 Veo 和 Sora 沒有提供的功能。
請記住這句話：Omni Flash 與其說是「更好的生成器」，不如說是「編輯層」 — 它在已有基礎影片後才真正變得有趣。
以下是 Google 模型卡和 API 文件中已確認的資訊，只保留真正重要的細節：
解析度是 Google 含糊其辭的一項規格 — 模型卡只寫著「高解析度」，沒有提供像素數字，而企業 API 的高解析度支援則標示為「即將推出」。如果解析度精確值對你的流程很重要，這是需要留意的缺口，而不是可以自行假設的數字。
Gemini Omni Flash 的定價為 每秒影片輸出 0.10 美元。這是 Google 公布的唯一明確數字，而且很清楚：一段 10 秒影片約需支付 1 美元，你可以在不必猜測的情況下估算批次工作的成本。
開發者立即注意到的問題，在於這個費率在 編輯期間究竟代表什麼。一位留言者在該模型的 Product Hunt 頁面上表示，如果你生成一段 20 秒的影片，接著說「讓第二個鏡頭慢一點」，每一輪都會按照完整影片重新計費，還是只會計算與上一個渲染結果的差異？Google 尚未公開說明這一點，而對於對話式模型來說，這正是成本可能悄悄膨脹的地方。我的看法是：在 Google 提供其他文件說明之前，應先按照每一輪編輯都會重新渲染來編列預算。
作為參考，據報這個每秒 0.10 美元的價格與 Veo 3.1 Fast 相同 — 這是 Google 團隊自己提出的比較，不過我會將它歸類為報導內容，而不是已公開的並列測試。
我們正在將 Gemini Omni Flash 加入 GPT Proto，因此你可以使用與目錄中其他模型相同的金鑰和計費方式來呼叫它 — 存取權限目前正在陸續開放。GPT Proto 採用 Google Vertex 風格的請求格式，因此圖片轉影片生成只需發送一個 POST 請求，接著輪詢返回的作業並下載結果。以下是完整的 Python 流程（請將 GPT Proto 控制台中的金鑰替換成你自己的）：
import requests, json, base64, time
BASE = "https://gptproto.com/v1beta/models/gemini-omni-flash-preview:predictLongRunning"
HEADERS = {"x-goog-api-key": "GPTPROTO_API_KEY", "Content-Type": "application/json"}
# 1) Turn a still image into a moving clip
with open("frame.png", "rb") as f:
image_b64 = base64.b64encode(f.read()).decode()
payload = {
"instances": [{
"prompt": "The subject slowly turns to face the camera as warm sunset light fills the room.",
"image": {"mimeType": "image/png", "bytesBase64Encoded": image_b64}
}],
"parameters": {"aspectRatio": "9:16"}
}
op = requests.post(BASE, headers=HEADERS, data=json.dumps(payload)).json()
operation_name = op["name"] # e.g. models/gemini-omni-flash-preview/operations/abc123
# 2) Poll until the render is done
POLL = f"https://api.gptproto.com/v1beta/{operation_name}"
while True:
result = requests.get(POLL, headers=HEADERS).json()
if result.get("done"):
break
time.sleep(10)
# 3) Download the finished video
uri = result["response"]["generateVideoResponse"]["generatedSamples"][0]["video"]["uri"]
video = requests.get(uri, headers=HEADERS)
open("output.mp4", "wb").write(video.content)
print("Saved output.mp4")
或者，也可以使用 cURL 執行相同的第一個步驟：
curl --location 'https://gptproto.com/v1beta/models/gemini-omni-flash-preview:predictLongRunning' \
--header 'x-goog-api-key: GPTPROTO_API_KEY' \
--header 'Content-Type: application/json' \
--data '{
"instances": [{
"prompt": "The subject slowly turns to face the camera as warm sunset light fills the room.",
"image": {"mimeType": "image/png", "bytesBase64Encoded": "BASE64_ENCODED_IMAGE"}
}],
"parameters": {"aspectRatio": "9:16"}
}'
文件中還有幾項實務備註：影片生成是一項長時間執行的作業，因此輪詢步驟不可省略；生成的檔案只會保留幾天，因此請及時下載；錯誤則遵循標準 HTTP 狀態碼 — 金鑰錯誤時為 401，餘額不足或沒有權限時為 403，觸及速率限制時為 429。
Omni Flash 刻意提供較少的可調參數 — API 不支援負面提示詞、temperature、top-p 或系統指令。這會改變你操控模型的方式：
將控制放在提示詞中，而不是參數裡。明確描述動作和物理效果（「大理石快速滾動，連續平滑鏡頭」），不要依賴設定值。不要把所有要求塞進一個超長提示詞裡 — 先生成一段穩固的基礎影片，再透過對話進行精準修改，這才是模型真正針對的工作流程。若要維持角色連續性，請提供參考圖片，而不是用文字描述臉部。也要調整好期待：Google 自己的模型卡承認，複雜動作、完全準確的文字，以及編輯間的完整一致性，仍是較弱的部分，因此同時依賴這三項能力的提示詞最容易令人失望。
這裡真正新穎的功能，是對話式編輯循環。透過與影片聊天來反覆修改，確實比不斷重新輸入提示詞更快，而且這是 Veo 和 Sora 都沒有提供的操作方式。這就是你應該選擇它的理由。
但早期反應一直保持克制，沒有過度炒作，值得如實轉述。社群反覆出現的結論是，Omni Flash 是出色的 編輯器，但只是尚可的 純生成器 — 多位親自測試的人表示，它在重新塑造一段原本就很好的影片時表現亮眼，但從零開始創作原始影片時說服力較弱，物理效果、動作與時間一致性被點名為薄弱環節。這與 Google 自己的承認一致。它也有更嚴格的限制：在 API 中，最長三秒的影片參考「雖然符合結構描述的接受條件，但無法正確處理」；不支援多影片參考；而音訊與語音編輯則在發布時刻意不提供 — Google 表示這是出於深偽風險考量。因此，這是可以一邊試用一邊使用的原型版本，而不是未經測試就直接接入生產環境的產品。
商業方面的反應則較為熱烈：發布資訊提到早期生產採用者（據報包括 Figma 和 WPP），這表示每秒價格的計算已經達到實際創意工作流程的門檻。我會將此視為定價方面的訊號，而非輸出品質方面的訊號。
這是大多數搜尋者真正想問的問題，而共識 — 包括 Google 的看法 — 是兩者互補，而非相互取代。Veo 只在 Gemini 應用程式內被 Omni 取代；開發者仍會透過 API 直接呼叫 Veo 3.1 來處理高保真工作。
| Gemini Omni Flash | Veo 3.1 / 3.1 Fast | |
|---|---|---|
| 最適合 | 對話式編輯、多輸入重新混製 | 高保真單次生成 |
| 輸入 | 文字、圖片、音訊（語音參考）、影片 | 文字、圖片（素材）、影片 |
| 影片長度 | 發布時約 10 秒（Google 稱這是部署選擇） | 4 / 6 / 8 秒，另支援延長 |
| 解析度 | 「高解析度」— 尚未公布公開數字 | 720p / 1080p / 4K（1080p 和 4K 僅支援 8 秒） |
| 原生音訊 | 是，每段影片皆有 | 是 |
| 編輯 | 多輪對話式編輯 | 提示詞／素材、延長 |
| 價格 | 每秒輸出 0.10 美元 | 每秒 0.10 美元（Fast，據報） |
| 浮水印 | SynthID + C2PA | SynthID |
實用原則是：當解析度和乾淨的電影級輸出最重要時，選擇 Veo 3.1；當透過對話變更、細修和重新混製影片更重要時，選擇 Omni Flash。 在許多實際流程中，答案是兩者都用 — 先以更銳利的生成器產生基礎影片，再交給 Omni Flash 進行編輯循環。
如果你的工作高度依賴編輯，就可以考慮 Omni Flash：例如 VFX 風格的調整、虛擬人物和基於參考圖的轉換，或任何需要多次反覆修改影片的工作。如果你今天就需要有保證的高解析度、長於約 10 秒的單段影片、可靠的影片參考輸入，或任何音訊／語音編輯功能，則應該先等待 — 這些功能不是尚未明確說明，就是受到限制，或在發布時被關閉。
準備好用它來建構了嗎？立即取得金鑰，並在 GPT Proto上瀏覽即時目錄 — Gemini Omni Flash 的存取權限目前正陸續開放。
TL;DR — 在相同解析度下，Seedance 2.0 Mini 在 GPTProto 上的成本比標準版 Seedance 2.0 低約 20% — 並不是大多數比較頁面所說的「半價」。更大的節省來自一項硬性限制：Mini 最高只支援 720p，因此完全跳過昂貴的 1080p 和 4K 等級。當你需要快速、大量反覆迭代，以及短影音社群片段時，請選擇 Mini。當你需要 1080p 或 4K、更複雜的動態，或要交付給客戶的最終剪輯時，請選擇標準版 Seedance 2.0。真正划算的做法是同時使用兩者：用 Mini 起草，再用標準版完成。本指南接下來將介紹 Seedance 2.0 Mini 及其完整版同系列模型，並展示這些選擇背後的實際數據。
Tiffany Layne | 2026-06-30
這週我刷新 ByteDance 的 Seed 頁面，等待 Seedance 2.5 出現的次數已經多到有點不好意思了。到目前為止，什麼都沒有。沒有模型頁面、沒有規格表，也沒有日期。這正是這篇文章存在的原因：目前流傳著大量關於 Seedance 2.5 的自信說法，其中大多數都把猜測當成事實。我想清楚區分兩者，然後告訴你今天實際可以執行什麼。
Tiffany Layne | 2026-06-23
搜尋「wan 2.7」，你會得到兩個不可能同時為真的答案。一些指南告訴你下載權重並在自己的 GPU 上執行；另一些則說只能透過 API 使用。我開始查找哪一個才是正確的，因為答案決定了你是否能自行託管這個模型——簡短結論是，多數信誓旦旦宣稱「它是開源的」的文章，只是在重複一種慣例，而非事實。以下說明 Wan 2.7 的真實面貌、Alibaba 已經與尚未發布的內容，以及今天如何將 Wan 模型投入生產環境。
Schuyler Stacy | 2026-06-24
Kling 3.0 Motion Control animates a static character image with the movement from a reference video. You give it two inputs — a picture of your character and a video of someone moving — and it returns a new clip where your character performs that exact choreography while keeping their own face, outfit, and look. This is motion transfer, not text-to-motion. Instead of describing an action in a prompt and hoping the model interprets it, you show it the action frame by frame. That makes it far more reliable for repeatable character animation, dance, and gesture work. This guide covers both paths: the Kling web app for one-off clips, and the GPTProto API for wiring Motion Control into a pipeline. We'll cover inputs and limits, the `pro` vs `std` tiers, prompt technique, full runnable code, pricing, and the failure modes worth knowing before you spend credits.
Michael Johnson | 2026-06-30
