Kimi K3.1 Pro 權重正式釋出,下載、量化、授權與多 GPU 部署怎麼準備?

Kimi K3.1 Pro 權重於十一月四日正式釋出。本文核對官方九十六個權重分片、MXFP4 格式、推論引擎、工具訊息回傳規則與自訂授權,整理自建部署需要保留的版本及資源條件。

Share
Kimi K3.1 Pro 官方權重發布貼文拼圖,包含電腦、雲朵與多張視覺任務示例
Kimi 官方權重發布貼文配圖,展示多種影像與操作情境。 圖片來源:官方原文。

Kimi K3.1 Pro 權重已在二〇二六年十一月四日正式釋出。Moonshot 官方貼文連到 Hugging Face 儲存庫,讓原本等待下載的團隊取得實際模型檔案。

這是十月線上服務發布之後的新進度。前次公告已介紹程式介面、產品入口與性能,這次最直接改變的是研究者可以自行載入權重、固定版本,並觀察自己的部署結果。

官方提供的量化格式與推論引擎指引,會影響檔案如何載入、哪些設備能運行,以及測試能否被其他人重現。

模型保存二點八兆參數,每次運算啟用其中一部分。因為其餘專家參數仍屬模型內容,部署資源需要按完整檔案與運行狀態規劃。

有多卡設備與維運能力的團隊,可以開始做固定版本的測試。商業使用者則需要把模型服務方式與公開的自訂授權一起核對,才能決定後續部署範圍。

從官方下載內容看起,較容易把資源、軟體與使用條件接成同一套計畫。

Kimi K3.1 Pro 權重這次實際開放了什麼?

完整權重讓團隊能自行載入模型,並固定所使用的檔案版本。權重是模型訓練後保存的數值,推論引擎會依這些數值,把輸入轉成後續輸出。

本次查詢官方儲存庫,主目錄列出九十六個 safetensors 權重分片,合計約一點五六兆位元組,以十進位單位計算。這是檔案大小快照,尚未包含其他設定與執行資源。

分片讓大型檔案能分段保存與下載。下載工具通常還要讀取索引,才能知道每個參數放在哪一片,因此只取得其中幾個檔案,還不足以組成完整模型。

對有自建需求的人,第一步可以先保存官方儲存庫網址與修訂版識別碼。若後續檔案更新,同一個名稱可能指向不同內容,固定修訂版才有共同的比較起點。

接著應核對檔案是否下載完整,並保留設定檔與授權文件。因為模型的數值格式、架構和分片對應會一起影響載入,單獨保存權重資料夾名稱不容易追查錯誤。

這也是線上服務與自建部署的差異。呼叫服務時,提供者維護底層版本與設備,自建之後,團隊需要自行記錄並維護這些條件,才能判斷問題來自哪一層。

實際取得檔案以後,下一個問題是數值格式與硬體支援。這次官方模型卡列出的量化設計,會直接影響推論引擎選擇。

Kimi K3.1 Pro 官方權重發布貼文拼圖,包含電腦、雲朵與多張視覺任務示例
Kimi 官方權重發布貼文配圖,展示多種影像與操作情境。 圖片來源:官方原文。

MXFP4 權重與 MXFP8 運算代表什麼?

低精度格式用較少位元保存或處理數值,能降低部分儲存與計算需求。官方模型卡列出 MXFP4 權重與 MXFP8 活化值,並說明使用量化感知訓練。vLLM 指引進一步區分,路由專家權重使用 MXFP4,其餘部分為 BF16,因此整個模型仍含不同格式。

活化值是模型處理目前輸入時產生的中間數值。權重格式描述長期保存的模型參數,活化格式則描述運行中的另一部分,因此兩個名稱需要分開理解。

量化感知訓練把較低精度的影響納入訓練流程。這與下載後再自行轉換數值格式的情況不同,讀者在比較第三方版本時,應確認它是否沿用官方格式與設定。

低精度帶來的資源變化,也要依實際實作測量。引擎是否有對應運算核心、是否需要額外轉換,以及哪些部分使用其他精度,都可能影響速度和記憶體。

因此,看到四位元名稱時,可以先查推論引擎的該模型指引,確認支援的是哪些設備與軟體版本。這能避免把理論上的位元數,直接當成完整服務的資源預算。

官方模型卡也列出混合注意力架構與多模態輸入。這些能力需要相對應的模型實作,通用聊天模型能載入,並不代表同一套舊版軟體已能正確處理本次所有路徑。

若團隊要比較不同量化版本,建議先固定一組有已知答案的任務。因為數值格式改變可能同時影響資源與輸出,測量時應把結果品質與耗用放在同一份紀錄裡。

格式能降低部分需求,整體部署仍得由完整模型與任務容量計算。這把問題帶回設備配置,以及服務要同時承接多少工作。

多 GPU 部署要先確認哪些資源?

權重只是記憶體需求的一部分,長上下文與並行工作也會占用資源。官方列出總參數二點八兆、每次啟用一千零四十億,兩個數字描述不同範圍。

專家混合架構會為每次計算挑選部分分支,因而減少當下需要的運算。但尚未被這次輸入選中的參數,仍可能在下一次輸入派上用場,因此載入策略需要涵蓋完整模型。

儲存容量與顯示記憶體也有不同用途。磁碟保存下載檔案,運行時還需要參數、工作緩衝區和對話狀態,實際占用會隨引擎配置與請求形狀改變。

官方列出一百零四萬八千五百七十六個 token 的上下文上限。這是可支援的容量規格,部署者仍需依設備設定實際允許的長度,並量測長請求能否在服務目標內完成。

Token 是模型切分文字與計算資料的單位。若多個使用者同時送入長資料,服務需要保存多份運行狀態,因此單一請求能完成,和持續承接多人工作仍是不同測試。

多卡之間的資料交換也會影響結果。相同張數若連接方式、頻寬或並行策略不同,等待與記憶體分配都可能改變,所以只留下「用了幾張卡」還不足以重現。

對第一次試跑,較清楚的做法是先限制輸入長度與同時請求數,確認載入、文字輸出與影像路徑是否正常,再逐步增加工作量。每次只改一組主要條件,比較容易找到瓶頸。

設備配置確定後,推論引擎與版本會決定模型能否正確運行。這也是官方指引需要和自己的測試紀錄一起保存的原因。

vLLM 的對應指引列出八張卡的張量平行起點,包含兩個 GB300 托盤或一個 B300 節點,並標示吞吐尚未調校。它也列出 MI355X 節點的特定測試配置,因此設備名稱仍需連同實際測試路徑閱讀。

官方推論引擎指引如何變成可重現測試?

固定模型修訂版、引擎和輸入條件,才能比較部署結果。官方模型卡目前連向 vLLM、SGLang 與 TokenSpeed 的對應操作指引,提供不同引擎的起點。

推論引擎負責載入參數、安排計算與處理請求。選擇時應查看指引所要求的版本與設備,再依現有環境試跑,因為三個名字代表不同實作,設定未必能直接交換。

測試紀錄可以把模型修訂版、引擎版本、驅動與硬體放在一起。若結果異常,這些資訊能幫助團隊重建當時環境,也讓不同同事有條件核對同一份輸出。

請求參數也需要固定。官方說明推理強度可選 low、high 與 max,預設為 max,因此比較兩次執行時間時,應先確認使用的是同一種強度。

代理任務還多一個訊息處理要求。官方要求多輪對話與工具呼叫,把完整助理訊息原樣帶回,包括推理內容與工具呼叫欄位,才能維持預期的續接方式。

若應用程式只保留最後可見文字,後續行為可能和官方範例不同。因此,測試應涵蓋一次完整工具循環,確認模型提出呼叫、工具回傳結果,再由模型接續處理。

這種測試會比單純問一題更接近程式代理的工作。因為部署目的通常包含持續操作,團隊需要觀察多輪狀態、錯誤回傳與任務完成結果,才能判斷服務是否可用。

效能紀錄則可分開留下首字等待、完整回覆時間與整個任務耗時。若中間有工具等待或重試,單次輸出速度很難涵蓋整項工作,保存分段時間才能找到改善方向。

當技術測試開始可重現,商業部署還要把使用方式對照授權條件。這次權重採用自訂條款,相關門檻需要按原文的期間與適用範圍閱讀。

測試輸出也應與原始輸入放在同一份資料夾。若程式任務最後通過,是因為人類修改了哪個步驟,這段介入就屬於完成成本,留下紀錄才能比較下一版是否真的改善。

若團隊本來已使用線上入口,可以先用相同驗收條件建立對照,再試自建服務。這樣能把模型能力、工具實作與設備效能的差異拆開,避免同時改變太多條件,最後卻無法解釋結果。

對需要長期保存研究的機構,環境紀錄還包含模型設定檔與套件鎖定資料。因為幾個月後重新安裝時,預設版本可能已更新,完整紀錄能減少重建環境時的猜測,也讓研究結果更容易交接給同事。

Kimi 自訂授權的兩組門檻怎麼讀?

模型服務經營者與大型產品的條款,使用不同收入期間與門檻。官方 LICENSE 允許使用、複製、修改、部署與建立衍生作品,同時要求保留著作權和授權聲明等條件。

第二條針對模型即服務業務。原文把它定義為提供第三方推論或微調存取,且對方能實質控制輸入、參數或訓練資料,並列出特定嵌入式終端產品與單純轉送請求的排除範圍。

若使用者或關係企業經營這類業務,且合計收入在任何連續十二個月超過二千萬美元,商業使用前需要與 Moonshot 另訂協議。收入條件涵蓋使用者與關係企業,期間也是連續十二個月。

第三條處理另一種情況。使用模型的特定商業產品或服務,若月活躍使用者超過一億,或每月收入超過二千萬美元,需在介面顯著顯示「Kimi K3.1-Pro」。

這兩條的收入期間不同,因此整理部署條件時,應各自保留原文。把年收入與月收入門檻混在一起,會改變條款描述的適用範圍。

第四條另外寫出例外,第二條與第三條不適用於原文定義的內部使用,也不適用於經 Moonshot 官方產品或認證推論合作夥伴取得的使用方式。

其中內部使用有具體定義,包含不把模型、輸出或底層能力提供給第三方。組織應按自己的服務方式對照完整文件,必要時再由負責授權的人確認實際適用條件。

建議先保存當次下載的 LICENSE,與模型修訂版一起歸檔。當技術配置與使用範圍都留下紀錄,後續擴大服務時才容易知道哪些條件需要重新檢查。

Kimi K3.1 Pro 權重常見問題

權重檔案大小可以直接當作顯存需求嗎?

檔案大小描述下載與儲存量,運行還包含模型狀態和工作緩衝。實際需求會隨引擎、精度、上下文與並行量改變,因此應以對應設備上的試跑紀錄規劃。

有權重就能重現線上服務的速度嗎?

線上服務包含提供者的設備、排程與軟體最佳化,自建配置需要另外量測。先固定輸入、推理強度與完成條件,才容易比較同品質工作的總耗時。

這次應該先測什麼?

可以先選一項已有驗收答案的短任務,跑通文字、影像與一輪工具回傳,再逐步增加上下文與同時請求數。每一步保留版本與資源紀錄,讓下一次調整有共同基準。

建議把一次小範圍且可重現的試跑完成,再估算持續服務的資源與維運成本。這樣才能把權重正式可取得的新進度,轉成符合自己需求的部署選擇。

延伸閱讀:Kimi K3.1 Pro 發布:百萬 Token 與開放時間,完整權重仍要等到 11 月

延伸閱讀:Kimi K3 開放權重下載:2.8 兆參數、100 萬 Token,真的能在本機執行嗎?

原始資料來源