1. 推論（Inference）とは何か
一言で言うと
推論とは、学習済みのAIモデルにユーザーの質問（プロンプト）を入力し、回答（テキスト）を生成するプロセス。ChatGPTやClaudeに質問するたびに、裏側で「推論」が走っている。
（プロンプト）
入力を一括処理
1トークンずつ生成
（レスポンス）
💻 プログラミングで例えると
// Training = コンパイル（一度だけ、時間がかかる）
model = train(data, epochs=100000) // 数週間〜数ヶ月
// Inference = 実行（毎回、高速）
answer = model.generate("半導体の将来は？") // 数秒推論は2つのまったく性質の異なるフェーズから成る。これが以降のすべての話の土台になる。
2. Prefill（プリフィル）— 入力を一括処理する
Prefillとは
ユーザーが入力したプロンプトのトークンをすべて同時に並列処理するフェーズ。全入力を読み込み、各トークン間の関係（Attention）を計算する。
Prefillの特徴
3. Decode（デコード）— 1トークンずつ生成する
Decodeとは
Prefillで作ったKV Cacheを使い、出力トークンを1つずつ逐次的に生成するフェーズ。新しいトークンが生成されるたびに、KV Cacheが1行ずつ追加されていく。
Decodeの特徴
4. Prefill vs Decode — なぜ分けて考えるのか
Prefill
Decode
📐 なぜこの区別が重要か
- Prefillには高い演算性能（FLOPS）が効く → GPUの性能が直接反映
- Decodeには高いメモリ帯域幅（GB/s）が効く → HBMの性能が直接反映
- 2つの性質が異なるため、同じGPUで両方を同時に動かすと干渉が起きる（→ Lesson 9で解説）
5. KV Cache — なぜメモリが爆発するか
KV Cacheとは
Prefillで計算した各トークンの「Key（鍵）」と「Value（値）」のペアを保存したもの。Decodeの各ステップで、新しいトークンが過去の全トークンを「振り返る」ために使う。KV Cacheがないと、毎ステップで全入力を再計算することになる。
KV Cacheの問題は「メモリを食う」だけでなく、同時に対応できるユーザー数を制限すること。HBM（高帯域メモリ）の容量がそのまま「何人同時に相手できるか」の上限になる。
📐 KV Cacheサイズの概算
- KV Cache = 2 × レイヤー数 × ヘッド数 × ヘッド次元 × シーケンス長 × バイト数
- DeepSeek R1: 61レイヤー × FP8 → 約 500MB / 8192トークン
- 100ユーザー同時 = 50GB のHBMがKV Cacheだけで消える
6. 主要メトリクス — InferenceXダッシュボードの「軸」
InferenceXダッシュボードでは、推論性能を複数の軸で測定する。まずは4つの基本メトリクスを理解しよう。
tok/s（トークン毎秒）
システム全体の総スループット。サーバー事業者にとっての「生産量」。この値が高いほど、同じハードウェアで多くのリクエストを捌ける = コストが下がる。
tok/s/user（ユーザー毎秒トークン）
1人のユーザーが体感するレスポンス速度。InferenceXでは「インタラクティビティ」と呼ぶ。この値が高いほど文字の出が速い。
TTFT（Time To First Token）
「送信」を押してから最初の文字が表示されるまでの待ち時間。入力が長いほどTTFTは長くなる。
TPOT（Time Per Output Token）
Decodeフェーズの速度。tok/s/userの逆数。ユーザー体験の核心。
トレードオフの核心
tok/s（スループット）と tok/s/user（インタラクティビティ）はトレードオフの関係にある。
- ユーザーを多く詰め込む → 1人あたりの速度は落ちるが、総スループットは上がる → コストが下がる
- 1人あたりの速度を上げる → 同時ユーザー数を減らす必要 → コストが上がる
このトレードオフの「どこまで行けるか」の限界線がパレートフロンティア（Lesson 10 で解説）。
7. 経済メトリクス — コストとエネルギー
$/Million tokens（百万トークンあたりコスト）
推論サービスの単位経済性。API利用料の原価に直結する。
入力: $1.35/M tokens ｜ 出力: $5.40/M tokens
perf/TCO（性能÷総所有コスト）
コスト効率。同じ予算でどれだけのトークンを生成できるか。ハードウェア選定の最重要指標。
picoJoules/token（pJ/tok）
エネルギー効率。データセンターの電力コストと環境負荷を示す。
TCO（Total Cost of Ownership）
ハードウェアの購入価格だけでなく、3〜5年の運用期間全体の総コスト。GPU本体は全体の一部に過ぎない。
🧠 セルフチェック
Q1: 推論の「Prefill」フェーズのボトルネックは何か？
回答を見る
計算量（Compute-bound）。全入力トークン間のAttention計算（O(n²)の行列演算）がボトルネック。GPUの演算コア（FLOPS）の性能が直接効く。
Q2: 「tok/s」と「tok/s/user」の違いを一言で説明せよ。
回答を見る
tok/s はシステム全体のスループット（全ユーザー合計の生成量）。tok/s/user は1人のユーザーが体感する速度。tok/s が高くても、ユーザーを大量に詰め込んでいれば tok/s/user は低くなる。
Q3: KV Cacheがメモリを大量に消費すると、実運用上どんな問題が起きるか？
回答を見る
同時に対応できるユーザー数が制限される。HBMの容量は有限なので、1ユーザーあたりのKV Cache（DeepSeek R1で約500MB/8192tok）× 同時ユーザー数がHBM容量を超えると、新しいリクエストを受けられない。100ユーザー同時 = 50GB がKV Cacheだけで消える。
Q4: tok/s/user = 60 のとき、TPOT（1トークンあたり生成時間）は何ミリ秒か？
回答を見る
約16.7ms。TPOT = 1 / tok/s/user = 1/60 ≈ 0.0167秒 = 16.7ms。
Q5: 推論コストを下げるには「tok/s を上げる」のと「tok/s/user を上げる」のと、どちらが直接的に効くか？ 理由も述べよ。
回答を見る
tok/s を上げる方が直接的にコストを下げる。$/Million tokens = TCO ÷ 生成トークン数 × 10⁶ なので、同じハードウェアコスト（TCO）でトータルの生成量（tok/s）が上がれば、1トークンあたりのコストは下がる。一方、tok/s/user はユーザー体験の質に影響するが、これを上げると同時ユーザー数が減り、むしろ $/M tokens は上がる方向に働く。これがスループットとインタラクティビティのトレードオフ。
📖 用語集
| 用語 | 説明 |
|---|---|
| Inference（推論） | 学習済みモデルで回答を生成するプロセス |
| Prefill | 入力トークンを一括並列処理するフェーズ。compute-bound |
| Decode | 出力トークンを1つずつ生成するフェーズ。memory-bandwidth-bound |
| KV Cache | Prefillで計算したKey/Valueペアの保存領域。Decode時に参照 |
| tok/s | システム全体の1秒あたりトークン生成数（スループット） |
| tok/s/user | 1ユーザーが体感する1秒あたりトークン速度（インタラクティビティ） |
| TTFT | Time To First Token — 最初のトークンが出るまでの待ち時間 |
| TPOT | Time Per Output Token — 1トークンの生成時間。tok/s/userの逆数 |
| TCO | Total Cost of Ownership — ハード償却+電力+運用の総コスト |
| HBM | High Bandwidth Memory — GPUに搭載される高速大容量メモリ |