FM デプロイ戦略と LLM 特有のデプロイ課題（GPU/メモリ/モデルロード/容量）｜基礎を学ぶ

このレッスンで学ぶこと 対応試験ドメイン D2 タスク 2.2.1・2.2.2（FM のデプロイ戦略と運用課題）。Amazon Bedrock のサーバーレス推論と Amazon SageMaker エンドポイントの自己ホストの使い分け、GPU・メモリ・モデルロード時間・容量予約という LLM 特有のデプロイ課題、プロビジョンドスループットやオートスケーリングの判断を身につけます。

解説

「基盤モデルをどこにどうデプロイするか」は実装ドメインの中核です。フルマネージドでモデルを呼ぶのか、自分でモデルをホストするのかで、運用負荷・コスト・制御の自由度が大きく変わります。試験では「要件に対してどのホスティング戦略を選ぶか」が問われます。

デプロイ先の選択肢

選択肢	概要	向いているケース
Amazon Bedrock（オンデマンド）	API 呼び出しで FM を利用。インフラ管理ゼロ、従量課金	一般的な GenAI 用途。最速で始められる
Amazon Bedrock（プロビジョンドスループット）	専有スループットを予約。安定したレイテンシ・容量を確保	大量・安定トラフィック、カスタムモデル、SLA 要件
Amazon SageMaker エンドポイント	モデルを自分でホスト。インスタンス/GPU を選択	Bedrock に無いモデルや独自モデル、細かい制御が必要

まず Amazon Bedrock のオンデマンドで足りるかを検討し、安定したスループット・容量保証が要るならプロビジョンドスループット、Bedrock に無い独自モデルを動かすなら SageMaker エンドポイントへ、という順で判断します。

LLM 特有のデプロイ課題

汎用 Web アプリと違い、LLM のホスティングには固有の難しさがあります。主な課題は下記のとおりです。

課題	内容	対策
GPU 要件	大規模モデルは GPU/アクセラレータが必要で高コスト	適切なインスタンスタイプ選定、Bedrock なら管理不要
メモリ	モデル重みが大きくメモリを大量消費	量子化・適切なインスタンス、エンドポイント分割
モデルロード時間	起動時にモデル重みのロードで時間がかかる	プロビジョンド容量で常時ウォーム、コールドスタート回避
容量確保	GPU インスタンスは需要逼迫で確保しにくい	プロビジョンドスループットや容量予約で確保

自己ホストの SageMaker では、これらを自分で設計します。Amazon Bedrock のマネージドを使えば GPU・メモリ・ロードの大半が抽象化され、開発者はスループット予約の判断に集中できます。

スケーリングとコスト

オンデマンドはトラフィックに応じて従量課金で柔軟ですが、ピーク時のレイテンシ保証は弱めです。プロビジョンドスループットは容量を予約してレイテンシと容量を安定させますが、未使用時もコストがかかります。SageMaker エンドポイントはオートスケーリングを自分で設定でき、ゼロスケール可能なオプションもありますが、GPU 起動とモデルロードの遅延を考慮する必要があります。

コード例（オンデマンドの推論呼び出し）

Bedrock のオンデマンド推論は API 一発です。インフラ管理は不要です。

Python

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

resp = bedrock.converse(
    modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
    messages=[{"role": "user", "content": [{"text": "在庫切れ時の謝罪文を書いて"}]}],
    inferenceConfig={"maxTokens": 256},
)
print(resp["output"]["message"]["content"][0]["text"])

試験で問われるポイント

Bedrock オンデマンド vs プロビジョンドスループット vs SageMaker 自己ホスト。マネージドで一般用途なら Bedrock オンデマンド、安定容量/SLA/カスタムモデルならプロビジョンドスループット、Bedrock に無い独自モデルや細かい制御なら SageMaker エンドポイント
GPU 確保とモデルロード遅延は LLM 特有の論点。GPU を自分で管理したくないなら Bedrock、容量を確実に確保したいならプロビジョンドスループット
「Lambda に大規模 LLM を載せる」はアンチパターンになりやすい。Lambda はパッケージサイズ・実行時間・GPU 非対応の制約があり、大規模モデルの推論ホストには不向き。Lambda はオーケストレーションや前後処理に使う
コスト最適化では「常時高トラフィック → プロビジョンド」「散発的 → オンデマンド」という需要パターンとの突き合わせが問われる

サービスの使い分け早見表

やりたいこと	使うもの	混同しやすいもの
一般用途で最速・管理ゼロに FM を使う	Amazon Bedrock（オンデマンド）	SageMaker エンドポイント（自己ホストで運用負荷大）
安定したスループット・容量を予約	Bedrock プロビジョンドスループット	オンデマンド（容量保証が弱い）
Bedrock に無い独自モデルをホスト	Amazon SageMaker エンドポイント	Bedrock（提供モデルに限定される）
推論の前後処理・オーケストレーション	AWS Lambda / Amazon ECS	Lambda に大規模 LLM 本体を載せる（制約で不適）

まとめ

FM デプロイは「マネージドで足りるか」から考えます。一般用途は Amazon Bedrock オンデマンド、安定容量や SLA・カスタムモデルはプロビジョンドスループット、Bedrock に無い独自モデルや細かい制御は Amazon SageMaker エンドポイントです。GPU 確保・メモリ・モデルロード遅延という LLM 特有の課題は、マネージドなら抽象化され、自己ホストなら自分で設計します。Lambda は推論本体ではなく前後処理・オーケストレーションに使うのが定石です。

次のステップ

次のクイズレッスンで、デプロイ先の選択と LLM 特有課題への対処を問うシナリオ問題に挑戦しましょう。