はじめに
前回は、ML ワークロードのセキュリティとして、
- IAM
- KMS
- VPC
- VPC Endpoint
- CloudTrail
- CloudWatch Logs
について整理しました。
今回は、このシリーズの最後として、AWS 上で機械学習を運用するうえで重要な
コスト最適化 について整理します。
機械学習では、モデルの精度だけを見ていると、コストが大きくなりすぎることがあります。
特に SageMaker では、
- Training Job
- Hyperparameter Tuning
- Endpoint
- Batch Transform
- Processing Job
- Feature Store
- Data storage
- Monitoring
など、さまざまな箇所でコストが発生します。
そのため、実務では
精度
処理時間
レイテンシー
運用しやすさ
コスト
をバランスよく考える必要があります。
本記事では、
- ML ワークロードでコストが発生するポイント
- Training コスト
- Endpoint コスト
- Batch Transform
- Serverless Endpoint
- Spot Training
- Auto Scaling
- インスタンスタイプ選定
- 実務や試験での見られ方
を、初心者にも分かりやすく整理します。
🎯 対象読者
- SageMaker のコスト最適化を整理したい方
- Training と Endpoint のコストの違いを理解したい方
- AWS の AI / ML 系資格を勉強している方
- SageMaker を実務で使うときのコスト感を知りたい方
- 精度だけでなく運用コストも意識したい方
🧩 まず結論：SageMaker のコストは「学習」と「推論」を分けて考える
SageMaker のコストを考えるときは、まず以下の2つに分けると分かりやすいです。
Training コスト = モデルを作るためのコスト
Inference コスト = モデルを使うためのコスト
もう少し整理すると、以下のようになります。
| 種類 | 代表例 | コストが発生する場面 |
|---|---|---|
| 学習コスト | Training Job、Tuning Job | モデルを学習するとき |
| 推論コスト | Endpoint、Batch Transform | 学習済みモデルで予測するとき |
| データ処理コスト | Processing Job、Data Wrangler | データ前処理や特徴量作成 |
| ストレージコスト | S3、Feature Store | データやモデルを保存するとき |
| 監視コスト | Model Monitor、CloudWatch | 本番運用を監視するとき |
まずは、
どこでコストが発生しているのか
を分けて考えることが大切です。
💰 ML ワークロードでコストが発生する主な場所
SageMaker を使う場合、コストはモデル学習だけではありません。
以下のようなポイントでコストが発生します。
| 項目 | 内容 |
|---|---|
| Training Job | 学習用インスタンスの利用時間 |
| Hyperparameter Tuning | 複数の Training Job の実行 |
| Processing Job | 前処理や評価処理の実行 |
| Endpoint | 推論用インスタンスの常時稼働 |
| Serverless Endpoint | リクエスト量や実行時間に応じた推論 |
| Batch Transform | 一括推論ジョブの実行 |
| S3 | 訓練データ、モデル成果物、推論結果の保存 |
| Feature Store | Online / Offline Store の利用 |
| Model Monitor | 監視処理やログ保存 |
| CloudWatch | ログやメトリクスの保存 |
特に注意したいのは、Endpoint は常時稼働になりやすい という点です。
Training Job は学習が終われば終了しますが、Endpoint は削除しない限り稼働し続ける構成になることがあります。
🏋️ Training コストとは？
Training コストは、
モデルを学習するために使うコンピューティングリソースのコスト です。
SageMaker Training Job では、指定したインスタンスタイプと実行時間に応じてコストが発生します。
一言で言うと、以下です。
Training コスト = インスタンス単価 × 学習時間
たとえば、大きなインスタンスを長時間使うと、当然コストは高くなります。
📌 Training コストを左右する要素
Training コストは、主に以下の要素で変わります。
| 要素 | 説明 |
|---|---|
| インスタンスタイプ | CPU / GPU / メモリ量によって単価が変わる |
| 学習時間 | 長く学習するほどコストが増える |
| データ量 | データが大きいほど処理時間が長くなりやすい |
| モデルの複雑さ | 大きなモデルほど計算量が増える |
| ハイパーパラメータチューニング | 複数の学習ジョブを実行するためコストが増える |
| 再学習頻度 | 頻繁に学習するとコストが増える |
Training コストを最適化するには、
単に安いインスタンスを選ぶだけでなく、学習時間や試行回数も意識する必要があります。
🧪 Training コスト最適化の考え方
Training コストを抑えるためには、以下のような方法があります。
| 方法 | 説明 |
|---|---|
| 適切なインスタンスを選ぶ | 必要以上に大きいインスタンスを使わない |
| 小さいデータで先に検証する | いきなり全データで試さない |
| 不要な特徴量を減らす | 学習時間やノイズを減らす |
| Early Stopping を使う | 改善しなくなったら学習を止める |
| チューニング回数を制限する | 探索範囲を広げすぎない |
| Spot Training を使う | 中断を許容できる学習でコストを抑える |
実務では、最初から大規模に学習するのではなく、
小さく試してから本番規模で実行することが重要です。
🎯 Hyperparameter Tuning のコスト
Hyperparameter Tuning は、モデル性能を改善するために有効です。
しかし、複数の Training Job を実行するため、コストが増えやすいです。
たとえば、1回の Training Job が 1,000円かかるとして、
50通りの設定を試すと、単純計算で 50,000円かかる可能性があります。
もちろん実際の料金は構成によりますが、考え方としては以下です。
Tuning コスト = Training Job のコスト × 試行回数
そのため、チューニングでは以下を意識します。
- 探索範囲を広げすぎない
- 重要なハイパーパラメータから試す
- 最大試行回数を設定する
- 早期終了を使う
- 小規模データで傾向を確認する
- Bayesian Optimization など効率的な探索を使う
チューニングは「たくさん試すこと」ではなく、
目的に合った設定を効率よく探すこと が重要です。
⚡ Spot Training とは？
Spot Training は、
SageMaker Managed Spot Training を使って、余剰キャパシティを利用し、Training コストを抑える方法 です。
一言で言うと、以下です。
Spot Training = 中断を許容できる Training を安く実行する方法
Spot Training は、通常のオンデマンドインスタンスよりコストを抑えられる可能性があります。
ただし、Spot は中断される可能性があるため、
すべての学習に向いているわけではありません。
✅ Spot Training が向いている場面
Spot Training は、以下のような場面に向いています。
| 場面 | 理由 |
|---|---|
| 学習が中断されても再開できる | Spot 中断に対応しやすい |
| コストを大きく抑えたい | 通常より安く実行できる可能性がある |
| 長時間の Training | 削減効果が大きくなりやすい |
| 実験や検証 | 本番緊急処理より柔軟に扱える |
| チェックポイントを保存できる | 中断後に再開しやすい |
特に、チェックポイントを保存できる学習処理では、Spot Training が使いやすくなります。
⚠️ Spot Training の注意点
Spot Training では、中断に備えることが重要です。
注意点は以下です。
| 注意点 | 説明 |
|---|---|
| 中断される可能性がある | 余剰キャパシティがなくなると止まる場合がある |
| チェックポイントが重要 | 途中経過を保存しておくと再開しやすい |
| 緊急性の高い処理には不向き | 必ず一定時間内に終わる保証は弱い |
| 再実行設計が必要 | 中断されても困らない設計にする |
試験では、
Training コストを削減したい
中断を許容できる
チェックポイントを保存できる
という文脈で Spot Training が候補になります。
🌐 Endpoint コストとは？
Endpoint コストは、
学習済みモデルをリアルタイム推論用にデプロイしている間に発生するコスト です。
Real-time Endpoint は、低レイテンシーで予測を返すために便利ですが、
構成によってはインスタンスが常時稼働します。
一言で言うと、以下です。
Endpoint コスト = 推論用リソースを起動している時間のコスト
Training Job は終われば停止しますが、Endpoint は消し忘れるとコストが続く点に注意が必要です。
📌 Endpoint コストを左右する要素
Endpoint コストは、主に以下で変わります。
| 要素 | 説明 |
|---|---|
| インスタンスタイプ | 大きいインスタンスほど高くなりやすい |
| インスタンス数 | 複数台にするとコストが増える |
| 稼働時間 | 起動している時間が長いほどコストが増える |
| Auto Scaling | 需要に応じて台数を調整できる |
| リクエスト数 | 負荷が増えるとリソースが必要になる |
| モデルサイズ | 大きなモデルほど高性能リソースが必要になりやすい |
Endpoint は本番サービスに直結しやすいため、
コストだけでなくレイテンシーや可用性も考える必要があります。
🔁 Auto Scaling とは？
Auto Scaling は、
リクエスト量や負荷に応じて推論用リソースを自動で増減する仕組み です。
一言で言うと、以下です。
Auto Scaling = 必要なときだけリソースを増やし、不要なときは減らす
たとえば、昼間はアクセスが多く、夜間は少ないサービスを考えます。
昼間：リクエストが多い → インスタンス数を増やす
夜間：リクエストが少ない → インスタンス数を減らす
このようにすることで、性能を保ちながら無駄なコストを抑えやすくなります。
✅ Auto Scaling が向いている場面
| 場面 | 理由 |
|---|---|
| リクエスト量が変動する | 負荷に合わせてリソースを調整できる |
| ピーク時だけ負荷が高い | 常に最大構成にしなくてよい |
| コストを抑えたい | 低負荷時にリソースを減らせる |
| 一定のレイテンシーを保ちたい | 負荷増加時にスケールできる |
ただし、Auto Scaling を設定していても、
スケールアウトには一定の時間がかかる場合があります。
そのため、急激なアクセス増加があるサービスでは、余裕を持った設計が必要です。
🧩 Serverless Endpoint とコスト
Serverless Endpoint は、
リクエスト頻度が少ない、または変動するリアルタイム推論に向いています。
Real-time Endpoint のように常時インスタンスを起動し続ける構成より、
アクセスが少ない場合にコスト効率がよくなる可能性があります。
一言で言うと、以下です。
Serverless Endpoint = 少量・不定期アクセスでコストを抑えやすい推論方式
ただし、Day 11 でも整理したように、コールドスタートには注意が必要です。
非常に低いレイテンシーが常に求められる場合は、
Real-time Endpoint の方が適していることがあります。
📦 Batch Transform とコスト
Batch Transform は、
大量データをまとめて推論するための仕組み です。
リアルタイム Endpoint のように常時稼働する必要はありません。
必要なときだけ Batch Transform Job を実行し、
処理が終わればリソースも終了します。
一言で言うと、以下です。
Batch Transform = まとめて処理し、常時稼働コストを避けやすい
たとえば、毎晩1回だけ全顧客のスコアを計算する場合、
Endpoint を常に起動しておくより Batch Transform の方が合うことがあります。
🧭 Endpoint と Batch Transform のコスト比較
| 観点 | Endpoint | Batch Transform |
|---|---|---|
| 実行形態 | 常時稼働しやすい | 必要なときだけジョブ実行 |
| 向いている場面 | 即時応答 | 一括処理 |
| コスト注意点 | 使っていない時間もコストが出る場合がある | 大量処理時の実行時間に注意 |
| 結果 | すぐ返す | S3 に保存 |
| 例 | Web API、ローン審査 | 夜間の顧客スコアリング |
覚え方は以下です。
リアルタイム性が必要 → Endpoint
まとめて処理でよい → Batch Transform
🧱 インスタンスタイプ選定
SageMaker では、用途に応じてインスタンスタイプを選ぶ必要があります。
大きすぎるインスタンスを選ぶとコストが無駄になります。
小さすぎるインスタンスを選ぶと、処理が遅くなったり、メモリ不足になったりします。
選定時の観点
| 観点 | 確認すること |
|---|---|
| CPU / GPU | GPU が本当に必要か |
| メモリ | データやモデルがメモリに収まるか |
| 学習時間 | 小さいインスタンスで遅すぎないか |
| 推論レイテンシー | 要求される応答時間を満たせるか |
| コスト | 過剰スペックになっていないか |
| スループット | 必要なリクエスト数を処理できるか |
特に、GPU は高価になりやすいため、
本当に GPU が必要な処理なのかを確認することが重要です。
🪣 ストレージコスト
ML ワークロードでは、S3 などのストレージにもコストが発生します。
保存対象には以下があります。
- 元データ
- 前処理済みデータ
- 特徴量データ
- モデル成果物
- 推論結果
- ログ
- 評価結果
- モニタリング結果
データを無期限に保存し続けると、ストレージコストが増え続けます。
対策
| 方法 | 説明 |
|---|---|
| 不要データを削除する | 使わなくなった中間ファイルを消す |
| ライフサイクルポリシーを使う | 古いデータを低コストストレージへ移動する |
| 保存期間を決める | ログや一時データを無期限にしない |
| 重複データを減らす | 同じデータを何度も保存しない |
特に、実験を繰り返すと中間ファイルやモデル成果物が増えやすいので注意が必要です。
📊 Monitoring コスト
Model Monitor や CloudWatch を使った監視も重要ですが、
ログやメトリクスを保存し続けるとコストが発生します。
もちろん、監視をしないのは危険です。
重要なのは、必要な監視を行いつつ、
不要なログや過剰な保存を避けることです。
| 観点 | 説明 |
|---|---|
| 監視頻度 | 必要以上に高頻度にしない |
| ログ保存期間 | 無期限保存にしない |
| メトリクス | 必要なものを選ぶ |
| アラート | 本当に対応が必要なものに絞る |
監視は「多ければ多いほどよい」ではなく、
運用上意味のある監視を設計することが大切です。
☁️ AWS 試験での見られ方
AWS の AI / ML 系試験では、コスト最適化は以下のような文脈で問われやすいです。
「Training コストを抑えたい」
この場合は、以下を考えます。
適切なインスタンスタイプ
Spot Training
Early Stopping
チューニング回数の制限
不要な特徴量の削減
「中断を許容できる学習を安く実行したい」
この場合は Spot Training が候補です。
Managed Spot Training
checkpoint
再開可能
「アクセスが少ないリアルタイム推論を安くしたい」
この場合は Serverless Endpoint が候補になります。
少量アクセス
不定期アクセス
常時稼働を避けたい
「大量データをまとめて推論したい」
この場合は Batch Transform が候補です。
夜間バッチ
一括予測
S3 入出力
「リクエスト量に応じて Endpoint の台数を調整したい」
この場合は Auto Scaling を考えます。
負荷に応じて増減
ピーク時にスケールアウト
低負荷時にスケールイン
👨💻 実務目線で見ると
実務では、ML のコスト最適化は単に「安くする」ことではありません。
本当に重要なのは、以下のバランスです。
必要な精度
必要なレイテンシー
必要な可用性
運用負荷
コスト
たとえば、非常に重要な本番 API では、多少コストが高くても Real-time Endpoint を安定稼働させる必要があるかもしれません。
一方で、毎晩1回だけ実行する予測処理であれば、Batch Transform の方が合理的です。
また、実験段階では大規模な GPU インスタンスを使う前に、
小さいデータや小さいインスタンスで試す方が安全です。
コスト最適化は、性能を犠牲にして安くすることではなく、
目的に対して過剰なリソースを使わないこと だと考えると分かりやすいです。
🧠 ここは特に覚えたいポイント
覚え方 1
Training コスト = モデルを作るためのコスト
Inference コスト = モデルを使うためのコスト
覚え方 2
Spot Training = 中断を許容できる Training を安く実行する方法
覚え方 3
Endpoint = 即時応答だが、常時稼働コストに注意
覚え方 4
Serverless Endpoint = 少量・不定期アクセス向け
覚え方 5
Batch Transform = 大量データをまとめて処理し、常時稼働を避けやすい
覚え方 6
Auto Scaling = リクエスト量に応じて Endpoint リソースを増減する
✅ まとめ
今回は、SageMaker のコスト最適化について整理しました。
重要なポイントは以下です。
- SageMaker のコストは、Training、Inference、Processing、Storage、Monitoring に分けて考える
- Training コストは、インスタンスタイプ、学習時間、データ量、チューニング回数に影響される
- Hyperparameter Tuning は有効だが、試行回数が増えるとコストも増える
- Spot Training は、中断を許容できる学習でコスト削減に役立つ
- Endpoint はリアルタイム推論に便利だが、常時稼働コストに注意が必要
- Serverless Endpoint は、少量・不定期アクセスの推論に向いている
- Batch Transform は、大量データをまとめて予測する場合に向いている
- Auto Scaling は、負荷に応じて Endpoint リソースを増減する仕組み
- インスタンスタイプは、性能とコストのバランスで選ぶ必要がある
- ストレージやログの保存期間もコストに影響する
ML ワークロードでは、精度だけでなく、
どの構成なら必要な性能を満たしながら無駄なコストを抑えられるか を考えることが重要です。
📌 シリーズまとめ
ここまでの 18 日間では、AWS の機械学習系資格や実務で重要になる内容を整理してきました。
- Day 1：機械学習の全体像
- Day 2：過学習・未学習・bias / variance
- Day 3：データ分割と cross validation
- Day 4：Confusion Matrix
- Day 5：accuracy / precision / recall
- Day 6：F1 Score
- Day 7：データ前処理
- Day 8：SageMaker の全体像
- Day 9：Data Wrangler と特徴量作成
- Day 10：Training とハイパーパラメータチューニング
- Day 11：SageMaker の推論方式
- Day 12：Model Monitor と Data Drift
- Day 13：Feature Store
- Day 14：SageMaker Pipelines と MLOps
- Day 15：Model Registry
- Day 16：SageMaker Clarify
- Day 17：ML ワークロードのセキュリティ
- Day 18：SageMaker のコスト最適化
このシリーズを通して、単にサービス名を覚えるのではなく、
どの場面で何を使うのか
なぜその評価指標を見るのか
モデルをどう学習・デプロイ・監視・改善するのか
安全性とコストをどう考えるのか
を整理してきました。
AWS の機械学習系資格では、個別サービスの知識だけでなく、
データ準備から学習、評価、デプロイ、監視、セキュリティ、コストまでを一連の流れで理解すること が重要です。
以上で、18 日間の AWS Machine Learning 学習メモシリーズを一区切りとします。