LLM開発のために200万円以上無駄にしたエンジニアの話
はじめに
こんにちは、Lightblueの園田です。
四畳半のオフィスで70億パラメータのLLMを事前学習した話ではエンジニアの樋口さんがlightblue/japanese-mpt-7bの開発・性能評価について報告しました。
本記事では、四畳半のオフィスで70億パラメータのLLMを事前学習した話で語りきれなかったしくじりも含めた開発裏話について紹介します。
LLM開発に必要なリソース
一般的に、LLMの開発にはA100やH100といった最新の高性能のGPUが使われます。
本日公開されたLlama2の70Bモデルでは、A100を1,720,320時間分利用し学習されています。
このようなリソースはGPUボードの費用だけでなく、電気代も高額になることから、LLMの開発には資本力が必要とされています。
H100はパブリッククラウドでほとんど提供されていないことから、LightblueでもA100を用いて開発しています。
200万円溶かした経緯
四畳半のオフィスで70億パラメータのLLMを事前学習した話では、70億パラメータの多言語データで学習済みのモデルを日本語データで追加学習させたため、最終的には60万円程度の計算リソースで開発できたと報告しています。
しかし、実際は、試行錯誤の過程で500万円ほど費用がかかっています。
これは、MPT以外のモデルのチューニングを行ったり、複数のモデルの日本語での性能を評価したりしていたからなのですが、その中のコストで実際の計算には使われなかった無駄な200万円が存在しました。
なぜ4畳半のオフィスで開発しているスタートアップには不相応な200万円という無駄なリソースが発生したかについて説明します。
クラウドでのA100の使い方
A100と一言に言っても、メモリサイズ（40GB/80GB）やGPUのボード数によってさまざまなタイプのインスタンスが用意されています。
今回はGCPを用いたのですが、どのクラウド環境でもA100のインスタンスは枯渇していて、通常のインスタンスのように自由に使える状況にありません。
特に80GBのインスタンスは事前に割当を申請し、確保されたあとはすぐにインスタンスを起動させるか、予約機能という物を使う必要があります。
ただし、この予約機能、インスタンスを起動させるのと同等のコストがかかってきます。。
予約済みのリソースの使用量にかかわらず、予約により他のユーザーは予約済みのリソースを使用できません。予約は、予約されていない実行中の VM と同じ量のリソースを占有するため、予約済みのリソースは実行中の VM と同じオンデマンド料金（適用される割引を含む）で課金されます。
200万円分無駄にした理由
LLM開発チームは以下のような状況でした。
チームメンバーのうち1人がGCPへのリソース申請を行っていた
申請を行っていたメンバーがB、M、Kの計算を混乱しがち（70億？7億？、1,000ドルは14万円？1.4万円？）
全メンバーに上記の料金やリソース確保のルール・状況が周知されていなかった
その結果、リソースの確保申請が早すぎ、実験のスケジューリングができていない状況で、インスタンスを立ててしまいました。
また、その状況を完全にチームメンバーが把握できていなかったため、遊ばせている80GBのインスタンスとは別に40GBのインスタンスを立てて複数のモデルの性能評価などを行なっていました。
その結果、8GPUのA100 80GBインスタンスを使っていない状態で立てっぱなしにするという状況が発生し、ほとんどのメンバーが気づいていない状態で時間が過ぎてしまいました。
これが200万円分無駄にした経緯になります。
どうすれば節約できるか
計画が大事
まず、計算リソースの確保ルールや料金、実験計画などをチーム内で認識を揃え、このような無駄が発生しないようにすべきです。
実験準備などは遅れてしまうこともあるので、ある程度、計算リソースを利用する見通しがたった状態で確保申請を出すことで、本体の実験が始まらないうちにも検証タスクなどを回すことで無駄にしない工夫ができます。
そもそもA100 80GB必要？
実は、MPT-7Bモデルの学習にはA100 80GBは不要で、A100 40GBでも学習できます。基本的なGPUプロセッサの計算性能は同等のため、若干のオーバーヘッド分の数%は差が出ますが、ほとんど同じ時間で学習は進みます。
A100 40GBであれば、比較的用意にインスタンスを立てることができるため、予約機能を使う必要もありません。また料金も2-3割ほど安くなります。
PDCAを回して、失敗して学んでいくというスタンスでは、時間・コスト面からLLMの開発では失うものが多いです。
その他注意すること
桁は重要
パラメータ数や学習させるトークン数、計算リソースの単価など、これまでの開発と比較して桁が変わることが多く、普段使わない桁数を扱うことも多いです。
そのときに、普段の感覚と違うことから1桁ずれた理解のまま議論を進めてしまうこともないとは言い切れません。
必ず、複数のメンバーで数字ずれていないか確認しましょう。
大手のメディアさんでもパラメータの桁数を間違えたりしています。日本人にとってbillionという単語は直感的じゃないのかもしれません。
（今回の200万円の無駄遣いはこれが主たる要因だったりします）
結局、LLMの学習はできる？
結論から言うとLLMの事前学習もファインチューニングも、十分な威力を発揮します。
LLMはzero/few-shot学習能力を評価されることが多いですが、独自ドメインに特化させていくには、独自に学習させていくことは十分検討に値すると考えています。
特に、モデルパラメータごとに必要な学習量はノウハウとして推計できるため、事前の計画を丁寧に立てることで、予算の範囲内で適切な学習を行うことができます。
おわりに
本記事では、LLMの事前学習周りの開発裏話を公開しました。
Lightblueでは、日本語での事前学習済みモデルの公開だけでなく、こういった裏話の公開もNLPコミュニティへの還元として重要だと考えています。
実際に開発する際に起こり得る失敗というのを広く公開することで、これから取り組む方々への戒めとなれば幸いです。
今回のしくじりですが、Google Cloudのスタートアッププログラムのおかげもあり、会社からの実質的な持ち出しはなく失敗することができました。
無償で提供いただいたクレジットとはいえ、開発に最大限活かしたいのがスタートアップとしての本音ではありますが、今後の開発体制を改めるきっかけとして大きな失敗をできたことに本当に感謝しています。
Lightblueでは、今回、LLMの事前学習済みモデルの開発・提供を通して社内体制の見直しも図っています。
生成AI特化チームとしてLLabを開設しました！チーム立ち上げメンバーを募集中です。
4畳半（6人掛）から15人掛のオフィスに拡張しました！w
2023年中にカスタマーサクセス、コンサルチームを立ち上げ予定です。こちらもチーム立ち上げメンバーを募集中です。
LLabチームでは、日本語で誰もが便利に使える基盤モデルの開発や提供基盤のGPU環境の整備に取り組んでいきます。これまでもジャーナル投稿や人工知能学会へ参加してきましたが、よりAIコミュニティへのコミットを強化していきます。
最後に、普通の人がみんなAIの恩恵を受けられる社会を作ることに興味を持ってくれた方は、ぜひ、連絡ください。
焼肉ランチに行きましょう！
ここには書ききれなかったしくじりや、今後の開発スケジュールなども話せる範囲でお話しします！
この記事が気に入ったらサポートをしてみませんか？