Kimi K3 をローカル環境でデプロイする方法は？

TL;DR

Kimi K3 はオープンウェイトだが、ワークステーション規模ではない。ネイティブモデルの提供にはデータセンター級GPUと分散メモリが必要。最短の本番経路には vLLM、トポロジやExpert並列、キャッシュ制御が重要なら 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 設計と組み合わせている。

このスケールはフロンティアモデル標準から見ても異例だ。すべての2.8Tパラメータをトークンごとに起動するのではなく、K3 は 896 のルーティングされるエキスパートのうち 16 個と共有エキスパートを選択する。これによりトークンごとの計算は大幅に削減されるが、推論システムのどこかで全エキスパートの重みが利用可能である必要がある点は変わらない。

K3 は、学習後の単なる圧縮手順としてではなく、SFT 段階から量子化認識学習を適用している。

したがってアーキテクチャは超大規模サービングに最適化されているが、「スパース計算」を「小さいメモリフットプリント」と混同すべきではない。一部のみがトークンごとに計算する一方で、完全なエキスパートプールを常にアクセス可能にしておく必要がある。

How Does Kimi K3 Perform?

Moonshot の公式 Kimi K3 ベンチマークスイートでは、特に長期的なソフトウェアエンジニアリングやエージェント型ワークロードにおいて、K3 は先端のプロプライエタリ・フロンティアモデルに近い性能を示す。

以下は推論、コーディング、エージェント、ビジョンをカバーする選抜結果。いずれも高いほど良い。

公式スコアは、推論、コーディング、エージェント、ビジョンタスク全般で Kimi K3 が GPT-5.6 Sol、Claude Fable 5、Claude Opus 4.8 に近い位置づけであることを示す。提供者公表の結果は普遍的な順位表ではなく能力の文脈として扱うべきである。詳細なベンチマーク分析は別稿にて。本ガイドの運用上の要点は、セルフホスティングがフロンティア級の能力とインフラ制御を与える一方、低コストなデスクトップ近道ではないということだ。

Can You Actually Run Kimi K3 Locally?

可能だが、「ローカル」には二つの全く異なる定義がある。

ローカルサーバー／プライベートデータセンター：現実的。

通常のデスクトップやノート：強 aggressive な量子化のコミュニティビルドで技術的には実験可能だが、対話用途では概して非現実的。

現行のvLLM Kimi K3 レシピは非常に高いベースラインを示している。

• NVIDIA: 少なくとも 8× GB300
• AMD ROCm: 少なくとも 8× MI355X または MI350X
• NVIDIA ドライバ: 現行の CUDA 13 K3 イメージには 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 のモデルは元のデプロイフットプリントより劇的に小さいが、それでもワークステーション標準から見れば巨大だ。さらに実行時状態、コンテキスト、キャッシュ、ビジョンプロジェクタ、OS プロセス、その他オーバーヘッドのためのメモリを確保すべきである。

ディスク容量は推論メモリと同義ではない。1 TB の SSD があっても、RAM が 64 GB のマシンで 600 GB のモデルが高速に動くとは限らない。SSD オフロードは極端な実験を技術的に可能にすることはあるが、トークン生成は極端に遅くなりうる。

How to Deploy Kimi K3 with vLLM

本格的なセルフホスティングには、vLLM が最も手堅い出発点である。

Moonshot は現在、vLLM を K3 推論エンジンの推奨の一つとして挙げており、vLLM は KDA、MXFP4 MoE、推論パーシング、ツールコーリング、プレフィックスキャッシュ、分散デプロイに対する K3 特有のサポートを提供する。

Check the prerequisites

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 ランタイムを修正すること。

Set your Hugging Face token

モデルリポジトリで認証が必要な場合は、トークンをスクリプトにハードコードせず環境変数に保存する。

export HF_TOKEN="YOUR_HUGGING_FACE_TOKEN"

Pull the K3 vLLM container

docker pull vllm/vllm-openai:kimi-k3

現行レシピはCUDA 13 ビルドと R580 以上の NVIDIA ドライバを指定している。

Launch 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 バックエンドと組み合わせる必要がある。Attention 設定を変更する前に代替案をベンチマークすること。

出典: vLLM Kimi K3 レシピ。これは初日のコマンドを現行の本番レシピに置き換えるものである。

初回の検証実行では、いきなり 1,048,576 トークンの能力に近い割り当てを行うのではなく、最大モデル長を制限することを検討するとよい。現行の vLLM レシピは、ワークロードに合わせて max-model-len を調整することを明確に推奨している。

例えば:

--max-model-len 131072

これは K3 のアーキテクチャ上のコンテキスト上限を変えるものではない。サービングエンジンに対し、初期テストにより扱いやすい運用範囲を与えるだけだ。

Test the local endpoint

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 が公式に推奨するもう一つの主要なデプロイルートである。

分散サービング、Expert 並列、ハードウェア特化カーネル、複雑な本番トポロジなどをより深く制御したい場合に特に有用だ。

専用の SGLang Kimi K3 Cookbook を用い、ハードウェア固有のトポロジを選択する。以下は Cookbook に記載の検証済み単一ノード 8×B300 Unified/Balanced プロファイル例。SGLang v0.5.18、コミット 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 はワークロード依存であり、公式クックブックの平均入出力長から算出する。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規模である。

Install llama.cpp on macOS or Linux

現行の GGUF モデルカードは以下を案内している。

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

Windows:

winget install llama.cpp

Start an OpenAI-compatible server

リポジトリでは現在、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 は、マルチターン会話やツールコールのワークフローにおいて、visible content だけでなく、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 トークンをサポートするが、最大能力と妥当なサーバー設定は別物だ。

開発では例えば次のように始める。

--max-model-len 131072

その後、利用可能メモリ、最初のトークンまでの時間、スループット、想定同時実行を測定しながら、コンテキストを段階的に増やす。

プレフィックスキャッシュを有効化

コーディングエージェントは、リポジトリの指示、ツールスキーマ、システムプロンプト、長いプレフィックスを頻繁に再利用する。

vLLM では:

--enable-prefix-caching

K3 のハイブリッドアテンションはプレフィックスキャッシュに特別な対応を要し、vLLM はモデル固有のサポートを実装済みである。

K3 パーサーを使う

エージェントワークロードでは次を含める。

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

これによりツールコールと推論出力が K3 のサービング形式と一致する。

ストレージを高速に保つ

この規模のモデルは、初回ダウンロード、チェックポイントのロード、更新、リカバリ時に局所ストレージへ異常な負荷をかける。

NVMe ストレージは、ネットワーク越しの低速ディスクに比べ望ましい。複数マシンでモデルファイルを共有する場合、モデルキャッシュのトポロジとネットワーク帯域は、単なるデプロイ詳細ではなく推論アーキテクチャの一部になる。

GPU 利用率以外も監視する

監視対象:

• HBM/VRAM 利用率
• CPU RAM
• キャッシュヒット率
• 最初のトークンまでの時間
• デコードのトークン毎秒
• リクエストキュー深度
• GPU 間通信
• ノード間帯域
• ツールコールパース失敗
• モデルロード時間

K3 規模では、一見健全な GPU 利用率だけではサービングトポロジの効率は判断できない。

Local Kimi K3 vs Hosted Kimi K3

セルフホスティングはデータパス、ランタイム、モデルウェイトを最大限に制御できる一方、GPU 容量、スケーリング、アップグレード、監視、復旧の責任も負う。ホステッドアクセスは大半のインフラ作業を不要にし、評価や可変需要には一般により迅速だ。

ハードウェアと損益分岐の詳細は Kimi K3 Self-Hosting vs API を参照。トークン価格、キャッシュ、K2.7 との比較は K3 の価格ガイドへ。本稿は比較を簡潔に留め、デプロイコマンド、設定、トラブルシューティングに焦点を当てる。

Common Kimi K3 Local Deployment Problems

モデルが GPU メモリに収まらない

最も予測可能な失敗だ。

104B のアクティベートパラメータからメモリを見積もらないこと。これはトークンごとの計算量であり、サービングシステムが利用可能にすべきエキスパート重みの総量ではない。

サポートされた分散トポロジ、より小さい GGUF 量子化、またはホステッドサービスを使用する。

CUDA または NVIDIA ドライバのエラー

現行の vLLM K3 イメージはCUDA 13 ベースで、ホスト側に R580+ ドライバを要求する。

ホストが R575/CUDA 12.9 スタックのままなら、アップデートするか、コンテナがホストドライバの非互換を解決してくれると仮定せず vLLM のソースからのビルド手順に従うこと。

最初のリクエストが極端に遅い

チェックポイントのロード、カーネルのコンパイル、キャッシュのウォームアップ、ファイルの取得が継続中でないか確認する。

マルチテラバイト級アセットでは、「サーバープロセス起動」と「本番トラフィックに投入可能」は同義ではない。

ツールコールが断続的に失敗する

現行の vLLM レシピは、K3 が時折パーサーの想定と異なるツールコール形式を出力する可能性を注記している。本番システムはツールコールのスキーマを検証し、すべてを盲信せずリトライを実装すべきである。

長い会話が不安定になる

reasoning やツール情報を含む完全なアシスタントメッセージを、次の K3 ターンに確実に返しているか確認する。

隠れた思考状態フィールドを落とすと、K3 が学習した思考履歴保持パターンが崩れる可能性がある。

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

適切なハードウェアを持つ多くの組織にとって、vLLM が最初のデプロイパスとして最良である。K3 専用サポート、OpenAI 互換 API、モデル固有のパーサー、プレフィックスキャッシュ、スペキュレイティブデコーディング対応、現行ハード向けレシピを備える。

分散推論のエンジニアリングと細粒度のサービング制御を重視するなら SGLang を選ぶ。

ワークステーション／サーバーでの実験が目的で、1-bit 版でも数百GBであることを理解している場合のみ、コミュニティの GGUF 量子化と llama.cpp を選ぶ。

一般的な開発者用ワークステーションに対する結論は異なる。デスクトップに K3 を無理に載せるためだけに数百GBの RAM を購入すべきではない。まずは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、K3 に向いているのはどちら？

新規本番デプロイのデフォルトとしては vLLM が容易。洗練された分散サービングトポロジを構築するチームには SGLang も魅力的。いずれも Moonshot の推奨 K3 推論エンジンに含まれる。

Kimi K3 のコンテキスト長は？

公式仕様では 1,048,576 トークン。ローカルサーバーは全ウィンドウを公開する必要はない。初期デプロイや高い同時実行には、より低い max-model-len の方が実務的である。

Kimi K3 はオープンソースですか？

より正確にはオープンウェイト。Moonshot は Kimi K3 Licenseの下でモデルウェイトを公開している。商用再配布などライセンスが重要な用途では、必ず直接ライセンスを確認すること。

ローカル GPU なしで Kimi K3 を使う最も簡単な方法は？

ホステッド API が最も簡単。Kimi K3 は CometAPIから OpenAI 互換の chat-completions インターフェースで利用でき、アプリケーションコードはローカルの vLLM や SGLang サーバー向けと近いままにできる。