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とは何か?から始めてください。概要は以下の通りです。
- 総パラメータ数2.8T、トークンあたり104Bがアクティブ。K3は、896のエキスパートを持つMixture-of-Expertsモデルです。各トークンは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でプルします。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
現場からのメモ:
- ハードウェア。MoonshotはH20クラスターで評価しました。現実的には、テンソル並列処理を備えた8-GPUノードが最低ラインとなります。B200クラスのハードウェアでは、100トークン/秒を超えるスループットが達成可能です。
- コンテキスト。モデルは最大1,048,576トークンをサポートしますが、完全なコンテキストでのKVキャッシュはそれだけで約27 GBになります。131Kから始めて、ワークロードが必要な場合にのみ引き上げてください。
- サンプリング。Moonshotのデフォルトは温度1.0、top-p 0.95です。エージェントワークロードの場合、温度を1.0に保ち、top-pを1.0に移動します。
これはデータ主権の意味での「ローカル」です。つまり、あなたのインフラストラクチャ、あなたのログ、あなたのコンプライアンスストーリーです。ラップトップの意味でのローカルではありません。インタラクティブな使用では、どんな量子化でもそれを変えることはできません。
オプション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からストリーミングすることで実現されました。この方法が機能する理由と、なぜ使用すべきではないのかは、以下の数値を見れば明らかです。
- K3は、すべてのトークンがアクセスする約115 GBの密なパラメータと、トークンあたり約25 GBのルーティングされたエキスパートウェイトを搭載しています。密な部分だけでもマシンのRAMを超過するため、SSDがスローモーションメモリの役割を果たします。
- 結果:トークンあたり約16秒。一部の構成では、トークンあたり1分以上を報告しています。これは、1時間に1段落のペースです。
- ディスクスループットがすべてです。M1世代のSSDは現在のAppleシリコンよりもはるかに読み取り速度が遅く、ネットワーク経由でエキスパートをストリーミングするとさらに遅くなります。
MoEの疎性とmmapによって2.8兆パラメータのモデルをラップトップで実行できるという証明としては、実に興味深い結果です。しかし、K3を使用する方法としては現実的ではありません。MacBookでK3の回答を得たい場合は、無料ティアまたはホストされたAPIを利用する方が良いでしょう。
ローカルK3をAPIワークフローに組み込む
vLLMまたはllama.cppのサーバーモードのどちらで提供するにしても、結果は同じです。ローカルホスト上にOpenAI互換のHTTPエンドポイントができます。ここからは他のAPIと同様であり、ローカルLLMをAPIとしてテストする際に使用するのと同じワークフローが適用されます。
- Apidogをエンドポイントに向ける。
base_urlをhttp://localhost:8000/v1(vLLMのデフォルト)に設定した環境を作成し、後でMoonshotのホストされたエンドポイントに切り替えます。同じリクエストで、2つのバックエンド、1つの変数です。 - 思考ストリームを検査する。K3は思考専用であるため、応答には回答の前に推論内容が含まれます。ApidogのSSEデバッグビューは、ストリームを到着時にレンダリングするため、推論の努力レベルが何を変えるかを確認するのがはるかに簡単になります。
- 感覚ではなく構造に基づいてアサートする。応答スキーマ、レイテンシ予算、トークン使用量フィールドを検証する自動テストを追加します。これにより、出力の品質を低下させる量子化の変更やエンジンアップグレードが、ユーザーからの報告ではなく、テストの失敗として検出されます。
- 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
