変更要約: 各節に図（figure）を追加＝cert-figure-retrofit。AI-300 第3章を新規作成（ドメイン3「GenAIOps インフラ」: Foundry 環境=プロジェクト/RBAC/マネージド ID/プライベートネットワーク/Bicep・CLI、基盤モデルのデプロイ=サーバーレス API エンドポイント vs マネージド コンピューティング/ユースケース別モデル選択/バージョン管理・デプロイ戦略/PTU、プロンプトのバージョン管理=設計・開発/バリアント比較/Git）
3.2基盤モデルのデプロイと管理
サーバーレス API エンドポイントとマネージド コンピューティングによる基盤モデルのデプロイ、ユースケースに応じたモデル選択、モデルのバージョン管理と本番デプロイ戦略、そして高負荷ワークロード向けのプロビジョニングされたスループット ユニット（PTU）の構成を理解します。
生成 AI アプリは、カタログから選んだ 基盤モデル（Foundation Model）をデプロイして使います。デプロイ方式・モデル選択・スループットの確保が運用の要点です。
3.2.1デプロイ方式とモデル選択
モデルのデプロイには2つの方式があります。サーバーレス API エンドポイント（従量課金で、インフラを管理せずに API として呼び出す）と マネージド コンピューティング（専用の計算リソースにデプロイ＝より細かい制御や分離が必要な場合）です。モデル選択は、ユースケース（必要な品質・コスト・遅延・コンテキスト長・マルチモーダル対応）に応じて行います。「まず要件 → 適切なモデルとデプロイ方式」を選ぶのが基本です。
3.2.2バージョン管理と PTU
モデルにも バージョン管理と本番デプロイ戦略（段階的に切り替える等）が必要です。モデルは更新・廃止されるため、固定バージョンへのデプロイや切替計画を持ちます。高負荷で安定した低遅延と予測可能なコストが必要な場合は、プロビジョニングされたスループット ユニット（PTU）で容量を予約します（従量課金より高負荷に強い）。低～変動負荷は従量課金（サーバーレス）が適します。
| 観点 | 選択肢 | 使いどころ |
|---|---|---|
| デプロイ方式（軽量） | サーバーレス API エンドポイント | 従量課金・インフラ管理不要 |
| デプロイ方式（専用） | マネージド コンピューティング | 細かい制御/分離が必要 |
| モデル選択 | ユースケース基準 | 品質/コスト/遅延/コンテキスト長 |
| 高負荷の容量確保 | PTU（プロビジョニング済み） | 安定低遅延・予測可能なコスト |
| 低～変動負荷 | 従量課金（サーバーレス） | 使った分だけ |
混同に注意：
①サーバーレス API エンドポイント（従量・管理不要）とマネージド コンピューティング（専用・細かい制御）。
②PTU（容量予約＝高負荷で安定）と従量課金（変動向け）。
③モデルは更新/廃止されるためバージョン管理と切替計画が必要。
「要件 → 選択」：例「インフラを管理せず API でモデルを呼ぶ」＝サーバーレス API エンドポイント、「専用リソースで細かく制御」＝マネージド コンピューティング、「高負荷で安定低遅延・予測可能なコスト」＝PTU、「変動する低負荷で使った分だけ」＝従量課金、「用途に合うモデルを選ぶ」＝ユースケース基準のモデル選択。
3.2.3この節のまとめ
- デプロイ：サーバーレス API エンドポイント（従量/管理不要）vs マネージド コンピューティング（専用/制御）
- モデル選択はユースケース基準（品質/コスト/遅延/コンテキスト長/マルチモーダル）
- 高負荷は PTU で容量予約、変動負荷は従量課金。モデルはバージョン管理と切替計画
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. インフラを管理せず、従量課金で基盤モデルを API として呼び出せるデプロイ方式はどれですか？
Q2. 高負荷のワークロードで、安定した低遅延と予測可能なコストを得るために容量を予約するのはどれですか？
Q3. 専用の計算リソースにモデルをデプロイし、より細かい制御や分離が必要な場合に適した方式はどれですか？
Q4. 基盤モデルを選ぶ際の基準として最も適切なものはどれですか？
Q5. 基盤モデルは更新・廃止されるため、本番運用で必要になるのはどれですか？
Q6. PTU と従量課金（サーバーレス）の使い分けとして正しいものはどれですか？