7.3.6 モデル規模と計算

学習目標

パラメータ規模、コンテキスト長、計算コストの関係を理解する
学習時と推論時でコスト構造がなぜ違うのかを理解する
実行できる例を通して、パラメータ数と KV cache のざっくり見積もり方を学ぶ
「なぜモデルを無限に大きくできないのか」という現実的な見方を身につける

一、パラメータ数はあくまで最初の見え方

なぜみんな `7B / 70B` のようにモデルを表すのか？

いちばんわかりやすいからです。
パラメータ数は、モデルの容量をざっくり表す指標として役立ちます。

パラメータが多いほど、通常は表現できる上限が高い

ただし、これは最初の見え方にすぎません。

同じ大規模モデルでも、コストは他の多くの要素で変わる

たとえば、どちらも 7B と書かれていても、
次の違いだけでかなり差が出ることがあります。

層数が違う
hidden size が違う
head 数が違う
コンテキスト長が違う
GQA / MoE を使っているかどうか

つまり、パラメータ数が無意味なのではなく、
それだけで判断してはいけないということです。

たとえ話：床面積は総コストそのものではない

パラメータ数は、家の床面積のようなものだと考えられます。
でも、実際のお金はそれだけでは決まりません。

階数や構造
内装の複雑さ
暖房や保守のコスト

同じように、大規模モデルの計算コストも、パラメータ数だけでは決まりません。

二、パラメータ数はどうやって増えていくのか？

デコーダーブロックの主な重みは Attention と FFN

ざっくり見積もるときは、主に次の2つを覚えておくと便利です。

Attention projection
FFN projection

多くの decoder-only モデルでは、
FFN のパラメータ数は Attention より大きくなることもあります。

とても使いやすい概算式

標準的な decoder block では、
次のような近似で考えられます。

Attention 関連はおおよそ 4 * hidden^2
FFN 関連はおおよそ 8 * hidden^2

したがって、1層あたりはだいたい次のように見積もれます。

12 * hidden^2

これに層数を掛ければ、
かなり実用的な一次見積もりになります。

なぜざっくり見積もりでも価値があるのか？

最初から1桁単位まで正確である必要はないからです。
むしろ大事なのは次のような点です。

だいたいどのくらいの規模か
どの部分が大きいコストを占めるか
どのハイパーパラメータを変えるとコストが一気に上がるか

三、まずは本当に役立つ見積もりスクリプトを動かそう

次のスクリプトは、現場でよく使う2つの量を見積もります。

デコーダーのみのモデルのおおよそのパラメータ数
推論時の KV cache のおおよその使用量

def approx_decoder_params(num_layers, hidden_size, ffn_multiplier=4, vocab_size=50000):
    attention_params = 4 * hidden_size * hidden_size
    ffn_params = 2 * hidden_size * (hidden_size * ffn_multiplier)
    norm_params = 4 * hidden_size
    block_params = attention_params + ffn_params + norm_params
    embedding_params = vocab_size * hidden_size
    total = num_layers * block_params + embedding_params
    return total


def kv_cache_bytes(
    num_layers,
    seq_len,
    batch_size,
    num_kv_heads,
    head_dim,
    dtype_bytes=2,
):
    # 2 は K と V の2つのキャッシュを表す
    return num_layers * batch_size * seq_len * num_kv_heads * head_dim * 2 * dtype_bytes


def human_readable(num_bytes):
    units = ["B", "KB", "MB", "GB", "TB"]
    value = float(num_bytes)
    for unit in units:
        if value < 1024 or unit == units[-1]:
            return f"{value:.2f} {unit}"
        value /= 1024


configs = [
    {
        "name": "small",
        "layers": 24,
        "hidden": 2048,
        "kv_heads": 16,
        "head_dim": 128,
        "seq_len": 4096,
    },
    {
        "name": "large",
        "layers": 48,
        "hidden": 4096,
        "kv_heads": 8,
        "head_dim": 128,
        "seq_len": 8192,
    },
]

for cfg in configs:
    params = approx_decoder_params(cfg["layers"], cfg["hidden"])
    kv_bytes = kv_cache_bytes(
        num_layers=cfg["layers"],
        seq_len=cfg["seq_len"],
        batch_size=1,
        num_kv_heads=cfg["kv_heads"],
        head_dim=cfg["head_dim"],
    )
    print("-" * 60)
    print("model       :", cfg["name"])
    print("rough params:", f"{params / 1e9:.2f}B")
    print("kv cache    :", human_readable(kv_bytes))

期待される出力：

------------------------------------------------------------
model       : small
rough params: 1.31B
kv cache    : 768.00 MB
------------------------------------------------------------
model       : large
rough params: 9.87B
kv cache    : 1.50 GB

モデル規模見積もり実行結果図

このコードでいちばん大事なポイントは？

1つ目：

パラメータ数は hidden_size^2 と強く関係している

つまり hidden size が少し大きくなるだけでも、
コストはかなり急に増えます。

2つ目：

KV cache は layers * seq_len * kv_heads * head_dim によって増える

だからこそ、コンテキスト長と推論メモリは強く結びついています。

なぜ `large` モデルの負荷は単純な倍増ではないのか？

多くの項目が同時に増えるからです。

層数が増える
hidden size が増える
seq_len が増える

これらが重なると、
学習コストも推論コストも、かなり大きくなります。

なぜ GQA / MQA は推論の負荷をやわらげるのか？

それらは直接、次の値を減らすからです。

num_kv_heads

そしてこれは、KV cache の式の中でも重要な項目です。

大規模モデルのコスト調整ノブ図

四、学習時と推論時は何が違うのか？

学習時にいちばん詰まりやすいのは？

学習時によくあるボトルネックは次の通りです。

パラメータ本体
勾配
オプティマイザ状態
中間の activation

そのため学習では、特に次のような点が重要になります。

mixed precision
gradient checkpointing
tensor parallelism / data parallelism
activation memory

推論時にいちばん詰まりやすいのは？

推論時の中心的な負荷は、より次のものにあります。

KV cache
スループット
1リクエストあたりのレイテンシ
同時接続時の GPU メモリ

そのため、次の点をよく気にします。

batch をどう設定するか
コンテキストをどれくらい長くするか
kv heads は何個あるか
cache を量子化できるか

なぜ「学習できる」ことと「うまくデプロイできる」ことは別なのか？

学習と推論は、そもそも同じ workload ではないからです。

学習は次のような性質があります。

大きな batch
継続的な更新
スループット重視

推論は次のような性質があります。

リアルタイム応答
cache が積み上がる
レイテンシ重視

だから、学習では問題なかった設計でも、
デプロイすると非常に苦しくなることがあります。

学習時と推論時のコスト構造の比較図

五、スケールアップは「大きいほど良い」ではなく、「大きいほど高い」

パラメータを増やすのは、能力の可能性を増やすことであって、無料で性能が上がるわけではない

パラメータが増えると、表現力の上限が上がることは多いです。
でも、そのためには次の条件も必要です。

十分なデータ
十分な学習 token
十分な計算資源

これらが足りないと、モデルはただ「大きい」だけで、
「その大きさに見合う価値」が出ないことがあります。

コンテキストを長くするのも、無料ではない

context length を伸ばすと、次の利点があります。

より多くの情報を使える

ただし同時に、次の負担も増えます。

Attention の計算コストが上がる
KV cache が大きくなる
長距離情報を安定して使うのが難しくなる

つまり、「128k に対応している」ことと、
「128k を全部うまく使える」ことは別です。

スケールアップでよくある現実的な3つの問題

学習コストが急激に上がる
推論サービスのコストも一緒に上がる
データや学習 token が足りないと、追加投資の効果が下がる

つまり、スケールアップの本質は、

能力、コスト、データのバランスを取ること

です。

六、とても実用的な判断の順番

学習側で詰まっているなら

まず次を確認します。

hidden size を攻めすぎていないか
batch と seq_len が高すぎないか
中間 activation が主なボトルネックではないか

推論側で詰まっているなら

まず次を確認します。

コンテキスト長
同時リクエスト数
kv cache のサイズ
GQA / MQA / cache quantization を使えるか

モデル規模を設計するなら

先に次の3つを自問します。

そのデータ量で本当に支えられるか？
学習予算は持つか？
上線後の推論コストは受け入れられるか？

この3つを一緒に考えないと、
モデル設計はすぐ「大きいほど良い」という幻想に引っ張られます。

七、よくある誤解

誤解1：パラメータが大きければ、必ず性能も良い

不十分です。
パラメータ数は容量であって、自動的に性能を保証するものではありません。

誤解2：推論コストはパラメータ数だけで決まる

違います。
コンテキスト長と KV cache も、同じくらい重要になることがよくあります。

誤解3：学習用メモリと推論用メモリは同じ

違います。
両者は、メモリの内訳もボトルネックも異なります。

残す証拠

このページを終えたら、この証拠カードを残します。

パラメータ: おおまかなパラメータ数の見積もりと主要な要因
学習コスト: forward + backward + optimizer state（前向き計算、逆伝播、最適化状態）
推論コスト: prefill、decode、KV cache、出力長（入力処理、生成、キャッシュ、長さ）
ボトルネック: メモリ、遅延、スループット、または品質
判断: 証拠に基づいて、より小さいモデル、量子化、バッチ処理、または検索を選ぶ

まとめ

この節でいちばん大事なのは、あるモデルが何 B かを覚えることではありません。
その代わり、次のような、より現実的な言葉を身につけることです。

モデル規模 = パラメータ容量、計算コスト = パラメータ、層数、hidden、コンテキスト長、KV cache、batch、そして実装方法を合わせて決まる。

これらをまとめて見られるようになると、
「なぜ大規模モデルは高いのか」「どこにコストがあるのか」「どう抑えるべきか」が、工程の感覚としてわかるようになります。

練習

例の seq_len を 4096 から 16384 に変えて、KV cache の使用量がどう変わるか確認してください。
なぜ hidden size は、多くの人が思うよりずっと「高い」のでしょうか？
自分の言葉で説明してください。学習が通っても、デプロイが楽とは限らないのはなぜですか？
長い会話サービスを作るなら、パラメータ数以外に、最初にどんな指標を気にしますか？

参考実装と解説

KV cache はおおむね sequence length、層数、batch size、key-value head の次元に比例して増えます。4096 から 16384 にすると、sequence length の部分だけで約 4 倍になります。
Hidden size は projection 行列、FFN 幅、activation memory、attention 次元に影響します。大きくすると、パラメータ数と token あたりの計算量が複数箇所で同時に増えます。
学習はオフラインで計画した batch と復旧手順の中で進められます。デプロイでは、レイテンシ、同時接続、メモリ制限、context の伸び、ユーザートラフィックの変動に対応する必要があります。
まず見るべきなのは、レイテンシ、スループット、リクエストごとの KV cache メモリ、同時セッション数、prefill/decode 速度、context 保持品質、有用な回答 1 件あたりのコストです。