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

自行託管 Kimi K3 的需求

自行託管 Kimi K3，代表必須為 2.8 兆個參數準備足夠空間。Moonshot 以 MXFP4 發布開放權重；每個權重約占半個位元組，因此光是權重就約為 1.4 TB，還未配置任何快取 token 的空間。目前市售的加速器沒有任何一款能單獨容納這個容量。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、啟用值緩衝區、配置器碎片，也沒有為第二個並行請求預留空間。此外，這些數字假設平行切分可以平均分配，但 93 個 layer 與 896 個 expert 不一定能平均切分。

已發布的建議配置明顯高於最低需求。截至 August 2026，Moonshot 建議使用包含 64 個以上 accelerator 的 supernode；SGLang cookbook 也提供以 4 個 8-GPU node 組成的 H100 配置，共 32 張 GPU 和 2,560 GB 的總記憶體，而最低需求僅為 18 張卡。這項差距不是浪費，而是用於 KV cache、啟用值記憶體，以及讓伺服器能同時批次處理多個請求的餘裕。即使是最有利的配置，使用 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 層、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。單一使用者使用完整 1 million context 時，需要 128 GiB；這個容量超過任何單張卡片所能容納的大小，而且只對應一段對話。

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

下一個版本發布後，這套推理方式仍然適用。如果模型宣稱支援 1 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。

兩種主流伺服器都會在模型卡上提供啟動命令。

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 設定張量平行，使用 --ep-size 設定專家平行，而且兩者的乘積必須等於實際擁有的 GPU 數量。

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

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

正常運作的伺服器會以 JSON 物件回應，並列出模型 ID。Connection refused 表示程序仍在載入權重，或已經結束，因此請先讀取伺服器日誌，再重新嘗試。

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

還有一項容易被忽略的成本。計費從執行個體啟動時開始，而不是從模型準備完成時開始。以 1 GB/s 下載 1.5 TB，大約需要 25 分鐘的叢集時間，之後才會產生第一個 token。請將權重預先存放在生命週期長於執行個體的磁碟區上，讓第二次執行能在幾分鐘內啟動。

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

在這一層不會執行 K3。開始前先明確說明這點，因為多數「在本機執行 K3」的討論最後都停在這裡，卻沒有承認這件事。

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

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

以上每種搭配都假設同時只有 1 個請求。當第 2 個人送出提示時，每個並行工作槽都需要自己的 KV cache。Ollama 的 NUM_PARALLEL 與 MAX_QUEUE 設定會在並行工作槽、排隊請求與剩餘 VRAM 之間替你進行取捨。

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

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

ollama run會在第 1 次使用時下載模型，然後顯示提示字元。不存在的標籤會回傳 Error: model "..." not found，因此請從程式庫頁面複製標籤，不要憑記憶輸入。完整操作流程，包括 systemd 單元與遠端存取，請參閱在 VPS 上執行 Ollama。

llama.cpp 可讓你更精細地控制量化與卸載：

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。請查看載入日誌，其中會列出已卸載的層數。溢出至系統 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 前綴。找不到模型的錯誤通常表示 id 已變更，因為供應商會在不同 checkpoint 之間淘汰 id。

接著計算損益平衡點，並沿用上述假設的租用費率。持續運作的 8 GPU 節點每月費用為 14,400 USD；以每百萬輸出 token 15.00 USD 計算，同樣的費用約可向 API 購買 960 million 個輸出 token。若要在成本上勝過 API，每月必須產生接近 1 billion 個輸出 token，約每天 30 million 個，並讓叢集全程維持忙碌，因為閒置 GPU 與忙碌 GPU 的計費費率相同。對於高度依賴 prompt 的 agent 工作負載，這個差距還會進一步擴大：重複的 context 會依照 cache hit 費率 0.30 USD／每百萬個 token 計費，而不是依照 cache miss 費率 3.00 USD 計費。

在這一層自行託管的，是模型周邊的所有元件：保存 API key、避免 key 傳到 client 的 gateway，request 與 response log、重試機制、速率限制，以及個別使用者的預算。這些元件可在完全不含 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 在技術上可以透過將大多數 layer 保留在系統 RAM 中來載入極大型 MoE；但對 2.8T 模型而言，這種方式的速度是每個 token 需耗時數秒。這只能證明檔案可以解析，不能作為讓使用者連線使用的服務。完整比較請參閱 Ollama 與 vLLM 的比較。無論模型為何，判斷標準都不變：你要服務的是共用硬體上的多位使用者，還是自己的單一使用者。

本檢查點之後仍然有效的 4 個數字

1. 參數總數乘以每個權重所占的位元組數，就是記憶體下限。低於這個數值無法執行；如果發布版本已經是 4-bit，量化技巧也無法大幅降低這個下限。
2. 啟用參數決定吞吐量級別。具有 2.8T 參數、其中 104B 為啟用參數的 MoE，運算量相當於 104B 模型。
3. 每個 token 的 KV cache，乘以上下文長度，再乘以並行數量，就是載入權重後仍會持續增加的成本。
4. 每美元每秒產生的 token 數，是唯一能決定級別的數字。以上所有數值都是它的輸入。

將這 4 項套用到任何發布版本，即使尚未查閱供應商指南，也能先得到正確答案。接著為記錄的每個數值標註日期。K3 推出後的 2 週內，價格與支援的架構清單都曾變更；本頁的所有數值，都是在 July 2026 發布的數值。

FAQ

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

不行。Moonshot 發行的 MXFP4 精度權重約為 1.4 TB，而目前市售最大單張加速卡只有 288 GB。MoE 模型無法以可用速度從磁碟串流載入未啟用的專家，因為路由器可能針對任何 token 選取任何專家，而 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／每百萬 token 計算，約可購買 960 million 個輸出 token。你還必須支付閒置時數、權重下載，以及維護叢集持續運作的人力成本。突發需求可按小時租用，並應根據實際測得的 token 使用量比較成本，不要依賴估算值。

104B 個作用中參數對速度有何影響？

這表示每個 token 的運算量相當於 104B 模型，因此吞吐量會落在這個級別，而不是 2.8T 級別。這與記憶體需求無關：全部 2.8T 個參數都會常駐記憶體，因為路由器可能針對任何 token 呼叫任何專家。使用作用中參數數量預估每秒 token 數，並使用參數總數規劃 VRAM。