Serverless Computing

サーバーレスコンピューティングは、イベントが発生したときだけプロバイダーがコードを実行し、基盤となるサーバーを自動的に起動・スケーリングし、トラフィックがなくなるとゼロまで縮退させ、予約済みマシンではなくリクエスト数と実行時間に応じて課金するクラウド実行モデルです。サーバー自体は存在しますが、開発者がサーバーをプロビジョニング、パッチ適用、またはサイズ設定する必要はありません。このモデルは、2014年11月に発表されたAWS Lambdaによって一般化し、現在ではLambda、Azure Functions、Cloud Run functionsなどの関数プラットフォームに加え、Google Cloud RunやAzure Container Appsなどのサーバーレスコンテナにも広がっています。カリフォルニア大学バークレー校の研究者は、2019年の論文「Cloud Programming Simplified: A Berkeley View on Serverless Computing」で、その長所と限界を説明しました。機械学習では、トラフィックが急増したり予測できなかったりするモデルサービングにサーバーレスが適しています。急増の合間にアイドル状態のGPUサーバーに課金されると、実際の処理コストを上回る可能性があるためです。

サーバーレス実行の仕組み#

コードは関数またはコンテナイメージとしてパッケージ化し、HTTPリクエスト、オブジェクトストレージへのファイル到着、キュー上のメッセージ、スケジュールなどのトリガーに関連付けます。イベントが到着し、利用可能なウォームインスタンスがあれば、プラットフォームはそのインスタンス上でハンドラーをただちに実行します。そうでなければコールドスタートが発生します。たとえば、AWSがLambda向けに開発したFirecracker microVMのような分離されたサンドボックスを作成し、コードを読み込み、言語ランタイムを起動してから、イベントを処理する前にハンドラー外の初期化コードを実行します。インスタンスはステートレスで破棄可能なため、リクエスト後も保持する必要があるものは、外部ストレージまたはデータベースに保存します。

コールドスタートと機械学習モデル#

初期化時にPyTorchなどのフレームワークをインポートし、数百メガバイトに及ぶこともあるモデルの重みを読み込むため、機械学習ではコールドスタートのコストが高くなります。一般的なパターンでは、インスタンスごとにモデルを一度だけ、ハンドラーの外または初回使用時に読み込み、ウォーム状態での呼び出しでは毎回そのモデルを再利用します。このハンドラーは、torchvisionのResNet-50分類器でそのパターンを実装しています。

import time

import torch
import torchvision

model = None  # module state survives between invocations while the instance stays warm


def handler(event, context):
    """Classify one image tensor, building the model only on a cold start."""
    global model
    cold_start = model is None
    if cold_start:
        model = torchvision.models.resnet50().eval()  # built once per instance
    with torch.inference_mode():
        logits = model(event["image"])
    return {"cold_start": cold_start, "class_id": int(logits.argmax())}


for _ in range(3):
    start = time.perf_counter()
    response = handler({"image": torch.rand(1, 3, 224, 224)}, context=None)
    print(response["cold_start"], f"{(time.perf_counter() - start) * 1000:.0f} ms")

Apple M5 Pro CPUでは、最初の呼び出しでネットワークを構築するため約0.2秒かかりますが、モデルを再利用する2回のウォーム呼び出しはそれぞれ約15 msです。チームは、小型のコンテナイメージ、コンパクトまたは量子化されたモデル、ONNX Runtimeなどの軽量ランタイムを使って、残るコールドスタートを短縮します。また、Lambdaのプロビジョニング済み同時実行数やCloud Runの最小インスタンスのように、ウォーム状態のインスタンスを一定数確保してコールドスタートをなくす方法もありますが、その場合は再びアイドル時間に対して課金されます。

AIワークロードにおけるサーバーレス#

サーバーレスは、イベント駆動型のコンピュータービジョンパイプラインに適しています。オブジェクトストレージへのアップロードをトリガーとして関数を実行し、データ前処理で画像を検証・リサイズしてからトレーニングデータセットに追加できます。セキュリティ警報システムでは、モーションセンサーが1枚のフレームを物体検出関数に送信し、人が検出された場合にだけ警告できます。後はプラットフォームの制限で決まります。AWS Lambdaは各呼び出しを最大15分、メモリを最大10,240 MBで実行でき、GPUはありません。コンパクトなモデルによるCPU推論には適していますが、長時間のトレーニングや、多数のGPUを使う分散トレーニングには対応できません。GPUサーバーレスによってこの制約は解消されつつあります。Cloud Runは、ゼロまでスケールできるコンテナにNVIDIA L4 GPUを接続し、ModalなどのプラットフォームはGPU使用時間を秒単位で課金します。

Ultralytics Platformは、YOLOのデプロイにも同じトレードオフを提供します。デフォルトサイズの1 vCPU、2 GiBのエンドポイントは無料で、アイドル時にはゼロまでスケーリングします。アイドル状態からの起動には約1分かかることがありますが、カスタムサイズではインスタンスを1つウォーム状態に保ち、その稼働時間に応じて課金されます。

サーバーレスと関連モデル#

• Infrastructure as a Service: リクエストの有無にかかわらず24時間稼働し、課金される仮想マシンです。OSとスケーリングは顧客が管理します。長時間のトレーニングジョブは通常ここで実行します。
• Kubernetes: チームが運用するクラスター上のコンテナをオーケストレーションします。Knativeはその上にリクエスト駆動型のゼロスケーリングを追加し、KServeはこれを使ってモデルをサービングします。
• エッジコンピューティング: データを生成するデバイス上またはその近くでコードを実行します。サーバーレスではクラウドリージョンでコードを実行しますが、一部のエッジプラットフォームは両者を組み合わせ、ユーザーの近くにある多数の小規模な拠点で関数を実行します。