如何在本地部署 Kimi K3？

TL;DR

Kimi K3 是開放權重，但並非工作站級可輕鬆承載：服務原生模型需要資料中心級 GPU 與分散式記憶體。生產路徑最直接的是使用 vLLM；當拓撲、專家並行與快取控制很重要時，選擇 SGLang。社群 GGUF 構建可降低硬體門檻，但仍需約 500 GB 至逾 1 TB 的可尋址記憶體，並以速度或品質換取可行性。對一般 PC 與 Mac，先透過託管 API 測試，只有在隱私、長期高負載或基礎設施控制有足夠理由時才自架。

What Is Kimi K3?

Kimi K3 是 Moonshot AI 的開放權重、原生多模態旗艦模型，用於長期軟體開發、代理式知識工作、推理與視覺理解。

Moonshot 將其描述為全球首個開放的 3T 級模型。其架構結合 Kimi Delta Attention 與 Attention Residuals，並採用稀疏 MoE 設計，對每個 token 僅選擇一部分專家。

其規模即便在前沿模型中亦不常見。K3 並非每個 token 都激活全部 2.8T 參數，而是從 896 個路由專家中選擇 16 個，加上共享專家。這大幅降低每 token 的計算量，然而推論系統仍需在某處可存取全部模型權重。

K3 也自 SFT 階段起即應用量化感知訓練，而非將低精度部署僅視為訓練後的壓縮步驟。

因此其架構針對超大規模服務進行了最佳化——但「稀疏計算」不應與「小記憶體佔用」混為一談。每個 token 只計算網路的一部分，但完整的專家池仍必須可被存取。

How Does Kimi K3 Perform?

Moonshot 的 Kimi K3 官方基準套件 將該模型置於接近領先專有前沿模型的水平，尤其在長期軟體工程與代理類工作上。

以下選摘涵蓋推理、程式設計、代理與視覺。所有分數均是越高越好。

官方分數顯示，Kimi K3 在推理、程式設計、代理與視覺任務上接近 GPT-5.6 Sol、Claude Fable 5 與 Claude Opus 4.8。將供應商報告視為能力參考而非通用排名；更詳細的基準分析見 專文。在本指南中，運營重點是：自架可提供前沿級能力與基礎設施控制，但並非低成本的桌面捷徑。

Can You Actually Run Kimi K3 Locally?

可以，但「local」有兩種截然不同的定義。

本地伺服器／私有資料中心：現實可行。

一般桌機或筆電：可透過高度量化的社群構建進行技術性實驗，但整體上不適合互動式使用。

當前的 vLLM Kimi K3 配方 設定了極高的基線：

• NVIDIA：至少 8× GB300
• AMD ROCm：至少 8× MI355X 或 MI350X
• NVIDIA 驅動程式：目前 K3 CUDA 13 映像需 R580+
• 建議多節點基礎設施以應對真實生產流量

vLLM 發布日的 day-0 指南也示範了 8-GPU B300 或 8-GPU MI355X 的快速啟動路徑。新部署請遵循較新的配方，因其反映了上線後的服務堆疊最佳化。

關鍵點是：K3 為開放權重，但不是消費者級的開放模型。

Official Weights vs Community GGUF Quantizations

另一種降低硬體門檻的方法是社群量化。

目前的 Unsloth K3 儲庫提供數個可透過 llama.cpp 相容軟體運行的 GGUF 變體。

綜合比較。可尋址記憶體數據為規劃估算（下載大小加約 10–15% 執行期裕度），非保證；上下文、快取、視覺與離載設定可能需要更多。

這也解釋了為何一些早期本地部署文章引用 594 GB：如今 594 GB 對應的是社群的 UD-IQ1_S GGUF 構建，而非對完整原生檢查點的有效描述。

466–649 GB 的模型相較原始部署足跡小了許多，但以工作站標準而言仍然龐大。另請保留執行期狀態、上下文、快取、視覺投影器、作業系統程序與其它開銷的記憶體。

磁碟容量不等於推論時的記憶體。擁有 1 TB SSD 並不代表 600 GB 模型能在 64 GB RAM 的機器上快速運行。SSD 離載可以讓極限實驗成為可能，但 token 生成速度可能慢到不適合互動。

How to Deploy Kimi K3 with vLLM

對於嚴肅的自架，vLLM 是最直接的起點。

Moonshot 目前列出 vLLM 為推薦的 K3 推論引擎之一，而 vLLM 對 KDA、MXFP4 MoE、推理解析、工具呼叫、前綴快取與分散式部署提供模型特定支援。

檢查先決條件

針對 NVIDIA 的生產部署，當前測試配方使用 vllm/vllm-openai:kimi-k3 容器。

檢查 GPU：

nvidia-smi

確認 Docker：

docker --version

確認 NVIDIA Container Toolkit 可見加速器：

docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

若最後一個命令看不到所有 GPU，請先修復主機／容器的 GPU 執行環境，再下載多 TB 的模型。

設定 Hugging Face token

若模型儲庫需要驗證，請將 token 儲存為環境變數，避免硬編碼於腳本。

export HF_TOKEN="YOUR_HUGGING_FACE_TOKEN"

拉取 K3 vLLM 容器

docker pull vllm/vllm-openai:kimi-k3

當前配方指定 CUDA 13 構建與 R580 或更新的 NVIDIA 驅動程式。

啟動 Kimi K3

當前 Blackwell TP8 起始範本（vLLM 配方更新於 2026-09-10）： 以此為基準，然後針對你的硬體與流量再行剖析或重建設定。

docker run --rm \
  --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN="$HF_TOKEN" \
  -e VLLM_USE_V2_MODEL_RUNNER=1 \
  vllm/vllm-openai:kimi-k3 \
  --model moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --attention-backend TOKENSPEED_MLA \
  --attention-config '{"use_prefill_query_quantization":true,"mla_prefill_backend":"TOKENSPEED_MLA"}' \
  --prefix-match-unit 128 \
  --enable-prefix-caching \
  --max-model-len 131072 \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3

當前配方需要 K3 的 CUDA 13 映像與 R580 或更新的 NVIDIA 驅動程式。FP8 KV 快取需與相容的 MLA prefill/decode 後端配對；變更注意力配置前請先進行基準測試。

來源：vLLM Kimi K3 配方。這取代早先的 day-0 命令，而非作為現行生產配方的替代。

首次驗證時，考慮限制最大模型長度，而非立即為完整 1,048,576-token 能力配置資源。當前 vLLM 配方明確建議根據工作負載調整 max-model-len。

例如：

--max-model-len 131072

這不會改變 K3 的架構上下文限制。它只是為服務引擎提供較易掌控的運行範圍以便初期測試。

測試本地端點

vLLM 在 8000 埠提供 OpenAI 相容 API。

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {
        "role": "user",
        "content": "Explain the difference between tensor parallelism and expert parallelism."
      }
    ],
    "max_tokens": 512
  }' 

或使用 OpenAI Python SDK：

python

from openai import OpenAI

 client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
    timeout=3600,
 )

response = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=[
        {
            "role": "user",
            "content": "Write a Python function that validates a JSON schema.",
        }
    ],
    max_tokens=1024,
 )

print(response.choices[0].message.content)

官方 vLLM 配方 使用相同的本機 OpenAI 相容模式，使應用程式在本地與託管推論間切換相對容易。

How to Deploy Kimi K3 with SGLang

SGLang 是 Moonshot 官方推薦的另一條主要部署路徑。

當你需要更深入地控制分散式服務、專家並行、硬體特定核心或複雜生產拓撲時，特別相關。

使用專門的 SGLang Kimi K3 Cookbook，並選擇硬體特定拓撲。以下為經驗證的單節點 8×B300 Unified/Balanced 設定；以 SGLang v0.5.18、commit 71de97b2 測量。

安裝支援 K3 的版本：

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

啟動經驗證的 B300 TP8/DCP8 配置：

sglang serve \
  --trust-remote-code \
  --model-path moonshotai/Kimi-K3 \
  --tp-size 8 \
  --dcp-size 8 \
  --mem-fraction-static 0.85 \
  --mamba-full-memory-ratio <value-from-official-calculator> \
  --reasoning-parser kimi_k3 \
  --tool-call-parser kimi_k3 \
  --host 0.0.0.0 \
  --port 30000

--mamba-full-memory-ratio 取決於工作負載：請根據平均輸入加輸出長度於 官方 cookbook 計算。不要將此 B300 拓撲直接套用至 H100/H200、GB200/GB300、AMD 或多節點部署；那些配置使用不同的 TP/PP/DCP/EP 佈局。

測試伺服器：

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [{"role": "user", "content": "Give me a five-step debugging plan for a distributed Python application."}]
  }'

對於正式部署，請在預計使用的 SGLang 版本、拓撲、上下文長度與流量混合上驗證容量、輸出品質與故障恢復。

vLLM vs SGLang vs llama.cpp

選擇推論引擎主要取決於你的硬體與部署目的。

若你擁有 8-GPU 的 Blackwell/MI35x 級伺服器，從 vLLM 開始。

若你正設計專門的分散式推論叢集並需要更低層的服務控制，也評估 SGLang。

若你的目標只是「證明 K3 能在你擁有的硬體上執行」，GGUF 加 llama.cpp 更易上手——前提是你的機器具有極其可觀的記憶體。

How to Run a Quantized Kimi K3 with llama.cpp or Ollama

社群的 Kimi K3 GGUF 儲庫 目前提供可與 llama.cpp 相容的變體。

這條路徑相較資料中心的原生權重部署大幅降低了門檻，但「大幅」是相對的：即便較小的構建也達數百 GB。

在 macOS 或 Linux 安裝 llama.cpp

當前 GGUF 模型卡提供：

curl -LsSf https://llama.app/install.sh | sh

在 Windows：

winget install llama.cpp

啟動 OpenAI 相容伺服器

儲庫目前以 UD-Q4_K_XL 為示例：

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

也可直接運行 CLI：

llama cli \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

這些命令直接來自 當前的 Kimi K3 GGUF 模型卡。

然而，UD-Q4_K_XL 約 1.51 TB，並非大多數工作站使用者的起點。若你的重點是降低記憶體需求而非盡可能保留品質，先嘗試較小的 1-bit 與 2-bit 變體。

例如：

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-IQ1_M

目前 UD-IQ1_M 目錄約為 649 GB。

649 GB 的模型仍不是一般筆電層級。理想情況下，頻繁存取的模型狀態應置於快速記憶體。大量依賴 SSD 離載或可讓極限實驗在技術上成為可能，但未必適用於互動式工作。

Run the Same GGUF Build with Ollama

Ollama 是同一條 GGUF 部署路徑的便利層，而非第四種獨立自架方法。

K3 GGUF 儲庫亦提供經 Ollama 啟動的路徑。

例如：

bash

ollama run hf.co/unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Ollama 簡化了模型管理與 API 体驗，但不會改變 K3 的記憶體需求。

將啟動器從 llama.cpp 換成 Ollama，無法把數百 GB 的量化模型變成 24 GB GPU 可運行的模型。底層模型資料仍必須被儲存與存取。

因此，Ollama 更適合作為便利的執行封裝，而非硬體的繞行方案。

Which Kimi K3 Quantization Should You Choose?

對於實驗而言，選擇主要是在模型大小與保真度之間權衡。

Important Kimi K3 Serving Behavior

有一項 K3 專屬的實作細節容易被忽略。

K3 使用保留的思考歷史。Moonshot 表示，多輪對話與工具呼叫流程應將 完整的前一個助手訊息回傳給模型，包含 reasoning_content 與 tool_calls，而不是僅保留可見內容。

一個簡化的應用模式如下：

messages = [
    {
        "role": "user",
        "content": "Inspect this project and propose a migration plan.",
    }
 ]

first = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

assistant_message = first.choices[0].message

 # Preserve the whole message object, not just assistant_message.content.
 messages.append(
    assistant_message.model_dump(exclude_none=True)
 )

messages.append(
    {
        "role": "user",
        "content": "Now identify the riskiest part of that plan.",
    }
 )

second = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

這對於程式代理、工具循環與長時間自主會話尤其重要。

K3 亦維持推理啟用，並支援 low、high 與 max 推理力度。當你的服務層暴露這些參數時，將推理力度視為延遲／品質控制項，而非對每個請求一律最大化。

How to Optimize a Local Kimi K3 Deployment

不要一開始就配置完整 1M 上下文

K3 支援 1,048,576 tokens，但最大架構能力與合理的伺服器配置並非同一回事。

開發階段可先從如下設定開始：

--max-model-len 131072

再依據可用記憶體、首個 token 時間、吞吐與預期並發量逐步提升上下文。

啟用前綴快取

程式代理經常重用倉庫說明、工具結構、system prompt 與長前綴。

對 vLLM：

--enable-prefix-caching

K3 的混合注意力架構需要特殊處理前綴快取，vLLM 已實作模型特定支援。

使用 K3 解析器

針對代理工作負載，加入：

--tool-call-parser kimi_k3 \
--reasoning-parser kimi_k3

這能讓工具呼叫與推理輸出符合 K3 的服務格式。

保持儲存足夠快速

此規模的模型在首次下載、檢查點載入、更新與恢復時對本地儲存施加異常壓力。

優先使用 NVMe，而非掛載的慢速網路磁碟。若多台機器共用模型檔，模型快取拓撲與網路頻寬不再只是部署細節，而是推論架構的一部分。

監控不只 GPU 利用率

追蹤：

• HBM/VRAM 使用率
• CPU 記憶體
• 快取命中率
• 首個 token 時間
• 解碼 tokens 每秒
• 請求佇列深度
• GPU 間通訊
• 節點間頻寬
• 工具呼叫解析失敗
• 模型載入時間

在 K3 規模下，表面健康的 GPU 利用率不代表服務拓撲高效。

Local Kimi K3 vs Hosted Kimi K3

自架使團隊能最大程度控制資料路徑、執行期與模型權重，同時也要對 GPU 容量、擴展、升級、監控與恢復負責。託管存取移除了大部分基礎設施工作，對評估或需求波動而言通常更快。

完整的硬體與損益分析，請參閱 Kimi K3 自架 vs API。關於 token 價格、快取與 K2.7 比較，請使用 Kimi K3 價格指南。本文因此簡化比較，重點放在部署命令、配置與疑難排解。

Common Kimi K3 Local Deployment Problems

模型無法裝入 GPU 記憶體

這是最可預期的失敗。

不要從 104B 的激活參數去推算記憶體。該數字描述的是每 token 的計算量，而非服務系統需可存取的專家權重數據量。

請使用受支援的分散式拓撲、較小的 GGUF 量化，或選擇託管服務。

CUDA 或 NVIDIA 驅動錯誤

當前 vLLM K3 映像基於 CUDA 13，並需要 R580+ 的主機驅動。

若主機仍在 R575/CUDA 12.9 堆疊，請升級，或依 vLLM 的從原始碼構建路徑，勿假設容器可修正主機驅動不相容問題。

第一次請求極慢

檢查檢查點是否仍在載入、核心是否仍在編譯、快取是否預熱中或檔案是否仍在拉取。

對多 TB 級資產而言，「伺服程序已啟動」與「模型可接收生產流量」並非同一狀態。

工具呼叫間歇性失敗

當前 vLLM 配方指出，K3 可能偶爾 產生解析器未預期的工具呼叫格式。生產系統應驗證工具呼叫模式並實作重試，而非盲目信任每個生成的呼叫。

長對話變得不穩定

確保你將完整的助手訊息——包含推理與工具資訊——回傳給後續的 K3 輪次。

遺漏隱藏的推理狀態欄位，可能破壞 K3 訓練時使用的保留思考歷史模式。

So, What Is the Best Way to Deploy Kimi K3 Locally?

對於大多數具備合適硬體的組織，vLLM 是最佳的首個部署路徑。它具備 K3 專用支援、OpenAI 相容 API、模型特定解析器、前綴快取、預測解碼支援與最新硬體配方。

當你更重視分散式推論工程與更細緻的服務控制時，選擇 SGLang。

僅當你的目標是工作站／伺服器實驗，且明白即便 1-bit 版本仍是數百 GB 時，才選擇 llama.cpp 加社群 GGUF 量化。

對常見的開發者工作站而言，更務實的結論是：不要只為了把 K3 強行塞進桌面而購買數百 GB 記憶體。先透過 CometAPI 使用 Kimi K3 測試，根據你的任務量化其效益，僅在隱私、長期使用或基礎設施控制令經濟性合理時再自架。

FAQ

Kimi K3 能在單張消費級 GPU 上運行嗎？

不切實際。該模型 遠超消費級 GPU 的 VRAM 容量。社群低位元 GGUF 量化可大幅縮小足跡，但目前最小的變體仍是數百 GB。

我能在 Mac 上運行 Kimi K3 嗎？

透過 GGUF 與儲存離載，原則上可在 CPU／Apple Silicon 上實驗性執行，但互動效能與記憶體容量是主要限制。一般 MacBook 不應被視為實用的 K3 服務平台。

Kimi K3 支援 Ollama 嗎？

社群 GGUF 構建可透過 Ollama 啟動。該執行環境簡化了設置，但不會改變底層記憶體需求。

vLLM 或 SGLang 哪個更適合 Kimi K3？

vLLM 是新生產部署較易的預設。SGLang 對打造複雜分散式服務拓撲的團隊具吸引力。兩者皆為 Moonshot 推薦的 K3 推論引擎。

Kimi K3 支援多少上下文？

官方模型規格支援 1,048,576 tokens。本地伺服器不必暴露整個上下文窗；為了初期部署與較高並發，設定較低的 max-model-len 會更實用。

Kimi K3 是開源的嗎？

更精確的描述是開放權重。Moonshot 在 Kimi K3 License 下釋出模型權重。於商業再散佈或其他重視授權條款的用途前，請直接審閱該授權。

若沒有本地 GPU，使用 Kimi K3 最簡單的方法是什麼？

託管 API 是最簡單的路徑。Kimi K3 可透過 CometAPI 使用，並提供 OpenAI 相容的 chat-completions 介面，因此應用程式碼可與本地 vLLM 或 SGLang 伺服器保持接近。