推論ワークロードの時代　20年積み上げてきたAWSのビルディングブロックは通用するのか？

2025年12月25日 10時30分更新

コードを渡せばAWS上で動く　今でもLambdaはアイデアへの最短の近道

　続く話は再び2013年にさかのぼる。とあるAWSのエンジニアが思いついたのは、「開発者がAWSにコードを渡すだけで実行できるようになったらどうだろう？」というアイデアだ。サービスも、実行環境も、プロビジョニングも、スケールもない環境で、コードが動く。「このアイデアを思いついたのは、Amazon EC2以外のメンバーだ。サーバーを担当しているメンバーは、そもそもサーバーがなかったら、という思いつきはできない。目的はサーバーを簡単にするのではなく、体験からサーバーを完全に取り除くことだった」とブラウン氏は語る。

AWSにコードを渡すだけで動作する

　たとえば、Amazon S3で膨大に蓄積されていた画像のリサイズやクロップ、透かしの付与といった作業が発生する場合、今までユーザーはEC2インスタンスを立ち上げて、オブジェクトが到着するたびに同様の処理を行なわなければならなかった。しかし、Amazon S3のようなストレージ側に小さなコンピュートが存在し、一定のトリガを元に特定の関数を動かすことができれば、サーバーを構築・管理する手間はなくなる。

　こうした気づきから生まれたのが、サーバーレスサービスとして2014年に発表されたAWS Lambdaだ。「Lambdaが可用性、スケール、フリートなどをすべて処理できる。お客さまはコードを実行した分だけお支払いすればよくなった。Lambdaは単なる新しいサービスではなく、新しい考え方だった」とブラウン氏は指摘する。

　Lambdaはイベント駆動型処理、データ処理、リアルタイム処理などさまざまなワークロードで利用され、サービス自体も、より大きなランタイムの実行、コンテナやVPC対応、予測可能な性能オプションなど、どんどん強化された。「あれから10年経ったが、今でもLambdaはアイデアから本番に最速で到達する方法の1つだ」とブラウン氏は語る。

サーバーレスを問い直した「AWS Lambda Managed Instances」

　そして数年前、AWSはEC2インスタンスとサーバーレスの2つのチームを統合し、コンピュートサービス全体を1つのチームで担当するようになった。サーバーのチームとサーバーレスのチームが統合されたことで、チーム内では必然的に「サーバーレスとは？」という議論が沸き起こり、「サーバーレスのメリットをEC2インスタンス上で実現できないか」という課題に到達した。

　こうした課題から今回発表された新サービスが「AWS Lambda Managed Instances」になる。「サーバーレスのシンプルさとインフラコントロールを橋渡しする」を謳うAWS Lambda Managed Instancesは、ユーザーのEC2インスタンス上でLambdaを動作させることができ、インスタンスのプロビジョニング、スケーリング、パッチ適用、可用性などはすべてLambdaが実行する。「既存のLambda関数がそのまま動くので、再設計や運用負荷がない。EC2インスタンスの性能を活かしつつ、Lambdaの開発体験をそのまま活かすことができる」とブラウン氏はアピールした。

AWS Lambda Managed Instances

　EC2インスタンス上で動くAWS Lambda Managed Instancesでは、従来Lambdaでは難しかった動画や機械学習の前処理、高スループットの分析はインスタンス上で処理を行なえる。「これはサーバーレスの逸脱ではなく拡張だ。より多くの性能、拡張性、機能を運用負荷なしにもたらす重い作業を取り除き、開発者はコードとビジネスロジックに完全に集中できる」とブラウン氏は語る。

膨大に増える推論ワークロードへの最適化

　続いて、ブラウン氏が掲げたのは「AI ELASTICITY（AIの弾力性）」というキーワードだ。「ワークロードの種類が推論に変わった。この20年間培ってきた従来のコンピューティングと変わってきた」とブラウン氏は語る。今までクラウドがもたらしてきた弾力性とミスマッチが起こってきたわけだ。「需要が瞬時に急増し、失敗のコストが高い世界。一歩間違えると、コストは高く付いてしまう。でも、AWSに求められる柔軟性、効率性、応答性は必要になる」とブラウン氏は語る。

AI ELASTICITY（AIの弾力性）

　推論はなぜ難しいのか？　推論のワークロードは、入力されたプロンプトをモデルが理解できるようにする「トークン化（Tokenization）、プロンプト全体を維持しながら、モデルがコンテキストを理解できるようにキーバリューキャッシュを生成する「プリフィル（Prefill）」、キーバリューキャッシュを参照しながら、レスポンスを1トークンずつ生成する「デコード（Decode）」、トークンを人間のわかる自然言語に変換する「デトークン（Detokenization）の大きく4つから構成されている。

推論で重要な4つのプロセス

　これら推論のワークロードでは、CPU/GPU、メモリのボトルネック、遅延などを考慮しつつ、リクエストに応じて処理を行なわなければならない。リクエストもさまざまだ。サイズが大きかったり、小さかったり、レスポンス要求がシビアだったり、時間をかけられるものもある。リクエストに応じつつ、全体を最適化する点に課題がある。

　これに対して、AWSが当初行なっていたのは、Webサービスでも実績のあるロードバランシングの手法だが、推論に特化したインスタンスタイプの設計も行なった。Amazon Bedrockを支える推論エンジンである「Project Mantle」では、まず顧客のリクエストを遅延要求に応じて3レベルの優先順位を付け、要求に応じたリソース配分を行なった。

　また、顧客ごとのリクエストを専用キューに割り当て、公平性を保つようにした。「Bedrockは通常の利用パターンを学習し、必要なキャパシティを予測して、利用可能な状態を確保している」とブラウン氏は語る。レイテンシは一貫し、スループットは増加し、利用効率は向上し、システムはレジリエンスのあるものになるという。

　もう1つ重要だったのが、全体処理の永続的な記録だ。AWSではDynamoDBやS3などで実績の高いジャーナルシステムを用い、Amazon Bedrockにおいてもリクエストを継続的に記録する。長時間利用される推論ワークロードの一貫性を保ち、さまざまな障害で処理の中断しても、中断時点からワークロードを再開できる。計算量の多いファインチューニングにおいて、障害が起こっても、効率的で安定した処理を行なえる。

推論ワークロードにもセキュリティやオブザバビリティを

　推論ワークロードにおいても、セキュリティやプライバシー対応のレベルも一層強化している。ハードウェアレベルで顧客ごとの機密性を保つNitro Systemにより、推論中のデータも暗号化され、AWSのオペレーターもデータにアクセスできない。「お客さまは実証済みで安全な場所で推論ワークロードを動かすことに対する暗号学的な保証が得られる」とブラウン氏は語る。

推論ワークロードでもセキュリティは保たれる

　AIプラットフォームのAmazon Bedrock自体も強化されている。モデルからLambda関数の呼び出しがサポートされ、長時間ジョブのためにOpenAIのレスポンスAPIにも対応する。また、IAMやアクセス管理を用いた権限管理、Cloud Watchによるオブザバビリティの利用も可能になった。

　「Amazon Bedrockは20年近く巨大なサービスを運営してきた経験してきた学びを反映している。推論というのは新しいタイプのコンピュートだ。独自のスケーリング、制約、要件がある。Amazon Bedrockはこうしたワークロードを信頼性、効率性、安全性を持って利用できる環境を提供する」とブラウン氏は語る。

　推論ワークロードに向けた技術的な取り組みをを披露したブラウン氏。「すべてのAPIリクエストにスケジューリング、公平性、レジリエンス、パフォーマンスに特化した高度なエンジンがある。お客さまはただ構築に集中できる。これこそAWSの仕事だ」と語り、デサントス氏にマイクを戻した。

この記事をシェアしよう