近年、ジェネレーティブ AI は世間の注目を集め、多くのコンテンツを生み出し、世界中で開発と活用が進んでいます。そのため、ジェネレーティブ AI の開発をすぐに開始し、チームの取り組みを加速させるためには、どのような環境を整えればよいのか疑問に思う人も増えています。本記事では、ジェネレーティブ AI 時代の DevOps、独自のプラットフォームの構築方法、NVIDIA のエコシステムなど、ジェネレーティブ AI に最適なプラットフォームを紹介します。
※本記事は2024年2月に開催された「マクニカデータ・AIフォーラム2024 Winter」での講演をもとに作成しています。
生成型AIとは、テキスト、音声、画像などの既存のデータや情報を基本モデルに入力することで、新たなデータや情報を生成する機械学習アルゴリズムと定義されます。近年、LLMに代表されるように、生成型AIは新たな問題解決手法としてビジネスに革新をもたらし始めています。
LLMとは「Large Language Model」の略称で、日本語では「大規模言語モデル」と呼ばれます。下図はLLMの仕組みを示したもので、文章を入力するとトークン化や文脈理解などの処理を経て、最終的に人間らしい自然な応答を返します。チャットボットや検索エンジン、テキスト生成などの用途が考えられますが、ビジネスで利用するにはカスタマイズが必須であり、課題の一つとなっています。
大まかに言えば、生成 AI を実際に使用するには 3 つの方法があります。
最初の方法は、ChatGPT や Google Bird など、広く利用可能で LLM を使用する既存のサービスを利用することです。
2つ目と3つ目は、どちらもLLMのカスタマイズですが、規模が異なります。2つ目は、PDF文書などの社内データをRAGで読み込んでLLMを拡張したり、プロンプトエンジニアリングで調整したりするような小規模なものです。3つ目は、微調整や独自の基礎モデルの開発といった大規模なものです。
これらの目標を達成するには数か月から数年かかる場合があるため、生成 AI の開発と使用を進めたい場合は、どの方法が最も適しているかを検討することが重要です。
一般的なAI開発・運用ライフサイクルは、データ収集・データ前処理から始まり、モデル開発(選定)、学習、評価、デプロイなどを経て、最後に運用・監視へと進みます。また、データ収集からモデル評価までのプロセスを繰り返し実行し、運用・監視を開始した後も精度の監視と再学習を継続するなど、精度向上に向けた取り組みが重要です。
一方、LLMの開発運用ライフサイクル(LLMOps)は、開発方針を決め、何をすべきか、コストはいくらかを決めることから始まります。次に、大きく分けて「基盤モデルの構築」「特定タスク向けの微調整」「独自データからのナレッジ統合」の3つの開発フェーズに分かれ、自社にとって最適なフェーズから開発を開始します。この時点で、十分な精度が出るまで試行錯誤を繰り返します。開発が完了したら、本番フェーズに移行し、サービスが提供されます。
下の図は、LLMOps を実現するために必要な要素を、「開発フェーズ」と「本番フェーズ」の 2 つのフェーズに大別して示したものです。
開発フェーズでは、自社データを使用しても期待通りのレスポンスと精度を実現することが目標となります。そのためには、LLM実行フローの可視化・検証やLLM入出力の分析など、実験を通じて精度を向上させる管理手法が必要となります。
一方、本番フェーズで望まれる安定したサービス運用やモデルアップデートによる機能拡張には、モデルやサービスの監視、データ分析、異常検知など、精度の高い運用・管理手法が必要となります。
各フェーズで考慮すべき点はたくさんありますが、すべてのフェーズを共通の基盤から管理できれば、効果的な LLMOps を実現できます。
下の図は、LLMOps を弊社の環境に実装した際のユースケースです。このケースでは、プロンプトをベースモデルに入力し、出力を得ながらモデルを調整する、プロンプトエンジニアリング実験管理を行いました。図の右上の要素に対応する、LLM チェーンを理解できる Weigts&Biases というツールを使用しました。
今回のユースケースのように、実験管理から始める場合でも、本番移行時の管理方法を検討できる基盤があることが、一貫した LLMOps の実現につながると考えています。実際、今回の実験管理には運用にも活用できる部分が多くありました。
ここからは、実際の開発に必要なインフラやフレームワークも含めた生成AI開発プラットフォームについてお話したいと思います。これはハードウェアやソフトウェアなどのインフラだけではなく、LLMOpsが実行できる基盤やアプリケーション層まで含めて、生成AIを開発から運用まで担えるものだと考えています。
さらに、生成AIプラットフォームを開発する際に考慮すべき点として、「実現したいことに合ったインフラを備えているか?」と「生成AIを実現するための環境が提供されているか?」の2点を挙げています。やはり、開発ライフサイクルを効率的に回せるプラットフォームが理想形です。
インフラストラクチャの検討に関してよくある質問は、「オンプレミスとクラウドのどちらを使用するのが良いですか?」です。
まずオンプレミスは、「開発用に大規模なリソースを確保したい」「データを外部に送れない」といった事情がある場合に良い選択肢です。一方、クラウドはオンデマンドで利用できるのがメリットなので、「既存のLLMサービスを使いたい」「実験がメイン」といったケースには向いています。
しかし、近年ではGPUリソースの可用性が大きな課題となっています。例えば、クラウド上でGPUリソースの取得に時間がかかったり、想定よりもリソースが不足したりすることがあります。このような場合にはオンプレミスが選択肢となる場合があります。
まず、プラットフォームの話やLLMの開発をする際には、LLMが実行できる環境が前提となるため、実際に環境を用意し、LLMベースのモデルを動作させる実験を行いました。
今回実験に使用したサーバーには、Llama-2の70億パラメータモデルとDGX-2(V100 x16)を搭載していました。その結果、GPUの枚数によって動作感が全く異なりました。具体的には、4~8では動作がかなり重く、12では少し改善しましたが、それでも重く感じました。このことから、ベースモデルがスムーズに動作できる環境を事前に用意しておくことの重要性を学びました。
次に、実際のプラットフォームの検討に移ります。まずはオンプレミスでありながらクラウドネイティブに利用できるKubernetesです。リソースを一括管理でき、スケーラブルで、コンテナをオーケストレーションしてユーザーにリソースを分配できることから、最近は生成AIの分野でも使われ始めている技術です。Kubernetesには多くのメリットがある一方で、図の右下に示すように、GPUリソースを効率的に活用する上で効果を発揮しにくい課題もあります。
Run:aiは、最新のオンプレミスやクラウド環境でGPUリソースを効率的に活用できるソリューションです。Run:aiは単一のGPUをスライスし、複数のコンテナでリソースを共有できるようにします。これにより、単一のGPUを十分に活用できない場合の無駄を排除します。
また、空きGPUが目立つ一方で、その管理方法がボトルネックとなり、結果的にリソースを無駄に消費してしまうケースもあります。これに対しては、空きGPUを余分に利用できるスケジューラ機能が有効です。さらに、リソースを可視化して管理する機能があるため、大規模にGPUリソースを利用するLLMの開発を加速できます。
LLMを開発するもう1つの選択肢は、NVIDIAが「大規模言語モデルを構築するための完全なソリューション」と謳うNeMoです。NeMoは自然言語処理、自動音声認識、音声合成などの機能を備えており、データ作成、モデル開発、実装のための実験など、一連の手順を完備しているのが特徴です。また、LLMを開発・運用する際には、ユースケースに応じて境界を設定する必要があります。そのような場合には、NeMo Guardrailsを利用することで、より安全に運用することができます。
生成AIを実現するには、2つのポイントがあります。1つ目は、生成AIの開発ライフサイクルを効率的に回すことです。2つ目は、生成AIの開発に適したプラットフォームを構築することです。
マクニカでは、お客様の企業に合った環境で理想的な生成AIを実現できるソリューションをご提供しております。これらのソリューションを通じて皆様のお役に立ちたいと考えておりますので、ご興味がございましたら、ぜひお気軽にお問い合わせください。
― 新型コロナウイルスへの対応
マクニカ株式会社の対応方針
メンテナンスサービスへの対応

お客様のブラウザーの設定は、JavaScriptが無効になっています。Javascriptを有効にして再読み込みをお願いいたします。

ブラウザの設定でJavaScriptが無効になっています。JavaScriptを有効にして再読み込みしてください。

元記事: https://www.macnica.co.jp/en/business/ai/blog/145251/

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください