Kimi K3ローカル実行方法と注意点

Moonshot AIは7月27日にKimi K3のオープンウェイトを公開し、Hugging Faceのダウンロードカウンターはすでに10万近くに達しています。2.8兆パラメータのモデルで、Moonshotが公開したすべてのベンチマークにおいてClaude Opus 4.8を上回ったとされています。さらに、Kimi K3は自前のインフラストラクチャでホストできます。

今すぐApidogを試す

ただし、ローカル実行には明確な制約があります。フル精度推論には1.57 TBのディスク容量が必要で、公開済みのMXFP4ウェイトでもダウンロードサイズは594 GBです。8B規模のLlamaをPCで動かすような意味での「ローカル」とは異なります。

この記事では、Kimi K3を自分のハードウェアで実行するための要件、コンシューマーマシンでの実行事例、そしてK3エンドポイントを起動した後にApidogでAPIワークフローへ組み込む手順を説明します。

ダウンロードするもの

まず、モデルの構成を確認します。背景から把握したい場合は、Kimi K3とは何か？を参照してください。

総パラメータ数は2.8T、トークンあたり104Bがアクティブ。

K3は896エキスパートを持つMixture-of-Experts（MoE）モデルです。各トークンは16個の選択エキスパートと2個の共有エキスパートを経由するため、トークンごとの計算量は総パラメータ数より小さくなります。
93層構成。

Kimi Delta Attention（KDA）層が69層、Gated MLA層が24層です。100万トークンのコンテキストウィンドウを実現する要素の一つがKDA設計です。
ネイティブビジョン対応。

4億100万パラメータのMoonViT-V2エンコーダを介して、公開ウェイトはテキスト、画像、動画入力を扱えます。
MXFP4ウェイト、MXFP8アクティベーション。

Moonshotは量子化を前提にトレーニングしており、4ビット版は後付けの変換ではなく意図された配布形式です。そのため、さらに低ビット化する余地は大きくありません。
思考専用モデル。

K3は回答前に推論を行い、低・中・高の努力レベルを選択できます。インスタントモードはありません。

ウェイトはHugging Faceリポジトリで、Kimi K3ライセンスへの同意後に取得できます。

huggingface-cli login

huggingface-cli download moonshotai/Kimi-K3 \
  --local-dir ./Kimi-K3

1 Gbps接続の場合、594 GBのダウンロードには約80〜90分を見込んでください。実際には回線速度、ストレージ速度、Hugging Face側の混雑状況にも左右されます。

オプション1：vLLMまたはSGLangでデータセンター向けに提供する

MoonshotはvLLM、SGLang、TokenSpeedの3エンジンを推奨しています。KDAのプリフィルキャッシュ対応がウェイトとともにvLLMへ組み込まれているため、まずはvLLMから始めるのが最もシンプルです。

vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --max-model-len 131072

起動前に、次の点を確認してください。

ハードウェア

MoonshotはH20クラスターで評価しています。実用的な構成の最低ラインは、テンソル並列処理を使う8 GPUノードです。B200クラスのハードウェアでは、100トークン/秒を超えるスループットが可能とされています。
コンテキスト長

モデル自体は最大1,048,576トークンをサポートしますが、最大コンテキストのKVキャッシュだけで約27 GBを消費します。まずは131072から開始し、実際のワークロードで必要になった場合だけ上げてください。
サンプリング設定

Moonshotのデフォルトは温度1.0、top-p 0.95です。エージェント用途では、温度を1.0に保ち、top-pを1.0へ変更する選択肢があります。

vLLMを起動すると、通常はOpenAI互換エンドポイントを利用できます。ローカルで疎通確認する場合は、以下のようにリクエストします。

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {
        "role": "user",
        "content": "Redisのキャッシュ無効化戦略を3つ説明してください。"
      }
    ],
    "temperature": 1.0,
    "top_p": 0.95
  }'

この構成での「ローカル」は、ラップトップで動かすという意味ではありません。データ主権、監査ログ、ネットワーク分離、コンプライアンス要件を自社インフラで管理できる、という意味です。

オプション2：大型ワークステーションでGGUF量子化を使う

Unslothはllama.cppユーザー向けにGGUF変換を公開しています。動的量子化を使うことで、公式リリースより小さい構成を選択できます。

量子化	サイズ	意味
UD-IQ1_M	約345 GB	最低限。積極的な1ビット動的量子化。
UD-IQ1_S	約650 GB	Unslothが推奨するバランスポイント。
UD-Q4_K_XL	約1.55 TB	ほぼフル精度。
UD-Q8_K_XL	約1.6 TB	実質的にロスレス。

目安として、RAMとVRAMの合計は量子化済みモデルのサイズとほぼ同程度必要です。不足した場合もllama.cppはオフロードで動作しますが、メモリ不足分が大きいほど推論速度は低下します。

128 GBマシンに接続されたMac StudioやDGX Stationは、実験用の実用的な最低ラインです。

ビジョンプロジェクタを含めてllama.cppを起動する最小構成は次のとおりです。

./llama.cpp/llama-cli \
  --model unsloth/Kimi-K3-GGUF/UD-IQ1_S/Kimi-K3-UD-IQ1_M-00001-of-00015.gguf \
  --mmproj unsloth/Kimi-K3-GGUF/mmproj-F16.gguf \
  --temp 1.0 \
  --top-p 0.95

ハードウェアがこの要件を満たさない場合、無理にK3を動かす必要はありません。2026年の最高のローカルLLMには、24〜128 GBに収まり、リアルタイムに近い応答速度を期待できるオープンモデルが掲載されています。

M1 Maxでの実験：可能だが、トークンあたり16秒

今週のHacker Newsスレッドでは、64 GBのM1 MaxでK3を実行した事例が報告されています。この事例では、すべてのウェイトをメモリへ常駐させる代わりに、2 TB SSDからストリーミングしています。

この方法が成立する理由と制約は、モデル構成を見ると分かります。

K3には、すべてのトークンがアクセスする約115 GBの密なパラメータがあります。
さらに、トークンごとに約25 GBのルーティングされたエキスパートウェイトへアクセスします。
密なパラメータだけで64 GB RAMを超えるため、SSDが低速なメモリとして機能します。
報告された速度はトークンあたり約16秒です。一部構成ではトークンあたり1分以上かかります。

ディスクスループットが重要です。M1世代のSSDは新しいAppleシリコンより読み取り速度が低く、ネットワーク経由でエキスパートをストリーミングする場合はさらに遅くなります。

MoEの疎性とmmapを使い、2.8兆パラメータのモデルをラップトップで実行できることを示す実験としては興味深いものです。一方で、日常的にK3を利用する方法としては実用的ではありません。

MacBookからK3の応答を使いたい場合は、無料ティアまたはホスト型APIを利用する方が適しています。

ローカルK3をAPIワークフローへ組み込む

vLLMでもllama.cppのサーバーモードでも、目標は同じです。OpenAI互換のHTTPエンドポイントを起動し、アプリケーションやテストツールから呼び出せる状態にします。

ローカルLLMをAPIとしてテストする場合と同じ手順で進められます。

Apidogの環境変数でエンドポイントを切り替える base_urlを設定した環境を作成します。

   base_url = http://localhost:8000/v1

vLLMのデフォルトURLを使う場合、この設定でローカルK3へ送信できます。後でホスト型Moonshotエンドポイントへ移行する場合も、環境変数を切り替えるだけで同じリクエストを再利用できます。

ストリーミングレスポンスを確認する

K3は思考専用モデルのため、レスポンスには最終回答の前に推論内容が含まれます。ApidogのSSEデバッグビューを使うと、ストリームを到着順に確認できます。努力レベルの変更が出力やレイテンシへ与える影響を確認しやすくなります。
出力品質だけでなく構造をテストする

自動テストでは、少なくとも次の項目を検証してください。

HTTPステータスコード
OpenAI互換レスポンススキーマ
usage内のトークン使用量
レイテンシ予算
ストリーミングチャンクの形式

これにより、量子化設定の変更や推論エンジンのアップグレードによる問題を、ユーザー報告より先にテスト失敗として検出できます。

GPUが使用中でもモックで開発を続ける 594 GBのモデルはロードに時間がかかります。実際のレスポンスを記録し、モックサーバーから返すようにしておけば、フロントエンド開発や統合テストを推論環境の起動待ちで止めずに済みます。

Apidogをダウンロードすれば、このモックとテストのセットアップを無料で始められます。モック機能とテスト機能はいずれもOpenAI互換サーバーで利用できます。

リクエスト形式はKimi K3 APIガイドで説明されているものと一致します。そのため、ホスト型APIに対して作成したリクエストやテストは、ローカルデプロイメントへ直接転用できます。

では、ローカルで実行すべきか？

判断基準をまとめると、次のとおりです。

あなたの状況	推奨
8 GPU以上のノードがあり、データ主権またはコンプライアンス要件がある	はい。MXFP4ウェイトとテンソル並列処理を使ったvLLMを検討します。
350 GB以上のRAM/VRAMを持つワークステーションがある	実行可能です。Unslothの1ビットGGUFを使い、速度には控えめな期待値を設定してください。
64〜128 GBのMacまたはPC	非推奨です。秒あたりトークンではなく、トークンあたり数秒以上になる可能性があります。
製品へK3を組み込みたいだけ	ホスト型APIを使用してください。OpenAIおよびAnthropic互換です。