Kimi K3 能本地部署嗎？8 張頂級 GPU 起跳

Kimi K3 的完整 checkpoint 約 1.56TB。就算用了 MXFP4 權重，也不是一張消費級顯卡能塞進去的模型。

目前公開的最低配置是 8 張高容量資料中心 GPU，不是先前流傳的固定 64 卡門檻。但這個「8 張」有很嚴格的前提：你用的是 GB300、MI350X 或 MI355X 這種每張就有大容量 HBM 的硬體，而且目標只是先把模型載入、啟動並驗證。

能載入模型，離能承接正式流量還很遠。

如果你還沒看過整套發布內容，可以先讀 Kimi K3 開放權重總整理。這篇只回答一件事：Kimi K3 可以怎麼部署，以及一般團隊該不該自己架。

Kimi K3 可以本地部署嗎？

可以，但這裡的「本地」是自有資料中心或租用 GPU 叢集，不是桌下工作站。

K3 是 2.8T 參數的 Mixture-of-Experts 模型，每個 token 啟用約 104B 參數。這個設計會減少每次推論的計算量，卻不會把模型檔案縮成 104B。原因很直接：下一個 token 可能被 router 分到另一批 experts，完整 expert 權重仍要分散放在叢集記憶體裡。

AMD 的 Day 0 分析把 checkpoint 算到約 1.5609TB。採用 8 張 MI355X 做 TP8 時，每張 GPU 載入約 190.974GiB 權重。再把一條 100 萬 token 序列的已知 runtime state 算進去，單卡約使用 205.401GiB。MI355X 每張有 288GiB HBM，因此帳面上還剩約 82.6GiB。

但這個餘量不是免費空間。Grouped GEMM、KDA、attention workspace、通訊 buffer、記憶體碎片與框架本身都會繼續吃容量。AMD 也沒有在這篇文章宣稱 throughput、首 token 延遲或每 token 延遲。

所以 8 卡代表「有一條已驗證的起跑線」，不代表「8 卡就是 production 規格」。

8 張 GPU 是所有硬體的最低門檻嗎？

不是。卡數取決於每張 GPU 的 HBM、低位元支援、節點互連和推論引擎。

這張表不能拿來比速度。每個配置的拓撲、context、並行策略和驗證狀態都不同。它只說明一件事：看到「8 卡能跑」時，先問是哪一張卡。

官方模型頁目前列出 vLLM recipe、SGLang cookbook與 TokenSpeed recipes。如果你的硬體沒有出現在這些配置中，不要只把 GPU 數量湊到一樣就照抄參數。

vLLM、SGLang 與 ATOM 怎麼選？

vLLM 適合已經使用 OpenAI 相容服務介面、希望先用官方容器啟動的團隊。K3 recipe 要求 vLLM 0.27.0 以上，NVIDIA 路線目前使用 CUDA 13 容器與新版驅動；AMD 則有獨立 ROCm image。文件也直接提醒，真正的 production traffic 應使用多節點。

SGLang 的優勢是配置矩陣更完整。它列出 B300、GB300、B200、GB200、H200、H100 與 MI35x 的節點形狀，也把低延遲、平衡、長上下文與 prefill/decode 分離放進同一套 cookbook。不過部分 serving round 仍在驗證中，文件明確要求使用者在自己的負載上重新測 throughput 與 accuracy。

ATOM 是 AMD 展示的 Day 0 路徑。8 張 MI355X 的配置已能啟動 OpenAI 相容服務，並完成基本正確性檢查。它證明 K3 可以塞進單一 8-GPU AMD 節點，但目前公開文章的重點是載入和功能驗證，不是正式效能比較。

底層還牽涉 KDA kernel、MoE 通訊與 Agent 沙箱。如果沒有熟悉 tensor parallel、expert parallel、RDMA 或 NVLink 的工程師，換一個 serving framework 不會自動把營運問題消掉。

100 萬 token 也能直接跑滿嗎？

模型支援 1,048,576 tokens，但部署時填入這個數字，不代表系統就能在合理併發下跑滿。

K3 的 69 層 KDA 使用固定大小 recurrent state，只有 24 層 Gated MLA 保存隨序列增長的 latent KV。這比每一層都留完整 KV cache 節省，但 100 萬 token 的 runtime state、prefill 時間與暫存空間依然可觀。Kimi K3 技術報告拆解有更完整的架構說明。

AMD 的容量估算把一條 100 萬 token 序列算進記憶體表，實際 Day 0 啟動命令卻先設為 16K。這不是矛盾。前者回答「理論容量怎麼分配」，後者回答「先用什麼設定完成驗證」。正式部署還要加入併發與服務品質目標。

一般團隊該選 API 還是自架？

沒有現成資料中心叢集的團隊，先用 API。

Kimi 官方提供 kimi-k3 API，也相容 OpenAI 與 Anthropic 介面。你可以先用真實任務測 coding、長文件、視覺輸入與工具調用，再判斷資料治理或使用量是否足以支持自架。這比先買硬體，再想模型要解決什麼問題安全得多。

已經有 8 張高容量 GPU 的研究單位，可以從官方 recipe 做載入和正確性驗證。第一輪先固定 context、batch size 與 reasoning effort，記錄峰值記憶體、錯誤率和工具調用格式，再逐步增加併發。

真的要承接正式流量，至少還要補五項：

1. 符合 recipe 的驅動、容器與推論引擎版本。
2. 高頻寬 GPU 互連，以及跨節點 RDMA 或對應傳輸方案。
3. checkpoint 下載、掛載、啟動和故障恢復流程。
4. 依實際平均輸入長度規劃 KV cache、KDA state 與最大併發。
5. 用自己的任務重跑 accuracy、工具調用與多輪 preserved thinking history。

若你只是要熟悉本地推論，麗臺 RTX PRO 4000 Blackwell 24GB可以用來測較小的量化模型。它不是 K3 硬體方案，也不能拿來推估 K3 叢集的速度。

常見問題

Kimi K3 可以用單張 GPU 在本地執行嗎？

不行。完整 checkpoint 約 1.56TB，公開配置最低也使用 8 張 GB300 或 MI350X／MI355X 等高容量資料中心 GPU。

每次只啟用 104B 參數，為什麼仍需要這麼多記憶體？

104B 是每個 token 實際參與計算的參數量，不是要載入的權重總量。不同 token 可能選到不同 experts，完整 2.8T 權重仍要分散常駐在 GPU 叢集。

8 張 GPU 就能正式部署 Kimi K3 嗎？

只能說部分高容量 GPU 已有 8 卡載入與驗證配置。正式流量還要評估上下文長度、併發、網路、快取與框架開銷，vLLM 也直接建議 production 使用多節點。

Kimi K3 應該用 vLLM 還是 SGLang？

先依現有硬體選官方已驗證的 recipe。vLLM 的入門文件較集中，SGLang 提供更多硬體拓撲與長上下文配置；沒有資料中心叢集的團隊直接使用 Kimi API 會更合理。

支援 100 萬 token，部署後就一定能跑滿嗎？

不一定。模型規格支援 100 萬 token，但實際可用長度還受 GPU 容量、併發與 runtime 設定影響。AMD 的 Day 0 啟動範例就先把最大長度設為 16K。

我的判斷

K3 開放權重的重要性，不在一般人終於能把它塞進家用電腦。恰好相反，它把前沿 open-weight 模型的部署現實攤得很清楚：權重可以公開，運算能力仍高度集中在少數有叢集的團隊。

對大多數開發者，現在合理的動作是用 API 驗證任務，把自架當成資料治理、規模或研究需求出現後的第二步。已經有硬體的團隊也不該只問「能不能啟動」，而要問自己的 context、併發與延遲目標能不能被這套拓撲穩定承接。

你手上的需求，真的需要掌控 1.56TB 權重，還是只需要一個可替換的 API 介面？先回答這題，再決定要不要自架。

利益揭露：本文部分連結為聯盟連結，點擊購買我會獲得回饋，不影響你的價格。

資料來源：Kimi K3 GitHub、Kimi K3 Hugging Face、Kimi K3 技術報告、vLLM K3 recipe、SGLang K3 cookbook、TokenSpeed recipes、AMD Kimi K3 部署說明、Kimi API 文件。