推論の基礎

学習と推論は別の仕事

学習は大規模なデータセットでモデルの重みを調整する処理で、通常は大規模なアクセラレータクラスタ上で一度だけ行います。推論は固定された重みを新しい入力に適用する処理で、製品が受けるすべてのリクエストに対して継続的に走ります。学習コストは基本的に一度きりの投資ですが、推論コストはトラフィックとともに積み上がります。だからこそサービング効率がAI製品の採算を決めます。

関連する区別として、推論フレームワークはモデルを効率よく実行するもの、推論サーバーはそれをバッチング、キューイング、ストリーミング、ヘルスチェック、オートスケーリング、HTTPまたはgRPC APIで包むものです。本番システムには両方が必要です。

モデルがプロンプトをテキストに変えるまで

1. 1. トークン化プロンプトはトークンに分割され、固定語彙のIDに対応づけられます。コストとコンテキスト上限を左右するのは文字数ではなくトークン数です。
2. 2. 埋め込みトークンIDがベクトルになります。位置情報（たとえばrotary embeddings）が、各トークンが系列のどこにあるかをモデルに伝えます。
3. 3. prefillプロンプト全体をTransformer層に1回の並列パスで通します。self-attentionは各トークンをそれ以前のすべてのトークンと比較し、causal maskが後続トークンを見えないようにします。このフェーズは計算律速で、最初のトークンまでの時間を決めます。
4. 4. decodeトークンは1つずつ生成されます。各ステップでモデルの重みとキャッシュされたattention状態を読むため、このフェーズはメモリ帯域律速で、トークン間レイテンシを決めます。
5. 5. KVキャッシュ過去のトークンについて計算したattentionのkeyとvalueをキャッシュしておくことで、新しいトークンは系列全体を再計算せず保存済みの状態を参照するだけで済みます。キャッシュはコンテキスト長に比例して増え、GPUメモリを重みと奪い合います。
6. 6. サンプリングとストリーミング確率分布から次のトークンを選び（greedy、temperature、top-k、top-p）、系列に追加します。通常は停止条件かトークン上限に達するまでクライアントへストリーミングします。

prefillとdecodeの分離が、サービングの挙動のほとんどを説明します。長いプロンプトは最初のトークンまでの時間を悪化させ、長い出力は総レイテンシを悪化させます。そしてサービング最適化のページにある最適化のほとんどは、どちらか一方のフェーズを狙ったものです。トークン単位の逐次生成は支配的な方式ですが唯一の方式ではありません。拡散型の言語モデルは反復的な精緻化によって文章全体をまとめて生成し、レイテンシの挙動も異なる、活発な研究方向です。

推論が動く場所

選定基準はモデルサイズ、リクエスト量、レイテンシ目標、コスト、そしてすでに運用しているインフラです。ブラウザ、エッジ、モバイルでの実行はWeb推論とエッジとモバイルで扱います。

推論サービスを表す指標

• 中央値とテール（P95/P99）の両方を報告してください。平均値は、利用者の記憶に残る遅いリクエストを覆い隠します。
• レイテンシとスループットは互いに引き合う関係にあり、両者を調整する主なレバーはバッチサイズです。
• どの数値にも必ずモデル、ハードウェア、系列長、同時実行数を併記してください。ワークロードを欠いた指標には意味がありません。