Kimi K3 來勢洶洶，要扳倒 GPT 與 Claude。它真有那麼強嗎？

Moonshot AI 剛發布 Kimi K3，這是中國有史以來最大的開放權重模型：一個 2.8 兆參數的 Mixture of Experts 模型，配備 100 萬 token 上下文視窗，內建視覺與推理能力，開箱即針對最大化利用率做了最佳化。API 今天上線，權重則要等到 7 月 27 日才會釋出。以下談談有什麼新東西、社群用了一天之後怎麼說，以及一個依照官方提示詞指南做出的示範。

Kimi K3 是什麼

Kimi K3 是 Moonshot AI 的第三代旗艦模型，接續自 2025 年 7 月的 K2、到今年稍早的 K2.6 與 K2.7 Code 的 K2 家族。早在 2026 年 7 月 16 日正式發布之前，K3 就已經透過 Moonshot 自家的 API 平台，以及 LMArena 上代號「Kivine」的隱形上架曝光。《金融時報》先前曾報導，Moonshot 打造 K3 的目的是縮小與 Anthropic Opus 4.8 等封閉前沿模型之間的差距，而發布當天公布的數字，也印證了這個說法。

架構：引擎蓋下改了什麼

K3 是一個 MoE 模型，總參數 2.8 兆，每個 token 從 896 個專家中啟動 16 個。這與 K2.6 的路由形狀有明顯差異，後者是 384 個專家、每個 token 路由 8 個外加 1 個共享專家。不過真正的頭條規格是脈絡：1,048,576 個 token，是 K2.6 256K 視窗的四倍。原生視覺輸入是內建的，而不是後來外掛上去的；推理也預設以 max effort 運行，而非一個可切換的開關。

規格	Kimi K2.6	Kimi K3
總參數量	1 兆	2.8 兆
每個 token 啟動的專家	8 個路由 + 1 個共享（共 384 個）	16 個（共 896 個）
上下文視窗	256K token	1,048,576 token
權重釋出	當天釋出開放權重	API 已上線，完整權重 7 月 27 日前釋出
視覺	MoonViT 編碼器，4 億參數	原生多模態輸入

Moonshot 稱 K3 為「開放」，但權重是分階段釋出的。API 與定價已經上線；可下載的 checkpoint 在真正登上 Hugging Face 之前，都還只是路線圖上的一個日期。

Benchmark，以及那些不能忽略的但書

Kimi K3 已經出現在早期 benchmark 報導的前段班，在程式撰寫、agentic 任務與長脈絡評測上都有亮眼成績。

這裡有一點值得停下來想：K3 在 Artificial Analysis 與 Vals 的標準化智慧指數上仍然未列名，因為它的程式 benchmark 混用了自家的評測框架（DeepSWE、Program Bench、SWE Marathon），與 SWE-Bench Pro 和 LiveCodeBench 只能大致對應。

它在 Arena 前端程式排行榜上的第一名說的是另一個故事：那是真人偏好的兩兩對決，而非標準化評分。所以在技術報告與完整權重釋出之前，整體樣貌都還在成形中。

定價

K3 的價格為每百萬輸入 token 3.00 美元、每百萬快取輸入 token 0.30 美元、每百萬輸出 token 15.00 美元。此託管部署的定價對應 262,144 token 的上下文視窗，而 Moonshot 的完整規格最高支援 1,048,576 token。這與 K2.6 大約輸入 0.95 美元、輸出 4.00 美元的價格結構明顯不同，反映了模型規模的躍升。

社群怎麼說

即使以 Kimi 的標準來看，發布當天也相當熱鬧，事前好幾天 r/LocalLLaMA 與 r/kimi 就被爆料與倒數貼文塞滿。三月底一篇頗具影響力的 Reddit 貼文曾預測 K2.6 會是漸進式更新，而「K3 正在開發中，目標將是追平」前沿封閉模型，這個判斷大致應驗了。

早期實測反應則好壞參半，這在任何重大發布上都很常見。r/kimi 上最早的幾篇詳細心得之一提到：「Kimi K3 很好……但沒有比 Kimi K2.7 好上太多」，同時點出一個在規模化下值得追蹤的問題——額度消耗，指出在持續負載下它「每小時大約吃掉每週額度的 6%」。對跑 agentic 工作負載、而非一次性聊天的團隊來說，這是很有用的參考。

在 LMArena 隱形階段就以「Kivine」代號追蹤 K3 的測試者，也注意到一個熟悉的 K2 特質：在與 Claude Fable 5 的兩兩對決任務中，這個疑似 K3 的版本「追求複雜度與視覺企圖心」，即使對手模型更快給出結果，它仍採取更大膽的路線。團隊在規劃如何把 K3 用在正式環境時，值得先理解這個傾向。

一位開發者的看法

規格表很亮眼，但真正該改變開發方式的數字是上下文視窗，不是參數量。專家數量變多聽起來很戲劇化，但真正關鍵的數字，是從 256K 跳到 1M token 的四倍成長。有了這個上下文額度，開發者不用再切分程式碼庫，不必先摘要文件才餵給模型，也不用單純為了塞進預算而寫檢索邏輯。這是工作流程層級的轉變。

權重分階段釋出這件事，同樣值得留意。過去 Moonshot 給開發者的印象一直是「開放」就等於「當天開放」，但這次 K3 打破了慣例：API 先上線，權重則要等到 7 月 27 日才會到齊。如果自架計畫得靠 K3 才能成立，比較保險的做法是先用託管 API 把開發做起來，7 月 27 日的權重釋出再另外當一個里程碑來確認就好。

最有用的早期訊號不在 benchmark 上：而是早期測試者對額度消耗的抱怨。任何一個在 agentic 使用下、一小時就能燒掉每週額度 6% 的模型，在接近正式生產迴圈之前，都值得先配上專屬的成本監控儀表板。

把 Kimi 模型的提示詞寫好的訣竅

今天的直播就用一個視覺化題目，實際測試了這些習慣：用 K3 一塊一塊重建一個航班追蹤地球儀，全程遵循 Moonshot 官方文件為 K2 系列建議的「逐檔案」節奏。先做幾何結構，接著是帶大氣層與星空的地球，然後依序完成即時資料流、渲染迴圈、互動層，最後再花一輪把五個部分串接起來。重點是：每個檔案都先獨立檢查過，才讓模型動下一個——因為像這樣能力強的 agentic 模型，遇到壞掉的相依關係時，常常會悄悄補過去、而不會主動告訴你。這個習慣，就算示範結束了，也值得繼續保留下去。

這套做法背後的原則，直接來自 Moonshot 自家文件，以及社群在 K2 系列上數個月的測試，而且能乾淨地沿用到 K3，因為兩者共用同樣的指令微調與同樣的 OpenAI 相容介面：dev

• 以目標思考，而非步驟。說清楚目的，讓模型自己選路徑，不要把每一步都寫成劇本。

• 先指定角色，其他之後再說。用「You are a senior [X]」開場，會把模型鎖進更緊實的專家框架，輸出品質明顯變好。

• 用分隔符切開各段落。在脈絡、限制與輸出周圍加上 XML 風格的標籤，能讓模型分別看待每個區塊，而不是把指示混在一起。

• 用正面語氣下指令。「Use named exports」幾乎每次都勝過「don't use default exports」。

• 明確說出交付物。一個檔案、乾淨的格式，不管限制是什麼，都直白說出來。

• system prompt 保持樸素。「You are Kimi, an AI assistant created by Moonshot AI」比精心設計的自訂設定更貼合這個模型的微調。

• 程式生成用 temperature 0.6。這個設定在整個 K2 系列上都是穩定的甜蜜點，在 Moonshot 自家技術報告另有說法之前，也是 K3 合理的起點。

• 把模型當成有自主性的 agent。它能自行串起數百次工具呼叫，所以每個工作階段交給它一個完整目標讓它跑，而不是每一步都去確認。

在 GMI Cloud 上試用

Kimi K3 提供 OpenAI 相容的 API，也就是說，只要團隊已經透過 GMI Cloud 的 serverless 推論在呼叫 LLM 端點，改一行模型名稱就能換成 K3，這也是 GMI 一路以來支援整個 Kimi K2 系列的相同模式。

先到 console.gmicloud.ai 的 playground 零設定跑一段提示詞，接著用 serverless API 做用多少付多少的測試，並在投入專屬部署前，先針對工作負載本身量測 token 用量、延遲與成本