パラメータが何Bという話が急に耳に入る瞬間 — モデルサイズの本当の意味

📍 AIのしくみ地図 — 10/29章

この記事はAIの基礎からMeta-Harness·応用比較まで順に読む全29章シリーズの10章目です。
📚 全体地図を見る

← 前の章: F6. 学習とは何か · 次の章: B1. Agentとは何か →

この記事は「AIのしくみ地図 20編」の 7編目(F7) です。
前編: F6 — モデル学習とgradient descent
次編: P1 — AIモデル地図開始 [予定]

Table of Contents

0. はじめに — 地図の現在地

F1 から F6 まで進んでこられた方は、LLM が「次のトークンを予測する関数」であること、Transformer がその予測をどう可能にしたか、attention・embedding が何をしているか、そして F6 で 学習とはパラメータを少しずつ修正する反復作業 という感覚まで掴まれたと思います。

今回の F7 は、その パラメータ(parameter) という単語そのものをもう一段深く掘る回です。F2 や F6 で「パラメータは学習される重み」という説明はすでにしたので、今回はそこから一歩さらに降りていきます。

ニュース記事や開発者ブログでこういう表現が続きますよね。

「Llama 3.1 405B をオープンソース公開」
「DeepSeek-V3 は 671B パラメータ、活性 37B の MoE」
「Mixtral 8x7B、実際は 47B」
「Claude Opus のパラメータ数は公開されていない」

この数字が具体的に何を意味するのか、なぜこの数字が重要なのか、なぜある会社は公開して別の会社は公開しないのか、そして「671B のうち 37B だけが活性」とはどういうことなのか。そこまで掴むのが今回のゴールです。

一行で言うと パラメータ数はモデルの VRAM・コスト・知能の上限を同時に決める唯一の数字 です。だからこの数字が公開されていないモデルに関して何かを推定しようとすると、別の手がかりから逆算するしかありません。

1. パラメータ再訪 — F2・F6 から一段深く

F2 で Transformer の内部に複数の層が積まれていて、各層ごとに 重み行列(weight matrix) があるという話をしました。F6 ではその重みたちを gradient descent で少しずつ修正するのが学習だと書きましたね。

パラメータとは、その重みたちの ひとつひとつの個数 のことです。ある行列の中に 1,024 × 4,096 = 約 419 万個の数字が入っていれば、この行列ひとつだけでパラメータが 420 万個あることになります。Transformer ブロックひとつの中にそういう行列が数十個、ブロックが数十〜数百積まれているので、パラメータは数十億〜数千億個になります。

パラメータの性格を再整理するとこうです。

学習で 値が変わる 数字たち(bias 含む)
入力が来ると、この数字と掛けて足して出力を作る
学習が終わると 固定される(推論時はもう変わらない)

ここまでは F6 の復習。ここからが F7 の本題です。この数字の「個数」が実務で何を決めるのか。

決めるものは三つあります。

VRAM 使用量 — モデルを GPU に載せるのに何 GB 必要か
計算量(FLOPs) — 一回推論するときどれだけ演算を回すか
知能の上限 — このモデルが学べる知識の量

この三つ全部がパラメータ数に直結しています。だから「このモデルは何 B?」という質問が実務で最初に出てくるんです。

2. FP16 × 2 バイト則 — パラメータ数が VRAM を直接決める

この記事で一番覚えて帰っていただきたい数字がひとつあります。

FP16 の場合、パラメータ N 個のモデルをロードするのにおよそ N × 2 バイトの VRAM が必要。

70B モデルなら 70 × 10⁹ × 2 = 140 × 10⁹ バイト = 約 140 GB VRAM。405B モデルなら 約 810 GB VRAM。

なぜ 2 バイトなのか。パラメータひとつは単なる小数点の数字です。この数字をコンピュータのメモリにどう格納するかでサイズが変わります。

FP32 (float32): パラメータ 1 個 = 4 バイト。もっとも精密だが重い
FP16 / BF16 (float16 / bfloat16): パラメータ 1 個 = 2 バイト。2026 年の標準
INT8 (8-bit 量子化): パラメータ 1 個 = 1 バイト。推論最適化用
INT4 (4-bit 量子化): パラメータ 1 個 = 0.5 バイト。ローカル実行用の極限圧縮

いまのフロンティアモデルは学習も推論も FP16 か BF16 が基本なので、N × 2 バイト が現実的な基準になります。

FIG 1. パラメータ数 → VRAM (FP16, 重みのみ)

8B (Llama 3.1 8B)16 GB

70B (Llama 3.1 70B)140 GB

405B (Llama 3.1 405B)810 GB

671B (DeepSeek-V3 総)1,342 GB

※ FP16 の重みのみの数値。KV キャッシュ・活性値を含めると実際は 1.4〜1.6 倍。H100 1枚 = 80GB を基準にすると、70B は H100 2枚・405B は 11枚・DeepSeek-V3 は 17枚が必要になる。

ここで終わりではありません。実際の推論では重み以外にもメモリが必要です。

KV キャッシュ (Key-Value Cache): これまで処理したトークンの attention key・value を保存。文脈が長いほど肥大
活性値 (Activations): forward pass 中の中間計算結果を保持
CUDA オーバーヘッド・バッチ余裕分

実務では パラメータ × 2 バイト × 1.4〜1.6 が実質 VRAM と見ます。70B モデルは重みだけなら 140 GB ですが、長いコンテキストで回そうとすると 約 200 GB は欲しい。これが実務の GPU 選定を決めるロジックです。apxml のハードウェア則

そしてこの「N × 2 バイト」則は 推論時の話 です。学習時にはここに gradient・optimizer state(Adam だとパラメータ数の 2〜4 倍の領域が追加で必要)まで乗るので、総 VRAM は推論の 4〜6 倍。だから学習は本格的な大型インフラがないと不可能な作業になります。

3. 2026 年モデルサイズ地図

具体的な数字で風景を見てみましょう。2026 年 4 月時点で実際に動いているモデルのうち、パラメータが公開されているものだけを整理しました。

モデル	総パラメータ	活性パラメータ	タイプ	ライセンス	ソース
Llama 3.1 8B	8B	8B	Dense	Llama Community	Meta
Llama 3.1 70B	70B	70B	Dense	Llama Community	Meta
Llama 3.1 405B	405B	405B	Dense	Llama Community	HF
Llama 4 Scout	109B	17B	MoE (16 experts)	Llama 4	llama.com
Llama 4 Maverick	400B	17B	MoE (128 experts)	Llama 4	llama.com
Llama 4 Behemoth	約 2T	—	MoE (学習中)	—	llama.com
Qwen 3 (Dense)	0.6B〜32B	= 総	Dense	Apache 2.0	Qwen
Qwen 3 30B-A3B	30B	3B	MoE	Apache 2.0	Qwen
Qwen 3 235B-A22B	235B	22B	MoE	Apache 2.0	Qwen
DeepSeek-V3	671B	37B	MoE (256 routed + 1 shared)	MIT	HF · 論文
Mixtral 8x7B	47B	13B	MoE (8 experts, top-2)	Apache 2.0	Mistral
Mixtral 8x22B	141B	39B	MoE	Apache 2.0	Mistral
GPT-5 / Claude Opus / Gemini Ultra	非公開	非公開	非公開	非公開	—

二つのポイントがすぐに目に入りますね。

ひとつ目、Dense と MoE ではまったく違う風景。 Llama 3.1 405B は総 = 活性なので推論のたびに 405B 全部が使われますが、DeepSeek-V3 は 671B のうち わずか 37B しかトークンごとに起動しません。

ふたつ目、フロンティアのクローズドモデル(GPT / Claude / Gemini)は数字そのものが存在しない。 これはセクション 6 で扱います。

いま注目していただきたいのは 活性パラメータ < 総パラメータ という MoE の構造。2024〜2026 年の LLM 業界をもっとも大きく塗り替えたアーキテクチャ転換です。

4. MoE — 「671B のうち 37B しか使わない」の正体

Mixture of Experts (MoE) は発想自体はシンプル。「モデル全体がすべてのトークンを処理する必要はない。質問の種類に応じて担当領域を分ければいい」。

例え話をひとつ。大型の総合病院を思い浮かべてください。小児科・整形外科・眼科・循環器内科… 専門医が 256 人いる病院です。患者さんがひとり来ると、受付(= ルーター) が症状を見て「この方は整形外科 + 眼科」と振り分ける。ひとりの診察で実際に動く医師は 2〜8 人 だけ。残りの 250 人は別の患者を診るか待機中。

DeepSeek-V3 はまさにこの構造です。

総パラメータ 671B(病院全体の医師の数)
各 Transformer 層に 256 個の routed experts + 1 個の shared expert
ルーターがトークンごとに 上位 8 個の expert を選んで起動
トークンごとの実活性パラメータ = 37B(医師 8 人)

FIG 2. MoE 構造 — DeepSeek-V3 671B / 37B

モデル全体 671B (VRAM にロード済み)

トークンごとの活性 = 37B (ルーター選択)

残り 634B (待機)

※ VRAM は 671B すべてを載せる必要がある。だが 1 トークン生成の計算量(FLOPs)は 70B 級の Dense モデルとほぼ同じ。「メモリは富豪、計算は倹約」な構造。

ここで実務感覚が二つ必要になります。

VRAM は総パラメータで決まる。 ルーターが選ぶ前に 671B 全部を GPU に載せておく必要があります。医師 8 人しか動かないからといって残り 250 人を帰宅させておけるわけではない。いつ呼ばれるかわからないので全員待機。だから DeepSeek-V3 の VRAM 要件は 1,342 GB、H100 17 枚必要になります。

計算量(FLOPs)は活性パラメータで決まる。 1 トークン生成するたびに実際に計算されるのは 37B 分だけ。だから推論速度と電力コストは 70B Dense とだいたい同水準になります。これが MoE の核心的な得です。知能は 671B 級、推論コストは 37B 級。 epoch.ai MoE vs Dense

このあたりが、いまフロンティア研究所がこぞって MoE に移行している理由です。Mixtral 8x7B (47B/13B)、Mixtral 8x22B (141B/39B)、Llama 4 Scout・Maverick、Qwen 3 MoE シリーズ… どれも同じ発想。

トレードオフもあります。 VRAM をたくさん食うのでコンシューマ GPU では動かない。8B Dense は RTX 4090 一枚に入りますが、47B MoE は 4090 では動きません。それにルーターの学習は繊細で、MoE を一からトレーニングするのは Dense より格段に難しい。だからスタートアップがゼロから MoE を作るのは珍しく、基本的には大手研究所が作った MoE の重みを使う形になります。

5. Chinchilla 則 — パラメータあたりトークンはどれくらいが妥当か

学習側に目を向けましょう。F6 で「大量のデータを流し込んで学習する」という話はしましたが、ではパラメータ数に対して データ量はどれくらいが妥当 なのか。

2022 年に DeepMind がこの問いに答えを出しました。有名な Chinchilla 論文 (Hoffmann et al., 2022)。

結論だけ書きます。

固定された学習計算予算のもとでは、パラメータ 1 個あたり約 20 個のトークンで学習させるのが最適。

例えば 70B パラメータのモデルなら 70B × 20 = 1.4T(1.4 兆)トークン 与えるのが学習効率的にベスト、というわけです。これより少ないと(パラメータ過剰) “under-trained”、多いと(データ過剰) “over-trained” とされました。

この法則が出る前までは業界は「パラメータを大きくすれば勝ち」みたいな空気で、GPT-3(175B) は 300B トークンしか学習していませんでした。Chinchilla 則で見ると GPT-3 は 相当に under-trained だったわけです。パラメータを 1/5 にしてデータを 5 倍にしたほうが賢くなっていたはず、と。

ところがこの法則、Llama 3.1 でおもしろい展開を見せます。

Llama 3.1 はすべてのサイズ(8B / 70B / 405B)を 15T トークン で学習しています。

405B × 20 = 8.1T → 405B は Chinchilla 基準に近い(少し超える、約 37 token/param)
70B × 20 = 1.4T → 70B は Chinchilla 基準の約 10 倍 データ(214 token/param)
8B × 20 = 160B → 8B は Chinchilla 基準の約 94 倍 データ(1,875 token/param)

70B・8B は派手に over-trained です。なぜこんな学習をしたのでしょう。

答えは「学習コスト最適化」ではなく「推論コスト最適化」にあります。 Chinchilla 則は「学習計算予算の最小化」を目標にした法則です。でも実際にモデルが公開されたあとは、推論が数億回・数十億回回ります。学習は一度きり。だから 「小さいモデルにデータを大量に注いで、推論時に安く使う」 という戦略が合理的になります。Meta Llama 3.1 ブログ

学習コスト: 15T トークンを 8B で学習 → 高い
推論コスト: 8B は軽い → 一度学習しておけば数十億回使うときに利得が積み上がる

この戦略転換が 2024 年以降の業界標準になりました。「Chinchilla-optimal は学習最適、われわれは推論最適を見る」。Llama・Qwen・Mistral すべて同じ哲学です。

実務感覚をひとつ。「8B モデルがいい」という言葉は曖昧です。 同じ 8B でも、2022 年基準の Chinchilla-optimal 8B と 2024 年の over-trained 8B はまったく別物。学習トークン量が 10 倍違えば品質は明確に差が出ます。「Llama 3.1 8B は Llama 2 7B より圧倒的に良い」という評価が出てくるのもこれが理由。パラメータ数は同じでも、注ぎ込んだデータ量が違うんです。

6. なぜ GPT・Claude・Gemini はパラメータを公開しないのか

ここがこの記事でもっとも興味深いパートです。一度探してみてください。GPT-4 が何パラメータか、Claude Opus が何パラメータか、Gemini Ultra が何パラメータか。公式の数字は存在しません。

OpenAI・Anthropic・Google DeepMind はいずれもフロンティアモデルのパラメータ数を公開していません。Anthropic の Claude 3 モデルカードを含め、公式文書のどこにもこの数字は書かれていない。モデルカードには「compute が大きい」程度の記述があるだけです。

なぜでしょう。推測されている理由は三つ絡み合っています。

① 営業機密(trade secret)。 パラメータ数が公開されると、競合が学習レシピを逆算できてしまう。Chinchilla 則 + パラメータ数 + 公開されている compute 推定値を組み合わせると、「この会社は何兆トークンを学習した」という推定が立ちます。モデル構造レベルの細かなノウハウが、パラメータ数という一つの数字を通して漏れる。

② ベンチマーク解釈の混乱回避。 数字が出ると「このベンチマークスコアを同じパラメータのオープンモデルと比べてみよう」という議論が始まる。GPT-4 が Llama 3.1 405B より性能がいいと言っても、パラメータが 2T なら「当然では?」という話になる。このフレーミング議論を会社はしたくない。

③ MoE を白状してしまうのが嫌。 ほとんどのフロンティアモデルが MoE らしいことは暗黙の了解ですが、「総 X、活性 Y」という数字を出した瞬間、競合の MoE 設計と直接比較が可能になる。ルーター設計や expert 数といった核心設定が露出しかねません。

Anthropic のポリシー は一貫しています。Claude 3、3.5、4、Opus 4、Sonnet 4.7 どのモデルカードにもパラメータ数は記載されていない。その代わりモデルカードは capabilities・safety・limitations を中心に構成されています。会社としては「モデルの本質は、パラメータ数ではなく学習プロセス全体にある」というスタンスなのでしょう。

実務者がこの状況を扱う方法は二つ。

ひとつ目、API 価格からの逆算。 トークン単価は推論コストを反映します。Claude Opus のトークン単価が Llama 3.1 405B のホスティング価格よりはるかに高いなら、活性パラメータが 405B より大きいと推定できます。

ふたつ目、ベンチマークからの逆算。 MMLU・GPQA・HumanEval などのベンチマークをオープンモデルと比較すれば「この性能なら何 B 相当」という感覚は持てます。ただし学習データ量も効いてくるので、正確性は高くありません。

というわけで 「GPT-5 って何 B ?」という問いの正解は「誰も公式には知らない」 です。流出ドキュメントやコミュニティ推定値が流通していますが公式ではない。この構造そのものが、オープンソースとクローズドソースモデルのもっとも大きな違いです。

7. 一行のまとめ

パラメータ数は 「このモデルはどれくらい大きいのか」という曖昧な問いを、VRAM・FLOPs・学習データ・価格という具体的な数字に翻訳してくれる唯一の鍵の値 です。FP16 × 2 バイト則で VRAM が出て、活性パラメータで推論速度が決まり、Chinchilla 則で学習データの妥当量がわかり、公開の有無でモデル会社の戦略が透けて見える。70B という数字一つを見て「これは H100 2 枚のモデルで推論コストは中くらい」という感覚が湧くようになれば、この記事の役目は果たせたことになります。

8. よくある質問(FAQ)

Q1. 自分のノート PC で 70B モデルを動かしたい。方法は?

INT4 量子化(4-bit)で圧縮すれば 70B は約 35 GB まで縮みます。RTX 4090(24GB)一枚ではまだ厳しいですが、最近の Apple M3 Max(64〜128 GB ユニファイドメモリ)や M4 Pro なら回ります。ただし量子化で品質は少し落ちます(ベンチマーク基準で 1〜3% 低下)。実務感覚では 「量子化 70B = 本来の 30B〜50B 相当」 と思っておくと安心。ローカルで本当に快適に使いたいなら 8B 級(Llama 3.1 8B、Qwen 3 8B)が現実解です。

Q2. MoE モデルはなぜコンシューマ GPU に向かないのか?

活性パラメータが小さくても VRAM は総パラメータで決まる からです。Mixtral 8x7B は活性 13B ですが、VRAM は 47B 基準 = 約 94 GB 要ります。RTX 4090(24GB)では INT4 量子化しても足りない。なので MoE は「クラウド API で使うと推論が安い」という利点であって「自宅 PC で動かしやすい」利点ではありません。ローカル運用が目的なら Dense モデルのほうが素直です。

Q3. パラメータが多いほど必ず賢くなるのか?

違います。パラメータは 知能の上限 であって 知能そのもの ではない。8B モデルに 15T トークンを丁寧に学習させると、2022 年の 40B モデルより賢いことがあります。そしてパラメータが多くても、学習データの質が悪かったり RLHF が甘かったりすれば品質は落ちる。「パラメータ × 学習データ量 × 学習手法 × 事後チューニング」の積が最終品質を決めます。このうちどれかひとつが弱いと、他を強くしても埋まりません。

Q4. Llama 5 や GPT-6 は何 B になるのか?

公式は誰も知りませんが、業界トレンドを見ると Dense はほぼ大きくならない 方向です。405B が Dense の事実上の上限。これ以上は推論コストが耐えられない。ただし MoE の総パラメータは伸び続ける。Llama 4 Behemoth が約 2T、業界では「活性パラメータは 30〜70B に固定、総パラメータは数兆規模に膨らむ」トレンドが続くと見られています。「より広い病院 + より賢いルーター」方向ですね。