Level 2：モデルとGPUを理解する

Level 1で、Nortia株式会社はSelf-hostをPoCすると決めました。次に来るのが「では、どのモデルをどのGPUで動かすのか」です。

ここで多くのプロジェクトが最初の躓きを経験します。パラメータ数だけを見てGPUを選ぶと、単体テストでは動くのに、同時利用が増えた瞬間にOOMで落ちるからです。

1. 現在の企業状況

• Self-hostのPoCを行う方針が承認された
• 検証用のハードウェアはまだ確定していない（Level 4で調達）
• モデルは未選定。社内には「有名なモデルを入れればよいのでは」という声がある
• Level 0で作った想定質問100件と、非機能要件シートがある

2. 発生した課題

技術選定の会議で、次のような発言が出ます。

「30Bクラスなら60GBくらいでしょう。121GBのマシンがあるなら余裕では？」

この見立ては、モデルの重みしか数えていません。実際に確保されるメモリは以下の合計です。

GPUメモリに載るもの

┌────────────────────────────┐
│ モデルの重み                 │ ← パラメータ数 × 精度
├────────────────────────────┤
│ KV Cache                    │ ← 同時実行数 × コンテキスト長に比例
├────────────────────────────┤
│ アクティベーション・ランタイム │ ← 断片化を含む上乗せ
└────────────────────────────┘

重みは固定ですが、KV Cacheは利用状況に比例して増えます。同時実行数を8から32に増やせば4倍、コンテキスト長を4Kから16Kにすれば4倍です。「1人で試したら動いた」は、何の保証にもなりません。

さらに厄介なのが速度です。メモリに載ることと、要求速度で動くことは別問題です。後述しますが、容量に余裕があるのに帯域で詰むという事態が普通に起こります。

3. 要件（この判断に関係する部分）

4. 選択肢

決めるべき変数は3つあり、それぞれ独立ではありません。

組み合わせは数十通りありますが、計算すれば大半はその場で消えます。

5. 技術比較：サイジングの7手順

ここからが本題です。実務では次の順序で進めます。手順3までは机上で終わり、手順4〜6は電卓で終わります。 実機が必要になるのは手順7からです。

Step 1：要件を数字にする

曖昧な言葉を、計算に使える変数へ落とします。

Step 2：必要スループットを出す

すべての出発点になる1つの数字です。

必要な合計出力速度 = 同時実行数 × 1利用者あたりの出力速度
                  = 50 × 25 tok/s
                  = 1,250 tok/s

この1,250 tok/sを1台で出すのか、複数台に分けるのかが、最終的なGPU台数の議論（Level 9）につながります。

Step 3：品質要件でモデル候補を絞る

メモリ計算の前に、品質で足切りします。 載っても使えないモデルを計算しても意味がないためです。

Step 4：メモリ収支を計算する

3つを足すだけです。

① 重み

重み = パラメータ数 × 1パラメータあたりのバイト数

BF16 = 2 bytes / FP8 = 1 byte / INT4 = 0.5 bytes

例：30B を FP8 → 30 × 1 = 30 GB

② KV Cache

生成済みトークン1つごとに、全レイヤ分のKeyとValueを保持し続けます。

KV Cache / token = 2 × layers × kv_heads × head_dim × dtype_bytes
                   ↑
                   K と V の2本

例：layers 64・kv_heads 8・head_dim 128・FP16
  = 2 × 64 × 8 × 128 × 2
  = 262,144 bytes
  ≈ 262 KB / token

1トークン262KBは小さく見えますが、これはリクエストごとに、コンテキスト長の分だけ積み上がります。

1リクエスト（4Kコンテキスト） = 262KB × 4,096 ≈ 1.07 GB
16並列                        = 約 17.2 GB
50並列                        = 約 53.7 GB   ← 重みより大きい

KVヘッド数が計算に効いている点にも注目してください。Attentionヘッドすべてに個別のKVを持たせる方式（MHA）ではなく、KVを共有するGQAを採用したモデルでは、この値が大幅に小さくなります。詳細はKV Cacheの解説を参照してください。

③ 上乗せ

アクティベーション、CUDAコンテキスト、メモリ断片化などで、①＋②に対しておおよそ10〜20%を見込みます。ここでは15%とします。

Step 5：帯域から速度の上限を見積もる

メモリに載っても、速度が出るとは限りません。デコード（1トークンずつ生成する処理）はmemory-boundです。

1トークン生成するたびに、（アクティブな）重みを全部読む

理論上のデコード速度 = メモリ帯域 ÷ 1トークンで読む重みのバイト数

ここで、Level 1で候補に挙がった「大容量Unified Memory機」の性格が効いてきます。

では、この機体では何もできないのでしょうか。式を逆から使えば、打ち手が見えます。

必要な重みサイズ = 帯域 ÷ 目標速度 = 273 ÷ 25 ≈ 10.9 GB 以下

読むバイト数を10.9GB以下にできれば、25 tok/sに届く可能性があります。方法は2つです。

MoEは「重みは全部メモリに置くが、1トークンの生成で読むのは一部だけ」という構造です。帯域が制約になっている環境では極めて有効ですが、バッチ処理では複数リクエストが別々のエキスパートを呼ぶため、実効的に読まれる量は増えます。理論値をそのまま信じず、実測（Level 4）で確認する前提が必要です。

プリフィルの計算量 ≈ 2 × パラメータ数 × 入力トークン数

例：30B・4K入力 → 2 × 30e9 × 4,096 ≈ 2.5 × 10^14 FLOPs

Step 6：三すくみを表にする

モデルサイズ・コンテキスト長・同時実行数は、同じメモリを取り合います。1つを伸ばせば他が減ります。

この関係を体感するために、実際に数字を動かしてみてください。

Step 7：候補を2〜3案に絞り、測定項目を決める

理論でできるのはここまでです。以降は実測でしか決まりません。測る前に、何を測れば合否が判定できるかを決めておきます。

6. 採用判断

NortiaのPoCでは、次の3案を検証対象とします。

70B級は、この段階で候補から外します。 検証機の帯域では理論値でも4 tok/s程度にとどまり、要件を満たす見込みがないためです。品質面で魅力があっても、要件を満たせない構成をPoCに含めると、検証工数が無駄になります。

7. Architecture

PoC時点のメモリ収支を、構成図ではなく予算表として持ちます。

検証機（121GB）のメモリ収支：案B（30B MoE・FP8・8K・16並列）
  ※ layers 48・kv_heads 4・head_dim 128・KVはFP16で試算

  0GB        30GB           43GB      49GB            121GB
  ├───────────┼──────────────┼──────────┼───────────────┤
  │  重み 30  │ KV Cache 約13 │ 上乗せ 約6 │   余裕 約72    │
  └───────────┴──────────────┴──────────┴───────────────┘
                                              ↑
                            同時実行を増やせるのはこの余裕の分だけ

この構成では、メモリ上は同時実行を大きく増やす余地があります。先に限界へ達するのは容量ではなく帯域であり、そのことがStep 5の計算で分かっています。

この図で管理すべき点は1つです。**余裕の部分が、そのまま「あと何並列いけるか」**を表します。運用時にここが枯渇すると、リクエストがキューで待たされるか、OOMで落ちます。

8. 実装

サイジング表テンプレート

PoC前に、次の表を埋めます。埋まらない欄がある時点で、まだ測定に進む段階ではありません。

実施手順

1. モデル候補のconfig.jsonから形状を取得する
2. 上表を候補ごとに作成する
3. 容量で落ちる構成を除外する
4. 帯域で落ちる構成を除外する
5. 残った2〜3案をLevel 3の推論サーバー選定へ渡す

9. Benchmark / Evaluation

Level 4で検証する仮説を、いま明文化しておきます。測ってから解釈を考えると、都合のよい説明が後付けされます。

10. 残った課題

• 理論値と実測値の乖離幅が不明（推論エンジンの実装効率に依存する）
• Continuous BatchingやPagedAttentionによって、KV Cacheの実効効率が変わる（Level 3）
• MoEのバッチ時の挙動は計算だけでは読めない
• 量子化による品質劣化を、日本語の社内文書で測ったデータがまだない

11. 次のLevelへ

Level 3：推論サーバーを選ぶでは、同じモデル・同じGPUでも、推論エンジンの実装によってスループットが数倍変わる理由を扱います。

Continuous BatchingとPagedAttentionが、このLevelで計算した「三すくみ」の制約をどこまで緩められるのか——それが次の論点です。