- はじめに
- 検証できるものとできないもの
- 自己申告ベンチマークの限界
- config とレポートが食い違うとき
- 確認できなかったこと
- レポートでよく抜けるもの
- 良いレポートの合図
- 自分で確認する手順
- おわりに
- 参考資料
- 試してみる
- シリーズ
はじめに
シリーズの最後です。ここまで config.json と技術レポートから数十の数字を取り出して計算してきました。この記事では、その過程で用いた判断基準を整理します。どの数字を信じ、どの数字を保留し、どの数字はまったく使わなかったのかという話です。
数値は 2026-08-12 に論文・公式レポート・config.json で直接確認しました。モデルは更新されるため、原典を再度確認してください。
検証できるものとできないもの
技術レポートの内容は、検証の難しさによって三つの層に分かれます。
第一の層は即座に検証できるものです。層数、ヘッド数、語彙サイズ、専門家数といった構造の値です。公開された config.json と照らし合わせれば数秒で確認できます。このシリーズで Qwen3、DeepSeek-V3、Kimi K2 のレポートの表と config を照合したところ、いずれも一致しました。
第二の層は計算で検証できるものです。パラメータ数が代表例です。最初の記事では config だけから Qwen3-8B のパラメータを 8,190,735,360 と計算し、リポジトリが報告する値と正確に一致しました。Mixtral-8x7B と Qwen3-30B-A3B も同様でした。三つのモデルすべてが誤差なく一致したということは、レポートが述べる構造が実際の重みと合っていることを意味します。
第三の層は検証できないものです。学習トークン数、データ混合の比率、GPU 時間、ベンチマークのスコアがここに入ります。これらはレポートを信じる以外に確認する方法がありません。
自己申告ベンチマークの限界
その第三の層のなかで最も頻繁に引用され、最も注意すべきものがベンチマークのスコアです。このシリーズがベンチマークのスコアをほとんど引用しなかった理由があります。
モデルの開発チームが自分のモデルを評価して発表した数値は、独立した評価ではありません。これは不正直だという意味ではなく構造的な限界です。評価プロンプト、使った例示の数、デコード設定、採点方法はチームごとに異なり、比較対象のモデルはたいていそのチームが実行したか、他のレポートから引用した値です。
このシリーズで唯一引用した性能の数値は、Kimi K2 レポートのデータ再記述実験でした。原本 10 エポック、1 回書き直して 10 エポック、10 回書き直して 1 エポックでそれぞれ 23.76、27.39、28.94 という値です。これを引用したのは、モデル間の優劣ではなく同じチームが同じ条件で統制した比較だったからです。そのときも著者自身の実験であり独立評価ではないと明記しました。
読むこつは単純です。スコアを見たら、誰がどんな設定で測ったのかをまず探してください。その情報がなければ、そのスコアは比較に使えません。
config とレポートが食い違うとき
このシリーズで実際に出会った不一致が二つあります。
第一に Qwen3 の語彙サイズです。config の vocab_size は 151936 ですが、レポートは 151,669 と記します。トークナイザファイルを直接開いてみると 151,669 でした。結論は両方とも正しいということです。異なるものを測っていただけです。config は埋め込み行列の大きさを、レポートはトークナイザの語彙数を述べています。
第二に Qwen3-8B の文脈長です。config の max_position_embeddings は 40960 で、レポートの表 1 は 128K と記します。レポート本文を読むと、長文脈の学習は 32,768 で行い、推論時に YaRN と DCA で四倍を確保するとありました。ここでも結論は同じです。異なるものを述べていました。
この二つの事例の教訓は一つです。不一致を見つけたら、どちらが誤りかを問う前に、二つの値が同じ対象を測っているかを確認してください。たいていは定義が違います。
確認できなかったこと
誠実な書き方の核心は、確認できなかったものを確認できなかったと書くことです。このシリーズにもそうした項目がありました。
Llama 3.1 と Gemma 2 の config.json はアクセスが制限されており読めませんでした。Llama 3.1 については技術レポートの表 3 に構造の値がすべて載っているためそれを出典とし、本文でも config ではなく表 3 から取ったと明記しました。Gemma 2 は config も読めず、このシリーズの主題に必要な値を確保できなかったため、まったく扱いませんでした。
これがこのシリーズが守った規則です。確認できなかった値は空けておくか、そのモデルを扱いません。もっともらしい数字を埋めれば文章は滑らかになりますが、読者がその文章を根拠に判断できなくなります。
レポートでよく抜けるもの
複数のレポートを並べて読むと、共通して空いている欄が見えてきます。
最大の空白はデータ混合の比率です。どの出典のデータを何パーセント使ったかを正確に明かすレポートはまれです。ドメイン名だけが列挙される場合が多くなります。
第二は失敗の記録です。最終的な設定だけが書かれ、何を試して捨てたのかはたいてい抜けます。例外的に、Kimi K2 レポートがアテンションヘッドを二倍にしたときの検証損失の低下が 0.5 から 1.2 パーセントにとどまり推論コストを正当化しなかったと記したのはまれな事例です。こうした記述があれば、判断の根拠を読者が検討できます。
第三は評価条件の細部です。スコアは大きく載りますが、プロンプトとデコード設定は付録にあるか、どこにもありません。
良いレポートの合図
逆に、信頼度を高める記述もあります。
値が学習の途中で変わったと記す場合です。DeepSeek-V3 レポートがバイアス更新速度を 14.3 兆トークンまで 0.001 とし、その後 0.0 に切り替えたと記したのが例です。こうした細部は作り上げるのが難しく、再現に実質的に役立ちます。
自らの限界を書く場合も同じです。Kimi K2 レポートが、合成データによる継続的なスケーリングは依然として活発な研究領域であり、多様な出典へ一般化しつつ事実性を損なわないことと幻覚を減らすことが主要な課題だと記した部分がそれにあたります。
数値に条件を添える場合も良い合図です。Kimi K2 がヘッド数を増やしたときの演算量の増加を述べる際に、シーケンス長 128k、全専門家数 384 固定という条件をあわせて記したのがそうです。条件のない倍率は解釈できません。
自分で確認する手順
最後に、このシリーズで実際に用いた手順を整理します。
第一に、config.json を直接取得します。モデルリポジトリの原本ファイルのアドレスにアクセスすれば、重みをダウンロードせずに構造を見られます。
第二に、パラメータを手で数えて公開値と突き合わせます。合えば config を正しく読めたということであり、レポートの構造記述も検証されたことになります。
第三に、レポートで該当する表を探して config と照合します。食い違えば定義の違いを疑います。
第四に、トークナイザが重要なら、トークナイザファイルを取得して実際のテキストで測定します。このシリーズの言語別トークン数はすべてそうやって得ました。
第五に、確認できない値は確認できないと書きます。
おわりに
八編にわたり、config.json のフィールドから始めて MoE ルーティング、アテンションの変種、位置エンコーディング、正規化、トークナイザ、学習レシピまで見てきました。全体を貫く主題は一つでした。すべての設計選択には代償があり、その代償はたいていメモリ、遅延、学習の安定性のいずれかとして現れるということです。
モデルは変わり続けます。今日確認した数字は来年には違っているでしょう。しかし、config を開いてパラメータを数え、レポートの表と照合し、確認できない値を空けておくという手順はそのまま使えます。それがこのシリーズが残そうとしたものです。
参考資料
- The Llama 3 Herd of Models (arXiv:2407.21783): https://arxiv.org/abs/2407.21783
- Qwen3 Technical Report (arXiv:2505.09388): https://arxiv.org/abs/2505.09388
- DeepSeek-V3 Technical Report (arXiv:2412.19437): https://arxiv.org/abs/2412.19437
- Kimi K2 (arXiv:2507.20534): https://arxiv.org/abs/2507.20534
- Qwen3-8B config.json: https://huggingface.co/Qwen/Qwen3-8B/raw/main/config.json
試してみる
- AI ベンチマーク整理 — ベンチマークが何を測り何を測らないのか確認してみましょう。
- ニューラルネットワークアーキテクチャ探索 — 構造の値を変えて感覚を養ってみましょう。
- VRAM 計算機 — レポートの数字を実際のメモリ要件に移してみましょう。
シリーズ
- 前の記事: 学習レシピ — 事前学習から後学習まで
- 次の記事: この記事がシリーズの最後です。最初に戻るには config.json 完全解剖 をご覧ください。
현재 단락 (1/43)
シリーズの最後です。ここまで config.json と技術レポートから数十の数字を取り出して計算してきました。この記事では、その過程で用いた判断基準を整理します。どの数字を信じ、どの数字を保留し、ど...