Kimi K3 全面解析：2.8 萬億參數、百萬上下文與開放權重的新門檻
最後審閱：2026 年 8 月 7 日。 本文的模型規格與基準結果來自月之暗面技術報告與官方 repository。部署前請重新確認權重、授權、runtime 支援、GPU 庫存與價格。
作者： Glows.ai Editorial Team。技術審核： Glows.ai Infrastructure Team。
Kimi K3 全面解析：2.8 萬億參數、百萬上下文與開放權重的新門檻
2026 年 7 月，月之暗面正式發布新一代旗艦模型 Kimi K3。它結合 2.8 萬億總參數、1040 億激活參數、原生視覺能力，以及最高 1,048,576 token 的上下文窗口。真正值得關注的，不只是模型變大，而是 Kimi K3 試圖同時服務長程程式設計、知識工作、多模態理解和 Agent 任務。
本文會說明：
- Kimi K3 的架構設計想解決什麼問題；
- 官方 benchmark 能證明什麼、不能證明什麼；
- 百萬級上下文為什麼是工程問題，而不只是模型參數；
- 如何規劃 Kimi K3 所需的 GPU、儲存和多節點環境。
以下規格以 Kimi K3 技術報告 與 Moonshot 官方 repository 為主要來源。
Kimi K3 的核心規格
Kimi K3 採用混合專家（MoE）架構，包含 896 個路由專家，每個 token 選擇 16 個專家，並使用共享專家。這讓單一 token 的實際計算量低於總參數量，但所有專家仍要儲存在多張 GPU 組成的服務集群中。
| 項目 | Kimi K3 |
|---|---|
| 模型架構 | Mixture-of-Experts |
| 總參數 | 2.8T |
| 激活參數 | 104B |
| 模型層數 | 93 層 |
| 路由專家數 | 896 |
| 每 token 選擇專家 | 16 |
| 上下文長度 | 1,048,576 tokens |
| 視覺編碼器 | MoonViT-V2 |
| 權重量化 | MXFP4 |
| 激活精度 | MXFP8 |
| 輸入 | 文字與圖片；官方服務也提供影片輸入 |
2.8T 是需要載入和儲存的完整權重規模，104B 則更接近每次前向計算真正參與運算的參數量。 MoE 可以降低每 token 的計算量，但不代表 Kimi K3 能像普通 100B 模型一樣部署。
Kimi K3 背後的三個架構設計
Kimi Delta Attention：為長上下文重新設計注意力
傳統 Transformer 在序列變長後，KV Cache、預填充工作和跨 GPU 通訊都會增加。Kimi K3 引入 Kimi Delta Attention（KDA）：透過固定大小的循環狀態處理長序列，並週期性插入 Gated MLA 層，保留全局資訊交互能力。
Kimi K3 的 93 層中包含 69 層 KDA 和 24 層 Gated MLA。它不是完全取消全注意力，而是在長序列效率和全局資訊之間取平衡。百萬上下文因此是模型結構、cache 管理和 GPU 並行共同設計的結果。
提醒： 支援 100 萬 token 不等於所有部署都能低成本跑滿 100 萬 token。GPU 記憶體、併發量、KV Cache 設定、預填充時間和推理引擎仍會決定實際可用上限。
Attention Residuals：讓模型選擇性回看前面的層
普通 Transformer 主要逐層傳遞資訊。Attention Residuals（AttnRes） 允許當前層從 embedding 層和先前多個區塊中，選擇性提取有價值的表示，目標是減少關鍵資訊在數十層傳遞後被稀釋。
AttnRes 與 KDA、Gated MLA、Stable LatentMoE 和訓練流程共同構成 Kimi K3 的主幹。重點不是某一個單獨元件，而是整體架構都朝長流程工作和稀疏執行設計。
Stable LatentMoE：把稀疏度進一步做大
每個 token 只從 896 個路由專家選擇 16 個，讓 Kimi K3 擁有更大的總容量，又不必每次都執行全部 2.8T 參數。高稀疏度也帶來負載平衡問題，因為部分專家可能被過度使用。Moonshot 以 Stable LatentMoE 和相關平衡策略處理這個問題。
Moonshot 表示，Kimi K3 相較 Kimi K2 有約 2.5 倍的整體 scaling efficiency 提升。這是官方綜合評估，不代表所有任務都快 2.5 倍或成本降低 2.5 倍。除非有獨立且對齊的 benchmark，否則應把它視為模型開發層面的聲明。詳情請參考官方 repository。
Kimi K3 的實際能力
Moonshot 公布的評測涵蓋推理、程式設計、工具調用、網路研究、多模態理解和桌面操作。
| 類別 | 測試集 | Kimi K3 成績 |
|---|---|---|
| 推理與知識 | GPQA Diamond | 93.5 |
| 程式設計 | ProgramBench | 77.8 |
| 程式設計 | Terminal-Bench 2.1 | 88.3 |
| 長程軟體工程 | FrontierSWE | 81.2 |
| 長程軟體工程 | SWE-Marathon | 42.0 |
| 網路研究 | BrowseComp | 91.2 |
| 工具調用 | MCPMark-Verified | 94.5 |
| 自動化操作 | AutomationBench | 30.8 |
| 桌面操作 | OSWorld-Verified | 84.8 |
| 文件視覺理解 | OmniDocBench | 91.1 |
| 影片理解 | Video-MME | 90.0 |
這些數字指向的是「觀察、操作、檢查、修正」的循環，而不是單輪聊天。它們是模型方公布的結果，部分由 Moonshot 自行評估；Agent benchmark 還會受到工具、prompt、框架和模型設定影響。技術報告也承認，Kimi K3 並未在所有評測全面超過當時最強的閉源模型。
長時間軟體工程
Kimi K3 可理解大型 repository、調用終端工具、編寫並測試程式碼，在較少人工干預下持續執行工程任務。官方案例中，模型分析並重寫 GPU kernel，將 AttnRes kernel 延遲從 283.6 毫秒降至 114.4 毫秒。這是 Moonshot 的案例結果，不能直接套用到其他硬體、編譯器或 kernel 版本。
端到端知識工作
模型可以把搜尋、閱讀文件、執行程式、分析資料和製作視覺化結果串成一個流程。技術報告披露的一個案例處理了數十年的 AI 晶片產業資料，包括 87 份季度報告、99 份原始 PDF 和超過 11,000 頁內容，過程中進行大量網路搜尋與終端操作。這更接近研究助理，而不只是聊天機器人。
視覺與工具協同
原生圖片輸入讓模型能夠觀察介面、圖表、渲染結果、文件和錯誤畫面，再選擇下一個工具動作。對 Agent 來說，視覺能力的價值在於把命令和命令造成的狀態連成可反覆修正的閉環。
開放權重不等於沒有部署門檻
Moonshot 建議使用 vLLM、SGLang 和 TokenSpeed 部署 Kimi K3，並透過官方管道提供相容 OpenAI API 格式的介面。完整模型仍需要分散式部署。
目前公開的參考拓撲包括：
- H100：4 個節點，每個節點 8 張 GPU；
- H200：2 個節點，每個節點 8 張 GPU；
- B200：2 個節點，每個節點 8 張 GPU；
- B300：單節點 8 張 GPU；
- GB300：2 個節點，每個節點 4 張 GPU。
vLLM Recipes 建議至少使用 8 張 GB300，正式流量通常還需要多節點。這些是起始配方，不是任何工作負載的容量保證。建立環境前，請確認模型 revision、runtime、拓撲和現時 GPU 庫存。
對個人開發者和中小團隊，更現實的路徑通常是：
- 直接使用官方 Kimi API。
- 租用較小的 GPU，先搭建 RAG、資料處理、評測和 Agent 沙箱，再接入 Kimi K3 API。
- 只有在資料隱私、控制權或穩定用量足以支撐集群時，才轉向多節點私有部署。
Kimi K3 更準確的說法是開放權重模型，不代表軟體完全沒有條件。授權允許使用、修改、部署、微調、再分發和建立衍生作品，但包含商業條款。例如 Model-as-a-Service 業務若連續 12 個月總收入超過 2,000 萬美元，需要另行與 Moonshot AI 簽署協議；大型商業產品也可能涉及介面標示要求。商業部署前請閱讀完整授權。
用分層方式規劃基礎設施
部署難點不只在 GPU 數量，還包括高速互聯、Tensor/Pipeline/Expert Parallel 設定、跨節點權重分布、百萬上下文的 KV Cache 與 KDA state 管理、中斷恢復，以及按照工作負載增加或釋放 GPU 的能力。
先用驗證型 GPU
L40S 或 RTX PRO 6000 不適合承載完整 Kimi K3，但適合用於 API 接入、RAG 與向量資料庫、Embedding／Reranker、OCR、Agent 工具與沙箱、小型開放模型、批量資料清理和評測。先把程式、資料和流程穩定，再租用大型集群。
再進入 H100、H200 或 B200 集群
當專案進入高併發推理、大規模資料處理、微調或多節點驗證，再使用高記憶體 GPU。只有在 GPU 具備合適互聯、並且位於相容區域時，集群才可作為單一服務。不要把分散在不同機房的幾十張卡簡單視為同一個模型集群。
Glows.ai 提供 B200、H200、H100、RTX PRO 6000、A100 和 L40S 等 GPU，但實際型號、區域、價格和庫存以建立實例時的 dashboard為準。
保存權重和環境
多 TB 權重與 runtime 依賴不適合每次重複下載。使用 Datadrive 持久化模型、資料和程式碼，使用 Snapshot 保存已配置完成的環境。這對反覆測試 vLLM、SGLang、CUDA kernel 和多節點設定的團隊尤其重要。可參考多機 DeepSeek-R1 SGLang 教學的分散式流程，以及Kimi K3 硬體、成本與可用性指南的選型說明。
誰適合關注 Kimi K3？
AI Agent 開發團隊可以用它的工具調用、網路研究、長流程執行和桌面操作能力，測試更自主的工作流。
大型程式碼庫團隊可以探索百萬上下文和長程 Coding 對跨模組重構、除錯與 repository 理解的幫助。
研究與顧問團隊可以把文件閱讀、搜尋、分析和報告生成串成一個流程。
考慮私有推論的企業需要同時評估集群成本、runtime 成熟度、授權、安全和資料治理。
推理基礎設施研究者則能從 KDA、稀疏 MoE、MXFP4、長上下文 state 和跨節點 Expert Parallel 研究完整的系統問題。
常見問題
Kimi K3 只是更大的聊天模型嗎？
不是。它的架構與評測都針對長時間 Coding、知識工作、多模態輸入和 Agent 循環；聊天只是其中一種介面。
104B 激活參數代表它能放進 104B GPU 嗎？
不能。完整的 2.8T 權重仍要儲存並分布到服務集群。激活參數描述每 token 的計算量，不是 checkpoint 的總記憶體需求。
百萬 token 上下文可以在高併發下直接使用嗎？
不一定。上下文長度、KV Cache 或 KDA state、預填充時間、batch size 和網路拓撲共同決定實際上限。請用預期工作負載量測。
中小團隊應該自架 Kimi K3 嗎？
通常應先使用 API，或選擇已有公開權重和實測配置的較小模型。只有在隱私、revision 控制或長期用量足以支撐多節點維運，並且已有恢復方案時，自架才較合理。
相關指南
結語
Kimi K3 的意義不只是 2.8T 這個數字，而是開放權重大模型進入更工程化的階段：原生視覺、百萬上下文、工具與終端操作，以及跨多張 GPU 和多個節點的高效執行。
對大多數讀者，官方 API 是評估 Kimi K3 最簡單的方式。對要建立私有 Agent、企業知識系統或高併發推理服務的團隊，GPU 集群、持久化儲存和部署工具鏈才是實際專案。Glows.ai 這類按需 GPU 平台可以讓團隊先用較小的實例驗證資料管線與 Agent 工作流，需求確定後再擴展到 H100、H200 或 B200。