自行託管 Kimi K3 需要多少硬體？

自行託管 Kimi K3 的需求

自行託管 Kimi K3，代表必須為 2.8 trillion 個參數提供足夠的儲存空間。Moonshot 以 MXFP4 格式發布開放權重；每個權重約佔 half a byte，因此光是權重就約為 1.4 TB，還未配置任何 token cache。現今在售的加速器沒有任何一款能單獨容納這些權重。K3 是多節點模型，因此單一伺服器無法執行。

這就是結論。以下內容說明背後的計算方式，因為這些計算也能套用到下一個版本。2026 年 7 月 17 日發布公告後的數週內，數家基礎架構供應商發布了 K3 部署指南，但每份指南都假設你已經擁有叢集。本頁從另一端開始：需要多少成本、可以改為執行哪些模型，以及如何判斷自己屬於哪一種情況。

總參數量與啟用參數量不同

K3 是混合專家模型。MoE（mixture of experts）會將網路分割成許多子網路，並讓路由器針對每個 token 選擇其中幾個。模型卡列出總參數量為 2.8T，每個 token 啟用 104B 個參數；這些參數來自 896 個路由專家，其中任一 token 會啟用 16 個專家，分布於 93 層中。

這兩個參數量回答的是不同問題。在每個「能否執行這個模型」的討論串中，混淆兩者都是最常見的錯誤。

啟用參數量決定運算成本。 每個 token 約需透過 104B 個參數進行計算，因此預期吞吐量應接近 104B dense 模型，而不是 2.8T 模型。這正是建立 MoE 的原因。

總參數量決定記憶體成本。 路由器可能在任何 token 上選取任何專家，因此第一個請求到達前，所有專家都必須常駐記憶體。你無法只將 104B 個參數放在 VRAM 中，再於需要時擷取其餘參數，因為擷取作業必須在微秒內完成，而 PCIe 連結每秒只能傳輸數十 GB。確實有人會嘗試這麼做。從 NVMe 串流專家會讓原本應能每秒產生數十個 token 的模型，變成每隔幾秒才產生一個 token。

因此，這類模型的運算成本低，但儲存成本高。請以 2.8T 評估硬體需求，以 104B 評估速度預期。

每個權重所占的位元組，以及 TB 的來源

參數數量乘以每個權重所占的位元組數。對權重而言，完整公式就是如此。

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 在訓練時已納入量化感知，並以 MXFP4 權重與 MXFP8 activations 發布，因此 4-bit 那一列才是實際情況。上方各列是用來比較的：若相同模型採用 bf16，權重需要 5.6 TB。MXFP4 還會為每 32 個權重儲存一個共用的 8-bit scale，因此額外增加約 6 percent；所以已發布的 repository 實際容量接近 1.5 TB，而不是整整 1.4 TB。

這也排除了常見的退路。「直接量化」在這裡沒有幫助，因為發布的 checkpoint 已經是 4-bit。降至 2-bit 可將權重降到 0.7 TB，但會造成沒有人在此 checkpoint 上測量過的準確度損失。即使如此，所需容量仍遠超任何單張卡。

Kimi K3 需要多少張 GPU

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

請將這些數字視為下限，而不是目標。它們只計算權重，不包含 KV cache、activation buffer、allocator fragmentation，也沒有為同時處理第二個請求保留空間。此外，這些數字假設平行切分可以平均分配，但 93 個 layer 與 896 個 expert 並不一定能做到這點。

已發布的建議配置明顯高於下限。截至 2026 年 8 月，Moonshot 建議使用 64 個以上 accelerator 組成的 supernode；SGLang cookbook 則提供一個由 4 個 8-GPU node 組成的 H100 配置，共 32 張 GPU、總計 2,560 GB 記憶體，而權重所需的下限是 18 張卡。這項差距並非浪費，而是用於 KV cache、activation memory，以及讓伺服器能同時批次處理多個請求的餘裕。即使是最寬鬆的配置，5 張 GB300 class 卡也代表一台大多數 provider 不會以單一 SKU 出租的機器。

KV cache 的成本最容易讓人意外

Weights 是固定成本。KV（key value）cache 則不是：它會隨 context length 增加，也會隨並行使用者數再次增加。對一般 attention 而言，公式是 bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element，接著再乘以 context length 和並行數。

以下是計算範例，僅供示範：64 layers、8 KV heads、head dimension 為 128、使用 fp8。計算結果為 2 64 8 128 1 = 131,072 bytes，因此每個 token 需要 128 KiB。

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

單一使用者使用 128k context 時，需要 16 GiB。單一使用者使用完整的 million context 時，需要 128 GiB；對單一對話而言，這已超過任何單張 card 的容量。

K3 不使用一般 attention，最後這個數字正是原因。它的 93 layers 中，有 69 個 KDA（Kimi Delta Attention）layers 和 24 個 Gated MLA（multi-head latent attention）layers。KDA 使用固定大小的 recurrent state，不會像 cache 一樣隨每個 token 增長；MLA 則將 key 和 value 壓縮成單一的 low rank latent vector，因此實際的每 token 成本遠低於上述計算範例。Moonshot 尚未公開 latent dimensions，因此我不會替 K3 本身提供每位使用者的數值。請改為測量自己的環境：先以較小的 --max-model-len 啟動 server，使用 nvidia-smi 監控記憶體，再逐步提高上限，直到 allocation 失敗。

這個推理方式在下一個 release 仍然適用。如果模型宣稱支援 million token context，卻未說明其 attention 設計，請先假設 cache 是限制因素，直到有人提出相反證據。

第 1 層：按小時租用叢集

這是唯一會執行 K3 本身的層級。您不需要購買硬體，而是在需要的時段租用，使用完畢後停止執行個體。

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

這個費率是估算值，不是報價。2026 年期間，資料中心加速器的隨選牌價大致介於每 GPU 小時 2 到 5 USD 之間，保留容量的價格更低。請採用供應商的實際費率，重新計算：GPU 數量乘以小時數，再乘以費率。圖表重點在於比例。每天讓 8 GPU 節點突發執行 4 小時，每月成本為 2,400 USD；讓符合 SGLang 規模的 32 GPU 設定持續執行，每月成本則為 57,600 USD。

兩個主流伺服器都會在 model card 上提供啟動命令。

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

在實際叢集上，不能直接執行這兩個命令。請加入符合硬體配置的平行處理旗標：SGLang 使用 --tp-size 設定 tensor parallel，使用 --ep-size 設定 expert parallel，而且兩者的乘積必須等於實際配置的 GPU 數量。

傳送實際網路流量前，先確認伺服器已啟動：

curl http://127.0.0.1:30000/v1/models

正常運作的伺服器會以 JSON 物件回應，並列出 model id。Connection refused 表示程序仍在載入權重，或已經結束執行。因此，重新嘗試前請先查看伺服器日誌。

第一天最常見的故障，是執行環境版本早於模型需求。K3 隨附 KDA 及新的 MoE layer，但穩定版 vLLM 和 SGLang 在推出時尚未支援這些元件。常見症狀是伺服器在啟動期間結束執行，並出現類似 Model architectures [...] are not supported for now 的訊息。這不是設定變更可以修正的問題，因為您的 build 中沒有執行這些 layer 所需的程式碼。請安裝 model card 指定的 nightly 版本，或等待包含該功能的 release。

還有一項容易忽略的成本。計費從 instance 啟動時開始，而不是從模型就緒時開始。以 1 GB/s 下載 1.5 TB 資料約需 25 分鐘，這段時間會計入叢集使用時間，之後才會產生第一個 token。請將權重預先放在生命週期長於 instance 的 volume 上，讓第二次執行可在數分鐘內開始。

Tier 2：在單一加速器上執行較小的模型

在這個層級中，您不會執行 K3。開始前請先明確說明這點，因為大多數「在本機執行 K3」的討論，最後都會停在這裡，卻不承認這一點。

容量估算規則相同，只是套用在較小的規模：參數數量乘以每個權重所占的位元組數，再加上 KV cache 與約 2 GB 的執行階段額外負載，總量必須低於 VRAM。使用 4-bit 時，每個參數約占半個位元組，因此可搭配下列配置：

• 16 GB 顯示卡：使用 4-bit 的 7B 模型，並保留足夠空間給較長的 context
• 24 GB 顯示卡：使用 4-bit 的 14B 模型
• 48 GB 顯示卡：使用 4-bit 的 32B 模型
• 80 GB 顯示卡：使用 4-bit 的 70B 模型，或使用 8-bit 的 30B 級 MoE 模型

Ollama 是在 已連接 GPU 的 VPS 上建立可用伺服器的最短途徑：

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run 會在首次使用時下載模型，接著顯示提示字元。不存在的標籤會回傳 Error: model "..." not found，因此請從 library 頁面複製標籤，不要憑記憶輸入。完整操作說明包含 systemd unit 與遠端存取設定，請參閱在 VPS 上執行 Ollama。

llama.cpp 可讓您更精確地控制 quantisation 與 offload：

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 會要求將每一層都放到 GPU 上。請查看載入日誌，其中會列出已 offload 的層數。溢出至系統 RAM 的層會使用 RAM 頻寬，而不是 HBM 頻寬，因此模型一旦無法完整放入記憶體，生成速度就會降低一個數量級。兩項工具之間的取捨，請參閱Ollama 與 llama.cpp 並列比較。

第 3 層：代管 API、自行託管編排

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

端點相容於 OpenAI，因此只要修改 base URL，現有的 client 即可運作。

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

可正常運作的 key 會傳回包含 choices 陣列的 JSON 物件。出現 401，表示 key 錯誤或缺少 Bearer 前綴。出現 model-not-found 錯誤通常表示 id 已變更，因為供應商會在不同 checkpoint 之間淘汰 id。

接著計算損益平衡點，並使用上述假設的租用費率。持續運作的 8 GPU 節點每月成本為 14,400 USD；以每百萬輸出 token 15.00 USD 計算，同樣的費用約可向 API 購買 960 million 個輸出 token。若要在成本上勝出，每月必須產生接近 1 billion 個輸出 token，約每天 30 million 個，並讓叢集全程保持忙碌，因為閒置 GPU 與忙碌 GPU 的計費費率相同。以 prompt 為主的 agent 工作負載會讓損益平衡點更難達成：重複的 context 會依每百萬 0.30 USD 的 cache-hit 費率計費，而不是每百萬 3.00 USD 的 cache-miss 費率。

在這一層自行託管的是模型周邊的所有元件：保存 API key、避免 key 傳到 client 的 gateway、請求與回應日誌、重試機制、速率限制，以及每位使用者的預算。這些元件可在完全不具備 GPU 的小型 VPS 上執行。相同的分工也適用於封閉權重；在模型層級無法 自行託管 Claude，因此你能掌控的只有編排部分。

哪種 serving stack 對應哪個層級

vLLM 與 SGLang 類型的伺服器屬於 tier 1。它們用於同時處理大量請求，支援 continuous batching 與 paged KV cache，並可透過 tensor parallelism 和 expert parallelism，將負載分散到多個節點。這類伺服器預設使用資料中心加速器，以及加速器之間的高速互連。在單張消費級顯示卡上，它們的安裝負擔較重，實際可感受到的優勢也很少。

llama.cpp 與 Ollama 屬於 tier 2。它們以單機、GGUF quantisation、模型無法完整載入時的 CPU offload，以及低並行度為目標。llama.cpp 技術上可以將大型 MoE 載入，方法是把大多數 layer 保留在 system RAM；但對 2.8T 模型而言，這種方式的速度是每個 token 需耗時數秒。這只能證明檔案可通過解析，不能作為可供使用者使用的服務。完整比較請參閱 Ollama 與 vLLM 的比較。模型不同不會改變判斷方式：關鍵始終在於，你是在共用硬體上服務多位使用者，還是在自己的機器上服務單一使用者。

這個檢查點之後仍然適用的 4 個數字

1. 參數總數乘以每個權重的位元組數，就是記憶體下限。低於這個下限無法執行；而當模型發布時已經是 4-bit 後，任何量化技巧也很難大幅降低此數值。
2. 啟用參數決定吞吐量級別。具有 2.8T 參數、其中 104B 個參數啟用的 MoE，其計算量相當於 104B 模型。
3. 每個 token 的 KV cache 大小，乘以 context length，再乘以並行數，就是載入權重後仍會持續增加的成本。
4. 每美元每秒可處理的 token 數，是唯一能決定層級的數字。以上所有數值都是它的輸入。

將這 4 個數字套用到任何版本，就能在查閱供應商指南前得到正確答案。接著為記錄的每個數值標註日期。K3 推出後的 2 週內，價格與支援的架構清單都已變更；本頁所有數值均為 2026 年 7 月發布的數值。

FAQ

Kimi K3 可以在單張 GPU 上執行嗎？

不行。Moonshot 發布的 MXFP4 精度權重約為 1.4 TB，而目前在售的最大單張加速器僅有 288 GB。MoE 模型無法以可用速度從磁碟串流未啟用的 experts，因為 router 可能在任何 token 選取任何 expert，而 PCIe 擷取所需時間遠超過 token 預算。K3 最小的合理部署方式是多 GPU 節點，已發布的部署配方使用 32 張以上的加速器。

Kimi K3 需要多少 VRAM？

僅權重就需從 1.4 TB 起算，相當於 18 張 H100 80GB 或 5 張 GB300 類別卡。除此之外，還要加上 KV cache 與 activation memory。截至 August 2026，Moonshot 建議使用 64 張以上的加速器；SGLang cookbook 則發布了使用 32 張 H100 GPU、總容量 2,560 GB 的設定，因此應將權重容量視為最低值，而非實際需求。

量化能讓 Kimi K3 塞進單一節點嗎？

沒有實際幫助。發布的 checkpoint 已採用 4-bit 量化感知訓練，因此容易取得的容量節省已經用盡。再次降至 2-bit 可將權重降至 0.7 TB，但仍超過最大單卡容量的兩倍；而且目前尚未量測 2-bit 對此模型的準確率影響。

租用 GPU 比 Kimi K3 API 便宜嗎？

只有在使用量高且穩定時才可能。假設每張 GPU 每小時 2.50 USD，持續運作的 8 GPU 節點每月成本為 14,400 USD；相同金額依照公布的 15.00 USD／每百萬 output tokens 費率，約可購買 960 million 個 output tokens。此外，還要支付閒置時數、權重下載，以及維持叢集運作的人力成本。突發工作負載可按小時租用，並應以實際量測的 token 使用量比較，而不是依據估算值。

104B active parameters 對速度有何意義？

這表示每個 token 的運算量相當於 104B 模型，因此吞吐量會落在這個級別，而不是 2.8T 級別。這不代表記憶體需求：全部 2.8T parameters 都會常駐，因為 router 可能在任何 token 呼叫任何 expert。使用 active count 預估每秒 token 數，並使用 total count 規劃 VRAM。