Moonshot AI が Kimi K3 のウェイトを公開しました。総パラメータ 2.8 兆・MXFP4 形式で 1.56TB、Hugging Face 上では 96 個の safetensors に分割されています。推奨実行環境は「アクセラレータ 64 基以上」。なかなか個人で動かせるモデルではありませんね。
ありがたいことに、仕様のほうは最初から公開されています。リポジトリの config.json に、層構成も量子化設定も全部書いてあります。
この記事では、その公開スペックが、**「1.56TB の実ファイルの中に、どう格納されているのか」**を確かめていきます。
- MXFP4 の重みは、safetensors 上では U8 の
*_packed+*_scaleペアに化けている - config の
group_size: 32は、ヘッダのバイト数の割り算でそのまま検算できる - 量子化の
ignoreリストが、dtype 分布の色分けとしてそのまま観測できる - そして 1 つだけ、config に書いていない数字が実ファイルから出てくる
ヘッダ読みの仕組みは前回の記事（Rust で 12GB を 172KB で判定する）に書いています。
safetensors は [8 バイトのヘッダ長][JSON][テンソル本体] で、Hugging Face の resolve/ URL は HTTP Range に対応しています。
まず config.json を読む
公開されているスペックを見ます（2026-07-28 取得）。
| 項目 | config.json の値 |
|---|---|
| hidden size / 層数 | 7168 / 93 層 |
| 最初の密な層 |
first_k_dense_replace: 1（レイヤー 0 だけ MoE でない・intermediate_size: 33792） |
| エキスパート |
896 個/層・毎トークン 16 個活性化・共有エキスパート 2・moe_intermediate_size: 3072
|
| attention |
model_type: "kimi_linear" — KDA（線形アテンション）69 層 + full attention 24 層・short_conv_kernel_size: 4
|
| コンテキスト |
max_position_embeddings: 1048576（1M） |
| vision | ViT 27 層・width 1024・qkv_hidden_size: 1536
|
| 量子化 |
mxfp4-pack-quantized・num_bits: 4・group_size: 32・scale_dtype: "torch.uint8"・symmetric |
量子化には対象外リストもあります。
"ignore": [
"re:.*self_attn.*",
"re:.*shared_experts.*",
"re:.*mlp\\.(gate|up|gate_up|down)_proj.*",
"re:.*lm_head.*",
"re:.*vision_tower.*",
"re:.*mm_projector.*"
]
つまり「ルーテッドエキスパートだけを 4bit にして、attention・共有エキスパート・埋め込み・vision は元の精度のまま」ということです。ここからは、これが実ファイルにどう写っているかを見ていきます。
この照合を可視化するツールを safetensors ビューア に実装したので、先に全体像を載せます。「Kimi K3（1.56TB）を読んでみる」→「全 96 シャードを読んでモデル全体を見る」で、ブラウザが 96 枚のヘッダだけを取得して集計します（実測 約 80 秒・72MB。ファイルはアップロードされません）。
シャード帯はバイト量比例・役割で色分けです。オレンジが MXFP4 の MoE 層 ×92、右端に埋め込み・プロジェクタ・vision tower が細く挟まっています。下の縞がレイヤー帯で、4 層ごとに full attention が入る 69:24 のハイブリッド構成が一目で分かります。
以下では、この中身をシャード 3 枚のヘッダ読みで順に確かめていきます。数値はすべて 2026-07-28 の実測です。
先頭シャード: 「最初の 1 層だけ密」
まず 1 枚目のヘッダです。
model-00001-of-000096.safetensors
取得 2,928 B で判定 / 全体 2,233 MiB (0.0001%)
テンソル 23 本 dtype 分布 = {'F32': 6, 'BF16': 17}
量子化テンソルなし（素の fp16/bf16 と思われる）
BF16 と F32 しかありません。テンソル名を見ると、入っているのは layers.0 だけ。しかも block_sparse_moe ではなく普通の FFN です。
language_model.model.layers.0.mlp.gate_proj.weight BF16 [33792, 7168]
language_model.model.layers.0.mlp.up_proj.weight BF16 [33792, 7168]
language_model.model.layers.0.mlp.down_proj.weight BF16 [7168, 33792]
config の first_k_dense_replace: 1 のとおり、レイヤー 0 は密な層（DeepSeek 系でもよく見る構成です）。shape の 33792 も intermediate_size と一致します。
ビューアで開くと、バイト配置帯は BF16 の緑一色です。
中盤シャード: MXFP4 は U8 ペアで入っている
96 枚の真ん中あたりを読みます。
model-00050-of-000096.safetensors
取得 824,112 B で判定 / 全体 16,203 MiB (0.0049%)
テンソル 5,404 本 dtype 分布 = {'F32': 7, 'BF16': 21, 'U8': 5376}
config は「MXFP4」と言っていましたが、dtype 分布のどこにも FP4 はありません。safetensors の dtype に FP4 が無いためで、重みは U8 として格納されています。5,376 本の U8 の名前を見ると、こういうペアがひたすら並んでいます。
...layers.49.block_sparse_moe.experts.0.w1.weight_packed U8 [3072, 1792] 5,505,024 B
...layers.49.block_sparse_moe.experts.0.w1.weight_scale U8 [3072, 112] 344,064 B
experts.0 から experts.895 まで。config の 896 エキスパートがそのまま居て、w1/w2/w3 × packed/scale で 896 × 3 × 2 = 5,376 本 — dtype 分布とぴったり合います。w1 の 3072 は moe_intermediate_size: 3072 です。
ビューアのテンソル一覧を experts.0.w で絞り込んだところです。
group_size: 32 を割り算で検算する
config は group_size: 32・scale_dtype: uint8 と言っています。ヘッダのバイト数だけで検算できます。
-
weight_packedは 1 バイトに FP4 を 2 個詰めます。[3072, 1792]バイト = 論理的には 3072×3584 の FP4 行列 - MX（microscaling）形式は 32 要素ごとに 1 個の E8M0 スケール（8bit = U8 で 1 バイト）。3584 ÷ 32 = 112 — scale の shape
[3072, 112]と一致 - バイト比でも: 5,505,024 × 2 ÷ 344,064 = 32 —
group_size: 32が実ファイルでそのまま成立
ちなみに、量子化設定の置き場所はフォーマットごとに流儀が違います。たとえば ComfyUI は <layer>.comfy_quant という専用テンソルに設定 JSON を丸ごと埋め込むので、ヘッダを読めば設定そのものが手に入ります（前回の記事で FLUX.1-dev などを実測しています）。一方MX 形式は、ヘッダに設定情報を一切持ちません。この命名規則（*_packed + *_scale）と割り算が手がかりになります。
検算をもうひとつ。U8 の packed バイトを FP4×2 で数え直すと、このシャードの実効パラメータは約 31B。93 層でおよそ 2.8T — 公称の桁と合います。
ignore リストが dtype 分布に写っている
シャード 50 の中身を役割で分けると、config の ignore リストがそのまま色分けとして見えます。
| 部位 | dtype | シャード内の割合 | ignore リストとの対応 |
|---|---|---|---|
| ルーテッドエキスパート 896 個（w1/w2/w3） | MXFP4（U8 packed + scale） | 約 87% | 量子化対象 |
| 共有エキスパート（shared_experts） | BF16 | 約 12% | re:.*shared_experts.* |
| attention・router・各種 projection | BF16 | 残り |
re:.*self_attn.* ほか |
| ノルム・補正バイアス類 | F32 | ほぼ 0% | — |
共有エキスパートの shape [6144, 7168] も、num_shared_experts: 2 × 3072 = 6144 で合います。「かさばる所だけを 4bit に削り、毎トークン必ず通る所は BF16 のまま守る」という設計が、ヘッダの上で実物として確認できました。
ビューアでシャードを単体で読むと、この表がそのまま出てきます（「Kimi K3（1.56TB）を読んでみる」ボタンの直後の画面です）。
MXFP4 の判定（packed/scale のペア数・ブロックサイズ・実効パラメータ）まで自動で出ます。手元の .safetensors をドロップしても同じ解析ができます。
config に書いていない数字がひとつありました: エキスパートは 3584 次元で動く
ここまで config と実ファイルは全部一致でした。ひとつだけ、config に数値が無いものが実ファイルから出てきます。
...block_sparse_moe.routed_expert_up_proj.weight BF16 [7168, 3584]
...block_sparse_moe.routed_expert_norm.weight BF16 [3584]
...block_sparse_moe.routed_expert_down_proj.weight BF16 [3584, 7168]
トークンを 7168 次元から 3584 次元（ちょうど半分）に落としてから 896 個のエキスパートに通し、終わってから 7168 に戻す — エキスパートを潜在空間で回す構成です。config には latent_moe_use_norm: true というフラグがあるだけで、潜在次元 3584 という値はヘッダの shape にしか出てきません。
この 3584 は、ビューアのテンソル一覧で routed_expert と絞り込むだけで見られます。
「Kimi K3（1.56TB）を読んでみる」→ 検索ボックスに routed_expert、の 2 操作です。この記事の他の数字も、同じ画面で全部追試できます。
attention の部品も名前どおり
config は「KDA（線形アテンション）69 層 + full attention 24 層」のハイブリッドだと言っていました。ヘッダにはその部品が名前で並んでいます。
...self_attn.A_log F32 [128]
...self_attn.dt_bias F32 [12288]
...self_attn.q_conv1d.weight F32 [12288, 1, 4]
...self_attn.k_conv1d.weight F32 [12288, 1, 4]
A_log と dt_bias と短い conv1d — Mamba / gated linear attention 系でおなじみの部品です。conv1d の末尾の 4 は short_conv_kernel_size: 4、12288 は 96 ヘッド × head_dim 128。safetensors に計算グラフは保存されませんが、層構成の答え合わせは名前と shape だけで十分でした（後述の全数読みで 69:24 も確認します）。
末尾シャード: vision tower は素の BF16
最後の 1 枚も読んでみます。
model-00096-of-000096.safetensors
取得 19,424 B で判定 / 全体 765 MiB (0.0024%)
テンソル 165 本 dtype 分布 = {'BF16': 165}
vision_tower.encoder.blocks.0.wqkv.weight BF16 [4608, 1024]
vision_tower.patch_embed.proj.weight BF16 ...
ignore リストの re:.*vision_tower.* のとおり、マルチモーダルの入口である vision encoder（ViT）は丸ごと素の BF16 です。wqkv の 4608 も config の qkv_hidden_size: 1536 × 3 で一致。
全 96 シャードで全数確認する
ここまでは抽出したシャード 3 枚のサンプルです。「中盤の 1 枚がこうだったから全層こうだろう」で終わらせず、全シャードのヘッダを読んで全数で照合します。96 枚 × Range 2〜3 回、**合計 72.3MiB（全体の 0.0049%）**で終わります。
読了 96/96 シャード（取得 72.3 MiB）
実効パラメータ合計 : 2,865,017,488,128 ≈ 2.865T
packed/scale ペア : 247,296 組 = 92 MoE 層 × 2,688（脱落ゼロ）
ブロックサイズ : 全ペアで 32（例外なし）
量子化なしシャード : 1（密レイヤー0）・94（埋め込み+lm_head）・95（projector）・96（vision tower）
A_log あり 69 層 / なし 24 層 → config の KDA 69 + full attention 24 と一致
- 公称「2.8 兆パラメータ」が、ヘッダの合算で 2.865T として出てきます（vision tower・埋め込み込みの全数）
- 92 の MoE 層は一層の例外もなく
group_size: 32の同じ量子化。ignore対象外のシャードは正確に 4 枚（密レイヤー 0・埋め込み+lm_head・projector・vision tower） - KDA 69 : full 24 も全数で一致
冒頭に載せたビューアの「全 96 シャードを読んでモデル全体を見る」は、この全数確認をブラウザ内でやっているものです。あの画像のシャード帯・レイヤー帯・87% という数字には、いま並べた全数の実測値がそのまま描画されています。
まとめ
-
config.jsonの公開スペックが、1.56TB の実ファイルで全項目確認できた
—group_size: 32はバイトの割り算で、ignoreリストは dtype 分布で、896 エキスパートはテンソル本数で、69:24 ハイブリッドはA_logの有無で、それぞれ確認できる - safetensors に FP4 の dtype は無いので、MXFP4 は U8 の
*_packed+*_scaleペアとして入っている - エキスパートが 3584 次元の潜在空間で動くことだけは config に数値が無かった
- config が付いてないレポジトリも多々存在する
追記（2026-07-29）: 技術レポートが出たので答え合わせをした
この記事を公開した翌日、Moonshot AI が Kimi K3 の技術レポートを公開しました（MoonshotAI/Kimi-K3 の k3_tech_report.pdf、47ページ）。ヘッダだけから読み取った内容を公式の記述と突き合わせられるようになったので、その結果を追記します。先に結果だけ書くと、ヘッダ読みは全項目レポートと一致しました。
| この記事の実測（ヘッダ + config） | レポートの記述 |
|---|---|
| 量子化はルーテッドエキスパートのみ。attention・shared experts・router・vision は BF16 のまま | §4.1.4 — MoE エキスパート重みを MXFP4 に量子化し、非エキスパート成分（attention 射影・latent MoE 射影・shared experts・router）は高精度のまま |
| ブロックサイズは全 247,296 ペアで 32（バイトの割り算で導出） | MXFP4 の参照先が OCP Microscaling 仕様 — ブロック 32 はその定義どおり |
A_log あり 69 層 / なし 24 層 |
§2.1 — KDA 3 層 + Gated MLA 1 層の 3:1 ブロック × 23、さらに最終層にもう 1 枚 Gated MLA を置く。69 = 23×3、24 = 23+1 |
| 密レイヤーはレイヤー 0 の 1 枚だけ | Table 1 — Number of Dense Layers: 1 |
| エキスパートは 3584 次元の潜在空間で動く（config に数値なし・テンソル形状から導出した唯一の値） | Table 1 — Latent MoE Dimension: 3584 (0.5×)。§2.3 が Stable LatentMoE として設計意図を説明 |
とくに 3584 は、まとめで「これだけは config に数値が無かった」と書いた値です。レポートはこの構造を Stable LatentMoE と呼んでいて、hidden 7168 の半分の潜在空間にルーテッドエキスパートを閉じ込めることで、896 エキスパートへの拡張を通信量・パラメータ量の破綻なしに成立させた、と説明しています。
ヘッダに写らないことも 1 つ分かりました。この MXFP4 は配布用の事後変換ではなく、SFT 以降の post-training 全体を MXFP4 重み + MXFP8 活性で通した QAT（quantization-aware training）の結果です（§4.1.4）。RL のロールアウトも同じ量子化で走らせて train–inference mismatch を消したとあります。つまり配布されている MXFP4 が「本番の精度」であって、どこかに無劣化の BF16 版が控えているわけではありません。
訂正が 1 つあります。この記事では全数集計の実効パラメータを 2.865T と書きましたが、レポートの Table 1 は総パラメータを 2.78T としています。差分 85.1B の正体は、集計スクリプトが *_scale（重み 32 個につき 1 バイト付くメタデータ）までパラメータとして数えていたことでした。scale を除いて数え直すと 2.7799T になり、Table 1 と一致します。ヘッダの合算だけで公式値を再現できること自体は変わりませんが、数え方はレポート側が正しいので、ビューアの全数集計もこの定義に直しました。
- ヘッダ読みの仕組みと Rust 実装: Rustでsafetensorsのヘッダだけ読む — 12GBのモデルを172KBで判定する
- 量子化フォーマットの見分け方: safetensors の量子化を見分ける
- フォーマット自体の解説: safetensorsって何？機械学習モデルを安全・高速に扱う新標準フォーマット