Google Cloudには開発した予測モデルをサーブする方法が複数あります。
そこで、サーブ方法の使い分けについてまとめます。
本記事でご紹介するサービスは、Google Cloud Professional Machine Learning Engineerの公式試験ガイドに含まれるので、試験勉強中の方の参考になれば幸いです。
予測モデルのサーブ方法4選まとめ
| No. | サービス名 | オンライン | バッチ | ストリーミング | 特徴 |
|---|---|---|---|---|---|
| 1 | VertexAI Endpoints | 〇 | - | - | 低レイテンシかつ同期的な予測実行 |
| 2 | VertexAI Batch Predictions | - | 〇 | - | 大量データをインプットとする非同期的な予測実行 |
| 3 | BigQuery ML (ML.PREDICT) | - | 〇 | - | BigQueryで保持しているデータを対象にSQL内の関数で予測実行 |
| 4 | Dataflow ML (RunInference) | - | 〇 | 〇 | Apache Beamの変換で予測実行 |
ユースケース別の使い分け
アプリケーション内で予測実行したい場合
ユーザーの画面入力値に応じた予測結果を画面表示したいケースなどです。
VertexAI Endpointsを利用します。
BigQuery MLでも予測実行対象を少量のデータに絞って利用することはできますが、VertexAI Endpointsのようにミリ秒レベルのレイテンシーは難しいと思います。
なお、VertexAI Endopointsはオンライン向けの予測モデルサーブ方法として手軽ですが、より厳密なコスト最適を目指す場合は汎用のコンピューティングサービス(CloudRunやGKE等)上に予測実行するアプリケーションをホストする方法もあります。
VertexAI Endpointsはインスタンス起動時間に対して課金されます。
また、ゼロスケールは2026/4/5時点でプレビューです。
アイドル時間が長いならリクエストベース課金のCloudRunの方がコストパフォーマンスは良いかもしれません。
大量データを対象にバッチで予測実行したい場合
販促キャンペーンを実施する際に効果的な見込み顧客を選別してメール送信したいケースなどです。
使い分けに対する私の考え方は以下の通りです。
- 開発者がSQLに習熟している → BigQuery ML
- 開発者がApache Beamに習熟している → Dataflow ML
- その他 → VertexAI Batch Predictions
BigQuery MLとDataflow MLはそれぞれの仕組みの中で予測実行できます。
これは、元々BigQueryやDataflow(Apache Beam)を利用していた開発者にとっては、学習コストをかなり抑えて導入できるメリットだと思います。
ストリーミングで予測実行したい場合
センサーから送信されるデータを元に故障検知し、リアルタイムにアラートしたいケースなどです。
上述の表のとおり、Dataflow MLを使います。
Pub/SubをDataflowでサブスクライブし、RunInference変換を用いて予測結果をデータに追加します。
ストリーミングで実行する場合は実現方法が限られます。
システム全体の中でごく一部の機能のみで利用したい場合、Dataflow MLを導入によって認知負荷が上がってしまう恐れがあります。
ストリーミングで予測実行したくなった時、バッチでの実現では何が問題になり得るかを検討することも有意義だと思います。
おわりに
Google Cloudで予測モデルをサーブするためのサービス4つをご紹介しました。
こうしてまとめてみると、サービスの特徴を踏まえて使い分けることが重要だと感じました。
これからどれを使おうか悩んでいる方の一助になれば幸いです。