メインコンテンツまでスキップ

Kimi K3をローカルで動かす:vLLM、DSpark、そして本当のハードウェア請求書

上級

Moonshotは Kimi K3 — 2.8兆パラメータのMixture-of-Expertsモデル — を2026年7月27日にオープンソース化しました。数日以内に、r/LocalLLaMA の「16× DGX Spark クラスタで K3 フルモデルを自宅で動かした」というスレッドは 800+ upvotes を超えました。コメントは称賛とパニックが入り混じっており、それがスタントなのか、本物のレシピなのか、ハードウェアの罠なのか、誰も判断できませんでした。

このページはそのレシピです。今日ローカルで動く唯一のサーブ経路(vLLM)、スループットを実用レベルにする投機的デコードのトリック(DSpark)、実際に必要な最低限のハードウェア、正確なサーブコマンド、初回で必ずハマる落とし穴、そしてMoonshotやRunpodのホスト型エンドポイントを呼ぶ場合との損益分岐計算を扱います。モデル自体 — アーキテクチャ、ベンチマーク、価格 — については、Kimi K3: 世界最大のオープンウェイトモデル を参照してください。

What you'll learn
  • K3 フル版に最低限必要なハードウェアを知る(1× DGX B300 ノードまたは 16× B200 — これ以下の経路は今日時点で存在しない)
  • DSpark を1段落で理解する:ブロック拡散ドラフティング、約3.14倍高速化、1ステップあたり7投機的トークン
  • vLLM で K3 を2コマンドでサーブする — ほとんどのガイドが忘れるフラグ付きで
  • プリフィル/デコードの非対称性に向き合う:16× DGX Spark クラスタで読み込み750 tok/s vs 書き出し21 tok/s
  • 損益分岐の計算をする:セルフホストが $0.95/M ホスト型に勝つのはいつか、そして絶対に勝てないのはいつか

1段落バージョン​

今日 K3 で本番運用可能な唯一のサーブスタックは vLLM で、2026年7月27日に Day-0 対応が追加され、DSpark と呼ばれる新しい投機的デコーダも同時に登場しました。最低ハードウェアは 1× 8× B300 ノード(または 16× B200)。英雄的なコミュニティのセットアップでは、16× DGX Spark (GB10) クラスタ でフルモデルを自宅で動かし、BoMは約 $64k+、およそ デコード21 tok/s、プリフィル750 tok/s を達成します。ホスト型推論(Runpod、Moonshot自身のAPI)は入力 $0.95/M、出力 $4/M — ほとんどのチームにとって、これが正解です。ただし特にオンプレでウェイトが必要な場合を除きます。

ステップ1 — サイジングの壁を理解する​

K3 は2.8兆パラメータ。MXFP4 重み量子化(Moonshot が出荷する形式)でも、生重みだけで KV キャッシュを割り当てる前に 約 1.4 TB の VRAM アドレス可能メモリ に達します。この数字がすべてを決めます。

What you'll learn
  • K3 フルモデルを単一のコンシューマ GPU、Mac Studio、H100 が数枚のワークステーションで動かす方法はありません。サイジングは滑らかではなくステップ状です。
  • vLLM のガイドは明快です:少なくとも 1× 8× B300(または GB300 NVL72)ノードが必要、16× B200 もサポートされます。
  • 量子化されたコミュニティ蒸留(Q2/Q3 やエキスパート剪定版)は時間とともにこの敷居を下げますが、2026年8月時点で動くレシピはすべてフロンティア級データセンターシリコン上でのフル精度 MXFP4 です。
ハードウェアプロファイル現実的な用途おおよその CapEx / OpEx
1× DGX B300 (8× B300)本番セルフホスト、単一ノードRunpod で約 $59/hr;購入価格 6桁
16× B200旧世代セルフホストRunpod で約 $94/hr
16× DGX Spark (GB10) クラスタ愛好家 / ラボ約 $64k–$75k CapEx + スイッチ + 2.3 kW ピーク
これより下—あなたはホスト API を呼んでいます

ステップ2 — DSpark を1段落で​

DSpark は K3 と同時にリリースされ vLLM にネイティブサポートされた ブロック拡散型投機的デコーダ です。MEDUSA や EAGLE のように投機的トークンを1つずつドラフトする代わりに、DSpark は 5層の非因果的注意バックボーンを使って 並列パスで7トークンをドラフト し、K3 ターゲットに対してブロック単位で検証します。低ランクマルコフヘッドがブロック内依存性をモデル化し、信頼度ヘッドが受理可能性を予測するため、スケジューラはドラフティングが価値のあるタイミングを判断できます。

vLLM ブログの具体的な数値:

  • DSpark なし: 118 tok/s(TP16)@ batch=1
  • DSpark あり: 370 tok/s(TP16)@ batch=1 — 3.14倍の高速化
  • 平均受理長: 3.85 トークン(14 ベンチマーク平均)、コーディングでは4.73 トークン/ステップ まで上昇、創作では2.61 まで低下
  • ドラフト-ターゲット互換性: DSpark は K3 の1トークンあたり576要素の MLA 潜在を共有するため、ドラフトページはターゲット KV キャッシュと統合される — 別のページ形式なし、2つ目のキャッシュのVRAM税なし

DSpark 投機的ウェイトは Hugging Face の Inferact/Kimi-K3-DSpark にあり、vLLM の --speculative-config フラグでそのモデルを指定します。

ステップ3 — vLLM で K3 をサーブする​

vLLM ≥ 0.11.1 が必要です(K3 はこのリリースで Day-0 サポート)。コマンドは2つ:投機なし(可動部品が少なくスモークテストに便利)、DSpark あり(本番で実際に必要なもの)。

スモークテスト — プレーンな K3​

Serve K3 without DSpark (baseline)

vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 8 \
--enable-prefix-caching \
--trust-remote-code

見逃されがちな2つのフラグ:--enable-prefix-caching は vLLM でデフォルトオフで、K3 のワークロード(特にエージェント型コーディング)はキャッシュヒットに依存して初めて手頃になります — これをオフのままにすると、最初のプロンプトが毎ターン再処理されます。--trust-remote-code は K3 がまだ stock transformers にないカスタムモデルコード(KDA attention、LatentMoE ルーティング)を出荷しているため必須です。

本番 — K3 + DSpark​

Serve K3 with DSpark speculative decoding

vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 16 \
--enable-prefix-caching \
--trust-remote-code \
--speculative-config '{"method": "dspark", "model": "Inferact/Kimi-K3-DSpark", "num_speculative_tokens": 7, "attention_backend": "FLASHINFER_MLA", "draft_sample_method": "probabilistic", "rejection_sample_method": "block"}'

num_speculative_tokens: 7 は DSpark 投機モデルの訓練済みブロックサイズと一致します — 下げないでください、ブロック拡散ドラフティングの本質を無駄にします。attention_backend: FLASHINFER_MLA は MLA ネイティブなドラフトがターゲットとキャッシュページを共有するために必要です。決定的サンプリングが必要な場合は、draft_sample_method を "greedy" に切り替え、クライアント側で temperature=0 を設定します。

ステップ4 — 誰も警告しないプリフィル/デコードの非対称性​

以下は、コミュニティのオペレータが 16× DGX Spark (GB10) で DSpark を有効にし、MikroTik CRS804-4DDQ ネットワーキングと 4×400→4×100 Gb ブレイクアウトケーブル、ピーク2.3 kW で K3 フルモデルを動かした実測値です:

ワークロードスループットピーク
プリフィル @ 4k コンテキスト655 tok/s8,288 tok/s
デコード @ 4k コンテキスト21.7 tok/s37 tok/s
プリフィル @ 16k コンテキスト759 tok/s21,457 tok/s
デコード @ 16k コンテキスト25.4 tok/s38 tok/s

読み込みは書き出しより30〜40倍速い。実践的にはこう意味します:

  • 大規模コードリポジトリや研究コーパスに対する長文コンテキスト Q&A は美しく動きます — 壁時計時間1分あたりほぼ100万トークンでコーパスを取り込みます。
  • 長文生成、ストリーミングアシスタント、チャット風UI は遅く感じます — 25 tok/s は使えるレベルですが、ホスト型 Sonnet/Fable クラスのモデルより明らかに遅れます。
  • モデルが長いツール呼び出しチェーンを生成するエージェント型ループ はデコードのボトルネックを増幅します。より簡潔な推論スタイルと構造化出力を検討してください。
  • バッチはプリフィルよりデコードに効きます — 並行リクエストが増えると GPU秒あたりのスループットは急峻に上昇します(vLLM ブログは高並行時に GPU秒あたり2K+ トークンを報告)。

ステップ5 — 初週の運用スレッドから見えた5つの落とし穴​

Guided walkthrough1 of 5
  1. vLLM ブログ以外のすべてのサーブガイドがこれを忘れます。--enable-prefix-caching なしでは、K3 の 90%+ の実世界キャッシュヒット率が0%になり、毎ターン全プロンプトが再処理されます。コストとレイテンシの両方が爆発します。一度設定して、永遠にオン。

ステップ6 — そもそもセルフホストすべきか?​

ほとんどのチームにとって正直な答えは「いいえ」です。ワークロードに応じて損益分岐計算をしてください:

経路コスト勝つとき
Moonshot API入力 $3.00/M、キャッシュヒット $0.30/M、出力 $15/Mプロトタイピング、低ボリューム、非機密データ
Runpod ホスト K3入力 $0.95/M、出力 $4/M中ボリューム定常、OpenAI 互換エンドポイントが必要、計算がどこで動くか気にしない
Runpod 8× B300 時間貸し$59.12/hrバースト実行、サーブ設定を制御したい、それでも CapEx は嫌
ハードウェアを所有$80k–$500k+ CapEx厳格なデータレジデンシー、24/7 飽和、または競合する推論プロダクトを構築中

16× GB10 クラスタのデコード約21 tok/s では、1ノードで時間あたり約76k 出力トークンを生成します。Runpod-K3 ホスト価格ではそれは時間あたり $0.30 の出力トークンです。$59/hr のホスト料金に勝つには、高バッチで 約 1500万出力トークン/hr に近いスループットと100%近い稼働率が必要です — 並行数で達成可能ですが、実際にそれだけの需要がある場合のみです。それ以下では、ホストが1桁勝ちます。

2026年に K3 をセルフホストする正しい理由:

  • データレジデンシー / 規制 — プロンプトと補完が VPC を離れられない。
  • 継続的飽和 — 24/7 で動くエージェント群があり、キャッシュヒット価格でも痛い。
  • モデル変更 — カスタム DSpark 投機モデルを訓練中、MoE エキスパートに LoRA ファインチューンをしている、またはルーティング変更を実験中。
  • 学習価値 — フロンティア MoE サーブをメタルレベルで理解したいラボまたはチーム。

これらのいずれも当てはまらない場合は、API を呼び、節約したエンジニアリング時間をより良いプロンプト、より良い評価、より良い コンテキストエンジニアリング に回してください。

ステップ7 — どの経路を選んでも動く最小 Python クライアント​

vLLM は OpenAI 互換エンドポイントを公開しているため、同じクライアントが自前のラック、Runpod のホスト K3、Moonshot の API で動きます。

Call your K3 endpoint with the OpenAI Python SDK

from openai import OpenAI

client = OpenAI(
  base_url="http://localhost:8000/v1",   # or Runpod / Moonshot base URL
  api_key="EMPTY",                        # self-hosted vLLM ignores keys
)

resp = client.chat.completions.create(
  model="moonshotai/Kimi-K3",
  messages=[
      {"role": "system", "content": "You are a terse coding assistant."},
      {"role": "user",   "content": "Explain DSpark speculative decoding in three bullets."},
  ],
  max_tokens=8192,
  temperature=0.2,
)

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

フラッシュカード — 覚えておくべき数字​

カードがまだありません — 追加して学習を始めましょう。🃏

クイズ​

Check yourself

0/4
  1. 200kトークンの研究コーパスとアナリストがチャットできる社内ツールを設計中。最初のトークンのレイテンシが重要、ユーザーあたりのトークン量は少ない。K3 をセルフホストすべきか?
  2. 初回の本番 K3 サーブに最も安全な vLLM フラグの組み合わせは?
  3. DSpark は並列パスで7トークンをドラフトする。実際に K3 がステップあたり典型的にいくつを受理するか?
  4. 16× DGX Spark を机に置いた。ユーザーに期待させるべきスループットプロファイルは?

ホスト経路に切り替えるべきとき​

  • プロトタイピングとデモ — Moonshot の API か Runpod を使う。レイテンシも価格もどちらも問題なし。
  • コスト重視の大ボリューム — Moonshot の $0.30/M キャッシュヒット入力価格は、実際にキャッシュされるワークロードでは無敵。
  • Claude Code や他のハーネスでのエージェント型コーディング — AI ゲートウェイ (LiteLLM / OpenRouter / Portkey) 経由で K3 を差し込み、ハーネスを変えずにモデルを切り替える。
  • モデル比較作業 — K3 が正しい選択か Anthropic に留まるかについては、モデルの選び方 と Claude ユーザーのための Kimi K3 を参照。

ソースと参考文献​