Kimi K3 自行部署指南
Kimi K3 可以自己部署嗎？
完整權重已經公開。真正的問題是：2.8 兆參數、每次啟用 1040 億參數與 1M context， 要穿過哪些硬體、軟體和授權閘門？
可以自行部署，但官方推薦路徑是資料中心級自建，不是一般桌機下載後直接執行。
OPEN WEIGHTS ≠ ONE-CLICK LOCAL
權重打開了，部署還有四道門
Moonshot AI 已公開 Kimi K3 的完整權重、模型卡、技術報告與部署入口。 團隊可以研究、修改、微調，也能在自己的環境提供推論。
這不代表一般桌機或一張消費級顯示卡就能把模型跑起來。 權重取得、儲存空間、GPU 叢集、推論引擎與授權，是不同問題。
公開權重解決「能不能取得並控制」；硬體與維運決定「能不能穩定服務」。
896 EXPERTS｜16 ROUTED PER TOKEN
每次只亮 16 扇門，整棟樓仍然存在
Kimi K3 有 896 個 routed experts。每處理一個 token，路由器挑選其中 16 個， 另有 2 個 shared experts。下一個 token 可以走進另一組 experts。
1040 億啟用參數比較像「這一步有多少設備正在工作」； 2.8 兆總參數則是「整座工廠要容納多少設備」。
WEIGHT STORAGE｜CLUSTER FLOOR
4 bit 很省，仍是 TB 級問題
Kimi K3 使用原生 MXFP4 權重。只以 4 bit 乘上 2.8 兆參數估算， 權重本體的理論下限約為 1.4 TB。
實際部署還有量化中繼資料、執行環境、快取與其他開銷。 因此 1.4 TB 不是完整記憶體需求，也不能拿來直接開採購單。
CAPACITY ≠ DEPLOYMENT PROOF
六種容量組合，只有兩條有直接部署證據
下表用官方 GPU 規格重算名目容量與單卡本地記憶體頻寬，再把「容量算得出來」和 「已有 Kimi K3 官方部署路線」分開。這不是報價單，也不代表相同總容量會得到相同性能。
不是完整執行記憶體需求
目前顯示六種容量組合。橘點代表只有容量推算，不能直接當成 Kimi K3 採購建議。
| GPU 組合 | 名目總 VRAM | 權重占名目容量 | 單卡本地頻寬加總* | Kimi K3 證據 |
|---|---|---|---|---|
| 80 × RTX 5090 32GB GDDR7／張 | 2.560 TB | 約 61% | 143.36 TB/s | 容量推算；官方路線未列此組合 |
| 32 × H100 SXM 80GB HBM3／張 | 2.560 TB | 約 61% | 107.20 TB/s | 卡數為容量推算；不是現成 recipe |
| 16 × H200 141GB HBM3e／張 | 2.256 TB | 約 69% | 76.80 TB/s | 卡數為容量推算；不是現成 recipe |
| 16 × B200 180GB HBM3e／張 | 2.880 TB | 約 54% | 128.00 TB/s | 卡數為容量推算；不是現成 recipe |
| 8 × B300 288GB HBM3e／張 | 2.304 TB | 約 68% | 64.00 TB/s | vLLM 列為最容易執行的 day-0 路線 |
| 8 × MI355X 288GB HBM3E／張 | 2.304 TB | 約 68% | 64.00 TB/s | vLLM 路線；AMD 已驗證 TP8 載入與正確性 |
*「單卡本地頻寬加總」只是各 GPU 峰值記憶體頻寬的算術和，不是跨卡或跨節點實效。 NVLink／Infinity Fabric、RDMA、collective communication 與 serving engine 都會改變結果。
權重占比以 1.5609TB checkpoint 除以廠商名目總容量估算；尚未計入 KV cache、工作區、 通訊 buffer、記憶體碎片與執行框架。AMD 的已驗證 TP8 分析顯示，1M context 還會再占用已知 runtime state。
CONTEXT IS A CEILING, NOT A DEFAULT
1M context 是上限，不是免費空間
模型卡列出的 context 上限是 1,048,576 tokens。 長程式庫、文件集、圖像與長時間代理工作，有機會留在同一段工作記憶裡。
上限不代表每次請求都該塞滿。長 context 會增加 prefill 時間、快取與資料治理負擔。 「支援 1M」和「能以可接受成本穩定服務 1M」是兩件事。
32K：適合先測實際文件與程式庫，不必一開始追求最大 context。
THREE DEPLOYMENT PATHS
能自建，不代表現在就該自建
台灣團隊做決策時，先看資料能否交給外部服務、使用量是否穩定， 以及公司有沒有多 GPU 叢集維運能力。這三項比「權重能下載」更接近真實採購問題。
先驗證模型是否真的適合工作
適合用量不穩定、團隊沒有叢集維運人員，或仍在比較模型的階段。 交換：少一部分基礎設施控制，不用先投入八張資料中心級 GPU。
要求區域、隔離與服務承諾
適合資料位置、延遲或合規要求明確，但不想自行維護驅動程式、網路與 serving engine 的團隊。 採購時仍要問資料留存、日誌、模型版本、故障切換與實際硬體。
把控制權與維運責任一起接下來
適合有穩定高用量、資料不能離開指定環境，而且已具備叢集維運能力的團隊。 硬體只是第一張清單；Docker、通訊、監控、容量規畫與授權都要一起算。
LICENSE TURNSTILE
公開權重仍有商業條件
Kimi K3 License 允許使用、複製、修改、部署、微調與建立衍生作品。 企業仍應依使用方式、營收與產品規模，逐條檢查授權。
「公開權重」也不等於訓練資料、訓練流程與完整生產環境都能被外界重建。 採購時要把模型取得、授權、部署工具成熟度與內部維護能力分開評估。
以上依 2026-07-29 公開授權文字整理，不是法律意見；實際商業使用請依完整授權與公司情況確認。
THE LAST GATE
Kimi K3 能自建，但不是桌機級本機模型
權重公開讓團隊取得控制權；資料治理、穩定用量與維運能力，才決定自建是否比 API 合理。
- 資料是否真的不能交給外部 API？
- 使用量是否足以長期占滿多 GPU 叢集？
- 公司是否有人能維護 Docker、跨節點通訊、監控與 serving engine？
三題只要有一題沒有明確答案，先用 API 或代管環境驗證需求， 通常比先買硬體更合適。
