Moonshot AI の Kimi K3 は、総パラメータ約 2.8T・アクティブ約 104B のオープンウェイト MoE です。公開ウェイトは MXFP4 でディスク目安が約 1.56〜1.68TB 級のため、「H100 80GB×8 では載らない」「B300×8 なら 1 ノードで動くのか」が自前推論の最初の分岐になります。
📑目次
結論から言うと、条件付きで Yes です。MXFP4 の公開ウェイトと、B300 288GB×8（合計約 2.3TB HBM）が揃うなら、シングルノードの Day0 検証は現実的です。一方で Moonshot 側の 64 基超推奨や、vLLM / NVIDIA Dynamo のマルチノード・ラック向けレシピは、ラボ検証と本番スループットを別軸で見積もる必要があります。
この記事で実務判断用に整理する材料は次の通りです。
- 公式仕様とメモリ下限
- B300×8 Day0 実測の読み方
- SGLang / vLLM / Dynamo の経路差
- 採用前の Go/No-Go チェックリスト
Kimi K3の公開仕様と「ダウンロードできる」≠「すぐ本番」
公式モデルカードの固定仕様
Kimi K3 を自前で動かす前に押さえるべきは、モデルカード上の固定仕様です。Hugging Face の moonshotai/Kimi-K3 では次が示されています。
- 総 2.8T / アクティブ 104B
- 896 experts のうち 16 を選択、共有 expert が 2
- コンテキスト長 1,048,576
- MoonViT-V2（401M）
- ウェイト MXFP4 / 活性化 MXFP8（QAT）
- Kimi K3 License
アーキテクチャとメモリの見方
アーキテクチャ上のポイントは次の通りです。
- 大半のアテンションが線形 KDA（固定サイズ state）
- 周期的に Gated MLA（圧縮 KV）が入るハイブリッド構成
- 長コンテキストでも KV が単調に膨らみにくい
- ボトルネックはまずウェイトの収まりに寄る
- 疎な MoE だから常駐メモリが自動で小さくなる、という誤解は避ける
独立報道と「落とせた」≠「常時回せた」
独立した日本語報道でも、次が整理されています（innovaTopia、PC Watch）。
- ウェイト公開
- MXFP4 約 1.56TB
- 64 基超の推奨
- vLLM / SGLang などの推論経路
「HF から落とせた」ことと、「目標 SLA で常時回せた」ことは別問題です。
ライセンスの運用分岐
ライセンスも運用分岐になります。Runpod の技術 FAQ では次のように説明されています。
- 広範な利用は可能
- 大規模 MaaS/MAU や売上しきい値では追加条件・表示義務が絡む
- MIT 派生の Kimi K3 License として整理される
- 社内検証と大規模 SaaS では、法務確認のタイミングが異なる
| 項目 | 値 | 出典 |
|---|---|---|
| 総 / アクティブ | 2.8T / 104B | HF model card |
| MoE | 896 experts、16 active + 2 shared | HF |
| Attention | 69 KDA + 24 Gated MLA | HF |
| コンテキスト | 1,048,576 | HF / Dynamo |
| ウェイト形式 | MXFP4（QAT）/ 活性化 MXFP8 | HF |
| ディスク目安 | 約 1.56TB（報道・FAQ）/ 1680GB 表記（vLLM Recipes） | innovaTopia, Runpod, vLLM |
| ビジョン | MoonViT-V2 401M | HF |
出典: Hugging Face moonshotai/Kimi-K3（2026年7月時点）
B300×8 1ノードは本当に載るのか（メモリとDay0実測）
メモリ判断の出発点
メモリ判断の出発点は単純です。
- FP8 換算で総パラメータ級を持つと約 2.8TB → 8×B300（約 2.3TB）には収まらない
- 公開が MXFP4 だからこそ、約 1.56〜1.68TB が主戦場
- ヘッドルームは KV / KDA state / ランタイム余白で決まる
Fixstars Day0 実測の読み方
Fixstars の Zenn 記事（Day0 実測・要帰属）は、次の環境で報告しています。
- GPU: B300 SXM6×8（288GB×8=2304GB）
- エンジン: SGLang 0.5.16、
lmsysorg/sglang:kimi-k3 - CUDA 13
報告値の要点は次の通りです。
- ウェイト実測: 約 195.86 GB/GPU、合計約 1.57TB
- 起動: 合計約 88.8 分（ロード約 81.4 分）。再起動コストが大きい
- steady-state: per-rank 使用 約 248/275 GB。Mamba/KDA state 17.13GB、MLA KV 1.70GB（65,984 tok/rank）
- DCP8 時の実効コンテキスト例: 65,984 × 8 = 527,872 tokens（
--mamba-full-memory-ratio=5時） - 反省点: ratio=5 は KDA state 過多。cookbook 既定は 0.9 前後で、平均リクエスト長から算出する
独立 FAQ との一致と限界
独立側でも Runpod FAQ は、8×B300（288GB、合計約 2.3TB）が weights+KV の最も単純なフィットと明記しています。
- H100 8×80GB ではウェイト非収まり（innovaTopia などとも一致）
- Day0 起動成功 ≠ 1M フルコンテキスト常時・高並列本番
- mamba-full-memory-ratio、DCP、エンジン差分で「使える ctx / 並列」は変わる
- コールドスタートが 1 時間前後なら、頻繁な再起動を前提にした開発フローには向かない
| 観点 | 目安 | 含意 |
|---|---|---|
| ウェイト | MXFP4 約 1.56〜1.68TB | 8×B300 に載る設計点 |
| ノード合計 HBM | 約 2.3TB（288×8） | KV/state/NCCL 用ヘッドルーム |
| コールドスタート | 数十〜90分級 | 頻繁な再起動向きでない |
| 長文向け調整 | mamba-full-memory-ratio を下げる | KDA state より MLA KV へ寄せる |
出典: Fixstars Zenn 実測、Runpod Kimi K3 FAQ、SGLang cookbook（2026年7月時点）
推論エンジン経路の比較（SGLang / vLLM / Dynamo）
同じ Kimi K3 でも、エンジン公式ドキュメントが想定する「最小検証」と「本番形」は揃っていません。選定は好みではなく、次の軸で分岐します。
- ノード形状
- 長文効率
- 運用基盤
SGLang cookbook
SGLang cookbook（公式 docs）の要点は次の通りです。
- Day0 タグ:
lmsysorg/sglang:kimi-k3 - ハードウェア行列に B300 1×8 を含む
- Unified / Prefill / Decode
- Low-Latency / Balanced / High-Throughput
- DSPARK
--mamba-full-memory-ratioの calculator- Fixstars が DCP を選んだ経緯とも整合しやすい
- 向く用途: 単一ノードでの長文効率検証
vLLM Recipes
vLLM Recipes（recipes.vllm.ai）の要点は次の通りです。
- 中心イメージ:
vllm/vllm-openai:kimi-k3 - Overview で MXFP4 1680GB を示す
- Prerequisites 寄りの姿勢は「最低 8×GB300・本番は multi-node」に近い
- TP / TEP / DEP や PD disaggregation の記述が厚い
- 向く用途: OpenAI 互換 serve やクラスタ標準化を優先する場合
- 注意: ツールコール形式の揺らぎに備え、スキーマ検証とリトライを前提にする
NVIDIA Dynamo
NVIDIA Dynamo（docs.nvidia.com）の要点は次の通りです。
- Kubernetes 上で Dynamo+vLLM を組む
- GB200 / GB300 NVL72 の aggregated / disaggregated を公開
- 構成例: 16×GB200 TP16、16×GB300 を 2×（8-GPU replica）
- FP8 KV と 1M ctx を前提にした本番ラック側のレシピ
- 単一 B300 ラボ検証とはレイヤが違う
時点依存のエンジン選択メモ
Fixstars の Day0 時点メモでは、次が説明されています。
- 当時 vLLM が DCP 未対応
- MLA KV が全 GPU 複製になる
- 長コンテキスト効率で SGLang+DCP を優先した
これは時点依存です。採用前に各公式の対応表を再確認してください。
| 軸 | SGLang cookbook | vLLM Recipes | NVIDIA Dynamo |
|---|---|---|---|
| 典型形状 | B300 1×8 を含む検証行列 | multi-node / 8×GB300 前提が強い | GB200/GB300 ラック + K8s |
| 強み | DCP・mamba ratio・DSPARK 導線 | OpenAI 互換 serve・広 HW ピッカー | KV-aware routing・disagg 運用 |
| 向く用途 | Day0 単一ノード検証・チューニング | クラスタ TP/EP 本番 | 大規模 agentic + 運用基盤 |
| 注意 | ratio 誤設定で ctx キャパ低下 | ツールパーサ揺らぎ・相互接続 | 重量級前提・初回起動が長い |
出典: SGLang cookbook、vLLM Recipes、NVIDIA Dynamo Kimi-K3（2026年7月時点）
採用前チェックリストと次アクション
読後に必要なのは、人気記事の見出しを繰り返すことではなく、自前環境での Go / No-Go 記録です。次を順に確認してください。
- GPU: B300 288GB×8（または同等の約 2.3TB 級）を確保できるか。H100 80GB×8 のみなら No-Go（ウェイト非収まり）。
- ストレージ / ネット: 1.5TB 超のダウンロードと、ノードローカルまたは共有キャッシュ。リリース直後は再試行前提。
- 目的: ラボ Day0 検証か、高並列本番か。後者なら 64 基超推奨や Dynamo / GB300 複数レプリカで再見積もり。
- エンジン: 単一ノード長文効率なら SGLang+DCP を第一候補とし、cookbook で ratio を平均リクエスト長から固定。クラスタ標準化なら vLLM / Dynamo 公式レシピ。
- 運用耐性: コールドスタート約 1 時間を許容できるか。reasoning 常時オン、ツールパーサ検証、ライセンスしきい値の法務確認。
- 評価: 自ワークロードで TTFT / ITL / throughput を測る。公開ベンチの数値をそのまま SLA にしない。
推奨ステップは次の通りです。
- HF で
moonshotai/Kimi-K3とライセンスを確認する - SGLang cookbook で B300 1×8 コマンドを生成し、ratio を平均リクエスト長から固定する
- 短文 smoke → 長文 / ツール呼び出し → 必要なら DSPARK
- 不足なら 16×B200 や GB300 複数レプリカ、Dynamo disagg へエスカレーションする
料金・API 利用の可否判断は、導入全体の別軸です。API 側の料金・ベンチ・注意点は関連記事「Kimi K3の導入判断」も併せて確認すると判断が速くなります。
よくある質問（FAQ）
関連記事:
- Agent Zero v2.6 — Docker 上のフル Linux デスクトップを持つ OSS エージェント（Opus 5 比較で再バズ）
- OpenClaude — 任意 LLM で動く OSS コーディングエージェント CLI（30k★・v0.26）
- Open Knowledge Format（OKF）とは？エージェント向けMarkdown知識仕様の導入判断
まとめ
Kimi K3 は 2.8T 級でも、MXFP4 により 8×B300 シングルノード Day0 が現実的な検証ラインになりました。成功条件は「MXFP4 + 十分な HBM + エンジン別の state/KV 設計理解」です。人気記事の見出しだけで本番サイジングしないでください。
次アクションは明確です。自前 GPU を棚卸しし、cookbook で ratio を固定し、smoke を回し、不足ならマルチノード / Dynamo へ進む。上のチェックリストで Go/No-Go を記録すると、議論が「動いた/動かない」から「どの用途で足りるか」へ移ります。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す