Kimi K3 Open Weights 來了，Benchmark 階段正式開始

Kimi K3 原本就是七月最受矚目的模型發布之一。隨著 open weights 進入生態系，開發者現在可以跨不同工作負載、服務堆疊與 agent 架構來評估它的表現。

Moonshot 將 K3 定位為一個 2.8 兆參數的 Mixture-of-Experts 模型，擁有 896 個 expert、每個 token 啟用 16 個 expert，原生支援多模態輸入，並具備 1,048,576 token 的上下文視窗。這些規格為程式撰寫、研究、知識工作與長時程 agent 工作流程開出了實質的可能性。

我們的 API 實測

過去這幾天，我們透過 API 針對推理、創意、程式撰寫、多模態與 agentic 工作流程測試了 Kimi K3。

最突出的結果，是它維持長時間作業的能力。在數次測試中，K3 連續工作三到四個小時，在需要規劃、迭代、工具使用與結構化交接的多步驟任務中持續推進。

K3 在擔任 sub-agent 的協調者時同樣表現強勁。它擅長把一個較大的目標拆解成獨立的工作流、指派專門任務、審查回傳的成果，並判斷哪些需要再跑一輪。對於正在打造 coding agent、研究系統，以及那些由主 agent 協調多個工具或 sub-agent 的營運工作流程的團隊來說，這讓它成為一個值得注意的模型。

它的推理風格特別適合開放式的工作。面對探索性的 prompt、多條替代解法路徑與創意問題解決，K3 在漫長的任務時程中都保持了很好的連貫性。

實用的多模態組合

K3 在文字之外原生支援視覺理解，並為軟體工程、知識工作與深度推理情境提供 1M token 的上下文視窗。

在多模態測試中，我們發現一種「雙模型」工作流程特別好用：以 K3 作為長時程推理與協調層，再在 agent 迴圈中加入 Google Gemini 的影像模型作為視覺審查者。

舉例來說，agent 可以請 K3 規劃任務、產生實作，並評估預期的視覺結果。接著由 Gemini 檢視算繪出的圖片、UI 截圖、圖表或設計成品，把視覺回饋送回 K3，K3 再修正計畫或實作並繼續推進。

這種做法把多模態工作變成一個回饋迴路：

1. K3 負責規劃、推理、撰寫並協調任務。

2. Gemini 影像模型評估視覺輸出。

3. K3 吸收回饋，決定下一步動作。

4. agent 反覆執行，直到輸出符合既定標準。

GMI Cloud 的模型庫是按模態組織的，因此可以把語言、推理、視覺、影像、音訊、影片與 3D 模型組合成最貼合任務的工作流程。

讓 K3 遊戲成品變好的視覺 Agent 迴圈

Kimi K3 負責遊戲邏輯、程式撰寫與迭代規劃，視覺層則交由專門的影像與視覺模型補上。在這個工作流程中，K3 先向 Gemini 或 GPT Image 索取材質、套用到每個場景元素上，再把多個角度的截圖送給視覺模型審查。這些回饋點出了打光、比例與材質品質上的問題，K3 便以此作為下一輪迭代的指示。

這個迴圈重複約 80 次後，把一開始平淡的原型變成了更精緻的策略遊戲環境，也展示了 K3 在搭配合適視覺模型時，如何協調長時間的創意工作流程。GMI Cloud 透過單一 API 同時提供 K3、Gemini 影像模型與 GPT Image 模型，讓開發者不必分別管理多家供應商，就能打造這種能自我改進的多模型迴圈。

Open Weights 讓評估的範圍更廣

K3 的 open-weight 釋出，讓團隊能評估的不只是模型的回答——開發者還可以探索，它在自家 prompt、agent 框架、推論組態與延遲需求下的實際表現。

這開出了幾條實用的路徑：

• 可重現的測試：跨模型套用一致的 prompt、tool 定義與評測 harness。

• Agent 架構實驗：在同一份工作負載上比較單 agent、supervisor agent 與多 agent 設計。

• 服務端評估：用團隊實際打算採用的堆疊，量測吞吐量、並行數、首個 token 時間與輸出品質。

• 部署彈性：依使用率、治理需求與營運目標，選擇託管推論、專屬端點或自管運算資源。

Model card 與公開 benchmark 是不錯的起點，但最有價值的評估，永遠是模型在你團隊真正想自動化的那些工作上的表現。

官方的 Kimi K3 權重與模型資料已公開於 Hugging Face，開發者可直接檢視此次釋出的內容並評估自架部署。

2.8T 的架構

K3 採用 Mixture-of-Experts 架構，不會為每個 token 都啟用全部 2.8 兆參數。Moonshot 表示 K3 擁有 896 個 expert，每個 token 啟用 16 個，以稀疏推論實現前沿等級的容量。

1M token 的上下文視窗，讓開發者在大型程式庫、長篇研究文件或漫長的任務歷史中，有更多操作空間。不過團隊仍應針對自家應用真正在意的上下文長度、並行程度與回應時間，實際做 benchmark。

開發者該測什麼

最好的 K3 評估，是紮根在真實工作上的。

先從一組聚焦的 benchmark 套件開始：

1. 程式庫任務：給 K3 一個 issue、驗收標準與測試指令，量測它的實作能否通過測試。

2. 長時間執行的 agent：測試一個有明確成功條件、工具存取、檢查點與人工審查的有界多小時工作流程。

3. Sub-agent 協調：給 supervisor agent 多個分別負責研究、實作、審查或測試的專門 agent，追蹤協調品質、重試次數與完成率。

4. 長上下文檢索：使用一個程式庫或文件集，量測證據品質、限制條件的追蹤與一致性。

5. 多模態回饋迴路：把 K3 與視覺模型搭配，評估截圖、設計成品、生成圖片、圖表或 UI 狀態。

6. 結構化輸出：針對直接串接下游系統的工作流程，測試 JSON 擷取、function calling 與 schema 遵循度。

先從託管推論開始

Open weights 帶來更多選擇，也讓團隊有機會先開始評估一個前沿模型，而不必等到自己能營運一整批 GPU 機隊。

當團隊有以下需求時，託管推論是很好的起點：

• 快速展開測試

• 在同一個工作流程中試用多個模型

• 應付變動流量而不必做容量規劃

• 沿用既有的 OpenAI SDK 寫法

• 把工程時間投入在產品與 agent 邏輯上

GMI Cloud 提供與 OpenAI 相容的推論 API，讓開發者沿用熟悉的 chat-completions 模式，同時取用廣泛的模型目錄。

from openai import OpenAI

client = OpenAI(
base_url="https://api.gmi-serving.com/v1",
api_key="YOUR_GMI_API_KEY",
)

response = client.chat.completions.create(
model="moonshotai/kimi-k3",
messages=[
{
"role": "user",
"content": "Plan a multi-agent workflow for reviewing a pull request."
}
],
)
print(response.choices[0].message.content)

隨著工作負載成熟，若團隊需要更專門的容量或掌控權，GMI Cloud 也支援專屬端點與 GPU 基礎設施。

用成果來衡量

K3 的價值來自完成的工作：一個被解掉的 issue、一個通過測試的 pull request、一個查證過的答案、一份審查過的成品，或一個真正達成目標的 agent 工作流程。

值得追蹤的指標：

• 完成率

• 每個成功任務所耗的 token

• 首個 token 時間與總任務時長

• agent 迭代次數

• sub-agent 的協調品質

• 工具呼叫與重試模式

• 每個成功成果的成本

• 人工審查時間

一個能以更少重試、更強協調與更少人為介入完成複雜任務的模型，創造的價值可能遠高於只用 token 價格評斷的模型。

為工作流程而打造

Kimi K3 擴大了開發者能用 open-weight 模型測試的範圍。我們早期的 API 實測顯示，它最深厚的實力展現在推理密集、創意導向、長時間執行與多 agent 的工作流程上。

對開發者來說，路徑很清楚：

• 拿真實任務測試 K3

• 把它當成長時程推理與協調層

• 在視覺回饋能強化流程之處，搭配專門模型

• 量測品質、延遲、吞吐量與每個完成任務的成本

• 先從託管推論起步，等需求變得可預測後再演進基礎設施

在 GMI Cloud 上試用 Kimi K3

Kimi K3 已可透過 GMI Cloud 與 OpenAI 相容的 API 使用，因此已經在用 GMI serverless 推論呼叫 LLM 的團隊，只要更換 model ID 就能開始測試。先在 GMI Cloud Playground 免設定跑 prompt，再轉往 serverless API 進行用多少付多少的測試。

想自架？可以參考官方的 Kimi K3 Hugging Face repository。