はじめに
2026年7月27日、Moonshot AI から Kimi-K3 のモデルウェイトが公開されました。7月16日のモデル発表時点から「オープンウェイトモデルとして史上最大」と大きな話題になっていたモデルです。
フィックスターズでは、ウェイト公開の当日に NVIDIA B300 x8 のシングルノード環境へデプロイし、推論性能のベンチマークを実施しました。本記事はその速報です。ダウンロード開始からベンチマーク完了まで、リリース当日のうちに一通り走り切ることができました。
Kimi-K3 とは
Kimi-K3 は Moonshot AI が開発したフロンティアクラスの MoE(Mixture of Experts)モデルです。モデルカードで公開されている主な仕様は以下のとおりです。
| 項目 | 仕様 |
|---|---|
| 総パラメータ数 | 2.8T(2兆8000億) |
| アクティブパラメータ数 | 104B |
| エキスパート構成 | 896 エキスパート中 16 がトークンごとに活性化(+ 共有エキスパート 2) |
| レイヤー数 | 93(KDA 69 層 + Gated MLA 24 層) |
| 公開ウェイトの精度 | MXFP4 ウェイト / MXFP8 活性化(量子化認識学習) |
| コンテキスト長 | 1M トークン(1,048,576) |
| マルチモーダル | ネイティブの視覚理解に対応(MoonViT-V2, 401M) |
| 推論モード | thinking mode が常時オン(low / high / max で強度設定可能) |
| ライセンス | Kimi K3 License(独自ライセンス) |
アーキテクチャ面では、ハイブリッド線形アテンションの Kimi Delta Attention(KDA)と、residual connection の置き換えである Attention Residuals という2つの独自技術が採用されています。アテンション層の大半(93層中69層)が KDA で、通常の(Gated MLA の)アテンション層は24層のみという構成です。後述しますが、このハイブリッド構成は推論サーバのメモリ管理にも直接影響してきます。
もう一つ重要なのが、SFT 段階から量子化認識学習(QAT)を行った MXFP4 ウェイトでの配布です。学習後に量子化するのではなく、最初から MXFP4 で使われることを前提に作られているため、追加の量子化作業なしでそのままデプロイできます。
発表時の各種評価では、Claude Fable 5 や GPT 5.6 Sol といった最上位のプロプライエタリモデルに肉薄する、オープンウェイトモデルとしては過去最高水準の性能とされています。コーディングやエージェントタスクでの強さが特に注目されています。
検証環境
| 項目 | 内容 |
|---|---|
| GPU | NVIDIA B300 SXM6 x8(シングルノード) |
| GPU メモリ | 288GB HBM3e x8 = 合計 2,304GB |
| CPU | Intel Xeon 6767P ×2 ソケット（64コア/ソケット、合計128コア、1スレッド/コア） |
| システムメモリ | 3.0 TiB DDR5 |
| インターコネクト | NVLink 5.0、18 links/GPU、53.125 GB/s/link = 956 GB/s/GPU（片方向） |
| OS / ドライバ | Ubuntu 24.04.4 LTS（kernel 6.8.0-71-generic）、CUDA 13.0、Driver 580.105.08 |
| 推論エンジン | SGLang 0.5.16（Docker コンテナ sglang-kimi-k3） |
なぜ SGLang か
リリース時点で vLLM と SGLang の両方が Kimi-K3 に対応していますが、今回は SGLang を選択しました。理由は DCP(Decode Context Parallelism)への対応です。
Kimi-K3 のようなハイブリッドモデルでは KV キャッシュのメモリ効率が実効コンテキスト長を左右します。リリース時点の vLLM は DCP に対応しておらず、KV キャッシュが全 GPU にレプリケートされます。一方 SGLang は DCP に対応しており、MLA の KV キャッシュを 8 GPU に分散配置できるため、同じメモリ量でも実効コンテキストキャパシティを 8 倍にできます。
メモリフットプリントの検討
総パラメータ 2.8T のモデルは、FP8 でもウェイトだけで約 2.8TB となり、本環境の GPU メモリ合計(約 2.2TB)には収まりません。しかし Kimi-K3 の公開ウェイトは MXFP4 で提供されており、実測でウェイトは 1 GPU あたり約 196GB、8 GPU 合計で約 1.57TB でした。B300 x8 のシングルノードにそのまま収まる計算になっており、超大規模モデルでありながら「1ノードで動かせる」ことを意識した設計と言えます。実測のメモリ内訳は後述します。
デプロイ
ウェイトのダウンロード
MXFP4 のウェイトで合計約 1.6TB。ダウンロードは約 1 時間で完了しました。途中、一部のファイルでダウンロードがスタックする現象があり、プロセスを kill して再実行したところ問題なく完了しました。リリース直後はアクセスが集中するので、同様の現象に遭遇したらリトライをおすすめします。
起動コマンド
docker run --gpus all \
--shm-size 32g \
--network host \
-v /data/hf_cache:/root/.cache/huggingface \
--ipc=host \
lmsysorg/sglang:kimi-k3 \
sglang serve \
--trust-remote-code \
--model-path moonshotai/Kimi-K3 \
--tp-size 8 \
--dcp-size 8 \
--disable-custom-all-reduce \
--mem-fraction-static 0.85 \
--reasoning-parser kimi_k3 \
--tool-call-parser kimi_k3 \
--mamba-full-memory-ratio 5 \
--speculative-algorithm DSPARK \
--speculative-draft-model-path RadixArk/Kimi-K3-DSpark \
--speculative-dspark-block-size 7 \
--enable-linear-replayssm-spec \
--host 0.0.0.0 \
--port 8001
ポイントとなるオプションを補足します。
--mamba-full-memory-ratio は、KDA の state pool と MLA の KV pool のメモリ配分比率を決めるオプションです。値を大きくすると KDA state pool が大きくなり(同時リクエスト数が多い短文ワークロード向き)、小さくすると MLA KV pool が大きくなります(長文ワークロード向き)。SGLang cookbook の Mamba ratio calculator に平均リクエスト長を入力して算出できます。今回はまず 5 で起動しましたが、これは後述のとおり反省点になりました。
--speculative-algorithm DSPARK は投機的デコーディングの設定です。公開されている draft モデル RadixArk/Kimi-K3-DSpark を組み合わせています。
起動時間: 合計約 89 分
起動完了までの合計時間は約 88.8 分、うちモデルロードが約 81.4 分でした。1.6TB 級のウェイトを読み込むので仕方ないところですが、設定を変えて再起動するたびに 1 時間半かかるのは、今後のチューニング作業においてはかなり効いてくるところです。
一つハマりどころとして、docker logs ではモデルロード中の進捗が表示されず、20 分以上完全に無言になります。ハングしたのかと不安になりますが、docker logs -f や docker attach であれば進捗表示を確認できるようです。
GPU メモリ内訳と KV キャッシュ
起動後の steady state における GPU メモリ使用量の内訳です(per-rank, TP0 代表)。
| 項目 | サイズ (GB) | 備考 |
|---|---|---|
| GPU 総メモリ | 275.04 | B300 SXM6 |
| 使用中 (nvidia-smi) | 248.02 | 起動後 steady state |
| 空き | 26.09 | |
| └ モデルウェイト(本体) | 195.86 | MXFP4 (compressed-tensors) |
| └ モデルウェイト(DSPARK draft) | 0.56 | |
| └ Mamba Cache (KDA state pool) | 17.13 | conv 0.56 + ssm 15.87 + conv_window 0.70 |
| └ MLA KV Cache | 1.70 | 65,984 トークン (per-rank, bf16) |
| └ KDA KV (K+V) | 1.26 | 527,872 トークン (per-rank, bf16) |
| └ その他 (NCCL / CUDA context / MM IPC 等) | 約 31.5 |
Kimi-K3 は MLA + KDA のハイブリッドモデルなので、KV キャッシュに相当するプールが 3 つ確保されます。
| プール | per-rank トークン | 全体 | 用途 |
|---|---|---|---|
| MLA KV | 65,984 | 527,872 (x DCP8) | Multi-Head Latent Attention。コンテキスト長の主指標 |
| KDA KV (K+V) | 527,872 | 527,872 (レプリカ) | Kimi Delta Attention |
| Mamba state | 313 リクエスト | 313 | KDA の同時実行リクエスト上限 |
実効コンテキストキャパシティは 527,872 トークン(MLA KV per-rank 65,984 x DCP8)です。
反省: --mamba-full-memory-ratio=5 は大きすぎた
起動後に気づいたのですが、--mamba-full-memory-ratio のデフォルト値は 0.9 です。5 という値は KDA state pool に寄せすぎで、結果として KV キャッシュのトークンキャパシティが約 0.5M に留まりました。コーディングエージェント用途ではコンテキストが長くなりがちなので、この値はもっと小さくして KV キャッシュ側にメモリを割くべきでした。ワークロードに合わせて cookbook の calculator で算出するのが正解です。
ベンチマーク結果
2 種類の負荷でスループットとレイテンシを測定しました。
Random (ISL=8K, OSL=1K, num-prompts 200)
| 並列数 | duration (s) | out_tput (tok/s) | total_tput (tok/s) | TTFT med/p90/p99 (ms) | ITL med/p90/p99 (ms) | failed |
|---|---|---|---|---|---|---|
| 10 | 543.4 | 376.9 | 3,391.9 | 624 / 1,137 / 5,180 | 37.9 / 39 / 509 | 0 |
| 20 | 397.0 | 515.8 | 4,642.6 | 675 / 1,902 / 10,772 | 50.9 / 52 / 654 | 0 |
| 30 | 338.3 | 605.4 | 5,448.2 | 746 / 6,250 / 16,784 | 60.4 / 63 / 797 | 0 |
| 40 | 315.2 | 649.7 | 5,847.6 | 1,170 / 12,368 / 22,238 | 70.5 / 76 / 825 | 0 |
| 50 | 225.9 | 367.2 | 3,305.1 | 10,934 / 46,651 / 55,621 | 71.7 / 76 / 810 | 119 |
各行の入出力トークンはいずれも in 1,638,400 / out 204,800 です(並列数 50 のみ失敗により in 663,552 / out 82,944)。
コーディングエージェント社内実データセット (max-duration 300, multi-turn)
| 並列数 | duration (s) | out_tput (tok/s) | total_tput (tok/s) | TTFT med/p90/p99 (ms) | ITL med/p90/p99 (ms) | failed |
|---|---|---|---|---|---|---|
| 10 | 396.4 | 481.6 | 2,477.6 | 370 / 670 / 731 | 38.7 / 39 / 87 | 0 |
| 20 | 405.4 | 672.0 | 3,787.7 | 393 / 986 / 2,469 | 51.7 / 54 / 341 | 0 |
| 30 | 458.4 | 754.2 | 3,879.6 | 409 / 1,422 / 2,410 | 61.1 / 62 / 359 | 0 |
| 40 | 686.8 | 629.4 | 2,925.8 | 452 / 2,073 / 3,400 | 70.6 / 73 / 392 | 0 |
| 50 | 726.6 | 791.9 | 3,276.7 | 4,454 / 9,135 / 14,245 | 74.6 / 76 / 458 | 0 |
スループットのスケーリング
Kimi-K3 on NVIDIA B300 x8: 並列数に対するスループット
左: total スループット(入力+出力)、右: output スループット。Random は並列数 40、実データセットは並列数 30 前後で頭打ちになり、Random の並列数 50 では 200 リクエスト中 119 が失敗してスループットが崩れている。
所見
率直な感想として、速いです。2.8T という規模からもっと遅くなることを覚悟していましたが、当社でこれまでに計測してきた GLM-5.2(B300 x4 構成)と同程度の速度が出ています。アクティブパラメータが 104B に抑えられた高スパース MoE と、MXFP4 ネイティブウェイト、DSPARK による投機的デコーディングの組み合わせが効いていると考えられます。
スケーリング特性を見ると、Random ワークロードは並列数 40、実データセットは並列数 30 で total スループットが頭打ちになります。Random の並列数 50 では TTFT の中央値が 10 秒を超え、200 リクエスト中 119 が失敗しました。実データセットでも並列数 40 以降は ITL と TTFT の悪化が目立ちます。今回の設定では、同時処理リクエスト数は 30 程度が実用上の上限と見てよさそうです。
コーディング性能の検証(主観)
スループットだけでなく出力の質も確かめたかったので、実タスクに近いお題として「A* 経路探索の可視化ツール」を単一 HTML ファイルで実装させてみました。二分ヒープの手実装、g スコア改善時の再オープン処理、タイブレーク規則の明示と理由のコメント化、2 画面比較モードなど、雑に実装するとボロが出やすい要求を意図的に盛り込んだプロンプトです。
使用したプロンプト(全文)
単一のHTMLファイルでA*経路探索の可視化ツールを作ってください。
外部ライブラリ・ビルド不要、ブラウザで開くだけで動くこと。
【中核要件】
- 40x25のグリッド。マウスドラッグで壁を描ける／消せる
- スタートとゴールはドラッグで移動可能
- 探索を1ステップずつアニメーション表示する。以下を色分けして区別:
- open set（探索候補）
- closed set（探索済み）
- 今まさに展開中のノード
- 確定した最短経路（探索完了後に始点まで辿って描画）
- 再生／一時停止／1ステップ実行／速度スライダー
【比較機能（デモの目玉なので必須）】
- ヒューリスティックを切り替えられること:
マンハッタン距離 / ユークリッド距離 / h=0（=ダイクストラ法）
- 同じ盤面を左右2画面に並べ、異なるヒューリスティックで
同時に探索させる比較モード
- 展開ノード数・経路長・所要ステップ数をリアルタイム表示
【実装上の要求】
- 優先度付きキューは配列のsortではなく、二分ヒープで実装する
- gスコアが改善した場合の再オープン処理を正しく扱う
- fが同値のときのタイブレーク規則を明示し、コメントで理由を書く
- 斜め移動のON/OFF切替（ONのときコストは√2、壁の角抜けは禁止）
- 追加: セルを右ドラッグで移動コスト1〜5の重みを設定でき、
重みは色の濃さで表現する
【UI】
ダークテーマ、余白を広く取り、色は探索状態の区別が一目で付くパレット。
操作方法は画面内に簡潔に表示。
Kimi-K3 は約 15 分でこのプロンプトを一発で実装し、ブラウザで開くだけで動作しました。比較のため、同じプロンプトを GLM-5.2(NVFP4)にも与えて生成物を並べて触ってみたところ、あくまで主観ですが、見た目と操作性は Kimi-K3 の方が良いと感じました。
Kimi-K3 の生成物。比較モードで 2 つのヒューリスティックを同時実行した状態。凡例・操作方法パネルやキーボードショートカットは要求外の作り込み。
GLM-5.2(NVFP4)の生成物。要件は概ね満たしているが、レイアウトや配色の完成度に差が出た。
生成されたコードを読んで気づいた点をいくつか挙げます。
- 両者とも優先度付きキューは要求どおり二分ヒープ(MinHeap クラス)を手実装しており、配列 sort で誤魔化していない
- タイブレークは、Kimi-K3 が「f 同値 → h 昇順 → g 降順 → LIFO」の 3 段構成で、各段の理由をコメントで説明した上で UI の凡例にも規則を明記。GLM-5.2 は h 昇順の 1 段のみ(こちらも理由コメントあり)
- Kimi-K3 はプロンプトで要求していないキーボードショートカット(Space で再生 / → でステップ / V で比較モード)や、凡例・操作方法のパネルを自発的に追加していた
- GLM-5.2 側にもランダム壁生成ボタンなど独自の工夫はあるが、レイアウトや配色を含めた全体の完成度は Kimi-K3 に分があった
定量ベンチマークではないので参考程度ですが、コーディングエージェントの推論バックエンドとしての体感品質という意味で、速度と合わせて好印象でした。
考察
2.8T モデルが 1 ノードで実用速度で動いたことが最大の成果です。MXFP4 でのネイティブ配布(QAT 済み)により、追加の量子化作業なしにダウンロードしてそのまま起動でき、B300 x8 に収まります。B300(Blackwell Ultra)の FP4 演算性能を活かせる配布形態です。
運用面の課題も見えました。起動(モデルロード)に約 1 時間半かかるため、設定変更の試行錯誤やフェイルオーバーの設計では起動時間を織り込む必要があります。また、KDA + MLA のハイブリッド構成ゆえに --mamba-full-memory-ratio のようなモデル固有のメモリ配分パラメータがあり、ワークロード(短文多並列か、長文エージェントか)に合わせたチューニングが実効性能を左右します。今回の設定は KDA state pool に寄せすぎたため、コーディングエージェント用途を想定するなら比率を下げて KV キャッシュを拡大し、長コンテキストでの挙動を確認するのが次のステップです。
まとめ
Kimi-K3 のウェイト公開当日に、NVIDIA B300 x8 シングルノードへのデプロイとベンチマークを完了しました。MXFP4 ネイティブ配布のおかげでウェイトは約 1.6TB に収まり、追加の量子化なしで 1 ノードで起動できます。スループットは同時 30 リクエスト程度までスケールし、2.8T モデルとしては予想を上回る実用的な速度でした。出力品質の面でも、A* 可視化ツールの実装タスクを一発でこなし、要求外の気の利いた作り込みまで見られました。
今回の検証は、単なる新モデルの速報にとどまらず、当社製品にも直結する取り組みです。
フィックスターズは、オープンウェイト LLM と独自のパフォーマンスエンジニアリングハーネスを組み合わせたオンプレミス AI アプライアンス「Fixstars Vega」を提供しています。Vega では最新のオープンウェイトモデルを継続的に評価しており、今回の Kimi-K3 の検証もその取り組みの一環です。
新しいモデルが公開されたその日から、セキュアなローカル環境で最新のオープンウェイトモデルを安全に活用できる。それが Vega の目指す姿です。組み込みソフトウェア開発への AI 活用にご興味があれば、ぜひ製品ページをご覧ください。
参考リンク
Discussion
興味深く読みました。ウェイト公開当日にB300 x8でデプロイからベンチマークまで完遂し、per-rankのメモリ内訳に加えて、--mamba-full-memory-ratio=5 は大きすぎたという反省まで開示している点が、まず誠実だと思います。
一点だけ、Randomの並列数50で119件失敗したのは、ISL 8K＋OSL 1Kで最大約46万トークンとなり、実効キャパシティ約52.8万に近づいたことで、MLA KV側が逼迫した影響が大きいのでしょうか。比率を下げた構成で実用上限がどこまで動くのか、続報もぜひ読みたいです。
コメントありがとうございます！
検証を担当したエンジニア（@kojiueno ）から、ご質問への回答をもらいました。今後の検証については、また別の機会にご報告できればと思います。
そうだと思います。--mamba-full-memory-ratio 0.5 に下げて、同じベンチマークを取るとエラーにならず、完走します。ただ、今度は同時処理リクエストの上限に達してしまったのか、並列数30でスループットはほぼ頭打ちになって、あまり伸びませんでした。