Kimi K3 已正式釋出完整模型權重。 Moonshot AI 將它稱為全球首個開放權重的 3 萬億參數級模型：總參數 2.8 萬億，每個 token 啟用約 1040 億參數，原生支援視覺輸入和 100 萬 token 上下文。 權重可以從 Hugging Face 免費下載，但“下載免費”不等於“普通電腦可以低成本執行”。 官方模型倉庫當前包含 96 個 Safetensors 權重分片，合計約 1.42 TiB，下載、校驗、載入和推理都需要伺服器級資源。 本文把釋出資訊、下載命令、硬體判斷、部署入口、許可證和效能對比分開說明，避免只看排行榜或一句“全球最強”。
先回答最常見的三個問題
Kimi K3 的完整權重確實已經公開，不是隻有 API 或技術報告。
官方入口是 moonshotai/Kimi-K3，GitHub 倉庫也明確列出 vLLM、SGLang 和 TokenSpeed 三條部署路線。
模型檔案可以免費下載，但完整倉庫體積超過 1 TiB，不能按 7B、32B 或普通消費級量化模型的方式估算硬體。
官方基準顯示它在部分程式設計、Agent 和知識工作測試中達到或超過 Claude、GPT-5.6 系列，但並非每一項都第一。
因此，更準確的表述是“開放權重模型中的旗艦級選擇”，而不是脫離任務和測試條件宣佈絕對最強。
這次開放了哪些內容
官方 GitHub 倉庫提供 README、Kimi K3 License 和技術報告。 Hugging Face 模型頁提供配置、Tokenizer、自定義建模程式碼以及完整 Safetensors 權重。 權重不是需要申請才能看到的佔位檔案，登入 Hugging Face 後可透過 CLI 下載到本地或伺服器。 官方也公開模型結構、量化格式、主要評測結果和推薦推理引擎。
但這不是一個完整訓練資料包。 “開放權重”表示可以取得並部署模型參數，不等於訓練語料、全部訓練流水線和每個評測環境都已經公開。 判斷開放程度時，應分別檢視權重、程式碼、許可證、訓練資料和復現實驗，而不是隻看專案標題中的 open-source。
2.8 萬億參數怎樣工作
Kimi K3 使用 Mixture-of-Experts 架構，共有 896 個專家，每個 token 選擇其中 16 個，並使用兩個共享專家。 總參數為 2.8T，啟用參數約 104B。 這意味著單次推理並不會像一個 2.8T 稠密模型那樣啟用全部參數，但所有專家權重仍需要儲存，並在裝置之間組織和傳輸。
模型共有 93 層，其中注意力層由 69 層 KDA 與 24 層 Gated MLA 組成。 視覺編碼器是 MoonViT-V2，約 4.01 億參數。 上下文上限是 1,048,576 token，但達到協議上限不代表任何部署都能經濟地提供 100 萬上下文。 KV cache、併發數、輸入圖片和輸出長度都會繼續消耗顯示記憶體。
MXFP4 不能直接等同於“小顯示記憶體量化版”
Kimi K3 從監督微調階段開始進行量化感知訓練，官方權重採用 MXFP4，啟用採用 MXFP8。 這比把 BF16 權重事後壓成 4-bit 更接近模型原生設計。 不過，能儲存 MXFP4 檔案不代表任意 GPU 都能高效執行對應運算元。 推理引擎版本、GPU 架構、通訊庫和核心支援仍會決定能否啟動及實際速度。
不要只用“2.8T × 0.5 byte”估算最終磁碟。 倉庫還包含視覺模組、尺度資訊、索引、Tokenizer 和其他配置；檔案系統也要為下載臨時檔案、快取和日誌預留空間。 部署前應以 Hugging Face 當前檔案清單為準，而不是引用釋出前的預估數字。
完整權重實際有多大
截至本文核對時，官方模型倉庫包含 96 個 .safetensors 分片。
透過 Hugging Face API 彙總這些檔案的 size 欄位，合計為 1,560,936,091,448 bytes，約 1.42 TiB。
這只是 Safetensors 權重之和，不包含下載中的臨時佔用、容器映像、Python 環境和執行日誌。
實際部署建議準備至少 2 TiB 可用的高速本地儲存。
如果下載工具會保留快取與 local-dir 兩份資料，空間需求可能進一步增加。
機械硬碟適合歸檔，不適合頻繁冷啟動超大模型；共享網路盤則要先測吞吐和後設資料效能。
下載前先做容量預檢
Linux 可以檢視目標分割槽：
|
|
Windows PowerShell 可以檢查資料盤：
|
|
除了容量，還要確認檔案系統支援大檔案、目錄配額沒有限制、下載賬戶對目標目錄有寫許可權。 在雲伺服器上，先計算資料盤、快照和出站流量費用；權重免費下載不代表雲磁碟免費。
安裝 Hugging Face CLI
在獨立 Python 環境中安裝當前版 huggingface_hub：
|
|
Windows PowerShell 使用：
|
|
若倉庫訪問要求登入，在 Hugging Face 建立只讀 token：
|
|
不要把 token 放進命令歷史、Dockerfile 或公開的部署指令碼。
先用 dry-run 檢視檔案清單
新版本 CLI 支援在真正下載前檢查計劃：
|
|
如果當前 CLI 不識別 --dry-run，先升級 huggingface_hub，再檢視：
|
|
不要因為示例命令與舊版 huggingface-cli 不同，就同時安裝多個互相覆蓋的環境。
記錄 hf --version 和下載開始時的模型 revision，後續才能重現同一份權重。
下載完整倉庫
目標目錄應位於容量充足的本地 SSD 或高吞吐並行檔案系統：
|
|
下載過程中不要反覆刪除快取重來。 Hugging Face 的下載器能夠複用已完成檔案；網路中斷後先執行同一命令恢復。 在伺服器重啟前儲存日誌，並確認目標目錄不是臨時系統盤。
固定 revision 避免檔案在叢集中不一致
模型倉庫可能繼續更新 README、配置、程式碼或權重索引。 生產環境應鎖定已驗證的 commit SHA：
|
|
多節點部署不要讓每臺機器在不同時間各自下載 main。
先確定 revision，再同步到所有節點，最後比較檔案清單和雜湊。
滾動更新時保留上一目錄，確認新版本能載入後再清理舊權重。
下載完成後不要只數檔案
檢查索引、總大小和異常小檔案：
|
|
確認 config.json、Tokenizer 檔案、權重索引和自定義程式碼都存在。
如果某個分片只有幾 KB，可能拿到的是 Git LFS/Xet 指標或未完成臨時檔案。
不要在不完整目錄上反覆啟動推理服務，讓錯誤日誌淹沒真正的下載問題。
普通電腦可以執行 Kimi K3 嗎
完整權重不適合普通桌上型電腦、遊戲本或單張消費級 GPU。 僅權重就約 1.42 TiB，實際服務還需要執行時、啟用、通訊緩衝和 KV cache。 即使透過 CPU offload 勉強儲存全部權重，記憶體頻寬和磁碟換入也會使互動速度失去實用性。
不要把“每 token 啟用 104B”理解成只需要載入 104B 參數。 MoE 路由會在不同 token 間選擇不同專家，完整專家集合仍需可訪問。 個人使用者想體驗模型，應優先選擇 Kimi 官方 API、認證推理供應商或 Kimi Code，而不是先購買硬體。
伺服器配置要從引擎配方反推
官方沒有給出一張適用於所有 GPU 的單機最低配置表。 合理做法是先選擇 vLLM、SGLang 或 TokenSpeed 的官方 Kimi K3 配方，再核對支援的 GPU 型號、節點數、互聯和精度。 超大 MoE 部署通常需要多 GPU 甚至多節點，並依賴高速 NVLink、NVSwitch 或 InfiniBand 類互聯。
顯示記憶體總量只是第一關。 節點間頻寬不足會讓專家並行通訊成為瓶頸；驅動、CUDA、NCCL 和推理引擎版本不匹配則可能在載入前就失敗。 準備機器時應同時記錄 GPU 架構、單卡顯示記憶體、拓撲、系統記憶體和本地盤吞吐。
用 vLLM 前先核對專用 recipe
官方倉庫推薦 vLLM，並連結到 Kimi K3 的部署配方。 先建立隔離環境並記錄版本：
|
|
Hugging Face 頁面給出的通用入口是：
|
|
對 Kimi K3 這種規模的模型，這條命令只是介面形式，不是單卡部署承諾。 張量並行、專家並行、多節點地址、埠和記憶體參數必須採用當前 recipe 中與硬體對應的配置。 不要憑其他 MoE 模型的參數猜測並行拓撲。
SGLang 也是官方推薦路線
基礎啟動入口如下：
|
|
先繫結 127.0.0.1 做本機驗證，不要直接把未鑑權模型服務開放到公網。
完整叢集同樣要根據 SGLang 官方 cookbook 配置並行方式、節點發現和通訊參數。
若日誌顯示不支援 MXFP4、未知架構或缺少自定義程式碼，先核對引擎版本與 Kimi K3 支援狀態。
用 OpenAI 相容介面做首次請求
服務健康後傳送一條短文字請求：
|
|
模型始終啟用 thinking，並透過 reasoning_content 返回推理內容。
首次測試使用短上下文和低併發，確認文字、推理欄位、結束原因和 token 統計，再逐步增加負載。
不要一啟動就提交 100 萬 token 輸入，這會把模型載入問題與 KV cache 壓力混在一起。
多輪對話必須保留思考歷史
Kimi K3 使用 preserved thinking history 模式。
繼續多輪對話或工具呼叫時，需要把上一輪 assistant message 按原樣放回 messages，包括 reasoning_content 和 tool_calls。
只儲存最終 content 可能破壞模型延續推理和工具狀態的能力。
應用資料庫也要能儲存這些欄位。 若考慮隱私或儲存成本，應在產品設計階段決定保留時間，而不是在請求前隨意刪除部分歷史。 對外展示時可以隱藏推理文字，但傳送給模型的歷史結構仍應遵守官方協議。
“效能直逼 Claude、GPT-5.6”怎樣理解
官方表格並不是 Kimi K3 在所有指標上都獲勝。 例如 Terminal-Bench 2.1 中，Kimi K3 為 88.3，GPT-5.6 Sol 為 88.8；DeepSWE 分別為 67.5 和 73.0。 但在 FrontierSWE 中，Kimi K3 為 81.2，高於表中的 GPT-5.6 Sol 71.3；SWE-Marathon 中 Kimi K3 為 42.0，GPT-5.6 Sol 為 39.0。 BrowseComp 的官方表格中，Kimi K3 為 91.2，GPT-5.6 Sol 為 90.4，Claude Opus 4.8 為 84.3。
這些資料支援“部分程式設計與 Agent 任務達到閉源旗艦水平”。 它們不支援“任何場景都全面超過所有閉源模型”。 模型選擇還要測試中文質量、延遲、吞吐、工具框架、拒答行為、輸出穩定性和實際成本。
橫向基準不能忽略 harness 差異
官方說明不同模型並不總使用同一個 Agent 框架。 Kimi K3 可能搭配 Kimi Code 或 Claude Code，GPT-5.6 Sol 通常搭配 Codex，其他模型也可能使用各自最優 harness。 不同工具、提示詞、上下文壓縮策略和最大思考強度都會影響結果。
部分分數來自模型廠商測試，部分引用第三方榜單，還有一些是內部 benchmark。 閱讀表格時要繼續檢視腳註、執行次數、硬體和任務子集。 企業選型最好拿自己的程式碼庫、文件和工具鏈做盲測，不要只按一列總分採購叢集。
Kimi K3 License 不是標準寬鬆許可證的簡單複製
許可證允許使用、複製、修改、釋出、分發、再許可、銷售、部署和微調，但包含額外商業條件。 若企業及關聯方經營 Model as a Service，連續 12 個月總收入超過 2000 萬美元，需要另行與 Moonshot AI 達成協議，才能將軟體或衍生版本用於商業目的。
商業產品或服務若月活超過 1 億，或月收入超過 2000 萬美元，需要在介面顯著展示 “Kimi K3”。 許可證對內部使用、官方產品和認證推理合作方另有例外說明。 準備商用、再分發或提供模型服務時，應由法務閱讀完整許可證，不能只寫“免費商用”。
權重下載後的安全邊界
Hugging Face 示例使用 trust_remote_code=True，這意味著載入模型時允許執行倉庫中的自定義 Python 程式碼。
在生產伺服器上，應先鎖定 revision、審查程式碼，再在非特權容器或專用賬戶中執行。
不要讓模型服務賬戶讀取 SSH 私鑰、雲憑據或生產資料庫備份。
API 埠前應配置認證、TLS、請求體限制和速率限制。 對圖片、影片和超長上下文設定大小上限，防止單個請求佔滿 KV cache 或磁碟。 儲存提示詞與推理日誌時執行脫敏，並明確使用者資料保留期限。
常見下載問題
No space left on device 不一定是目標盤真的滿了，也可能是快取預設寫到了較小的系統盤。
檢查 HF_HOME、容器掛載和臨時目錄實際位置。
下載速度突然歸零時，先看磁碟寫入和檔案校驗，不要立即殺死程序。
出現 401 或 403 時，檢查 token 許可權、登入賬戶和倉庫訪問條款。
出現 checksum 或分片缺失時，重新執行同一 revision 的下載命令，讓工具補齊檔案。
多節點找不到模型時，比較掛載路徑和許可權；相同目錄名不代表各節點看到同一塊儲存。
常見啟動失敗
unknown model type 通常意味著 Transformers 或推理引擎版本尚未包含 Kimi K3 支援。
unsupported quantization 指向 MXFP4 核心、GPU 架構或引擎構建不匹配。
NCCL timeout 多與節點網路、網絡卡選擇、防火牆或並行拓撲有關，不應透過無限增加超時掩蓋。
若載入到一半被系統殺死，檢查 GPU 顯示記憶體之外的主機記憶體和 cgroup 限制。 能載入但速度異常慢時，記錄每張卡利用率、跨卡流量、首 token 延遲與解碼速度。 只有部分 GPU 空閒，通常說明並行配置或專家分佈沒有按預期生效。
什麼時候應直接用 API
個人開發、功能驗證、低併發應用和沒有 GPU 叢集的團隊，優先使用 Kimi API 或認證推理服務。 API 不需要下載 1.42 TiB 權重，也不承擔引擎升級、故障恢復和叢集通訊成本。 已有的 Kimi K3 API 呼叫、視覺輸入與工具使用示例可參考：Kimi K3 API 快速入門。
本地部署更適合必須控制權重、隔離資料、修改推理棧，或擁有現成高階 GPU 叢集的組織。 即使這樣，也建議先透過 API 建立質量基準，再衡量自託管吞吐、延遲與總擁有成本。 “已經下載成功”只是部署開始，不是服務達到生產標準。
上線前記錄一份可復現清單
- 模型倉庫 commit SHA 與許可證版本。
- 96 個權重分片的數量、總大小和校驗狀態。
- 推理引擎、PyTorch、CUDA、驅動與 NCCL 版本。
- GPU 型號、節點拓撲、顯示記憶體和主機記憶體。
- 上下文長度、併發、thinking effort 與最大輸出。
- 首 token 延遲、輸出速度、錯誤率和峰值資源。
- 自有任務集上與 API、Claude、GPT-5.6 的對比結果。
- API 鑑權、日誌脫敏、限流和資料保留策略。
完成這些記錄，後續升級權重或引擎時才能判斷效能變化來自哪裡。
官方入口
Kimi K3 的意義不僅是釋出了一個高分模型，更在於完整旗艦權重已經可以被研究、審查和部署。 但 1.42 TiB 權重、叢集通訊和自定義許可證也決定了它不是面向普通電腦的一鍵本地模型。 先透過官方 API 驗證任務效果，再按固定 revision 下載，並依據 vLLM 或 SGLang 的 Kimi K3 專用配方規劃叢集，是更穩妥的採用順序。