re:Invent 2024: Amazon EKSで高性能生成AIを実現 - ELIとVannevar Labsの事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - High-performance generative AI on Amazon EKS (KUB314)
この動画では、Amazon EKSで生成AIのワークロードを実行する方法について詳しく解説しています。Amazon EKSがGenerative AIの実行に適している理由として、スケーラビリティ、コスト最適化、柔軟なカスタマイズ性が挙げられ、特にKarpenterを活用した効率的なリソース管理の方法が紹介されています。また、Eli Lilly and Companyから招かれたCasimir Starslak IIIが、EKS上に構築したMLプラットフォーム「CATS」の事例を共有し、500人以上のDeveloperが利用し月間数十億トークンを処理する規模にまで成長した経緯と、45%のコスト削減を実現したVannevar Labsの事例など、具体的な成功例も紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
生成AIの現状と本番環境への移行課題
おはようございます。Cube 314へようこそ。本日は、Amazon EKSで生成AIのワークロードを実行する方法についてお話しします。この数日間、多くの方がキーノートに参加されたと思います。Peterのキーノートは月曜日の夜、つまり昨日でしたね。そして今まさに、Machine Learningのキーノートが行われています。このセッションにお越しいただき、ありがとうございます。
これらのキーノートでは、Machine Learningや生成AIの新機能について多く語られています。トレーニング用のGraviton、Ultra サーバーなど、素晴らしい機能が次々と登場しています。しかし、この会場にいらっしゃる皆さんの多くは「それは素晴らしいけれど、Amazon EKSで動作しなければ使えない」とお考えではないでしょうか。実際、最大規模のFoundation Modelの多くは、Kubernetesで学習されています。そこで今日は、Amazon EKSが生成AI、そして実質的にあらゆるMachine Learningワークロードの実行をいかに容易にしているかについてお話しします。本日は、MLワークロードにおいてAmazon EKSとKubernetesが優れた選択肢となった理由についてお話しいただくRama Ponnuswamiさん、そして特別ゲストとして、Eli Lilly and Companyから、Amazon EKS上にMachine Learningプラットフォームを構築し、成功を収めた経験についてお話しいただくCasimir Starslak IIIさんをお迎えしています。
まず、生成AIについて簡単にご説明させていただきます。生成AIとは、人間が作成したかのような内容を生成できるAIのことです。多くの場合、人間が作成したものと区別がつかないほどです。これは、数千億のパラメータを持つFoundation Modelによって実現されており、来年までには1兆パラメータに近づくと予想されています。生成AIの真のイノベーションは、MLアプリケーションの開発時間を短縮できる点にあります。巨大なFoundation Modelを起点として、特定のタスクに必要な調整を行うための少量のトレーニングだけで済むようになったのです。
ユースケースについては、主に4つの大きなカテゴリーが見られます。最もなじみ深いのは、カスタマーエクスペリエンスの向上です。昨日、Andyが登壇して、amazon.comでのショッピングをサポートする新しいエージェント「Rufus」について話していました。次に従業員の生産性向上があります。昨日は、コード移行ツールについていくつか発表がありました。AmazonではJava 11からJava 17への移行で、多くの開発者の時間を節約できました。また、Windowsのモダナイゼーションコード移行についても発表しました。コンテンツ生成、画像生成、ビデオ生成も魅力的です。さらに興味深いのはビジネスオペレーションです。この数日間、多くのお客様とミーティングを行いましたが、皆さんの多くが、より迅速なトラブルシューティングのためのログ分析や、開発者のオンボーディングの効率化など、すでにプラットフォームに生成AIを活用されています。
私たちが観察しているトレンドには、より複雑な生成AIワークフロー、エージェント同士の対話、そして本番環境のモデルにおけるガードレールなどの機能要件が含まれます。最後のポイントが最も興味深いのですが、AWSには多くの異なるツールがあります。昨日は特にBedrockについて多く語られました。Amazon Q、そして異なるレイヤーのスタックがあります。Amazon EKSはそのスタックの下層に位置し、最大の柔軟性、カスタマイズ性、そして最高レベルのスケーラビリティを必要とする場合に使用します。大規模な企業では、Amazon EKS、Bedrock、Q、その他のツールを組み合わせて使用することになるでしょう。
2023年が生成系AIのProof of ConceptやPOCの年だったとすれば、2024年は本番環境への移行の年となっています。本番環境へのマインドセットの移行には、異なる考え方が必要です。収益を上げるか、コストを削減する方法を考え始める必要があります - POCを永遠に続けることはできません。大規模な推論のコストや、レイテンシーについて考える必要があります。最高のパフォーマンスを発揮するモデルを選ぶのではなく、本番環境での運用コスト、レイテンシー、そしてユーザー体験への影響とのバランスを取る必要があります。本番環境への移行時には、セキュリティ、コンプライアンス、倫理的な制約についても考慮する必要があります。これが今年見え始めているトレンドです。
生成AIの課題とAmazon EKSによる解決策
ここで、生成系AIの課題とAmazon EKSがそれらをどのように解決するかについて、Ramaに説明を譲りたいと思います。ありがとう、Mike。皆さん、おはようございます。私はRama Ponnuswamiで、Amazon EKS上のAMLのワールドワイドGo-to-Marketを担当しています。 本番環境でワークロードをスケールし始める際に、お客様が直面する一般的な課題について、3つの観点からお話ししたいと思います。Mikeが言及したように、組織内の異なるチームには異なるニーズがあります。
1つのモデルですべてのニーズを満たすことはできません。おそらく、異なるチームの特定のニーズに合わせて、複数のモデルをカスタマイズして実行する必要があります。これには運用面での課題が伴います：モデルのバージョン管理をどうするか、新しいモデルが登場した際のアップグレード方法、モデルに対するガードレールの構築方法、そしてモデルのデータアクセス管理をどうするかといった課題です。
これらのモデルのカスタマイズは簡単ではありません。カスタマイズには、ドメイン固有の厳選されたデータが必要で、そのデータは特定のユースケースに適合し、そのドメインに特化したタスクをモデルが実行できるようにする必要があります。これは、複数のデータソースの統合が必要であり、データセキュリティ要件を維持しながら、すべてのデータへのアクセスを管理する必要があることを意味します。
最後に、これらすべてが意味するのは、大規模なインフラストラクチャの管理が必要になり、それがより複雑になるということです。多くのお客様が、本番環境で重要な規模に達し始めると、インフラストラクチャの制御をより多く委譲することで、これらのパラメータの制御能力が低下すると感じ始めることを私たちは目にしています。本番ワークロードで重要な規模に達したお客様は、インフラストラクチャに対するより多くの制御を求め、Amazon EKSのようなオプションを検討し始めます。これにより、すべてのモデルとML環境をカスタマイズし、ROI目標を達成するためのコスト最適化を行うために必要な制御を得ることができます。
では、組織レベルでの課題についてお話ししました。次に、Data ScientistやML Engineerが日々の業務で直面する課題について考えてみましょう。 Data Scientistは、インフラの管理に時間を費やしたくないものです。彼らが本当に必要としているのは、すぐに利用できるインフラで、そこにコードを書いてモデルをデプロイし、スケールできるものです。また、MLモデルのライフサイクルを管理するためのボイラープレートコードやスクリプトの作成に時間を取られたくありません。代わりに、これらの機能が全て備わった、すぐに使えるプラットフォームを求めています。彼らは、モデルの構築とスケーリングが必要になるたびに、個別のアドホックな方法で構築するのではなく、繰り返し使える最適化された方法でこれらの要件を満たしたいと考えています。
まとめますと、 本番環境でGenerative AIをデプロイする際の主な課題や考慮点は、3つの観点があります。1つ目は、スピーディーな展開です。Data ScientistやML Engineerが素早くモデルを構築し、デプロイし、スケールアップできるようにする必要があります。2つ目は、モデルのカスタマイズをスケーラブルに実現する方法です。組織内の異なるチームの特定のユースケースに合わせて、複数のモデルをカスタマイズできるようにする必要があります。3つ目は、これらのモデルが現在の需要だけでなく、将来の需要にもシームレスに対応できるスケーラビリティを確保すること、そして規模が拡大していく中でコストを継続的に最適化できるようにすることです。
Amazon EKSの利点と顧客事例
ここで多くのお客様が、Amazon EKSが非常に有効だと感じている理由があります。特に、データセキュリティの懸念やコスト最適化の課題に対応するためにインフラストラクチャをより細かくコントロールする必要がある環境において、ROIの目標を達成する必要があるからです。 では、Amazon EKSがどのようなメリットを提供し、なぜ多くのお客様がGenerative AIワークロードのデプロイにEKSを活用し始めているのか、詳しく見ていきましょう。これも先ほどの観点に沿って説明します。まず、EKSによってより迅速な展開が可能になる理由は2つあります。1つ目は、多くの場合、お客様がすでにKubernetesをアプリケーション開発の標準として採用しており、MLワークロードにも必要な基盤機能をすでに構築しているため、その既存のプラットフォームを拡張してMLモデルをデプロイできることです。2つ目は、オープンソースツールの利用可能性です。ML分野は一般的に進化が速く、多くのイノベーションがオープンソースの領域で起きています。これらのオープンソースツールは通常、Kubernetesとの統合機能が最初から備わっているため、EKSを使用することで、お客様はこれらのML特化のソリューションを簡単に統合し、必要なツールを全てData Scientistに提供することで、より迅速な開発を実現できます。
スケーラビリティの面では、Amazon EKSはAWSのML関連インフラストラクチャサービスとネイティブに統合されており、MLモデルの需要が増加しても、シームレスにスケールを継続できます。カスタマイズについては、EKSでインスタンスレベルまでのインフラ全体を制御できるため、EKS内のML環境の設定方法に制限されることなく、特定のニーズに合わせて柔軟に環境を構成できます。また、インスタンスの選択肢が多いため、MLワークロードのスケールに応じて、適切なインフラのサイジングとインスタンスを選択し、コストを継続的に最適化することができます。
EKS上でのMLにおける柔軟性とコスト最適化が、3つのレイヤーでどのように機能するのか、さらに詳しく見ていきましょう。1つ目はインスタンスレベルです。EKSは全てのEC2インスタンス、NVIDIAベースのGPUインスタンス、AWS Trainium、AWS Inferentia、Intelベースのインスタンスなどをサポートしています。AWSで利用可能な全てのEC2インスタンスをEKSで活用でき、ワークロードの要件に基づいて使用するインスタンスを柔軟に選択できます。しかし、これだけでは十分ではありません。新しいワークロードがスケジューリングされるたびに、手動でこれらの選択を行いたくはないでしょう。ここで重要な役割を果たすのがKarpenterです。
Karpenterを使用することで、特定のインスタンスのプロビジョニングに関するパラメータを提供し、ワークロードに応じて適切なインスタンスを選択するという、これらすべての選択を効果的に自動化することができます。KarpenterはEKS最適化AMIと共に、需要が増加した際に迅速にインスタンスを起動するために必要なすべての依存関係を備えています。Karpenterは高速なスケーリングを提供し、重要なことに、需要が減少した際にはコスト最適化のためにスケールダウンします。また、GPUの共有メカニズムを活用でき、EKSの組み込みマルチテナンシー機能により、限られたGPUリソースを複数のチーム間で安全に共有し、GPU使用率を向上させることができます。さらに、オープンソースのMLソリューションを統合し、組織内で必要な特定の機能に適したツールを選択してEKSと統合することができます。
EKS上でGenerative AIを実行している顧客をいくつかご紹介したいと思います。Vannevar Labsは、国家情報機関や国防省に非従来型の情報を提供するテクノロジースタートアップです。最高レベルの機密性とデータセキュリティが求められる環境で、彼らはEKS、Ray、Karpenterを組み合わせて使用することで、推論コストを45%削減することができました。これは、CPUとGPUの混合インスタンスタイプを使用し、GPUインスタンス内の未使用のCPUリソースを活用してCPU負荷の高いワークロードをスケジューリングすることで達成されました。彼らの具体的な設定については、最近AWSコンテナブログチャンネルで詳細な記事を公開しています。
Informaticaは、EKS上で複数のLLMモデルのトレーニングと微調整を行うLLMOpsプラットフォームを構築した別の顧客です。彼らは以前使用していたマネージドサービスと比較して約30%のコスト削減を達成しました。さらに、マネージドサービスのカスタマイズ制限に縛られなくなったことで、設定の柔軟性も向上しました。
Zoomは、マルチモーダルホスティングを行う同様のプラットフォームを作成し、継続的な需要に対して信頼性高く効率的にスケールすることができている別の顧客です。
もう一つ重要な顧客として、Hugging Faceをご紹介したいと思います。Hugging Face Hubを使用したことがある方は、プレミアム価格版でも無料版でも、現在はすべてEKS上で動作していることをご存知でしょうか。彼らがこのプラットフォームを構築する際に直面した課題は、専用の推論エンドポイントを持つ何百万ものモデルの推論を可能にし、さらに多くの異なるドメイン名もホストする必要があるシステムを作ることでした。これらすべてを無料枠の価格で提供する必要があったため、プレミアム価格帯としても提供できるようにインフラコストを徹底的に最適化しなければなりませんでした。彼らが実装したソリューションは、2000以上のノードを持つ複数のEKSクラスター上にデプロイし、より少ないインスタンス内に多くのパーツを効果的にビンパッキングすることでした。また、数秒ごとにモデルを入れ替えるGPUのタイムシェアリングも活用しています。これにより、MLデベロッパーが協力して作業できるプラットフォームを世界中で効果的に提供することができています。
EKSの機能強化とMLワークロード最適化
先ほど、Kubernetesをアプリケーション開発の標準プラットフォームとして既に採用しているお客様について触れました。これは、そうしたプラットフォームの概要を示したものです。これらのプラットフォームには、ロギング、モニタリング、災害復旧、大規模なセキュリティなど、基盤となる機能がすべて組み込まれており、これらの課題はすでに解決済みです。MLに関して、お客様は再びこれらの課題を解決したり、一からやり直したりすることを望んでいません。むしろ、これらの基盤機能をそのまま活用し、その上でMLワークロードを実行できるように拡張したいと考えています。これが一つ目の大きな利点です。二つ目の利点は、お客様がオンプレミス、エッジ、クラウドなど、すべての環境でKubernetesを標準レイヤーとして使用できることです。Kubernetesを使用することで、これらの運用を統合することができます。最近のリリースにご注目いただいている方なら、先週日曜日にEKS Hybrid Nodesをリリースし、これによってお客様の利用がさらに容易になったことをご存知でしょう。EKS Hybrid Nodesを使用すると、クラウド、オンプレミス、エッジのノードを単一のEKSマネージドコントロールプレーンに接続でき、コントロールプレーンの管理をすべてオフロードできます。これにより、すべての環境にわたるインフラストラクチャの論理的なマッピングが得られ、利用可能なGPUリソースをより効率的に活用し、コストを最適化することができます。コストとROIのメリットに基づいて、どのワークロードをどの環境にデプロイするかを選択できます。
お客様がこれらのプラットフォームを拡張しようとする際に見られる傾向として、その上にOSSソリューションを統合することが挙げられます。これにより、Kubernetesはインフラストラクチャのオーケストレーションという得意分野に専念し、ML固有の機能はOSSソリューションが提供するという形になります。例えば、多くのお客様がEKSにVLLMを組み合わせて使用しているケースがあります。これにより、メモリとモデルの最適化、マルチモデル管理、リクエストのバッチ処理、推論インフラのキューイングなどの機能が提供されます。これによって、データサイエンティストがモデルをデプロイするだけで推論を実行できるエンドポイントや推論スタックをすぐに利用できるようになります。
これらをまとめますと、お客様がGenerative AIにEKSを使用することで得られるメリットは、環境をより細かくコントロールできること、特定のニーズに合わせてカスタマイズできること、将来の需要に応じてシームレスにスケールできること、そしてROIの目標を達成するために継続的にコストを最適化できることです。ここで、EKSが提供する具体的な機能についてMikeに説明を譲りたいと思います。
まず、これはRamaが先ほど説明した利用可能なツールについて、より具体的に示した図です。主に2つの部分があります：オープンソーススタックとKubernetesです。RamaはRay、VLLM、JupyterHubについて触れましたが、これらのツールはすべてKubernetesで動作します。これは、私たちAmazonがよく話題にするフライホイール効果そのものです。新しい機械学習ツールを提供しようとする際、素晴らしいアイデアがあれば、最初のデプロイメントターゲットの一つとしてKubernetesで確実に動作するようにすることが非常に重要です。これらのフレームワークやツールの多くは、まさにそのように、Kubernetesで優れた動作を実現しています。私たちは特定のツールにコントリビュートすることを選択しており、例えばRayについては、Neuronフレームワークとうまく連携するようにコントリビューションを行っています。
もう一方では、Amazon EKSがあります。私たちは、この大規模なトレーニングと推論を支えるAWSのインフラストラクチャのイノベーションとサービスがEKSでうまく機能するようにしています。CSIドライバー、Amazon Elastic Container Registry (ECR)、そしてMLワークロードで必要となる多くの基盤サービスが、EKSで最適に動作するよう確保しています。
Control Planeのスケーラビリティに関する私たちの取り組みは、十分に評価されていないと感じています。EKSのパフォーマンスが向上しても、「新機能のお知らせ」のような投稿はあまり行いません。しかし、サービス開始から6年前にEKSクラスターを作成し、バージョン1.10から1.30まで継続的にアップグレードしてきたお客様がいることを私は確実に知っています。これらのクラスターは、6年前に作られた当時とは全く異なる姿になっています。EKSクラスターを作成するたびに、EC2インスタンス、ネットワークゲートウェイ、Network Load Balancerなど、専用のインフラストラクチャを構築しています。新しいインスタンスタイプ、より高速なボリューム、より優れたネットワーキングなど、パフォーマンスを継続的に向上させるための取り組みを数多く行っています。
今年、私たちが重点的に取り組んでいるプロジェクトの1つが、より大規模なスケールを実現するためのetcdの管理方法の変更です。10,000から70,000ノードのクラスターを求めるお客様もいます。これを実現するために、Kubernetesのバックエンドデータベースであるetcdの管理方法を大幅に見直す必要がありました。この詳細については、来年さらに多くの情報を公開する予定です。
EKSにおけるInferenceワークロードの最適化
Elastic Fabric Adapter（EFA）は、AWSにおける低レベルのインフラストラクチャ革新の一例です。これはOSをバイパスするハードウェアインターフェースで、ノード間の高度な通信を可能にします。私たちはDevice Pluginを通じて、EKSとKubernetesで簡単に使えるようにしています。最近の注目すべき機能強化として、EFAがサブネット間通信のサポートを追加しました。以前はEFAで単一のサブネットに制限されていましたが、現在は同じAvailability Zone内でサブネット間の通信が可能になっています。AZ間でのトレーニングはコストがかかるため避けたいところですが、この機能によりIPアドレスの枯渇問題に対処できます。
IPアドレスの枯渇に役立つもう1つの機能は、MLトレーニングワークロードに関連するものです。これらのワークロードは多くの場合、単に計算処理を行うだけで、インターネットとの通信は必要なく、クラスター内の他のノードとの通信だけが必要です。最近、EFAのみのENIサポートを追加し、クラスター内のEFAデバイスに実際のIPアドレスを追加する必要がなくなりました。これは現在EKSでサポートされています。
大規模なトレーニングジョブを実行する際には、処理するすべてのデータを扱える大規模なストレージバックエンドが必要です。世界で最も大規模なストレージバックエンドと言えば、おそらくAmazon S3でしょう。S3は昨年、Mountpointというテクノロジーをオープンソース化しました。これにより、S3バケットをEC2インスタンスにマウントし、ファイルシステムコマンドを使用してS3オブジェクトコマンドに自動的に変換することができます。私たちはCSI Driverという Kubernetesネイティブなインターフェースを通じて、これをEKSで簡単に使えるようにしています。最近の注目すべき機能強化として、CSI Driverがより細かなアクセス制御を追加し、クラスター内のどのトレーニングPodがどのバケットにアクセスできるかを制限できるようになりました。
Generative AI のトレーニングとInferenceは安価ではありません。これらのインスタンスは需要が高く、標準的なCPUインスタンスよりもコストがかかります。AWSは過去5年間にわたり、価格性能の向上とコスト削減に向けて広範な取り組みを行ってきました。AWS InferentiaとAWS Trainium - 昨日もTrainium 2を発表したばかりですが - これからも私たちはシリコンレベルでの革新を続け、トレーニングワークロードに最高の価格性能比を提供していきます。これらは素晴らしい技術ですが、この会場にいる皆さんにとっては、EKSで動作しなければ意味がありません。
ここ数ヶ月で、私たちは Amazon Linux 2023（Amazonの最新の汎用Linuxディストリビューション）とBottlerocket（コンテナ最適化オペレーティングシステム）の両方に対応した高速化AMIを導入しました。
これらは、Self-managed Node GroupsやKarpenter管理グループなど、さまざまなEKSのコンピューティングオプションで動作します。ここで見落とされがちなのが、私たちが舞台裏で行っているテストです。ドライバー、フレームワーク、ライブラリ、CUDAツールキットなど、AMIに組み込まれるすべてのコンポーネントは複雑で、急速に変化しています。そのため、これらのAMIをリリースする前に、洗練されたテストフレームワークでトレーニングジョブやInferenceジョブを実行しています。これにより、皆さんは特にトレーニングワークロードに関して、AMIを使用して確実に動作させることができます。
最近はKarpenterについてよく話題に上がりますが、Managed Node Groupsは5年前のre:Inventで発表した最初のマネージドコンピューティング製品です。トレーニングワークロードは多くの場合動的ではないため、Managed Node Groupsは実はトレーニングワークロードに適しています。トレーニングジョブを実行するために必要な大規模な静的キャパシティプールがあれば十分で、頻繁に増減する必要はありません。EC2は数ヶ月前にCapacity Block Reservationsという機能をリリースしました。これらのインスタンスタイプは需要が高いため、Capacity Blocksはホテルの予約システムのようなものですが、EC2インスタンス向けです。最大8週間前からGPUのキャパシティを予約でき、指定した時間に確実に利用できます。最近では予約期間の延長も可能になり、これがManaged Node Groupsでネイティブに動作するようになりました。特にトレーニングワークロードにとって、これは素晴らしい機能強化だと考えています。
GPUインスタンスは、CPUインスタンスよりも故障する頻度が高い傾向にあります。複雑な数学的計算を実行しているためです。EC2チームはデータセンターレベルでパフォーマンスを向上させるための広範な取り組みを行っています。例えば、データセンターの湿度を1%変更するだけでGPUインスタンスの寿命を10%延ばすことができますが、それでも時々故障することがあります。今年は、クラスター内で不具合が発生したインスタンスが実際の作業を行わないまま無駄にお金を消費することがないよう、そうした故障を検出することに多くの努力を注いできました。この機能は先週、EKS Auto Modeでリリースされ、今後1〜2週間で他のコンピューティングオプションにも展開される予定です。
主に2つのパートから構成されています。1つ目は、クラスター内でDaemon Setとして実行されるノードヘルスモニタリングエージェントで、あらゆる種類の問題を監視します。私たちは6年間にわたって多数のクラスターを運用してきた経験があり、ノードが故障する可能性のあるあらゆるケースを見てきました。その知見を活かして、特にGPUインスタンスに焦点を当てたノードヘルスモニタリング修復エージェントを構築しました。自動修復の面では、Managed Node Groupsが自動修復機能を備えることになり、EKSに問題を検知させることを選択できます。故障の種類に応じて、インスタンスの再作成が必要な場合もあれば、再起動で済む場合もあります。この機能はまもなくリリースされる予定です。
昨年のre:Inventで、CloudWatch Container Insightsのバージョン2をリリースしました。これは、バージョン1と比べて格段に優れています。数年前にバージョン1を試された方なら、その課題をご存知かもしれません。新しいバージョンのContainer Insightsは非常に使いやすく、コンテナワークロードに対してよりコスト効率が高くなっています。EKSクラスター内でエージェントとして実行するContainer Insightsプラグインの最近の改良点として、NVIDIAとNeuronインスタンスタイプの両方のモニタリングプラグインが自動的に含まれるようになりました。これらのメトリクスを収集してCloudWatchに送信し、GPUリソースの使用効率を監視したり、ワークロードの実行状況を理解したり、ハイパーパラメータのチューニング方法を把握したりすることができます。チームは、シンプルですぐに使えるGPUとNVIDIAのモニタリング機能を提供するために多くの努力を重ねました。まだご覧になっていない方は、ぜひチェックしてみることをお勧めします。
EKS Auto ModeとKarpenterによる推論の効率化
推論について具体的にお話ししたいと思います。冒頭で2024年は本番環境の年になると申し上げましたが、本番環境とは一般的に、顧客にリクエストを提供するライブワークロードがある場合、推論を意味します。 大規模言語モデルのスケールでの推論は複雑になる可能性があります。コスト効率が良く、レイテンシー、スループット、可用性の面で望ましいパフォーマンスを持つモデルをどのように提供すればよいのでしょうか？これらはすべて、スケールでの推論を実行する際の懸念事項となります。 EKSでの推論に関する私たちの考え方は、この3つの指標に基づいています：モデルが提供する1秒あたりのトークン数を示すスループット、最初のトークンまでの時間を示すレイテンシー、そしてGPUの計算使用率を示すコストです。
左側にこれらの指標の視覚的な表現があります。私たちが構築している多くの機能やフレームワークの改良は、スループット、レイテンシー、コストのトレードオフを達成するのに役立つように設計されています。完璧な答えは決して存在しませんが、私たちはお客様自身がそのトレードオフを簡単に行えるようなツールを提供したいと考えています。
ゼロへのスケーリング、迅速なスケールアップ、MLコンテナイメージの最適化は、containerdプロジェクトで私たちが取り組んでいる分野です。MLイメージは多くの場合、数十ギガバイト、時には数百ギガバイトにもなり、インスタンスを起動する際に、コストがかかっている状態でイメージのダウンロードを15分も待つのは望ましくありません。そのため、この高速化に向けて多くの取り組みを行ってきました。先ほどハードウェア障害の最小化についてお話ししましたが、これらの一般的なフレームワークがAmazon EKS上でうまく動作するよう、オープンソース分野でも多くの貢献を行っています。
その話題に関して言えば、 RayとVLLMという2つのプロジェクトは、ここ2日間の顧客との会話でも、本番環境でのInferenceワークロードの実行に使用されているものとして、他のどのプロジェクトよりも頻繁に言及されています。Device Plugin、EFA、NVIDIA、Neuronアクセラレーテッドドライバーなどを使用することは、EKSでInferenceを行う際に私たちが顧客の間でよく目にするインフラストラクチャスタックとなっています。
先ほどManaged Node Groupsがトレーニングに適していると申し上げましたが、Inferenceはより動的なワークロードであり、Karpenterは本当にそれに適したツールです。Karpenterを使用すると、EC2インスタンスタイプの幅広さと深さを簡単に活用できます。場合によっては、GPUインスタンスを使用する必要がなく、Inferenceに Gravitonインスタンスを使用したいこともあるでしょう。一般的に、Inferenceワークロードにおいて、私たちは多くの顧客がKarpenterで成功を収めているのを目にしています。
最新情報として、ここ数日の間に発表があったのをご覧になった方もいるかもしれませんが、Auto Modeと呼ばれる機能を導入しました。Auto Modeの一部として、Karpenterを EKSに統合し、より使いやすくしています。 Auto Modeは、EKSデータプレーン、つまりクラスターで通常必要となるコンピューティング、ストレージ、ネットワーキングに関する新しい簡単設定ボタンと言えます。これは現在、EKSにデフォルトで含まれており、Karpenterの観点から特にこのプレゼンテーションで取り上げています。 Karpenterは Inferenceに適しており、現在はデフォルトで組み込まれています。右側の3つの特徴、つまりコンピューティングの最適化、コスト効率、多様なワークロードのサポートは、まさにKarpenterに組み込まれている機能です。
まだ他のプレゼンテーションをご覧になっていない方のために説明しますと、Auto Modeで私たちが行った興味深いイノベーションは、この新しい運用モデルです。これまでAWSでコンピューティングを実行する方法は2つありました。1つはAWS所有のアカウントでコンピューティングが実行される完全マネージド型のLambda Fargateモデル、もう1つは標準的な自己所有のEC2でした。この新しいマネージドインスタンスモデルは、その中間に位置するものです。つまり、お客様のアカウント内のEC2インスタンスではありますが、EKSなどのAWSサービスがそのインスタンスのライフサイクルを所有します。インスタンスを削除しようとすると、「サービスによって使用中」というエラーが表示され、EKSを通じて操作する必要があります。
これを取り上げる理由は、 特に機能面において、EKSでの機械学習ワークロードを始める際の難しい部分の多く、例えば適切なデバイスドライバーの設定、EFAプラグイン、インスタンスストレージの設定などが、現在ではEKS Auto Modeで完全に自動化されているからです。以前は、ローカルディスクインスタンスを持つ顧客は、インスタンス上にRAID zeroボリュームを設定するために非常に複雑なユーザーデータスクリプトを作成する必要がありました。現在では、私たちが自動的にzeroを設定し、NVIDIAやNeuronなどのDevice Pluginを自動的に設定し、そのインスタンスに適したAMIを既に含めています。トレーニングワークロードについて考える必要のある作業が大幅に減りました。Auto Modeが完全に適していると言い切るのはまだ早いでしょう。インスタンスの最大存続期間が21日という制限があり、場合によっては数ヶ月続くトレーニングジョブを実行している顧客と話すことも多いからです。しかし、Inferenceワークロードや本番環境でのモデル実行には、Auto Modeが適していると考えています。
これは、ここ2日間の顧客との会話で検証された、よく見かける一般的なスタックの例です。 Ray VLLMとKarpenterを使用して、Head PodとKubeBay Operatorを実行するための標準的なCPUインスタンスを起動し、その後、実際のサービング処理を実行するためにInferentialインスタンスを起動します。これは、EKSで本番環境における推論ワークロードを実行するお客様の間で、よく見られるようになってきているパターンです。
最後に、いくつかの顧客事例をご紹介させていただきます。H2O.ai、Omi、Unitaryなど、これらのお客様はすべて推論ワークロードを扱うためにKarpenterに移行しており、それぞれのケーススタディやブログをご覧いただけます。特にH2O.aiの事例は興味深く、Bottlerocketを使用してコンテナイメージを事前取得しています。その方法については、ブログで詳しく解説しています。先ほど15分かかると申し上げましたが、確かに最適化は可能ですが、最も速い方法は、インスタンス自体にコンテナイメージを事前にロードすることです。これはBottlerocketを使えば簡単に実現できます。多くのお客様がKarpenterを使用して推論ワークロードの実行に成功しているのを目にしています。
Eli Lilly and Companyにおける技術革新とCATSプラットフォーム
それでは、EKSで成功を収めているお客様の一社について、Kazにバトンタッチしたいと思います。皆さん、こんにちは。Casimir Starslakと申します。Eli Lilly and Companyのプロダクトマネージャーリーダーを務めており、研究とAI製品を担当しています。EKSを使用した生成AIケイパビリティの構築について、お客様の視点からお話しさせていただきます。 Lillyにおける技術の進化についてお話しし、なぜEli Lillyの人間がre:InventのEKS AIトラックで登壇しているのかを説明させていただきます。EKSを含むプラットフォーム開発と、現在進行中の生成AIのスケールアップについてお話しします。
まず、歴史的な背景をご説明させていただきます。こちらの写真は、Lillyの技術の歴史を物語っています。左側は1987年の写真で、パーソナルコンピュータ技術の最新導入に大変喜んでいる、典型的な80年代の企業幹部たちが写っています。右側の写真、ご存知の方もいらっしゃるかもしれませんが、これはCray-2スーパーコンピュータです。1989年、Lillyは米国で初めて政府機関以外でこれを購入した組織となりました。この話をさせていただいたのは、1年前にLillyに入社してから、150年の歴史を持つ企業には予想もしていなかった、このような早期の技術採用とイノベーションの歴史があることを知って、嬉しい驚きを感じたからです。これには、ソフトウェア開発やデータサイエンス、そしてこれらの技術採用に伴うすべてが含まれていました。
残念ながら、その後は順調な上昇カーブを描いたわけではありません。業界全体がいわゆるAIウィンターを経験したように、私たちも独自の技術イノベーションの冬の時代を経験しました。それは2001年頃、私たちが「Year X」と呼ぶ年から本格的に始まりました。これは最初のProzacの特許が切れ始めた年でした。当時、これはLillyの利益の3分の1を占めていました。他の医薬品も特許切れを迎え、売上が劇的に減少するにつれて、コストの見直しが行われ、ソフトウェア開発のような「非コア」とされる分野の支出が削減されました。技術イノベーションの一部は大きな打撃を受け、初期のイノベーションが衰退していく長い期間が続きました。
しかし、現在では状況は完全に一変しています。医薬品企業として今後何年も、何十年も成功し続けるためには、テクノロジー企業になる必要があるという認識が、社内全体に広がっています。幸いなことに、最近の医薬品開発で成功を収めており、非常に有望なパイプラインを持っているため、投資が可能になっています。ソフトウェアエンジニアリング、ロボティクス、自動化、データサイエンス、そしてあらゆる種類のAIなど、テクノロジー関連の能力に大規模な投資と成長が見られています。
この進化の過程で投資を行う中、私たちは最新のソフトウェア開発プラクティスのほとんどを採用しようと努めています。その一環として、数年前に私が所属しているSoftware Product Engineeringチームが設立されました。このチームは元AppleのエンジニアリングリーダーであるGokul Radhakrishnanが率いており、高い信頼性と利用度を持つスキル製品とプラットフォームの構築に注力しています。私たちは、Lillyの開発者全体にこれらのプラクティスを実証し、広めるためのソフトウェアエンジニアリングの卓越した中心として機能することを目指しています。これを実現するために、共有ライブラリと再利用可能なコンポーネントに焦点を当てたプラットフォームアプローチを採用しています。
私たちはオープンソースの機能とツールを活用し、組織全体で使用できる広範な可観測性ツールを構築しています。私たちが大きな投資を行ってきたプラットフォームの1つが、CATSプラットフォームです。
CATSは「Cloud Applications and Technology as a Service」の略で、包括的なクラウドアプリケーション開発およびホスティングソリューションです。これはAWS上に構築され、一連のオープンソースとAWSマネージドサービスを使用してサポートされています。これは非常に簡略化された図ではありますが、主なポイントとしては、KubernetesマネジメントにはEKS、コンテナ実行にはEC2とFargate、そしてS3、RDS、Secret Managerなど、その他多くのAWSサービスが統合されています。また、GitHubアクションから始まり、DockerイメージをECRにプッシュし、Argoが検知して適切なKubernetes環境に自動的にデプロイするまで、チームがコミットからプロダクションまでシームレスに移行できるようにGit CI/CD自動化も実装しています。
開発者にとって、これはクラウドへの移行に伴う新しい開発方法を意味します。数多くのインフラストラクチャに関する決定を下したり、そのインフラストラクチャを構築したりする必要がなく、メニューのように用意されているため、スピードと効率性が向上します。自動化されたデプロイメントのスピードの恩恵も受けられます。これは、クラウドへのテクノロジー変革における重要な部分であり、大きな利用実績を上げています。また、堅固なセキュリティプラクティスと脆弱性スキャンを実装する道筋を設定することで、標準化を通じたセキュリティも実現しています。
また、Amazon のサービスや、Loki や Grafana などのオープンソースツールを通じて、可観測性ツールも提供しています。このプラットフォーム上でアプリケーションを構築するチームは、アプリケーションの拡張に役立つ包括的なロギング、アラート、レポート、可視化機能を利用できます。最大の利点は、スケーラビリティと信頼性です。一度このプラットフォーム上でアプリケーションを開発すれば、チームが追加作業をすることなく、高い信頼性を維持しながら、Lilly のグローバルな従業員全体に対してスケールアップすることができます。
この数年間で、このプラットフォームは何百人もの開発者に利用され、大きな採用実績を上げています。多くの国でグローバルに展開されているアプリケーションの数とコミット数は指数関数的に増加しています。私が特に気に入っている指標の一つは、インターン生の夏季プログラム終了時のフィードバックで、ほぼすべてのインターン生が CATS について言及し、それが彼らのインタープロジェクトの開発をどれだけ加速させたかを語っていたことです。これは、プラットフォームの有効性を示す良い指標だと思います。
Lillyの生成AIプラットフォームの構築と成果
ご想像の通り、この利用増加の多くは、私たちが大きな投資を行っている生成 AI からもたらされています。 状況をご説明すると、Lilly の目標は製薬業界の中で、生成 AI の採用 とその影響においてリーダーになることです。私たちは、生成 AI が私たちの仕事の多くを根本的に変革すると考えており、すでに投資を行っています。実は Lilly には、低分子・高分子の生成やスクリーニングのためのツールを使用した創薬における AI 活用の歴史があります。また、LLM が登場する以前から、臨床サマリーなどの NLP 作業を行っていた優れたデータサイエンスチームも持っています。
私たちは本格的に生成 AI に取り組んでおり、ハイパースケーラーとも協力しています。既製のソリューションを実装し、より組織や使用事例に特化したソリューションについては、小規模な企業やスタートアップと協力しています。また、大規模な社内開発も行っており、このテクノロジー変革の一環として、そうした機能の一部を社内に持つことが適切かどうかを評価しています。ユースケースや実証実験も行っていますが、私たちは本当に会社全体に貢献できる、スケーラブルな製品やプラットフォームに焦点を当てるよう心がけています。私たちが構築を決めたプラットフォームの一つが、Lilly でのこうした取り組みを加速させるための、開発者向けの広く利用可能な生成 AI プラットフォームでした。
私たちは生成 AI が重要になることを認識しており、信頼性が高く、グローバルで多数のユーザーにスケールできるものにしたかったため、先ほどご説明した CATS プラットフォームの上に構築することを決めました。 これらの主要コンポーネントを組み合わせ、2023年に開発を開始し、12月に最初の本番リリースを行いました。
この1年を通して、私たちは機能と性能を追加し続けてきました。基盤レベルでは、これはモデルライブラリです。各チームが最新かつ最高のLLMから選択できるようにしたいと考えており、常に更新を行っています。私たちはAnthropicのモデルラインを高く評価していますが、OpenAI、Gemini、Hugging Face Llamaなども提供しています。法的承認さえ得られれば、Hugging Faceのほぼすべてのモデルを展開できます。チームはこれらをリテールとしてホストすることもできますし、オープンソースも用意しており、さらにGPUクラスターでローカルにホストできるファインチューニングされたモデルもあります。
その上に、私たちはオーケストレーションツールを構築しました。LangChainをメインのオーケストレーションフレームワークとして使用し、プロンプトエンジニアリングやモデルチェーニングのためのシンプルなツールから始めました。より複雑なオーケストレーションツールを追加し、現在ではAgentic Workflowsやマルチエージェントシステムもサポートできるようになっています。運用のスケーリングとメンテナンスのためのツールも用意しており、チームが必要とするスケーリングの多くを処理しています。中央チームには、キャパシティのプロビジョニングを考えるオペレーションチームがあります。最近では、AWSチームと協力して、クロスリージョンの推論とレート制限の最適化を行い、スケールアップ時のパフォーマンス向上と遅延の低減を実現しました。これらを中央で処理することで、他のチームはこれらを心配する必要がありません。
私たちは様々な評価ツールを作成し、チームがスケールアップ時のドリフトを監視したり、最新モデルを評価する際にパフォーマンスの変化を簡単にチェックできるようにしています。また、Lilly環境に特化したデータ統合機能も備えており、常に新しい機能を追加しようとしています。情報検索ツールについては、基本的なSemantic Searchの機能とベクターデータベースから始めて、徐々に複雑な機能を追加してきました。チームがチャンクサイズやオーバーラップなどを最適化できるよう、要素の一部をチューニング可能にしました。さらに、Contextual ChunkingやHybrid Searchなどの機能も追加し、チームが自前で構築する必要がないよう、情報検索の改善を続けています。
これらすべては、監視とコンプライアンス、セキュリティのレイヤーで包まれています。完全な入出力ログを備えており、Cyberチームはすべてのモデル設定とユーザーを可視化できます。また、Cyberチームが設定可能なスキャンとアラートも用意しています。これにはAWSのツールとオープンソースツールを使用しており、Cyberチームに安心感を与え、優先プラットフォームとしての位置づけを確立しています。これにより開発を加速し、チームが素早く始められ、POCやMVPに迅速に到達できるようになりました。チームには選択肢があり、ユースケースに適したモデルを簡単に切り替えることができます。品質、セキュリティ、コンプライアンスが組み込まれており、AWSのEKS上に構築されているため、非常にスケーラブルです。小規模なテストから世界規模の展開まで、大きな問題やダウンタイムなしで実現したユースケースもあります。
2023年12月に本番環境へのリリースを行い、まだ1年も経っていませんが、ビジネスのあらゆる部分に影響を与えているという点で、その普及ぶりに感銘を受けています。私のお気に入りの例は、Agentic Discovery Assistantです。これは約20の異なるツールにアクセスできるケミインフォマティクスエージェントで、ケミインフォマティクスツールやLillyの分子情報を含む内部データベース、さらに外部データベースにもアクセスできます。LLMが質問に答えたり、ユーザーのプロンプトワークフローを実行したり、使用するツールを選択したりすることで、初期段階の研究者を支援できる強力なワークフローを実現しています。
私たちは臨床試験の分野で実装を行っており、規制当局への対応をサポートしています。世界中の規制当局から数千もの質問を受け取り、それらに回答する必要がありますが、これはLLMの自然な適用分野です。また、グローバル製造オペレーションにおいて、Manufacturing分野向けのツールも開発しています。製造ラインの稼働時間に大きな焦点を当てており、このプラットフォーム上で、SOPの構造化・非構造化データや機器のセンサーデータを活用して、ライン作業者の稼働時間の監視と管理を支援するAssistantを開発しました。Claims作成ツールもあり、さらにこのプラットフォーム上で初めての患者向けQ&Aツールも開発中です。
この採用状況を見るのは興奮します。結果に関して言えば、私たちは加速を実感しています。チームから直接話を聞いていますし、数週間でPOCを出せるようになり、数ヶ月で実際にMVPを本番環境にリリースできるようになったチームも見てきました。これらのツールが準備され利用可能な状態にあるため、品質、セキュリティ、コンプライアンスの要件を満たすことができています。可視性、ログ記録、アラートなどすべてが整っているため、Cyberチームからも推奨されるプラットフォームとなっています。
急速なスケールアップを可能にし、大きな採用成果を上げています。Lillyには500人以上のDeveloperがこのプラットフォームを使用しており、30カ国以上に数千人のエンドユーザーがいて、1ヶ月あたり数十億のトークンがプラットフォームで処理されています。このスケールは私たちが期待していた通りで、Lillyのテクノロジー進化を支えています。もちろん、その上に影響力のある製品を構築していますが、私たちの取り組みによって、この分野で働きたいと考える人材の採用と定着という好循環も生まれており、先ほど話した変革を支えています。
最後に、学んだ教訓についてお話しします。主な教訓は、このプラットフォームアプローチ、つまりEKSのようなスケーラブルなプラットフォームを使用し、Generative AI開発に対してある程度の方向性を持ったアプローチを構築するという私たちの信念と直感が正しかったということです。Developerがこれを使用し、開発が加速し、スケールアップが進み、本番環境への移行も進んでいます。このようなプラットフォームを構築すると、特にLillyのような場所では、非常に優秀で機動力のあるDeveloperチームが最初の早期採用者として自然に使い始めます。
その後には分布曲線全体が続きますが、より広い採用を実現するためには、啓発活動、質問への回答、サポートドキュメントの提供、サポートチームの設置、そして製品としての考え方の維持など、多くの取り組みが必要です。私たちは本当にこれを製品として扱い、Product Manager、ロードマップを持ち、常にVoice of Customerの収集に努めています。私たちは情報検索パイプラインの最新の改善を構築することに夢中になるかもしれませんが、顧客はQA環境の安定性を望んでいるかもしれません。そのため、エンジニアリングとテクノロジーに没頭しすぎず、顧客のニーズに根ざした姿勢を保つことが重要でした。
期待値は急速に高まっていきました。当初、Lillyの一部の開発者たちは、特定のプラットフォームに誘導され制約を設けられることに対して懐疑的でした。しかし、その懐疑的な態度は、開発のスピードアップや承認取得の容易さを実感することで、すぐに理解へと変わりました。そして私たちは採用が進んでいることを確認しています。その後、より多くの機能やドキュメント、正式なSLAを求める声へと変わっていきました。このようなプラットフォームを構築する際は、ドキュメントの整備やサポートの充実を怠らず、特にLillyのような患者向けシステムや24時間365日稼働の製造システムを持つ企業では、SLAについての事前のコミュニケーションを心がけてください。最後に、先ほど触れたサイバーセキュリティチームとのパートナーシップについてですが、特にLillyのようなサイバーセキュリティやプライバシー、法的要件の基準が高い企業では、早期からの投資が本プラットフォームの成功の鍵となりました。
Data on EKSプロジェクトと今後の展望
ありがとうございます。素晴らしい洞察を共有していただき、感謝いたします。このプレゼンテーションを通じて多く語られてきたのは、お客様が目的のML機能を実現するためにEKS上にソリューションを統合したいと考えているということです。 多くのお客様から、これらのソリューションを迅速に統合するための始め方や、統合におけるベストプラクティス、そして成功事例に基づくテンプレートやパターンの提供について、ガイダンスを求められていました。 そこで私たちはData on EKSプロジェクトを立ち上げました。これは、お客様の間で見られる様々なパターンを公開するオープンソースプロジェクトです。ML特有の課題を解決するためにEKSと統合される一般的なソリューションを簡単に始められるよう、ブループリント、パターン、Terraformテンプレートを公開しています。
この1年間で、私たちは多くのパターンをリリースしてきました。実際の現場でそれらのパターンの成功を確認しながら、さらに新しいパターンを作り続けています。特に、EKS上での推論に特化したパターンのリリースに重点を置いてきました。最近リリースしたものには、NVIDIA Triton with vLLM、RayServe with vLLM、NVIDIA Names on EKSなどがあります。Data on EKSのウェブサイトでは、推論だけでなく、トレーニングやファインチューニングに関する様々なパターンをご覧いただけます。
さて、セッションもほぼ終わりに近づいてきました。 これからEKSに関する興味深いセッションがいくつか予定されています。Amazon EKS Infrastructure as Codeのセッションや、S&Pによる、EKS上に実装して週数百万件の推論リクエストに対応している事例についてのセッションがあります。また明日は、Kubernetesの未来についてのセッションも予定されています。 Amazon EKSについての学習は、ワークショップやデジタルバッジの取得、ベストプラクティスガイドなど、様々なリソースを通じて継続することができます。これでセッションは終了となります。最後まで熱心にお聞きいただき、ありがとうございました。ご質問がございましたら、私たちはしばらくの間、会場の外で待機していますので、お気軽にお声がけください。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion