「環境持続可能性のために生成型AIのワークロードを最適化する」

Optimizing the workload of generative AI for environmental sustainability.

生成AIの採用は急速に拡大し、世界中のさまざまな産業やユーザーに広がっています。生成AIモデルの複雑さと規模が増しているため、環境への影響を最小限に抑えるための取り組みが重要です。これには、提供されるリソースを最大限に活用し、必要な総リソースを最小限に抑えるためのエネルギー削減と効率化に焦点を当てた継続的な取り組みが必要です。

AWSにおけるディープラーニングワークロードの持続可能性の最適化に関するガイダンスに加えて、この記事では生成AIワークロードに特化した推奨事項を提供します。具体的には、ゼロからモデルをトレーニングする、追加のデータを使用したファインチューニング、Retrieval Augmented Generation（RAG）、およびPrompt Engineeringなど、さまざまなカスタマイズシナリオに対する実践的なベストプラクティスを提供します。この記事は主に大規模言語モデル（LLM）に焦点を当てていますが、ほとんどの推奨事項は他の基礎モデルにも適用できると考えています。

生成AIの問題設定

生成AIの問題を設定する際には、以下の点に注意してください。

• 生成AIの使用を持続可能性の目標に合わせる – プロジェクトのスコープを決める際には、持続可能性を考慮に入れてください：
  • 生成AIソリューションとリソース消費の少ない従来のアプローチとのトレードオフは何ですか？
  • 生成AIプロジェクトはどのように持続可能なイノベーションを支援できますか？
• 低炭素度のエネルギーを使用する – 規制や法的な側面が許す限り、2022年に消費された電力が100%再生可能エネルギーに帰属しているまたはグリッドの公表された炭素度が他の場所（またはリージョン）よりも低いAWSリージョンの1つでモデルのトレーニングと展開を行ってください。詳細については、「持続可能性の目標に基づいてワークロード用のリージョンを選択する方法」を参照してください。リージョンを選択する際には、ネットワークを横断するデータ移動を最小限に抑えるようにしてください：モデルをデータに近い場所でトレーニングし、ユーザーに近い場所でモデルを展開します。
• 管理されたサービスを使用する – 専門知識と特定のユースケースに応じて、Amazon Bedrock（サーバーレスの完全管理型サービスで、さまざまな基礎モデルにAPI経由でアクセスできる）を選択するか、Amazon SageMakerを使用して完全に管理されたインフラストラクチャ上でモデルを展開するかの選択肢を検討してください。管理されたサービスを使用することで、デプロイされたハードウェアの高い利用率と持続可能性の最適化の維持責任をAWSに移行することで、より効率的に運用することができます。
• 適切なカスタマイズ戦略を定義する – プロンプトエンジニアリングから完全なファインチューニングまで、モデルの能力を向上させるためのいくつかの戦略があります。それぞれのニーズに最も適した戦略を選択する際には、それぞれに必要なリソースの違いも考慮してください。たとえば、ファインチューニングはプロンプトエンジニアリングよりも高い精度を達成する可能性がありますが、トレーニングフェーズでより多くのリソースとエネルギーを消費します。トレードオフを考えてください：最適なパフォーマンスよりも受け入れ可能なパフォーマンスを優先するカスタマイズアプローチを選択することで、モデルの使用するリソースを削減できます。以下の図はLLMのカスタマイズ戦略の環境への影響をまとめたものです。

• NVIDIA Studio LineupにRTX搭載のMicrosoft Surface Laptop Studio 2が追加されました
• 慈善家のジェームズ・ドゥーリー氏がユニプレイ・マーキングに投資
• 「OpenAI、DALL·Eの第3のイテレーションを発表」

モデルのカスタマイズ

このセクションでは、モデルのカスタマイズに関するベストプラクティスを共有します。

ベースモデルの選択

適切なベースモデルを選択することは、生成AIワークロードのカスタマイズにおいて重要なステップであり、ファインチューニングの必要性と関連するリソース使用量を減らすのに役立ちます。以下の要素を考慮してください。

• 能力と制限の評価 – Amazon SageMaker JumpStartやAmazon Bedrockのプレイグラウンドを使用して、LLMの能力を簡単にテストし、その基本的な制限を評価します。
• カスタマイズの必要性を減らす – オープンなLLMリーダーボード、総合的な評価ベンチマーク、またはモデルカードなどの公開リソースを使用して、異なるLLMを比較し、それらが事前トレーニングされた特定のドメイン、タスク、言語に対してどのように適しているかを理解して情報を収集してください。ユースケースに応じて、ドメイン固有のモデルや多言語モデルを検討して追加のカスタマイズの必要性を減らすことができます。
• 小さなモデルサイズと小さなコンテキストウィンドウから始める – 大きなモデルサイズとコンテキストウィンドウ（単一のプロンプトに収まるトークンの数）はより高いパフォーマンスと機能を提供するかもしれませんが、推論にはより多くのエネルギーとリソースが必要です。大きなモデルにスケールアップする前に、より小さなサイズとコンテキストウィンドウのモデルの利用可能なバージョンを検討してください。専門的な小さなモデルは、特定のターゲットタスクに集中して容量を持っています。これらのタスクでは、専門的なモデルはリソースのトレーニングと推論により少ないリソースで、より大きなモデル（たとえば1750億パラメータを持つGPT3.5など）と定性的に似たような振る舞いを示すことができます。このようなモデルの例には、Alpaca（70億パラメータ）やマルチステップの数理推論にT5のバリアントを利用することがあります（110億パラメータ以上）。

プロンプトエンジニアリング

効果的なプロンプトエンジニアリングは、生成型AIモデルのパフォーマンスと効率を向上させることができます。プロンプトを注意深く作成することで、モデルの振る舞いを誘導し、不要な反復やリソース要件を減らすことができます。以下のガイドラインに注意してください：

• プロンプトを簡潔に保ち、不要な詳細を避ける – 長いプロンプトはトークンの数を増やします。トークンが増えると、モデルはより多くのメモリと計算リソースを消費します。ゼロショット学習やフューショット学習を取り入れて、モデルがわずかな例から学習して素早く適応するようにすることを検討してください。
• 異なるプロンプトを徐々に試してみる – 望ましい出力を得るために、望ましい結果に基づいてプロンプトを洗練させてください。タスクに応じて、自己整合性、生成された知識プロンプト、ReActプロンプト、または自動プロンプトエンジニアなどの高度なテクニックを試して、モデルの能力をさらに向上させることができます。
• 再現可能なプロンプトを使用する – LangChainプロンプトテンプレートなどのテンプレートを使用すると、プロンプトの履歴をファイルとして保存または読み込むことができます。これにより、プロンプトの実験の追跡、バージョニング、再利用性が向上します。各モデルに対して最適な回答を生成するプロンプトがわかると、異なるプロジェクト間でのプロンプトの反復と冗長な実験を削減することができます。

情報検索を利用した生成

情報検索を利用した生成（RAG）は、事前定義されたデータセットから適切な外部情報を取得し統合することで、モデルの能力を効果的に向上させる手法です。既存のLLMをそのまま使用するため、この戦略では新しいデータでモデルをトレーニングしたり、ゼロから新しいモデルを構築するために必要なエネルギーやリソースを避けることができます。Amazon KendraやAmazon OpenSearch Service、LangChainなどのツールを使用して、Amazon BedrockやSageMaker JumpStartと組み合わせてRAGベースのソリューションを構築することができます。

パラメータ効率の高いファインチューニング

パラメータ効率の高いファインチューニング（PEFT）は、生成型AIにおける持続可能性の基本的な要素です。ファインチューニングと比較して、より少ない訓練可能なパラメータで同等のパフォーマンスを達成することを目指しています。事前トレーニングされたLLMのほとんどのパラメータを凍結しながら、ごく一部のモデルパラメータのみをファインチューニングすることで、計算リソースとエネルギー消費を削減することができます。

パラメータ効率の高いファインチューニングライブラリなどのパブリックライブラリを使用して、Low Rank Adaptation（LoRa）、Prefix Tuning、Prompt Tuning、またはP-Tuningなどの一般的なPEFTテクニックを実装することができます。例えば、研究によれば、LoRaの利用により、モデルのサイズに応じて訓練可能なパラメータの数を10,000分の1に、GPUメモリの要件を3分の1に削減することができ、同等またはそれ以上のパフォーマンスを実現することが示されています。

ファインチューニング

追加データを使用して事前トレーニングされたモデル全体をファインチューニングします。このアプローチは、PEFTよりもパフォーマンスを向上させる可能性がありますが、リソースの使用がより多く必要です。利用可能なデータが事前トレーニングデータと大きく異なる場合には、この戦略を使用してください。

適切なファインチューニングアプローチを選択することで、モデルの再利用を最大化し、各ユースケースごとに複数のモデルをファインチューニングする際のリソース使用を避けることができます。例えば、モデルを組織内の特定のドメインやビジネスユニットで再利用することを予想する場合は、ドメイン適応が適しています。一方、一般的なタスク全体での使用には、インストラクションベースのファインチューニングが適しています。

ゼロからのモデルトレーニング

一部の場合では、LLMモデルをゼロからトレーニングする必要があります。ただし、このアプローチは計算コストが高く、エネルギーを消費します。最適なトレーニングを行うために、以下のベストプラクティスに注意してください：

• 効率的なシリコンを使用する – AWS TrainiumベースのEC2 Trn1インスタンスは、高性能のディープラーニングモデルトレーニングに特化しており、エネルギー効率が最適化されています。2022年には、Trainium上でモデルをトレーニングすることで、エネルギー消費を比較可能なインスタンスに対して最大29%削減することが観察されました。
• 高品質なデータとスケーラブルなデータキュレーションを使用する – SageMaker Trainingを使用して、トレーニングデータセットの品質を向上させ、大量のデータへの依存を最小限に抑えます。多様で包括的かつキュレーションされたデータセットでトレーニングすることで、LLMはより正確な応答を生成し、ストレージと計算要件を削減することでコストとエネルギーを最適化することができます。
• 分散トレーニングを使用する – SageMakerの分散ライブラリを使用して、データ並列処理、パイプライン並列処理、テンソル並列処理などを実行し、複数のGPUやインスタンスで並列計算を実行します。これらのアプローチにより、トレーニングバッチをより小さなマイクロバッチに分割してGPUの利用を最大化します。小さなマイクロバッチは効率的なパイプラインでGPUに供給され、すべてのGPUデバイスを同時にアクティブに保つため、リソースを最適化します。

モデルの推論と展開

モデルの推論と展開に関する以下のベストプラクティスを考慮してください：

• 大規模なモデルの推論にはディープラーニングコンテナを使用 – SageMakerやDeepSpeed、Hugging Face Accelerate、FasterTransformerなどのオープンソースフレームワークで、ウェイトプルーニング、蒸留、圧縮、量子化、コンパイルなどの技術を実装するために、ディープラーニングコンテナを使用できます。これらの技術はモデルのサイズを減らし、メモリ使用量を最適化します。
• 適切な推論モデルのパラメータを設定 – 推論中に、モデルの出力に影響を与える特定のパラメータを調整する柔軟性があります。これらのパラメータを理解し適切に設定することで、モデルから最も関連性のある応答を得ることができ、プロンプトチューニングの反復回数を最小限に抑えることができます。これにより、メモリ使用量が減少し、エネルギー消費量も低下します。考慮すべき主なパラメータはtemperature、top_p、top_k、およびmax_lengthです。
• 効率的な推論インフラを採用 – AWS Inferentia2アクセラレータ上にモデルを展開することができます。Inf2インスタンスは、AWS Inferentia2アクセラレータが大規模なディープラーニングモデルを実行するために特別に設計されているため、Amazon Elastic Compute Cloud（Amazon EC2）インスタンスと比較して最大50%の性能/ワットを提供します。インフェレンスAIの最新のイノベーションを展開する際に、Inf2インスタンスは最も省エネルギーなオプションとなり、持続可能性の目標を達成するのに役立ちます。
• 推論のサービスレベル契約（SLA）を持続可能性の目標と合わせる – ビジネス要件を満たしながら、持続可能性の目標をサポートするSLAを定義してください。ビジネス要件を満たすために、それ以上に要求を満たさないようにSLAを定義します。リソース使用量を大幅に削減し、サービスレベルの低下を許容範囲内で受け入れるためのトレードオフを行います：
  • 入力リクエストをキューに入れ、非同期で処理する – ユーザーがいくらかの待ち時間を許容できる場合、非同期エンドポイントにモデルを展開して、タスク間でアイドルなリソースを削減し、負荷スパイクの影響を最小限に抑えます。これにより、リクエストの処理がない場合はインスタンス数をゼロにスケーリングし、エンドポイントがリクエストを処理している場合にのみインフェレンスインフラを維持します。
  • 可用性を調整する – ユーザーがまれなフェイルオーバーの場合にいくらかの待ち時間を許容できる場合、余分な容量を予約しないでください。停電が発生した場合やインスタンスが故障した場合、SageMakerは自動的にインスタンスを可用ゾーン全体に分散します。
  • 応答時間を調整する – リアルタイムの推論が不要な場合は、SageMakerバッチ変換を使用してください。永続的なエンドポイントとは異なり、バッチ変換ジョブが完了するとクラスタが廃止されるため、推論インフラを継続的に維持する必要がありません。

リソース使用量のモニタリングと最適化

最適化の効果を時間とともに追跡するための改善プロセスを実装してください。改善の目標は、割り当てたすべてのリソースを使用し、最小限のリソースで同じ作業を完了することです。このプロセスを実現するために、クラウドリソースの利用状況に関するメトリクスを収集してください。これらのメトリクスは、ビジネスメトリクスと組み合わせて、炭素排出量のプロキシメトリクスとして使用することができます。

環境を一貫して監視するために、Amazon CloudWatchを使用してCPU、GPU、メモリの利用状況などのシステムメトリクスを監視できます。NVIDIA GPUを使用している場合は、GPUの利用状況とパフォーマンス状態を監視するためにNVIDIAシステム管理インターフェース（nvidia-smi）を考慮してください。TrainiumとAWS Inferentiaアクセラレータの場合、AWS Neuron Monitorを使用してシステムメトリクスを監視できます。以下は、監視する価値のあるいくつかの主要なメトリクスです：

• CloudWatchのCPUUtilization、GPUUtilization、GPUMemoryUtilization、MemoryUtilization、およびDiskUtilization
• nvidia-smiログのnvidia_smi.gpu_utilization、nvidia_smi.gpu_memory_utilization、およびnvidia_smi.gpu_performance_state
• Neuron Monitorのvcpu_usage、memory_info、およびneuroncore_utilization

結論

生成的AIモデルがますます大きくなるにつれて、ワークロードの環境への影響を考慮することが重要です。

本稿では、AWS上で生成的AIワークロードを実行するために必要な計算、ストレージ、およびネットワーキングリソースを最適化し、その環境への環境への影響を最小限に抑えるためのガイダンスを提供しました。生成的AIの領域は常に進歩しているため、最新のコース、研究、ツールに関して更新された情報を持つことは、持続可能性のためにワークロードを最適化するための新しい方法を見つけるのに役立ちます。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!