3行でいうと

  • 公式のHugging Faceで、重みが公開されている主なモデルは、K3（総2.8兆、MXFP4）、K2.7-Code、K2.6、K2.5（いずれも総1兆、ネイティブINT4）、K2-Instruct（block-fp8）です。小さい公式モデルとして、Moonlight-16B-A3B（MIT）とKimi-VL-A3B系（MIT）もあります。
  • ライセンスは2系統です。K3は「Kimi K3 License」で、APIを第三者に提供する事業者には売上の条件と別契約の条項があります。K2.6などの「Modified MIT」は、大きな商用製品での名前の表示が追加されただけでした。どちらも、読んだ範囲では、自分や自社の内部で使う分には重い制限は見つかりませんでした。
  • モデルカードには、必要なGPUの数もメモリも書かれていません。ハードの規模が書かれているのは、vLLMとSGLangとKTransformersの資料です。K3では「最低8基のGB300」（vLLM）、K2.5では「RAM 600GB以上とRTX 4090が2基以上」（KTransformers）といった規模でした。普通のPC向けの道は、公式の資料には見つかりませんでした。
  • 公式の量子化は、K3がMXFP4（重み）とMXFP8（活性化）、K2系がINT4などです。GGUFなどの量子化版は、読んだ一覧の最初の30件に、公式（moonshotai）の名前のものはなく、すべて第三者でした。Moonshot AIは、ある評価で第三者のAPIが公式APIより低いスコアになる例が広く見られる、と書いています。

この記事は、実際に使って確かめた記録ではありません。運営者はKimiを入れていますが、使い心地はこの記事には書いていません。この記事は、公式の資料を2026年10月24日に読んでまとめたものです。コマンドは公式ページに載っているとおりに写したもので、動作確認はしていません。公式ページは要約として取得したため、読み切れていない箇所は「読めていない」と書きました。ハードの規模、推論エンジンの版、モデルの状態は、短い期間で変わります。契約や法律の助言ではありません。ライセンスの解釈は、専門家に確認してください。

先に結論

前提：用語をそろえる

公式のHugging Faceに、何が公開されているか

公式の組織ページ（huggingface.co/moonshotai）は、2026年10月24日に、19のモデルのうち10だけを表示していました（前のガイド02の確認時と同じ）。表示されていた分は次のとおりです。

モデル 規模（カードの表記） 文脈 ライセンス 量子化（カードの表記） 推奨エンジン（カード） 確かさ
Kimi-K3 総2.8兆、有効104B、専門家896のうち16を選ぶ 1,048,576 Kimi K3 License MXFP4（重み）とMXFP8（活性化）、QAT vLLM、SGLang、TokenSpeed 文書に書かれている
Kimi-K2.7-Code 総1兆、有効32B 256K Modified MIT ネイティブINT4 vLLM、SGLang、KTransformers 文書に書かれている
Kimi-K2.6 総1兆、有効32B 256K Modified MIT ネイティブINT4 vLLM、SGLang、KTransformers 文書に書かれている
Kimi-K2.5 総1兆、有効32B 256K Modified MIT INT4（K2.6のデプロイ文書とKTransformers文書から。カード自体は読めていない） 同上 一部読めていない
Kimi-K2-Instruct 総1兆、有効32B 128K Modified MIT block-fp8 vLLM、SGLang、KTransformers、TensorRT-LLM 文書に書かれている
Moonlight-16B-A3B-Instruct 総16B、有効3B 8K MIT BF16 vLLM、SGLangなど 文書に書かれている
Kimi-VL-A3B-Thinking-2506 総約16B（有効の数はカードに明記なし） カードに明記なし MIT カードに明記なし vLLMが推奨 文書に書かれている

ほかに、Kimi-K2-Base、Moonlight-16B-A3B、Kimi-VL-A3B-Thinking が一覧に出ていました。残りの9つのモデルは、ページに表示されておらず、読めていません。一覧に出ているモデルの更新日は、年が表示されていませんでした。

K3のリポジトリは、README、LICENSE、設定とPythonの補助ファイル、そして96個の safetensors の分割ファイルで、全体の大きさは1.56TBと表示されていました（Hugging Faceのファイル一覧。分割ファイルは1つあたり16.6〜17GBと表示された分が多く、全部の大きさは読めていません）。リポジトリには docs フォルダと deploy_guidance.md は見当たりませんでした（一覧の続きが読めていないので、確定ではありません）。公式のGitHub（MoonshotAI）には Kimi-K3 のリポジトリがあり、README、技術報告のPDF、各エンジンのレシピへのリンクがあります。このREADMEには、ローカルでの動かし方の説明も、ハードの要件も、シェルのコマンドもありません。

K3.1 Proについて。 公式ブログ（Kimi K3.1 Pro。日付は記事内に書かれていませんでした）は、「3T級のオープンウェイトモデル」と書き、重みは「2026年11月4日までに公開する」としています。Hugging Faceの表示、ライセンス、パラメータ数、量子化は、その記事には書かれていませんでした。この記事の確認日（10月24日）時点で、重みが公開されているかは、読めた範囲では確認できていません。

ライセンス：動かす前に読む条件

前のガイド（02）に概要を書いたので、ここでは「自分の使い方がどれに当たるか」の見方に絞ります。K3とK2.6のLICENSEを、10月24日に読み直しました。

使い方 K3（Kimi K3 License） K2.6などの Modified MIT 確かさ
自分や自社の内部で、出力を第三者に出さずに使う 第4条が、内部利用（ソフトウェア、出力、その能力を第三者が使えない形）と、Moonshot AIの公式の製品や認定された推論パートナー経由の利用を、第2条と第3条の対象から外している MITに表示条件が付いただけで、内部利用だけを区別する書き方は読んだ範囲では見つからなかった 文書に書かれている
自社の製品に組み込んで、利用者に出す 商用利用は認められる。著作権表示を含める。製品の月間利用者が1億人超、または月の売上が2,000万ドル超なら、画面に「Kimi K3」を目立つように表示（第3条） 同じ数字の条件で「Kimi K2.6」を表示 文書に書かれている
他社にAPIで推論やファインチューニングを提供する 第2条。利用者が入力、パラメータ、学習データを意味のある形で制御できる提供で、自社と関連会社の12か月の売上の合計が2,000万ドルを超えるなら、商用利用の前にMoonshot AIと別の契約が必要 該当する条項は読んだ範囲では見つからなかった 文書に書かれている
ファインチューニングして配る 前文が、実行、デプロイ、ファインチューニング、派生物の作成を許している。再配布は著作権表示が条件 標準のMITと同じ形で、派生物にも表示の条件が及ぶ 文書に書かれている
法令の遵守 第1条が、適用される法令に従うことを求めている 読んだ範囲では見つからなかった 文書に書かれている

K3 Licenseの第2条は、「最終利用者向けの製品の中に機能として組み込む場合」と「他社が動かすモデルへの単なる中継」を、MaaSの定義から外しています。第5条は現状のままの提供で、保証はありません。問い合わせ先は license@moonshot.ai と書かれていました。K3のLICENSEには、版番号、「関連会社」の定義、商標、解除、準拠法の条項は、読んだ範囲では見つかりませんでした。

K2.6のLICENSEは、標準のMITへの変更が1つだけ（表示の条件）だと書いています。K2.7-Code、K2.5、K2-Instruct のLICENSEについては、前のガイド（02）で、表示する名前だけが違う、と整理しました。今回は読み直していません。Moonlight と Kimi-VL がMITであることは、各カードの表記で確かめました。

僕らの見立てです。個人や社内で試す範囲なら、読んだ範囲では条件に当たりにくい一方で、「自分のサービスの裏でK3を動かして、誰かにAPIとして貸す」場合は、K3だけ売上の条項に当たる可能性があります。ただし、解釈は法務に確認してください。

公式が書いているハードの規模

モデルカードは、GPUの数もメモリも書いていません（K3、K2.6、K2.7-Code、K2-Instruct のカードで確かめました）。ハードの記載があるのは、次の資料です。

資料 書かれている規模 注意 確かさ
vLLM レシピ（K3） NVIDIAは最低8基のGB300。本番の流量には複数ノードを勧める。AMDは最低8基のMI355XまたはMI350X ページに「Pre-release」の表示。イメージ vllm/vllm-openai:kimi-k3 は CUDA 13のみで、ドライバは r580 以上 資料に書かれている
SGLang クックブック（K3） B300は1ノード8基、GB300は2ノード各4基、GB200は4ノード各4基、B200は2ノード各8基、H200は2ノード各8基（高スループットは4ノード各8基）、H100は4ノード各8基（80GB、余裕が最も小さい）、MI350X/MI355Xは1ノード8基、Ascendは4ノード各8基 検証済みと書かれているのは、B300の1ノード8基の一部の組み合わせだけ。ほかは「最終検証中」。精度は再測定していない 資料に書かれている
Moonshot AI の公式ブログ（K3） 推論には、64基以上のアクセラレータの「スーパーノード」構成を勧める 理由は、通信の帯域が広いほど推論の効率が上がるため、と書かれている。GPUの型番やメモリは書かれておらず、最低条件として書かれたものではない 文書に書かれている
K2.6のデプロイ文書（Hugging Face） vLLMもSGLangも、H200を1ノード、TP8の例 「コマンドは例で、最適とは限らない」と書かれている 文書に書かれている
K2.6のデプロイ文書（KTransformers） 8基のL20と2基のIntel 6454Sで、プレフィルが毎秒640.12トークン、デコードが毎秒24.51トークン（同時48本） 例の数値。条件はその構成のもの 文書に書かれている
KTransformers文書（K2.5） 最小でRTX 4090が2基（VRAM合計48GB）以上、AVX512F対応のx86 CPU、RAM 600GB以上、重みの保存に約600GB。起動例は4090が4基 カードでなく、KTransformers側の資料。起動に2〜3分と書かれている 資料に書かれている
vLLM レシピ（K2.5） BF16では8基のH200（合計約640GB）。NVFP4では4基のBlackwell K2.5の資料。K2.6でも同じ方法と、K2.6のデプロイ文書にある 資料に書かれている

僕らの概算です（公式の記載ではありません）。K3の重みは、MXFP4（1つの重みが4ビット）なので、2.8兆×0.5バイトで約1.4TBになります。Hugging Faceの表示の1.56TBに近い大きさです。つまり、ディスクにも、メモリにも、手元のPCでは置けない規模です。1兆規模のK2系は、K2.5のKTransformers文書の「重みの保存に約600GB」が、公式の資料で見つかった唯一の容量の記載です。K2.6など他のモデルの容量は、今回読んだ範囲では書かれていませんでした。

推論エンジン：公式のコマンドを写す

次は、公式のカードと資料に載っているコマンドを、そのまま写したものです。動作確認はしていません。

重みを手元に落とす（Hugging Face CLI）

vllm serve "moonshotai/Kimi-K3" のようにモデル名だけで起動すると、重みは最初の起動時にHugging Faceから取得されます。先に自分で落としておきたい場合は、Hugging Faceの公式ドキュメント（huggingface_hub のCLIの説明）に、次の書き方があります。K3のリポジトリで実行した結果ではなく、ドキュメントの例を写したものです。

# リポジトリ全体を取得（既定ではキャッシュに置かれる）
hf download <リポジトリ名>

# 置き場所を指定する
hf download <リポジトリ名> --local-dir <フォルダ>

# 何を落とすかを先に確かめる（落とさない）
hf download <リポジトリ名> --dry-run

# 一部のファイルだけ
hf download <リポジトリ名> --include "*.safetensors"

モデルカードが載せている起動コマンド（K3）

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server \
    --model-path "moonshotai/Kimi-K3" \
    --host 0.0.0.0 \
    --port 30000

SGLangのDockerの例は、--gpus all、--shm-size 32g、--ipc=host を付け、Hugging Faceのキャッシュをマウントし、環境変数 HF_TOKEN を渡す形です。カードには docker model run hf.co/moonshotai/Kimi-K3（Docker Model Runner）も載っていますが、ハードの記載はなく、これが普通のPCで動くという意味かは、カードからは読めません。TokenSpeed は、カードがレシピへのリンクだけを載せていて、コマンドは載っていません。

パーサーとオプションが要るなら、資料のコマンドを使う（K2.6のデプロイ文書）

K2.6のHugging Faceのデプロイ文書は、vLLM 0.19.1を、公式が「手動で確認した」と書く推奨の安定版としています（nightlyは実験的で不安定になりうる、とも書かれています）。SGLangは v0.5.10 以降が対応です。

vllm serve $MODEL_PATH -tp 8 --mm-encoder-tp-mode data --trust-remote-code --tool-call-parser kimi_k2 --reasoning-parser kimi_k2

sglang serve --model-path $MODEL_PATH --tp 8 --trust-remote-code --tool-call-parser kimi_k2 --reasoning-parser kimi_k2

文書は、--tool-call-parser kimi_k2 はツール呼び出しに必須、--reasoning-parser kimi_k2 は思考がデフォルトで有効なので必須、と書いています。カードのコマンドには、この2つのフラグがありません。ツールや思考の出力を扱うなら、カードのコマンドだけでは足りない、ということです（僕らの整理です）。

K3のパーサー（SGLangの例）

K3のパーサーの名前は、K2とは違い kimi_k3 です。SGLangのクックブックにある、8基のGPUでメモリを抑える例は次のとおりです。

sglang serve \
  --trust-remote-code \
  --model-path moonshotai/Kimi-K3 \
  --tp-size 8 \
  --context-length 65536 \
  --enable-symm-mem \
  --mem-fraction-static 0.82 \
  --mm-feature-transport cpu \
  --reasoning-parser kimi_k3 \
  --tool-call-parser kimi_k3 \
  --host 0.0.0.0 \
  --port 30000

vLLMのレシピは、--enable-auto-tool-choice --tool-call-parser kimi_k3 --reasoning-parser kimi_k3 を挙げています。同じレシピに、モデルが、パーサーの想定と違う形でツール呼び出しを出すことがあるので、スキーマの検証と再試行を勧める、と書かれています。

CPUとGPUを組み合わせる方法（KTransformers）

KTransformersは、重みの一部（専門家）をCPU側に置いて、GPUと組み合わせて動かすための、別のプロジェクト（kvcache-ai）です。Apache-2.0と表示されています。K2系の例（K2.6のデプロイ文書）は次のとおりです。

python -m sglang.launch_server \
  --host 0.0.0.0 \
  --port 31245 \
  --model /path/to/kimi-k2.6 \
  --kt-weight-path /path/to/kimi-k2.6 \
  --kt-cpuinfer 96 \
  --kt-threadpool-count 2 \
  --kt-num-gpu-experts 30 \
  --kt-method RAWINT4 \
  --tensor-parallel-size 4 \
  --trust-remote-code

上は、公式の例から、メモリや並びを決めるオプションの一部を省いて写したものです。全文は、K2.6のデプロイ文書を見てください。--tensor-parallel-size 4 なのに、ハードの記載は8基のL20、という食い違いが原文にあり、読めた範囲では説明がありません。KTransformersのトップページの対応モデル一覧に、Kimi は K2、K2-0905、K2-Thinking、K2.5 まで書かれていて、K3は載っていませんでした（ページ内の日付つきの項目で一番新しいのは2026年8月26日）。

Transformersで直接読み込む場合

K3のカードの例は、trust_remote_code=True を付けて AutoModel.from_pretrained(...) を使い、device_map="auto" を指定する形です。K2.6とK2.7-Codeのカードは、transformers を >=4.57.1, <5.0.0 と書いています。K3のカード、Moonlightのカード、K2-Instructのtransformersの例、K2.6のデプロイ文書のコマンドは trust_remote_code（または --trust-remote-code）を付けています。K2-InstructのvLLMとSGLangの例には付いていません。リポジトリ内のPythonコードを実行する設定なので、読んでから使うのが安全です（これは僕らの注意です）。

量子化：公式が書いていること、書いていないこと

対象 公式の記載 確かさ
K3 MXFP4の重みとMXFP8の活性化。SFTの段階からのQAT。「広いハードで動かすため」と説明。Hugging Faceのテンソルの型は F32、BF16、U8 文書に書かれている
K2.6、K2.7-Code ネイティブINT4。K2-Thinkingと同じ方法 文書に書かれている
K2-Thinking QATで、MoE部分にINT4の重みだけの量子化。低遅延では約2倍の速度で劣化なし、と書かれている。形式は compressed-tensors で、FP8やBF16に戻すには別のリポジトリの手順を使う 文書に書かれている
K2-Instruct block-fp8 文書に書かれている
公式のGGUF、MLX、AWQなど 読んだ範囲では、公式（moonshotai）が配っているものは見つからなかった 書かれていない（読んだ範囲では）

K3のモデルツリーは、量子化版を52件と表示し（K3のカードのサイドバーは58件と表示していて、取得したページで数が違いました）、最初のページの30件には、moonshotai の名前のものはありませんでした。作者は、GPUベンダー、企業、個人など様々で、形式は GGUF、NVFP4、MLX、W4AFP8 などでした。SGLangのクックブックは、その中のNVIDIA製のNVFP4版を、別のイメージで動かす選択肢として挙げ、Ascend向けには別のW4A8版（1.49TB）を挙げています。K3のカードは、llama.cpp、Ollama、LM Studio で使える量子化版の一覧にリンクしていますが、どれが良いかは書いていません。個々の品質を、この記事では確かめていません。取得した最初の30件には、名前に「Uncensored」とついた第三者の版も含まれていました。作者は公式とは別なので、出所と中身は自分で確かめてください。

公式が出している注意。 Kimi Vendor Verifier（K2.6と同時に公開）の公式ブログは、K2 Thinking の後に、ベンチマークの異常なスコアの報告が多く、デコードのパラメータの誤用が原因のものが多かったと書いています。第三者のAPIと公式APIで、スコアに目立つ差が出た例も挙げ、この差は広く見られる、としています。長い出力のテスト（AIME2025）は、KVキャッシュの不具合や量子化による劣化を見つけやすい、とも書かれていました。つまり、第三者が量子化した重みや、自分で組んだ環境は、元のモデルと同じ精度を保つ保証がない、と読めます。ただし、公式ブログは、個別の量子化版を名指しして悪いとは言っていません。

自分のPCで動かす入口と、現実的な制約

公式の資料から読み取れる入口は、規模ごとに次の3つです。

入口 公式の資料にあること 制約 確かさ
1. K3、K2.6などの大きいモデルを、サーバー級のGPUで動かす vLLM、SGLangのレシピ。8基以上のGPU。コマンド、パーサー、イメージ 容量が1.4〜1.6TB規模（K3）。ドライバや専用イメージ。資料に「Pre-release」や「最終検証中」の表示 資料に書かれている
2. K2系を、CPUのメモリとGPUの組み合わせで動かす（KTransformers） RAM 600GB以上、4090が2基以上（K2.5の資料）。起動例は4基 普通のPCではない。K3は対応表に載っていなかった 資料に書かれている
3. 小さい公式モデル（Moonlight-16B-A3B、Kimi-VL-A3B-Thinking-2506）を、vLLMなどで動かす MITライセンス。BF16の16B。vLLMとSGLangのコマンド。Kimi-VLはvLLMの例で vllm 0.9.1 VRAMの要件は、どちらのカードにも書かれていない。2025年に出た世代で、K3やK2.6とは別のもの 文書に書かれている

3番について、僕らの概算です。Moonlightの重みは、BF16で16B×2バイトなので、約32GBです。これに、実行中のメモリが足されます（公式の記載ではありません）。Moonlightの文脈は8Kです。Kimi-VLのカードは、長く考えるモデルで32Kトークン程度まで出力しうるので、vLLMを勧める、と書いています。思考の部分は特別な区切りで囲まれて出てくるので、サンプルのコードがそれを切り出しています。どちらのカードも、llama.cpp、Ollama、LM Studio で使える量子化版へのリンクを載せていて、Moonlightで8件、Kimi-VLで14件と表示されていました（内容は読めていません）。

小さい公式モデルを試す手順は、各カードに次のように書かれています（コマンドはカードの記載を写したもので、動作確認はしていません）。

# Moonlight-16B-A3B-Instruct（カードのvLLMの例）
pip install vllm
vllm serve "moonshotai/Moonlight-16B-A3B-Instruct"

K3やK2.6を、手元の1台のPCで動かす方法は、今回読んだ公式の資料には見つかりませんでした。「見つからなかった」であり、「不可能だ」という意味ではありません。第三者が極端に小さくした版を出していることは、一覧からわかりますが、品質は確かめられていません。

K3を試したいだけなら、重みを落とさずに、公式のAPI（ガイド06）で呼ぶほうが、手元の準備は圧倒的に少なくて済みます。これは、僕らの見立てです。ただし、APIに送ったデータの扱いは、ガイド03にまとめた規約に従います。

最初の10分でやること

ここは、公式に書かれていることを順番に並べた、読んだ人がすぐ動くための手順です。ただし、各項目の「目安」は僕らの整理です。

  1. （試すだけなら）最初は小さい公式モデルで。 Moonlight-16B-A3B-Instructは、pip install vllm と vllm serve "moonshotai/Moonlight-16B-A3B-Instruct" の2行がカードに載っています。ここで、起動、呼び出し、止め方の流れだけ先に体験できます（これは僕らの整理です）。
  2. モデルを決めて、そのカードとLICENSEを開く。 K3なら Kimi K3 License、K2.6なら Modified MIT。上の表で、自分の使い方（内部、製品組み込み、API提供）が、どの行に当たるかを書き出します。
  3. 容量を確かめる。 Hugging Faceの「Files」で、リポジトリ全体の大きさを見ます（K3は1.56TBと表示）。ダウンロード先と、読み込む先の両方に、その容量が要ります（僕らの整理）。落とす前に hf download <リポジトリ名> --dry-run で中身を確かめられます。
  4. 資料のハード表を見る。 K3は vLLM のレシピとSGLangのクックブック、K2系はK2.6のデプロイ文書。自分の環境が、書かれた規模に届いていなければ、ここで止めて、APIか小さいモデルに切り替えます。
  5. 版を揃える。 K2.6は、vLLM 0.19.1（推奨の安定版）、SGLang 0.5.10以降、transformers は4.57.1以上5.0未満。K3は、レシピの専用イメージとドライバの条件（r580以上）を確かめます。
  6. 起動はコマンドを写し、フラグの意味を確かめる。 パーサーの2つ（kimi_k2 か kimi_k3）、--trust-remote-code、ポート番号を見ます。
  7. 最初の呼び出しは小さく。 文脈長を絞り（SGLangのK3の例は65536）、短い質問で、思考の出力が返ってくるかを確かめます。K3のカードは、文章では reasoning_content が返ると書きながら、サンプルのコードでは response.choices[0].message.reasoning を読んでいて、カード自身の中で名前が食い違っています。サーバーのパーサーの設定によっても出方が変わりうるので、実際の応答を見て、どのフィールドに入っているかを確かめます（これは僕らの整理です）。

動いたあとの確かめ方

気をつけること

出典