前言¶

2026 年 7 月 27 日，Moonshot AI 在 Hugging Face 與 GitHub 同步發佈了 Kimi K3 的全量模型權重與技術報告配套代碼倉庫。這是迄今公開可下載的、參數規模最大的開源權重模型之一——總參數量 2.8 萬億（2.8T），推理時激活約 1040 億（104B），上下文窗口達 100 萬 token。

在此之前，同等量級的模型幾乎只存在於閉源 API 中。K3 的放出，讓「開源權重能否追平閉源前沿」再次成爲開發者社區的熱點討論。本文基於 MoonshotAI/Kimi-K3 官方倉庫與 Hugging Face 模型頁 覈實關鍵信息，從架構、量化、評測到自託管部署逐一梳理。

Kimi K3 是什麼¶

Kimi K3 是 Moonshot AI 的旗艦級原生多模態 Agent 模型，支持文本與圖像輸入，面向長週期編碼、知識工作、推理與工具調用場景。官方將其定位爲「世界上首個開放的 3T 級模型」（Open 3T-class model）。

與上一代 Kimi K2 系列相比，K3 的主要變化包括：

• 稀疏 MoE 規模大幅擴展（896 專家，每 token 激活 16 個）；
• 上下文從 K2.6 的約 25 萬 token 擴展到 1048576 token；
• 引入 Kimi Delta Attention（KDA） 與 Attention Residuals（AttnRes），配合 Stable LatentMoE 框架，官方稱相較 K2 整體 scaling 效率提升約 2.5 倍。

若暫時無法承擔自託管成本，也可通過 Kimi API 調用 kimi-k3 模型。官方提供 OpenAI / Anthropic 兼容接口，定價爲：緩存未命中輸入 \(3 / 百萬 token**，緩存命中 **\)0.30 / 百萬 token，輸出 $15 / 百萬 token。

架構與關鍵參數¶

K3 採用 Mixture-of-Experts（MoE） 稀疏架構，核心規格如下（數據來自官方 README）：

KDA（Kimi Delta Attention） 是 Moonshot 爲長上下文與大規模 MoE 設計的注意力機制。KDA 將 KV 緩存壓縮爲固定大小的狀態向量，官方技術博客稱在 128K 上下文下可將 KV 緩存佔用降至標準 MLA 的約 1/16，在 1M token 場景下優勢更明顯。推理框架需實現 KDA 內核才能正確加載模型，因此不能直接用舊版 vLLM 跑通。

K3 默認始終開啓 thinking 模式，API 會返回 reasoning_content 字段；多輪對話需將完整的 assistant 消息（含 reasoning 與 tool_calls）原樣傳回，這與普通 chat 模型的用法略有不同。

原生 MXFP4 量化¶

K3 從 SFT 階段起 即採用量化感知訓練（Quantization-Aware Training），最終以 MXFP4 權重 + MXFP8 激活 的形式發佈。這是首個在該體量上以原生 4-bit 權重形式開源的主流模型。

MXFP4 的意義在於：在約 2.8T 參數量下，若按 4 bit/參數估算，純權重數據約 1.4 TB 量級；實際 Hugging Face 上的 MXFP4 權重包體積約 594 GB 左右（含量化元數據與分片）。相比 FP16 全精度，下載與存儲成本顯著下降，但對 GPU 的低精度算力與推理框架支持提出了更高要求。

部署時需顯式指定 --quantization mxfp4，並開啓 --trust-remote-code 以加載 KDA 自定義算子。

編碼與 Agent 評測表現¶

官方在 README 中公佈了與 Claude Fable 5、GPT-5.6 Sol 等閉源模型的對比結果（K3 使用 reasoning_effort=max）。編碼與 Agent 相關基準摘錄如下：

可以看到，K3 在 Terminal-Bench 2.1、SWE-Marathon 等終端與長週期編碼任務上表現突出，部分指標與閉源前沿模型互有勝負。需要留意的是：不同基準使用的 Agent harness 並不統一（Kimi Code、Codex、Claude Code 等），橫向對比時應結合官方腳註理解，不宜簡單得出「全面超越閉源」的結論。

社區討論「開源追平閉源」，更多是指：在若干編碼與 Agent 榜單上，K3 已具備與閉源旗艦同臺競技的能力，而非每一項基準均領先。

自託管推理：vLLM 部署要點¶

權重公開後，Moonshot 同步提供了 vLLM、SGLang、TokenSpeed 的部署指引。其中 vLLM 的正式 recipe 見 recipes.vllm.ai/moonshotai/Kimi-K3。

硬件門檻¶

這是 K3 自託管最需要正視的一點：它不是「單卡或八卡就能跑起來」的桌面級模型。

• 官方 vLLM recipe 建議至少 8× GB300，生產流量需多節點；
• Moonshot 文檔推薦 64 及以上加速器 的超節點（Supernode）配置；
• ROCm 路徑需 8× MI355X / MI350X 及對應 Docker 鏡像。

即便 MXFP4 已將權重量壓至約 594 GB，單張 H100（80 GB 顯存）仍無法容納完整模型；tensor parallel 與 expert parallel 跨節點分佈式推理是常態。長上下文（如 1M token）還會額外佔用大量 KV cache，實際部署時通常需將 max-model-len 從較小值（如 131072）起步，再按顯存與吞吐需求逐步調高。

vLLM 啓動示例¶

官方推薦使用 K3 專用 Docker 鏡像 vllm/vllm-openai:kimi-k3（基於 CUDA 13，主機驅動需 r580+）。典型啓動參數思路如下：

# 使用官方 K3 鏡像（CUDA 13 / cu130）
docker pull vllm/vllm-openai:kimi-k3

# 單機 8 卡示例（具體參數以官方 recipe 爲準）
python -m vllm.entrypoints.openai.api_server \
  --model moonshotai/Kimi-K3 \
  --trust-remote-code \
  --quantization mxfp4 \
  --tensor-parallel-size 8 \
  --max-model-len 131072 \
  --served-model-name kimi-k3

幾點實踐建議：

1. --trust-remote-code 必須開啓，否則 KDA 自定義 CUDA 算子無法加載；
2. --quantization mxfp4 對應模型原生量化格式，Blackwell 硬件可直連硬件格式，H100/H200 上由框架模擬；
3. 多節點 MoE 通信：跨節點建議配置 --all2all-backend deepep_v2（RDMA）或 flashinfer_nvlink_one_sided（NVLink）；
4. 服務啓動後暴露 OpenAI 兼容 API，現有 SDK 只需修改 base_url 即可接入。

若暫時不具備集羣條件，可先通過 Kimi API 或第三方託管推理（如 Telnyx 等合作伙伴）體驗，待硬件與運維能力就緒後再遷移至自託管。

開源許可與使用注意¶

K3 權重與代碼倉庫均採用 Kimi K3 License（自定義許可，非 OSI 標準開源協議）。根據社區對許可條款的解讀：

• 研究與大多數商業用途可免費使用；
• 若作爲 Model-as-a-Service 運營且 12 個月累計營收超過 2000 萬美元，需另行簽署商業協議；
• 產品 MAU 超 1 億 或 MRR 超 2000 萬美元 時，需在顯著位置標註「Kimi K3」品牌。

下載權重前建議通讀 LICENSE 文件，確認自身場景是否符合條款。

小結¶

Kimi K3 全量權重的釋出，標誌着開源模型首次在 3T 參數量級 上與閉源前沿正面交鋒。MXFP4 原生量化、KDA 長上下文注意力、百萬 token 窗口與多模態 Agent 能力，共同構成了其技術標籤；而 594 GB 級權重 + 64 卡超節點推薦配置，也清晰劃定了「能下載」與「能自建 serving」之間的鴻溝。

對絕大多數開發者而言，更現實的路徑是：先用 API 驗證業務場景，再評估集羣成本與合規要求，最後決定是否自託管。無論如何，K3 的發佈爲開源生態提供了可復現、可審計的 frontier 級基線，後續微調、蒸餾與垂直領域適配的工作值得持續關注。