はじめに
前回は、SageMaker の Training とハイパーパラメータチューニングについて整理しました。
今回は、学習済みモデルを実際に使って予測するための仕組み、つまり
推論（Inference） について整理します。
SageMaker では、モデルを学習したあと、そのモデルを使って予測する方法が複数あります。
代表的なものは以下です。
- Real-time Endpoint
- Serverless Endpoint
- Asynchronous Endpoint
- Batch Transform
どれも「学習済みモデルを使って予測する」という点では同じですが、
使いどころがかなり違います。
本記事では、それぞれの違いを
- すぐ結果が必要か
- データ量が多いか
- リクエスト頻度が安定しているか
- 処理に時間がかかるか
- コストをどう考えるか
という実務目線で整理します。
🎯 対象読者
- SageMaker Endpoint の種類を整理したい方
- Real-time / Serverless / Async / Batch Transform の違いを理解したい方
- AWS の AI / ML 系資格を勉強している方
- 推論方式の使い分けで迷いやすい方
- 実務でモデルをどうデプロイするか考えたい方
🧩 まず結論：推論方式は「即時性」と「処理量」で考える
SageMaker の推論方式は、最初に以下の2つで考えると分かりやすいです。
すぐ結果を返したいか？
大量データをまとめて処理したいか？
ざっくり整理すると、以下のようになります。
| 推論方式 | 向いている場面 | 一言で言うと |
|---|---|---|
| Real-time Endpoint | 低遅延で即時応答したい | 常時使える API |
| Serverless Endpoint | リクエスト頻度が少ない・変動する | サーバー管理を減らしたリアルタイム推論 |
| Asynchronous Endpoint | 処理に時間がかかる・入力が大きい | 非同期でゆっくり処理 |
| Batch Transform | 大量データをまとめて処理したい | 一括予測 |
覚え方は以下です。
すぐ返すなら Real-time Endpoint
たまに使うなら Serverless Endpoint
時間がかかるなら Asynchronous Endpoint
まとめて処理するなら Batch Transform
🌐 SageMaker Endpoint とは？
SageMaker Endpoint とは、
学習済みモデルを呼び出して予測結果を返すための仕組み です。
アプリケーションから見ると、モデルを API のように呼び出せるイメージです。
アプリケーション
↓
Endpoint にリクエスト
↓
モデルが推論
↓
予測結果を返す
たとえば、ユーザーが画面上でローン申請をしたとき、
その場でリスク判定を返すようなケースでは Endpoint が使われます。
⚡ Real-time Endpoint とは？
Real-time Endpoint は、
リクエストに対してすぐに予測結果を返すための Endpoint です。
一言で言うと
Real-time Endpoint = 低遅延のリアルタイム API
ユーザー操作や外部システムからのリクエストに対して、
すぐに結果を返す必要がある場合に向いています。
🧪 Real-time Endpoint の具体例
たとえば、以下のようなケースです。
例：ローン審査
ユーザーがローン申請を送信
↓
申請データを Endpoint に送信
↓
モデルが信用リスクを予測
↓
すぐに結果を返す
この場合、ユーザーは画面上で結果を待っているため、
数分後ではなく、できるだけ短い時間で結果を返す必要があります。
例：EC サイトの推薦
ユーザーが商品ページを開く
↓
現在の行動データを Endpoint に送る
↓
おすすめ商品を即時に返す
このようなリアルタイム性が必要な場面では、Real-time Endpoint が向いています。
✅ Real-time Endpoint が向いている場面
| 場面 | 理由 |
|---|---|
| Web アプリから即時に呼び出す | ユーザー操作にすぐ応答する必要がある |
| API として常に利用する | 他システムから随時呼ばれる |
| 低レイテンシーが重要 | 予測結果をすぐ返す必要がある |
| リクエストが継続的にある | 常時稼働のコストを正当化しやすい |
Real-time Endpoint は便利ですが、
基本的には常時稼働するリソースを意識する必要があります。
そのため、リクエストがほとんどないのに常時起動しておくと、
コスト効率が悪くなることがあります。
🧩 Serverless Endpoint とは？
Serverless Endpoint は、
サーバーやインスタンスの管理をあまり意識せずに使えるリアルタイム推論の仕組み です。
一言で言うと
Serverless Endpoint = 管理負担を減らしたリアルタイム推論
リクエストが少ない、またはアクセス頻度が大きく変動する場合に向いています。
Real-time Endpoint のように常にインスタンスを意識するのではなく、
リクエストに応じて処理する形に近いイメージです。
✅ Serverless Endpoint が向いている場面
| 場面 | 理由 |
|---|---|
| リクエスト数が少ない | 常時起動のコストを抑えやすい |
| アクセスが不定期 | 必要なときだけ処理しやすい |
| インフラ管理を減らしたい | インスタンス管理を意識しにくい |
| 小さめの推論処理 | 軽量なリアルタイム推論に向く |
たとえば、社内ツールでたまにモデルを呼び出すようなケースでは、
Serverless Endpoint が候補になります。
⚠️ Serverless Endpoint の注意点
Serverless Endpoint は便利ですが、
常に Real-time Endpoint の完全な代替になるわけではありません。
特に注意したいのは、コールドスタート です。
しばらく使われていなかったあとにリクエストが来ると、
起動に少し時間がかかる場合があります。
そのため、非常に低いレイテンシーが常に求められる本番 API では、
Real-time Endpoint の方が適していることがあります。
覚え方としては以下です。
Serverless Endpoint = コストや管理負担を抑えやすいが、コールドスタートに注意
🕒 Asynchronous Endpoint とは？
Asynchronous Endpoint は、
リクエストを受け取ったあと、すぐに結果を返さず、処理完了後に結果を保存する推論方式 です。
日本語では、非同期推論と考えると分かりやすいです。
一言で言うと
Asynchronous Endpoint = 時間がかかる推論を非同期で処理する
Real-time Endpoint のようにすぐレスポンスを返すのではなく、
まずリクエストを受け付け、処理が終わったら結果を S3 などに保存します。
🧪 Asynchronous Endpoint の具体例
たとえば、ユーザーが大きな動画ファイルをアップロードし、
その内容をモデルで分析するケースを考えます。
ユーザーが 500MB の動画をアップロード
↓
Asynchronous Endpoint に推論リクエスト
↓
モデルが動画を分析
↓
数分後に結果を S3 に保存
このような処理は、すぐにレスポンスを返すリアルタイム API には向いていません。
入力データが大きい場合や、推論処理に時間がかかる場合は、
Asynchronous Endpoint が向いています。
✅ Asynchronous Endpoint が向いている場面
| 場面 | 理由 |
|---|---|
| 推論に時間がかかる | すぐに結果を返す必要がない |
| 入力データが大きい | 大きなファイルを処理しやすい |
| 結果を後で取得すればよい | 非同期処理で問題ない |
| 処理完了後に S3 へ保存したい | 結果管理がしやすい |
たとえば、
- 動画分析
- 大きな画像ファイルの解析
- 長い文書の処理
- 重いモデルの推論
などでは、Asynchronous Endpoint が選択肢になります。
📦 Batch Transform とは？
Batch Transform は、
S3 上にある大量のデータをまとめて予測するための仕組み です。
一言で言うと
Batch Transform = 大量データを一括推論する
Endpoint のように常時起動してリクエストを待つのではなく、
必要なタイミングでジョブを実行し、大量データをまとめて処理します。
🧪 Batch Transform の具体例
たとえば、会社が毎晩、100万人分の顧客データを分析したいとします。
S3 に 100万人分の顧客データを保存
↓
夜間に Batch Transform Job を実行
↓
全顧客の解約リスクをまとめて予測
↓
結果を S3 に保存
↓
翌朝、営業チームが利用
このような場合は、リアルタイム性は必要ありません。
大量データを効率よくまとめて処理したいので、Batch Transform が向いています。
🧭 4つの推論方式を比較する
ここまでの内容をまとめると、以下のようになります。
| 推論方式 | 即時性 | 入力データ | 出力 | 向いている場面 |
|---|---|---|---|---|
| Real-time Endpoint | 高い | 1件ずつ、または少量 | すぐ返す | Web API、即時判定 |
| Serverless Endpoint | 比較的高い | 1件ずつ、または少量 | すぐ返す | 不定期・少量アクセス |
| Asynchronous Endpoint | 低い | 大きめの入力 | 後で保存 | 重い推論、動画・大きなファイル |
| Batch Transform | 低い | S3 上の大量データ | S3 に保存 | 夜間処理、一括予測 |
試験対策では、まず以下の判断軸を押さえると分かりやすいです。
即時応答が必要 → Real-time Endpoint
アクセスが少ない・変動する → Serverless Endpoint
処理が長い・入力が大きい → Asynchronous Endpoint
大量データをまとめて処理 → Batch Transform
🔁 推論方式を選ぶときの考え方
実務では、推論方式を選ぶときに以下を確認します。
| 確認ポイント | 考えること |
|---|---|
| レイテンシー | すぐ結果を返す必要があるか |
| データ量 | 1件ずつか、大量データか |
| 入力サイズ | 小さいデータか、大きなファイルか |
| リクエスト頻度 | 常時あるか、たまにしかないか |
| コスト | 常時稼働リソースが必要か |
| 結果の受け取り方 | すぐ返すか、後で S3 に保存するか |
このように、技術的な違いだけでなく、
業務要件に応じて選ぶことが重要です。
☁️ AWS 試験での見られ方
AWS の AI / ML 系試験では、推論方式の使い分けは非常に出やすいポイントです。
特に、問題文に以下のようなキーワードが出たら、対応する推論方式を考えます。
「低レイテンシー」「すぐに返す」
この場合は Real-time Endpoint を考えます。
ユーザーのリクエストに即時応答する
API として使う
「アクセス頻度が少ない」「コストを抑えたい」
この場合は Serverless Endpoint が候補になります。
常時稼働を避けたい
リクエスト頻度が不定期
ただし、コールドスタートが問題になる場合は注意が必要です。
「入力が大きい」「処理に時間がかかる」
この場合は Asynchronous Endpoint を考えます。
大きなファイル
長い処理
結果は後で取得
「大量データをまとめて処理」
この場合は Batch Transform を考えます。
S3 上の大量データ
夜間バッチ
結果を S3 に保存
👨💻 実務目線で見ると
実務では、モデルを作るだけでなく、
どう使うか が非常に重要です。
同じモデルでも、使い方によって最適な構成は変わります。
ケース 1：画面操作にすぐ反応したい
ユーザーが画面で操作した直後に予測結果が必要な場合は、
Real-time Endpoint が向いています。
ユーザー操作
↓
即時に推論
↓
結果を画面に返す
ケース 2：社内ツールでたまに使う
アクセス頻度が低く、常時稼働リソースを持つほどではない場合は、
Serverless Endpoint が候補になります。
たまにリクエスト
↓
必要なときだけ推論
↓
管理負担を抑える
ケース 3：動画や大きなファイルを分析する
入力サイズが大きく、推論に時間がかかる場合は、
Asynchronous Endpoint が向いています。
大きなファイルを投入
↓
非同期で処理
↓
結果を S3 に保存
ケース 4：毎晩まとめて全顧客を予測する
大量データを一括で処理し、すぐに結果を返す必要がない場合は、
Batch Transform が向いています。
夜間に大量データを処理
↓
結果を S3 に保存
↓
翌日の業務で利用
🧠 ここは特に覚えたいポイント
覚え方 1
Real-time Endpoint = 低遅延で即時応答
覚え方 2
Serverless Endpoint = 少量・不定期アクセス向け
覚え方 3
Asynchronous Endpoint = 処理が長い・入力が大きい場合
覚え方 4
Batch Transform = 大量データをまとめて予測
覚え方 5
すぐ返すか、後で保存するかで推論方式を選ぶ
✅ まとめ
今回は、SageMaker の推論方式について整理しました。
重要なポイントは以下です。
- SageMaker Endpoint は、学習済みモデルを呼び出して予測する仕組み
- Real-time Endpoint は、低遅延で即時応答が必要な場面に向いている
- Serverless Endpoint は、アクセス頻度が少ない・変動する場面に向いている
- Serverless Endpoint ではコールドスタートに注意する
- Asynchronous Endpoint は、処理に時間がかかる推論や大きな入力に向いている
- Batch Transform は、S3 上の大量データをまとめて予測する場合に向いている
- 推論方式は、即時性、入力サイズ、データ量、コスト、リクエスト頻度で選ぶ
モデルを本番で使うときは、単に精度だけでなく、
どのように推論を実行し、どのように結果を返すか を考えることが重要です。
📌 次回予告
次回は、モデルを本番運用したあとに重要になる
- Model Monitor
- Monitoring
- Data Drift
について整理します。
モデルはデプロイして終わりではなく、
本番環境で正しく動き続けているかを継続的に確認する必要があります。