【MLA-C01】デプロイ基盤の選択｜リアルタイム/サーバーレス/非同期/バッチ・マルチモデルを図解

デプロイ基盤の選択 エンドポイント4種 MLA-C01 AWS資格の森 機械学習エンジニア(MLA)
2026.06.03
無料MLA-C01 ドメイン3：デプロイと運用自動化｜M3-1「デプロイ基盤の選択」。SageMakerの4つのエンドポイント種別とマルチモデル・Neoの使い分けを図解します。

学習したモデルは、使われてはじめて価値を生みます。SageMakerには推論の提供方法が複数あり、リアルタイム・サーバーレス・非同期・バッチの4種を、要件（レイテンシ・ペイロードの大きさ・トラフィックの性質・コスト）で使い分けます。MLA-C01でも頻出の判別ポイントです。この記事で各種別の「向き・不向き」を押さえましょう。前の記事は M2-3、全体像は シラバスマップ をどうぞ。

学習済みモデルをエンドポイントとしてデプロイするイメージ図
図：デプロイは「どう推論を届けるか」の設計です。要件に合った提供方法を選ぶことが、性能とコストの両立につながります。

4つのエンドポイント種別を使い分ける

判別の軸はシンプルです。常時の低遅延が要るか、トラフィックは断続的か、ペイロードが大きく処理が長いか、大量データを一括処理するか。これで選びます。

リアルタイム・サーバーレス・非同期・バッチの4つの推論方式の使い分けを示す図
図：常時低遅延ならリアルタイム、断続トラフィックならサーバーレス、大ペイロード・長時間なら非同期、大量データ一括ならバッチ、が基本の対応です。
種別 向いている場面
リアルタイム推論 常時稼働で低レイテンシ。安定したトラフィックの即時応答
サーバーレス推論 断続的・予測しづらいトラフィック。アイドル時のコストを抑えたい（コールドスタートは許容）
非同期推論 大きなペイロード・長い処理時間。リクエストをキューに入れ、結果はあとで受け取る
バッチ変換 大量データを一括でスコアリング。常時エンドポイントは不要

頻出の引っかけ：「即時応答は不要・大きな入力・処理が長い」なら非同期、「夜間にまとめて大量処理」ならバッチ。常時リアルタイムを選んでしまう誤りに注意します。

コストを抑えるホスティング：マルチモデルエンドポイント

顧客ごと・店舗ごとなど多数の小さなモデルを提供する場合、それぞれに専用エンドポイントを立てるとコストが膨らみます。マルチモデルエンドポイントは、1つのエンドポイントで多数のモデルをホストし、必要なモデルを動的に読み込むことでコストを大きく抑えます。似た用途で複数モデルをまとめるマルチコンテナもあります。

個別エンドポイントとマルチモデルエンドポイントのコスト比較の図
図：モデルごとに個別エンドポイントを立てるとコスト過大。1つのエンドポイントに集約すれば、多数のモデルを効率よく提供できます。

デプロイ先・コンテナ・エッジ

  • デプロイ先：SageMakerエンドポイントのほか、Kubernetes（Amazon EKS）・Amazon ECS・AWS Lambda なども選べる。既存の基盤に合わせて選択
  • コンテナ：SageMaker提供のコンテナをそのまま使うか、独自環境ならBYOC（Bring Your Own Container）で持ち込む
  • エッジ最適化：端末（エッジデバイス）で動かすならSageMaker Neoでモデルを最適化し、軽量・高速に
  • オーケストレーション：ワークフロー全体はSageMaker Pipelinesや Apache Airflow で組み立てる

確認クイズ

Q1. あなたは高解像度の医用画像を解析するモデルをデプロイします。1件あたりの入力ペイロードが大きく、推論に数十秒かかります。利用側は即時応答を必要とせず、結果はあとで受け取れれば十分です。最も適切な推論方式はどれですか。

A. リアルタイム推論エンドポイントを常時稼働させ、同期で応答する。
B. 非同期推論エンドポイントを使い、リクエストをキューに入れて処理し、結果はS3などからあとで受け取る。
C. サーバーレス推論エンドポイントで、コールドスタートを受け入れつつ同期応答する。
D. すべてのリクエストをLambda関数だけで同期処理する。

Q2. あなたが運用する社内ツールの推論は、日中にときどき呼ばれる程度で、利用が読みにくく、夜間や週末はほとんど使われません。アイドル時にコストを払いたくなく、多少の初回遅延（コールドスタート）は許容できます。最も適切な推論方式はどれですか。

A. リアルタイム推論エンドポイントを24時間プロビジョニングして常時待機させる。
B. 大量データを夜間に一括処理するバッチ変換ジョブを使う。
C. 高性能インスタンスのリアルタイムエンドポイントを複数台、常時冗長構成で運用する。
D. サーバーレス推論エンドポイントを使い、需要に応じて自動でスケールし、アイドル時のコストを抑える。

Q3. あなたは毎晩、その日に蓄積された数百万件の取引データをまとめてスコアリングする処理を実装します。リアルタイム性は不要で、常時稼働するエンドポイントを持ちたくありません。最も適切な方法はどれですか。

A. SageMakerのバッチ変換ジョブで、蓄積データを一括処理してから結果を出力する。
B. リアルタイム推論エンドポイントを常時稼働させ、1件ずつ送って処理する。
C. 非同期推論エンドポイントを常時起動し、1件ずつキューに入れる。
D. サーバーレス推論エンドポイントで、1件ずつ同期的に処理する。

Q4. あなたのSaaSでは、顧客ごとに個別に学習した数百個の小さなモデルを提供しています。各モデルに専用のリアルタイムエンドポイントを立てたところ、エンドポイント数が膨大でコストが過大になりました。コストを抑えつつ多数のモデルを提供する最適な方法はどれですか。

A. これまでどおり、モデルごとに専用エンドポイントを立て続ける。
B. すべてのモデルを1つの巨大モデルに統合し、1エンドポイントで提供する。
C. マルチモデルエンドポイントを使い、1つのエンドポイントで多数のモデルをホストして動的に読み込む。
D. すべてのモデルを各利用者のブラウザ上だけで実行する。

よくある質問（FAQ）

Q. 非同期推論とバッチ変換はどう違う？

A. 非同期は1件ずつのリクエストをキュー経由で処理し（大ペイロード・長時間向け）、バッチ変換は大量データをまとめて一括処理します。常時エンドポイントが不要な点は共通ですが、用途の粒度が違います。

Q. サーバーレス推論のデメリットは？

A. アイドルから起動する際のコールドスタートによる初回遅延です。常に低遅延が必須ならリアルタイムを選びます。

Q. マルチモデルエンドポイントが向くのは？

A. 多数の小さなモデルを提供し、すべてを常時稼働させる必要がない場合です。1エンドポイントに集約してコストを抑えられます。

まとめ

  • 推論は4種を使い分け：常時低遅延＝リアルタイム／断続トラフィック＝サーバーレス／大ペイロード・長時間＝非同期／大量一括＝バッチ
  • 多数の小モデルはマルチモデルエンドポイントでコスト集約
  • デプロイ先はエンドポイント・EKS・ECS・Lambdaから、独自環境はBYOC、エッジはNeo
🎯 次のステップ

※本記事はAWS公式試験ガイド(MLA-C01)および各サービスの公開ドキュメントに基づき、エンジニアKが作成しています。サービス仕様は更新されることがあるため、最新は必ずAWS公式でご確認ください。本サイトはAmazon Web Services, Inc.の公式サイトではありません。AWSは同社の商標です。

コメント

タイトルとURLをコピーしました