
Meta Muse Image:模型、API,以及每張均一價 $0.01 的圖像
- typesafe新TypeSafe: Jev 1.132026-09-24$0.04 / $0.00 每百萬 tokens · 1008 tok/s
- OpenAI新OpenAI: GPT-6 Luna2026-09-2237智能
- OpenAI新OpenAI: GPT-6 Sol2026-09-2248智能
- Anthropic新Anthropic: Claude Opus 5.52026-09-2258智能
- xAI新Grok 4.72026-09-2146智能
- Orca新Orca: OrcaCyber Zero 1.02026-09-17$3.00 / $5.00 每百萬 tokens · 194 tok/s
- Orca新Orca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 每百萬 tokens · 1189 tok/s
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-09-1040智能
- OpenAIOpenAI: GPT-6 Astra2026-09-0453智能77程式
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241智能76程式
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245智能76程式
- AnthropicAnthropic: Claude Fable 5.12026-09-0153智能82程式
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 每百萬 tokens · 22 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 每百萬 tokens · 107 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642智能72程式
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 每百萬 tokens · 220 tok/s
- z-aiZ.ai: GLM 5.32026-08-1845智能75程式
- obsidianQwen3.8 27B2026-08-1534智能68程式
- DeepSeekDeepSeek: DeepSeek V4 Pro 08132026-08-1236智能69程式
- xAISpaceXAI: Grok 4.62026-08-1244智能77程式
如果你搜尋的是這個消歧義後的名稱而來到這裡,簡短答案是:Meta Muse Image 是 Meta 的代理式圖像生成與編輯模型,屬於專有而非開放權重,你要透過 Meta 自家的 Model API,使用識別碼 muse-image-1.0 來呼叫它,固定價格為 每張生成圖像 $0.01,且該價格已包含搜尋接地(search grounding)。這就是這則搜尋所問問題的完整答案,以下全部都是相關參考資料——這個模型能做什麼、如何存取它、計費單位究竟是什麼、Meta 對來源出處的文件說明了什麼,以及文件在哪裡止步。
關於本頁的存頁理據,有兩點值得直說,因為這個家族已經被發布不只一次,再寫一篇發布文只會與我們既有的報導重複。這裡是該名稱的標準參考頁:讀者搜尋該名稱後所抵達的目的地。其存頁理據是我們於 2026 年 9 月 29 日以第一方資料測得的持續需求——讀者以三種拼法輸入此名稱的消歧義形式,曝光次數達數百次,而我們之所以占有那個位置,是因為其他頁面的偶然因素,並非因為我們寫過一篇長得像這樣的頁面;而它的轉換率幾乎為零,因為我們所發布的內容沒有任何一篇長得像參考頁。那項測量只是關於人們輸入什麼的事實,僅此而已;它完全不涉及該模型在世界上的品質或受歡迎程度。至於可標定日期的錨點,在此是用來標定該模型日期的事實,而非用來報導的事件:Meta 為 Muse Image 與 Muse Video 發布的上市貼文標註日期為 2026 年 7 月 7 日,並描述該模型於當日在 Meta 的消費者端產品介面「今日起提供」,因此 2026 年 7 月 7 日就是本頁所依據的上市日期。除句中另有說明外,以下每一項數字均於 2026 年 9 月 29 日讀取自 Meta 自家的頁面。
Muse Image 究竟是什麼
Meta 自己的一句描述就是起點,因為它確實在發揮作用,而不只是行銷話術:Muse Image 是「一種由搜尋提供依據的代理式圖像生成,並針對生產量定價為每張 0.01 美元」。在 Meta 的模型頁面上,能力面向被拆解為四種工作模式——圖像生成、精準編輯、錨定構圖,以及多輪精修——而開發者文件則把同樣的內容濃縮成一句話:「Muse Image 能從對話中生成並編輯圖像。」
最與眾不同的主張,用 Meta 的話來說,就是 Muse Image「是一款在渲染前先進行推理的圖像模型」。Meta 的發布文章把這點說得具體而非只是概念:「Muse Image 不是直接把提示詞映射成圖像,而是像代理一樣運作:它會呼叫搜尋與程式編寫工具來提升準確度、自我精煉自身生成的結果,並透過擴展測試時運算來改進。」實際上,這意味著模型在開始繪製前會先規劃,當提示詞涉及現實世界的事實時,會從網路上取得即時參考資料,而在講求精確度的情況下——也就是 Meta 所描述用來製作精準圖表和 QR 碼的途徑——會撰寫並執行程式碼,然後在回傳結果前先檢查一遍。
Meta 最先點名的三項能力,就是評估它時該看的重點,而這三項能力就寫在 Meta 自己的句子裡:Muse Image「忠實遵循指令、精準編輯,並能從多個參考來源進行構圖。」在三者之中,編輯這項宣稱最為犀利,因為它宣稱的是克制,而非輸出:Meta 的模型頁面說,該模型「旨在只改變你指定的內容,其餘一切保持不變」,並支援跨多輪的迭代精修,而非一次性的編輯。構圖則是「錨定構圖」(anchored composition)模式所在之處——把「一整系列生成結果錨定在一小組參考圖像上,讓角色、風格與場景從一張圖到下一張圖保持一致」,如果你產出的是型錄或廣告組合,而不是單張圖片,這正是關鍵能力。綜合來看,這些宣稱區分了「你會拿來生成圖像的模型」與「你會在其上建立管線的模型」,而它們都是廠商宣稱:Meta 並未針對這個模型發布任何關於指令遵循或編輯保真度的獨立基準。
代理式框架不僅關乎工具。Meta 在文件中說明 Muse Image 會與Muse Spark(其推理模型)搭配,使「這兩個模型能共享工具,並共同規劃以實現強大的代理式媒體生成」——文件中記載的範例是多重部分輸出,例如動畫 GIF、內嵌圖片的頁面,以及小型互動遊戲。如果你正在建構任何混合生成圖像與生成文字或程式碼的東西,這種搭配是設計中值得理解的部分,也是該模型與 Muse Spark 以相同 API 與相同驗證機制提供服務,而非使用具有自身憑證的獨立圖像端點的原因。
你怎麼稱呼它:API 表面
Muse Image is reached through Meta's Model API, and the developer documentation is specific about the shape of that call. The model identifier is muse-image-1.0, passed as the model field on every request. Requests go to the base URL https://api.meta.ai/v1 with a bearer token — the documentation notes that it uses the same base URL and auth as Muse Spark — and there are two image endpoints plus a conversational one:
• 生成 — POST /v1/images/generations,輸入文字提示詞,輸出圖片。
• 編輯 — POST /v1/images/edits,提示詞加上輸入圖片,用於圖像到圖像的工作。
• 跨回合精進 — POST /v1/responses,也就是 Responses API,這正是文件所述多輪流程的運作方式。
在 images 端點上,有文件記載的參數不多,且值得牢記,因為成本與輸出格式正是由它們決定。n 接受 1 到 10,預設為 1。size 接受 "WxH" 格式字串,例如 1792x1024,而文件明確指出,在這些端點上它「僅設定長寬比,而非確切像素」——不要把它解讀為解析度保證。response_format 預設為 b64_json,或 url,而 output_format 預設為 webp,可選用 png 與 jpeg。代理式行為可切換:images 端點接受一個 tool_enablement 擴充功能,涵蓋 enable_image_search、enable_web_search 與 enable_shell,以及一個 reasoning_strength 為 high(預設)或 low。調低推理強度是控制成本與延遲的手段,而且這是你應該用自己的提示詞進行 A/B 測試、而不是盲目相信的第一件事。
在 Responses API 上,同樣的控制項位於 image_generation 工具物件內,該工具物件位於 tools 中,且預設啟用圖片搜尋、網頁搜尋與 shell,而輸出陣列會以固定順序傳回:一個推理項目,概述模型規劃與查詢的內容;一個訊息項目;接著一個 image_generation_call 項目(每張圖片一個)。圖片本身位於該項目的 result 欄位中,以 base64 表示,而其 id 文件記載為已簽章的控制代碼,你可將其傳回,以在後續回合繼續編輯同一張圖片。該控制代碼就是多回合精修的機制——它能讓你避免重新上傳圖片只為變更其中一個細節。兩個圖片端點也都接受 stream: true,會發出 image_generation.completed(用於生成),以及 image_edit.completed(用於編輯)。Model API 文件記載為可直接替換相容於 OpenAI SDK、Anthropic SDK 及 OpenAI 相容的代理 CLI,因此既有的圖片呼叫只需變更模型字串,而不必重寫。
有一點注意事項應該放在參考資料裡,而不是放在註腳中:Meta 並未公布我們能查閱到的 Muse Image 速率限制。Meta 自家開發者網站上的速率限制頁面只回傳了一個沒有任何數據的空殼,就跟定價頁面一樣。如果你的設計重視吞吐量,那會是你得從 API 而不是從文件得知的未知數。

價格,以及其計價的單位
每張圖片 1 美分。這個數字取自 Meta 自家的 Muse Image 模型頁面,該頁面的定價表列出了這款模型,並將搜尋接地與推理皆標示為已包含,價格則列為$0.01/image;開發者文件也重申:「Muse Image 以每張生成圖片固定 0.01 美元計費。」計價單位是圖片,而不是 token——文件直接這麼說(「Muse Image 並非以 token 計價」)——這點很重要,因為以 token 回報用量的圖片 API,通常也以 token 計費。Muse Image 會回傳包含輸入與輸出 token 數量的 usage 區塊,而這些數字僅供參考。
這三項計費細節都源自這個單位。第一,n 是乘數:一次要求回傳十張圖片,就會按十張圖片計費,因此 1–10 這個參數既是一項支出控制,也同樣是便利功能。第二,失敗不計費——未能生成,或在回傳前被安全篩選移除的圖片,都不會計入。第三,搜尋接地包含在每張圖片的價格內,而不是另立一個收費項目;Meta 的文件指出,它是「每張圖片價格的一部分,因此不會另外收取搜尋接地費用」。最後這一點,正是讓這個費率對代理式工作具有意義的關鍵:一個在渲染前會搜尋網路的模型,可能在單一輸出背後產生多次工具呼叫,而 Meta 表示,這些工具呼叫不會與圖片分開計費。
我們無法從費率卡佐證這個數字,而這點值得說明,不該略過。我們抓取的 Meta 開發者網域下每一個定價 URL,傳回的都是不含任何美元金額的頁面外殼,因此這個數字以可讀陳述形式存在的地方,就只有模型頁面與圖像生成文件這兩處。如果你需要第二個來源以供採購之用,Meta 的網站上目前並沒有。

實際上,一分錢買到的與其說是折扣,不如說是決策的改變。Meta 在模型頁面上的官方說法是,該模型「讓你執行先前因前沿定價而無法觸及的工作負載」——廣告變體生成、目錄圖像,以及每位使用者個人化——而按此費率,十萬張圖片的標價約為 $1,000。如果你正在把這個費率和你可能已在付費使用的高階圖像模型相互衡量,有用的做法是用你自己的提示詞和你自己的評估,把兩者都跑一遍,而每張圖片一分錢,正是讓這項比較便宜到真正值得去做的原因。
溯源:Content Seal 能解決什麼、不能解決什麼
Meta 隨這款模型推出了不可見的浮水印系統,並將其記錄得足夠精確,值得引用:「Muse Image 包含 Content Seal,也就是我們的不可見浮水印系統。在 Meta AI 應用程式與 meta.ai 上由 Muse Image 建立的影像,都會帶有一道隱藏的來源訊號,且這道訊號會保持完整——即使經過裁切、壓縮、調整大小或螢幕截圖也一樣。」Meta 表示,計劃將 Content Seal 擴展到影片,並預告一款偵測工具,可讓你檢查某張影像是否帶有該標記。
請仔細閱讀那句話的適用範圍,因為它比乍看之下更狹隘。來源出處訊號被描述為是由在 Meta AI 應用程式和 meta.ai 上建立的圖片所帶——也就是消費者端介面——而 Meta 的模型頁面和 API 文件,對於透過 Model API 生成的圖片是否帶有相同標記則隻字未提。我們兩邊都找不到任何明確說法,因此請把 Content Seal 視為消費者端的來源出處功能,在你親自測試過自己帳號的輸出之前,不要假設它會跟著 API 生成的檔案一起出現。另外,我們所報導過唯一一次針對該偵測器的測試來自路透社,該測試發現偵測器在圖片經過裁切後,無法驗證大多數帶有浮水印的圖片;那項發現及其數據刊載在我們針對這個模型的解說文章中,若想了解來源出處的論點,該讀的是那篇文章,而不是這一篇。
運行位置
Meta 自家的可用性聲明,摘自發布貼文:Muse Image「即日起可在 Meta AI 應用程式和 meta.ai 上使用,美國的 Instagram 限時動態,以及特定國家/地區的 WhatsApp 也可使用,並即將在 Facebook 推出。」這些都是 Meta 的說法,而這些平台都是 Meta 自家的產品——它們全都沒有候補名單、沒有邀請碼,也沒有另外的註冊程序。在開發者方面,該模型是透過 Model API 提供服務,上方提及的識別碼與端點就是為此而設。Meta 的模型頁面也把第三方推論平台列為執行該模型的方式之一;我們在此不具名提及這些平台,而本頁面任何內容都不應被解讀為針對 Meta 自家 API 以外任何平台的條款或費率所做出的主張。
Meta 尚未公布 Muse Image 登上 Model API 的日期,而 Meta 的開發者文件也未載明任何日期。本頁唯一能依據的日期,是模型本身的發布日期,2026 年 7 月 7 日,這是由 Meta 自家公告貼文的日期欄所確立。如果你要標註的是 API 介面的日期,而不是模型的日期,那就照 Meta 的說法:什麼都沒有。
開放權重還是專有?專有——而該系列兩者都有
這是讀者在這個系列中最常答錯的問題,因此值得直接回答。Muse Image 是專有模型。Meta 的開發者文件明確劃出界線:你透過 Model API 呼叫的模型——Muse Spark、Muse Image、Muse Voice Transcribe 和 SAM——是由 Meta 提供服務的,而「Muse Glimmer 走的是不同的路徑:你下載開放權重,在自己的硬體上執行它,而不是透過 Model API 呼叫它」,採用寬鬆的 Apache 2.0 授權。Muse Glimmer 是這個系列中的開放權重路線,而它是不同的模型:一個從 Muse Spark 蒸餾而来的多模態模型,並非 Muse Image 的開放版本。Meta 的 Muse Image 頁面上沒有任何地方載明授權條款或提供權重,因為根本沒有權重可提供。如果自我託管是硬性要求,Muse Glimmer 才是該評估的模型;如果你想要這裡所述的圖像模型,你就得呼叫 Meta 的 API,並按每張圖片付費。

Meta 聲稱其排名為何,標示為 Meta 的說法
Meta 的發布貼文寫道:「截至撰稿時,根據人類偏好 Elo 排名,Muse Image 在 Arena 的文字轉圖像、單圖編輯與多圖編輯項目中位居第二。」這句話有兩點值得注意,而兩者都出自 Meta 自己的措辭。這是由廠商自行提報的排名,而非獨立評分,而且這是人類偏好 Elo的成績,而非在固定測試框架上取得的基準測試結果——當前兩名之間的差距小於一項基於有限票數建立的 Elo 評分誤差範圍時,這項區別就會帶來實質差異。Meta 隨該說法發布的圖表標註日期為「2026 年 7 月 5 日」,而該說法本身也加上了「截至撰稿時」的限定,因此這是一名與其有利害關係的當事人所引述的即時排行榜快照,而非已成定局的排名。
同一篇貼文還附上一張由 Meta 主動為你標註說明的規模化圖表:那張顯示品質隨推理能力上升的圖,圖說寫的是「Elo from internal ablation」。那是廠商內部的量測數據,無法與第三方排行榜相提並論。Meta 的論點是:品質會隨測試時運算量提升,且呈近似對數線性的關係,而推理與工具使用一旦結合便會相互加乘——這是一項內部消融實驗,而他們也確實如此標明。
這個模型在非 Meta 的榜單上也有獨立排名,而我們已經報導過這些排名:我們的解說文章收錄了 Artificial Analysis 圖像榜單與競技場排名及其數字,而兩個對戰頁面則把這些數字與點名的競爭對手並列。如果你想看的是獨立的情況,而非廠商自家的說法,就該去那裡讀。本頁不會重印那些數字,而且其中一項無論如何都得仔細解讀,因為 Artificial Analysis 只為提供可呼叫 API 的圖像模型排名——因此 Muse Image 的獨立排名講的是 Model API,而不是 Meta AI 應用程式。
說明文件未回答的內容
參考頁面唯有指出記錄到哪裡為止,才有用處,因此以下是我們在 2026 年 9 月 29 日無法從 Meta 確認的事項。Muse Image 沒有已公布的速率限制。沒有已公布的延遲特性、沒有成功率,也沒有在生產流量下對代理迴圈進行的獨立評估——每張圖片的價格有文件記載,但營運範圍則無。沒有任何獨立第三方對指令遵循或編輯保真度提供基準測試,而 Meta 本身也未公布這類數字;Meta 模型頁面上的基準測試圖表沒有可讀的數字。沒有授權聲明,因為該模型未獲授權下載。而 Muse Image 在 Model API 上開始可供呼叫的日期,在 Meta 的文件中任何地方都沒有說明。這些闕漏都不是避開該模型的理由——一張一分錢、內含搜尋接地的圖片,光憑這點就值得測試——但每一項都是在管線依賴它之前,應先測量而非假設的理由。
對開發者的裁決
Meta Muse Image 值得評估,如果你的問題在於量體:目錄圖像、廣告變體、逐使用者個人化,任何過去因為前沿每張圖價格而導致專案夭折的情境。單價是有文件的,單位明確無歧義,失敗不計費,而搜尋接地包含在費率之內而非另行計費——這在市場上罕見到足以成為頭條。但它不值得盲目採用,因為價格以外的一切——吞吐量、延遲、代理迴圈在你提示詞上收束的可靠程度、來源訊號是否隨 API 輸出傳遞——都缺乏文件記載,而廠商自家的排名主張,是在某個時間點引述的人類偏好排名,而非實測結果。此處決策的誠實樣貌,是針對你目前已在使用的圖像模型,用你自己的提示詞,做一場一美分的實驗,背後有便宜的失敗模式與經過驗證的備援方案。至於這個模型是什麼、如何呼叫、成本多少,本頁即是參考;至於它該不該進入你的技術堆疊,只有你自己產生的數字才算數。
