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

Kimi K3のオープンウェイトが公開されました:594GB MXFP4、2.8兆パラメータ。vLLMまたはllama.cppでセルフホストするために必要なこと、M1 Maxでの現実的な検証、そしてローカルエンドポイントのテスト方法について。

Ashley Innocent

Ashley Innocent

29 7月 2026

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

Apidog エンタープライズ

オンプレミスデプロイ

SSO & RBAC

SOC 2 準拠

Apidog Enterpriseを見る

Moonshot AIは7月27日にKimi K3のオープンウェイトを公開し、Hugging Faceのダウンロードカウンターはすでに10万近くに達しています。その売り文句は明らかです。2.8兆パラメータのモデルで、Moonshotが公開したすべてのベンチマークでClaude Opus 4.8を打ち負かしました。そして今、あなたはそれを自分でホストすることができます。

しかし、数字を見ると問題点も明らかです。フル精度での推論には1.57 TBのディスク容量が必要です。リリースされたMXFP4ウェイトでさえ、594 GBのダウンロードサイズです。これはあなたが所有できるモデルですが、この規模での「ローカル」は、8BのLlamaの場合とは意味が異なります。

このガイドでは、K3を自身のハードウェアで実行するために必要なこと、コミュニティがコンシューマーマシンで達成したこと、そしてK3エンドポイントを稼働させた後にApidogを使ってAPIワークフローに組み込む方法について説明します。

button

ダウンロードするもの

まず、そのモデルの形状について。詳細な背景を知りたい場合は、Kimi K3とは何か?から始めてください。概要は以下の通りです。

ウェイトは、Hugging FaceリポジトリでKimi K3ライセンスの背後にゲートされています。ライセンスを承認した後、huggingface-cliでプルします。1 Gbpsの接続では、594 GBのダウンロードに約80〜90分を見込んでください。

オプション1:vLLMまたはSGLangによるデータセンタークラスの提供

MoonshotはvLLM、SGLang、およびTokenSpeedの3つのエンジンを推奨しています。KDAのプリフィルキャッシュへの貢献は、ウェイトと共にvLLMに組み込まれたため、vLLMが最も抵抗の少ない方法です。

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

現場からのメモ:

これはデータ主権の意味での「ローカル」です。つまり、あなたのインフラストラクチャ、あなたのログ、あなたのコンプライアンスストーリーです。ラップトップの意味でのローカルではありません。インタラクティブな使用では、どんな量子化でもそれを変えることはできません。

オプション2:大型ワークステーションでのGGUF量子化

Unslothはllama.cppユーザー向けにGGUF変換を公開しました。彼らの動的量子化は、K3を公式リリースよりも小さくする唯一現実的な方法です。

量子化 サイズ 意味
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

お使いのハードウェアがこれに満たない場合は、無理に実行しないでください。2026年の最高のローカルLLMリストには、24〜128 GBに収まり、リアルタイムで応答するオープンモデルが掲載されています。K3を1ビットで不十分なRAMで実行しても、そうはなりません。

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

今週のHacker Newsスレッドでは、64 GBのM1 MaxでK3を実行した事例が報告されています。これは、ウェイトをメモリに保持する代わりに2 TBのSSDからストリーミングすることで実現されました。この方法が機能する理由と、なぜ使用すべきではないのかは、以下の数値を見れば明らかです。

MoEの疎性とmmapによって2.8兆パラメータのモデルをラップトップで実行できるという証明としては、実に興味深い結果です。しかし、K3を使用する方法としては現実的ではありません。MacBookでK3の回答を得たい場合は、無料ティアまたはホストされたAPIを利用する方が良いでしょう。

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

vLLMまたはllama.cppのサーバーモードのどちらで提供するにしても、結果は同じです。ローカルホスト上にOpenAI互換のHTTPエンドポイントができます。ここからは他のAPIと同様であり、ローカルLLMをAPIとしてテストする際に使用するのと同じワークフローが適用されます。

  1. Apidogをエンドポイントに向ける。base_urlhttp://localhost:8000/v1(vLLMのデフォルト)に設定した環境を作成し、後でMoonshotのホストされたエンドポイントに切り替えます。同じリクエストで、2つのバックエンド、1つの変数です。
  2. 思考ストリームを検査する。K3は思考専用であるため、応答には回答の前に推論内容が含まれます。ApidogのSSEデバッグビューは、ストリームを到着時にレンダリングするため、推論の努力レベルが何を変えるかを確認するのがはるかに簡単になります。
  3. 感覚ではなく構造に基づいてアサートする。応答スキーマ、レイテンシ予算、トークン使用量フィールドを検証する自動テストを追加します。これにより、出力の品質を低下させる量子化の変更やエンジンアップグレードが、ユーザーからの報告ではなく、テストの失敗として検出されます。
  4. GPUが忙しい間にK3をモックする。594 GBのモデルはロードに時間がかかります。実際の応答を一度記録し、モックサーバーにそれらを返させることで、フロントエンドの作業が推論ボックスの待ち時間で止まらないようにします。Apidogをダウンロードして、これを無料で設定できます。モックおよびテストツールはどちらも、OpenAI互換サーバーで動作します。

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

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

簡単な意思決定表:

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

正直なまとめ:K3のオープンウェイトが重要であるのは、フロンティアクラスのモデルを監査、ファインチューニング、自己ホストできるからであり、ほとんどの人がそうすべきだからではありません。ハードウェアを持つチームにとっては、vLLMパスは今日機能し、優れたパフォーマンスを発揮します。他のすべての人にとっては、オープンリリースは、より安価なホストアクセスや、提供を競うサードパーティプロバイダーを通じて間接的に報われます。

この表のどの側に位置するにしても、エンドポイントはモデルがあなたのコードと出会う場所です。スキーマチェック、ストリーミング検査、およびモデルが思考している間も開発を進められるモックなど、コードの一部としてテストしてください。

button

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる