生成AIとLLMOps

　生成AIは文章・音声・画像といった既存のデータや情報を基盤モデルに入力することで、新たなデータや情報を生成する機械学習のアルゴリズムと定義されています。近年ではLLMに代表される新しい問題解決手法として、生成AIがビジネスに革新をもたらし始めています。

　LLMは「Large Language Model」の略称で、日本語では「大規模言語モデル」と呼ばれています。下図はLLMの仕組みを示したもので、文章などが入力されるとトークン化や文脈理解などの工程を経て、最終的には自然に人間的な応答を返すことが可能です。活用例としてはチャットボット・検索エンジン・テキスト生成などが挙げられますが、ビジネスで活用するにはカスタマイズが不可欠であり、それが課題のひとつになっています。

　生成AIを実際に活用するまでには、大きく分けて3つの道のりがあります。

　1つ目は、既存サービスを利用する方法です。世の中に多くリリースされている、ChatGPTやGoogle BirdなどのLLMを活用したサービスを使うということです。

　2つ目と3つ目はどちらもLLMのカスタマイズですが、規模が異なります。まず2つ目にはRAGでPDF文書などの自社データを読み込ませて拡張したり、プロンプトエンジニアリングで調整したりするといった、小規模なものが該当します。そして、3つ目にはファインチューニングや独自の基盤モデル開発など、大規模な手法が挙げられます。

　これらの実現には、数ヶ月～年単位の時間を要することもあります。そのため、これから生成AIの開発・活用を進めていきたい場合には、どのような方法が適しているかを考えることも重要です。

　一般的なAI開発・運用のライフサイクルはデータ収集とデータの前処理から始まり、そのあとモデルの開発（選定）・学習・評価・デプロイなどを経て、やがて運用・監視に至ります。また、データ収集からモデル評価までを繰り返し実行したり、運用・監視の開始後も精度監視と再学習を継続的に行ったりと、精度を高めるための取り組みが重要になります。

　一方、LLMの開発・運用ライフサイクル（LLMOps）は、まず開発の方針決定からスタートし、やるべきことやコストなどを決めます。次に「基盤モデルの構築」「特定タスクへのファインチューニング」「独自データからの知識統合」の大別した3つの開発フェーズで自社に適したフェーズから開発を進めます。このとき、十分な精度が出るまで試行錯誤を繰り返します。そして、開発が完了した後はプロダクションフェーズへと移行し、サービスを提供します。

　下図にはLLMOpsの実現に必要な要素を、「開発フェーズ」と「プロダクションフェーズ」の2つに大別して記載しました。

　開発フェーズで目標とすべきなのは、期待通りの応答をさせることや自社のデータを使っても精度を出していくことです。そして、その実現にはLLM実行フローの可視化・検査や、LLMの入出力の解析といった、実験で精度を高めるための管理手法が必要になります。

　一方、プロダクションのフェーズで望まれる安定したサービス運用や、モデル更新による機能拡張のためには、精度の高い運用・管理手法が求められます。具体的には、モデル・サービス監視、データ解析・異常検知などが挙げられます。

　各フェーズで考えなければならないことは多くありますが、すべてのフェーズを共通の基盤で管理できれば、効果的なLLMOpsを実現できるでしょう。

　下図は、弊社の環境でLLMOpsの実装を行った際のユースケースを示したものです。このときはプロンプトを基盤モデルに入力し、出力を得ながらモデルの調整を行うプロンプトエンジニアリングの実験管理をしました。LLMのチェーンがどうなっているかを把握できることや、図の右上にあるような要素に対応しているなどの理由から、このときはWeigts&Biasesというツールを使いました。

　このユースケースのように、まずは実験管理から始める場合であっても、プロダクションが移った際の管理手法を考えていけるような基盤を用意しておくことが、 一貫したLLMOpsの実現に繋がると私たちは考えています。実際のところ、この実験管理では運用にも活用できる部分が多々ありました。

生成AI開発プラットフォーム

　ここからは、実際に開発を進めていくうえでのインフラやフレームワークなども含めた、生成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リソースの効率的な活用には効果を見いだせないこともあります。

　最新のオンプレミスやクラウドの環境を作ったうえで、GPUリソースを効率的に活用できる基盤に、Run:aiというソリューションがあります。Run:aiでは1枚のGPUをスライスすることで、リソースを複数のコンテナで共有して使うことができます。これにより、1基のGPUを使い切れない場合にムダをなくすことができます。

　また、空きGPUが目立つものの管理方法がネックで、そのままにした結果リソースがムダになっているケースも発生しがちです。これに対しては、空いているGPUを余分に使えるスケジューラー機能が有効に働きます。さらに、リソースを可視化して管理できる機能もあるため、大規模にGPUリソースを使うLLMの開発も加速できるでしょう。

　LLM開発の選択肢としては、NVIDIA社が「大規模言語モデルを構築するための完全なソリューション」と謳っているNeMoも挙げられます。NeMoは自然言語処理・自動音声認識・音声合成などの機能を有しており、データの作成やモデル開発、実装のための実験といった一連の流れをすべて提供していることが特徴です。また、LLMを開発して運用する場合には、ユースケースに沿って境界線を設けなければなりません。そんなときには、NeMo ガードレールを利用することで、より安全に運用を行えます。

まとめ

　生成AIの実現には、2つのポイントがあります。1つ目は、生成AIの開発ライフサイクルを効果的に回すこと。2つ目は、生成AIの開発に適したプラットフォームの構築です。

　そしてマクニカでは、お客様が自社に適した環境で理想の生成AIを実現するためのソリューションを扱っております。これらを通じてぜひお役に立てればと考えておりますので、ご興味がございましたら、ぜひお問い合わせいただけますと幸いです。