2.2モデルデプロイ戦略

FM のデプロイは、従来の ML 推論とは異なる課題（巨大モデル・GPU・トークン処理・コールドスタート）があります。トラフィック特性とレイテンシ要件で方式を選びます。

2.2.1デプロイ方式の選択

• Lambda オンデマンド呼び出し：散発的/バースト的トラフィックに。Bedrock をオンデマンドで呼び、サーバーレスで弾力的。
• Bedrock プロビジョンドスループット：安定した高スループットや厳しいレイテンシ SLA に。容量を予約する。
• SageMaker エンドポイント：自前/カスタムモデルやハイブリッド構成のホスティングに。リアルタイム/非同期/バッチ。
• モデルカスケード：簡単な問い合わせは小型/安価モデル、難しいものだけ大型モデルへ。コストと品質を両立。

デプロイは「呼ぶ FM の種類」と「トラフィック特性」で決めます。Bedrock のマネージド FM はオンデマンド（弾力・従量）か プロビジョンドスループット（容量予約・安定レイテンシ）で呼び、アプリは Lambda・ECS/Fargate から API Gateway 越しに公開します。自前/オープンウェイトのモデルや特殊ランタイムは SageMaker エンドポイント（リアルタイム/非同期/バッチ変換）でホストし、コンテナは GPU 利用率・メモリ・トークン処理容量に合わせて設計、モデルロード戦略でコールドスタートを抑えます。コスト最適化では モデルカスケード（ルーティングで簡単な問い合わせを小型モデルへ）や、タスク特化の小型事前学習モデルの活用が効きます。「巨大な単一モデルを常時フル稼働」ではなく、トラフィックに応じて弾力化＋難易度でモデルを段階化するのがプロの定石です。

2.2.2この節のまとめ

• 散発＝Lambda オンデマンド／安定高負荷＝プロビジョンドスループット／カスタム＝SageMaker
• コスト最適＝モデルカスケード（難易度でモデル段階化）