AI 知識

Kimi K3 的三個系統設計

AI 知識｜Kimi K3｜2026-07-30

Kimi K3 的完整權重已經公開。它有 2.8 兆總參數、每次推論啟用約 1,040 億參數，並支援 100 萬 token context。

這些數字很適合成為標題，卻也帶來最現實的問題：即使權重可以下載，多數開發者也沒有足夠的 GPU、記憶體、網路與儲存設備把完整模型跑起來。

如果只把「open weight」理解成下載模型檔案，這次開放對一般人似乎離得很遠。

但 Kimi K3 同時公開了一份 47 頁的技術報告，以及 KDA kernel、expert parallelism、agent sandbox 等相關基礎設施設計。這些內容揭露的不是另一張跑分表，而是超大型模型如何處理三個難題：

  1. 長上下文如何避免記憶體持續膨脹？
  2. 近 900 個 experts 如何避免 GPU 負載不均？
  3. 長任務 agent 等待推論時，如何停止沙箱空轉？

這三個問題不只屬於 Kimi K3。任何想讓 AI 執行更長任務、使用更多工具、處理更大 context 的系統，最後都會碰到相似的工程限制。

第一個設計：把長上下文從「一直累積」改成「持續更新狀態」

標準 Transformer 的 attention 需要保留歷史 token 的 key-value cache。序列越長，cache 通常也越大。

當 context 從幾萬 token 擴張到 100 萬 token，問題不只是模型能不能讀，而是記憶體、資料搬移與跨裝置通訊能不能承受。

Kimi K3 採用混合式注意力架構：93 個 attention layers 中，有 69 層 Kimi Delta Attention，也有 24 層 Gated MLA。

KDA 的核心方向，是以固定大小的 recurrent state 持續濃縮過去資訊。新 token 進來時，模型更新 state，而不是把所有歷史都當成會持續成長的 cache。

這不代表 Kimi K3 完全沒有 KV cache。它仍保留部分全域注意力層，因此部署端需要同時管理 KDA recurrent state 與 MLA KV cache。真正的工程價值，是把多數長序列計算從「資料量跟序列長度一起長」改成「維護固定大小狀態」。

為什麼 FlashKDA 選擇 16-token chunks

Recurrent state 對長序列比較節省，但 GPU 喜歡大量平行、形狀規則的運算。序列相依與 GPU 平行運算之間，本來就有張力。

FlashKDA 把計算切成 16-token chunks，並將不同平行特性的工作拆成兩個 kernels。

官方 deep dive 列出三個選擇 chunk size 16 的原因：

  • Gate 設定下的數值範圍適合 BF16。
  • 16 x 16 matrix inversion 比 64 x 64 便宜。
  • 計算能更直接對應現代 NVIDIA GPU 的 MMA instructions。

早期單一 fused kernel 會讓 token-parallel 工作被 recurrent propagation 的較低平行度拖慢。拆成兩個 kernels 後，官方內部測試得到至少 15% end-to-end speedup。

這個案例的知識點不是「所有模型都該使用 16」。而是模型架構不能只在數學上成立，還要依實際硬體的精度、記憶體與平行方式共同設計。

第二個設計：MoE 最大的敵人，不一定是算力不足，而是工作分配不均

Kimi K3 是 Mixture-of-Experts 模型。每層有 896 個 routed experts，但每個 token 只選其中 16 個。

MoE 的直覺很吸引人：模型可以擁有非常大的總容量，每次卻不必啟用全部參數。

問題是 token 不會平均選擇所有 experts。

如果大量 token 都被路由到少數熱門 experts，持有這些 experts 的 GPU rank 就會變成瓶頸。其他 ranks 即使先算完，也必須等待最慢的一個。

更麻煩的是，每個 iteration 的 token 分布會改變。動態 tensor shapes 可能造成 GPU 記憶體碎片，甚至在 routing imbalance 高時發生 OOM。

MoonEP 如何處理熱門 experts

MoonEP 使用 dynamic redundant experts。當 planner 發現某個 expert 太熱門，可以把它預取到額外 slot，讓其他 rank 分攤工作。

每個 rank 最後固定處理 S x K tokens，讓 computation shape 維持靜態。

這個方法的重點不是盲目複製所有 experts，而是只為會形成瓶頸的熱門 experts 建立有限冗餘，並把 token 直接送到最終位置，減少額外記憶體複製。

官方 benchmark 顯示，在 routing imbalance 增加時，MoonEP 的 iteration time 維持較平穩，並降低動態 shape 帶來的記憶體問題。

這些結果不能直接保證任何硬體、任何模型都不會 OOM，但它揭露一個通用原則：分散式 AI 系統的速度，常由最慢的 rank 決定，而不是由所有 GPU 的平均算力決定。

第三個設計：模型推論時，執行沙箱不該一直付租金

Agentic reinforcement learning 需要大量獨立 sandbox。

Agent 可能在 sandbox 裡啟動程式、執行測試、讀寫檔案，再把結果交回模型決定下一步。當模型正在推論，sandbox 通常沒有工作，卻仍可能占著 CPU 與記憶體。

Kimi K3 報告介紹的 AgentENV，以 Firecracker microVM 提供隔離環境，並把 sandbox life cycle 變成可以管理的資源。

它提供幾個重要操作：

  • Pause：暫停 sandbox，釋放 CPU 與記憶體占用。
  • Resume：模型結果回來後恢復原本狀態。
  • Fork：從既有狀態分叉出多個平行環境。
  • Incremental checkpoint：只保存變動部分，降低狀態保存成本。

技術報告列出的低延遲數字為 checkpoint 133 ms、resume 49 ms。報告也指出，在特定 agentic RL 工作流中，等待模型推論可能占 sandbox lifetime 最多 98%。

這裡最容易被誤讀。

98% 不是所有 AI agent 的固定浪費比例，也不是每個應用都能立刻節省 98% 成本。它描述的是特定訓練流程中，sandbox 等待模型回覆可能占據的時間上限。

真正有價值的問題是：當 agent 需要工作幾十分鐘或幾小時，系統能不能區分「正在執行」與「只是在等待」，並在等待期間停止支付不必要的資源成本？

為什麼這三個設計比單一跑分更值得讀

Benchmark 通常把複雜系統壓成一個數字。

但模型能否在實際環境中運作，還取決於至少四層：

  1. 模型架構：長序列的記憶如何表示。
  2. 單機 kernel：數學運算如何映射到 GPU。
  3. 跨機排程：experts 與 tokens 如何分配。
  4. Agent runtime：工具執行環境如何保存、暫停與恢復。

Kimi K3 的 2.8T 規模讓這些問題變得非常極端，但解法背後的原則可以縮小到其他系統：

  • 不要保存不需要一直成長的狀態。
  • 不要只看平均負載，要消除最慢節點。
  • 不要讓等待中的資源維持完整占用。
  • 不要把模型、kernel、網路與 runtime 當成彼此獨立的問題。

開放權重之外，還有另一種真正的開放

模型社群常把「是否開放權重」當成開源程度的主要判斷。

權重當然重要。研究者可以檢查、微調、部署並建立新的 inference support。

但對無法運行 2.8T 模型的大多數人，另一種開放可能更直接：把架構選擇、失敗模式、benchmark 條件與基礎設施實作一起公開。

一份技術報告如果只說「我們更快」，價值有限。

當它進一步交代：

  • 為什麼 chunk size 選 16；
  • 為什麼 expert imbalance 會讓 iteration 變慢；
  • 為什麼 sandbox 等待模型時應該 Pause；
  • 哪些數字只在指定條件下成立；

其他團隊才有機會驗證、質疑，或把相同原則用在較小的模型與系統。

閱讀大型模型發布時，可以先問五個問題

  1. 總參數之外，每次實際啟用多少參數？
  2. 長 context 的記憶體成本如何隨序列長度變化？
  3. MoE routing imbalance 如何處理？
  4. Benchmark 使用哪套 harness、硬體與推理設定？
  5. 除了權重，有沒有公開 kernels、排程與 runtime 設計？

這五題比單純比較一張排行榜，更能判斷一個模型是否真的具備可部署性，也更能看出技術是否能被外部社群重現。

結語

Kimi K3 的完整權重很大，大到多數人不會直接把它搬回自己的機房。

但 47 頁技術報告所揭露的三個問題，會出現在越來越多 AI 系統裡：

  • 如何用固定狀態支撐更長 context；
  • 如何讓數百個 experts 不被最忙的 GPU 拖住；
  • 如何讓長任務 agent 在等待時不浪費 sandbox 資源。

當模型競賽從幾分鐘的聊天走向幾小時的工作，勝負可能不只在模型本身。

真正的差距，會出現在那些看不到的地方：kernel、記憶體、網路、排程，以及一個環境能不能在正確的時間睡著，再從原地醒來。

查證摘要

  • Kimi K3 為 2.8T 總參數、104B activated parameters 的 MoE 模型。
  • 模型含 69 層 KDA、24 層 Gated MLA，每 token 從 896 個 routed experts 選 16 個。
  • 官方技術報告共 47 頁，完整權重已公開。
  • FlashKDA、MoonEP 與 AgentENV 分別處理長序列 kernel、expert parallelism 與 agent sandbox life cycle。
  • 2.5 倍 scaling efficiency、15% kernel speedup 與 98% sandbox waiting 都是官方或指定測試情境的數字，不泛化成所有工作負載保證。

查證來源

回文章列表