スタートアップでゼロからLLMを訓練する
(yitay.net)- Rekaはクリーンな状態から大規模言語・マルチモーダルモデルの訓練インフラを構築する中で、コンピュート確保よりも クラスター品質のばらつき と運用の不安定さのほうが大きなボトルネックになった
- 同じH100 GPUでも供給元やクラスターによって、ノード障害、配線問題、GPUエラー、I/O・ファイルシステムのボトルネック、チェックポイント削除、納期遅延が重なり、ハードウェアくじ のような状況が生じた
- GoogleのTPU・社内インフラの経験とは異なり、外部GPU環境ではマルチノード学習、配線、サポート品質の差が大きく、MFU とダウンタイムがクラスターごとに大きく異なった
- 複数クラスターと大容量データ移動、外部コードベースの制約を受け入れる必要があり、RekaはPyTorchベースへ移行しつつ、監視、効率的なチェックポイント、カスタムファイルシステムを自前で構築した
- 限られたコンピュートのため、Big Tech流の体系的なスケーリングではなく、少数の短いアブレーション実験と Yolo run に頼らざるを得なかったが、その結果21BのReka Flashと7Bのedgeモデルを作ることができた
クリーンな状態から訓練インフラを作る
- Rekaは 高性能なマルチモーダル言語モデル を訓練する中で、大規模言語・マルチモーダルモデルを ゼロから訓練 するために必要なインフラを新たに構築した
- 核心的な難しさはTPUとGPUのどちらを選ぶかではなく、外部インフラとコード環境で実際の訓練を安定して回せるだけの 運用品質 を確保することだった
LLM時代のハードウェアくじ
- モデル訓練の第一条件はコンピュートの確保だが、実際には供給元・クラスター・アクセラレータ接続品質のばらつきが最大の変数として作用する
- 同じH100 GPUでもクラスター全体の品質は大きく異なり、ここでいうハードウェアはチップそのものより クラスター全体の品質 に近い
- Rekaは複数のコンピュートプロバイダから数百〜数千チップ規模のクラスターを借りていたが、その状態は比較的対処可能なレベルから、数時間ごとに失敗するレベルまでさまざまだった
- 一部のクラスターでは配線問題やGPUハードウェアエラーのため、ノードが短い周期で失敗した
- 同じプロバイダのクラスター同士でも堅牢性には大きな差があった
- ノードが安定していても、I/Oやファイルシステムが悪ければチェックポイント保存がタイムアウトしたり、クラスター利用率が大きく低下したりする
- 一部のコンピュートソースは実行のためにまったく異なるソフトウェアスタックを要求し、自前のコードベースを持ち込んだチームには 移行コスト が追加で発生した
- 事前にどのハードウェアが割り当てられるのか、それがどれだけ堅牢で障害耐性のある体験になるのかを知るのは難しかった
- プロバイダが納期通りに納品できなければ数か月単位で遅れ、他の供給元でも数週間から数か月の間、調達できない状況が起こり得た
- 一部のプロバイダはチェックポイントを誤って削除することさえあった
MFUと障害対応のための社内ツール
- クラスターごとに Model Flop Utilisation(MFU) が異なり、誤配線されたノードやプロバイダ側の問題に当たると無視できない量のコンピュートが無駄になった
- ファイルシステムが非常に非効率な環境では、誰かがクラスター間で大量データ転送を始めるだけで、訓練実行のMFUが急落することもあった
- プロバイダのサポート水準にも大きな差があった
- 丁寧なサポートから無関心な対応までさまざまだった
- 「ChatGPTスタイル」の定型応答や、あらゆる問題をユーザーのせいにする対応もあった
- 各クラスターは固有の悩みと障害モードを持ち、クラスターごとに個別のホットフィックスが必要なように感じられた
- Rekaは使える環境を作るために複数の社内ツールを構築した
- 監視 ツール
- 効率的なチェックポイント
- 複数の最適化
- スケーラブルなデータ保存のためのカスタムファイルシステム導入
- こうしたツールの組み合わせにより、劣悪なハードウェアでもダウンタイムを減らし、MFUを意味のある形で改善できた
GPUとTPU経験の違い
- Rekaは主にGPUでモデルを訓練した
- Googleで大規模言語モデル訓練にTPUを主に使っていた経験と比べると、CUDAとncclは見慣れない環境だった
- GPUの障害率は、GoogleでTPUを使っていた経験とは大きく異なっていた
- Googleの UL2 20B は作業が誤って1か月間動き続けても失敗しなかった
- GPU環境なら最初の数日で失敗していたはずだと見ている
- ただしこの差はチップそのものより、アクセラレータを管理する ハードウェアチームの力量 とプロバイダのサポート品質により関係している可能性が高い
- GPU環境のマルチノード訓練は、TPU podのように分散訓練を第一級の概念として扱っているというより、後付けの要素のように感じられた
- プロバイダごとにマルチノード訓練を可能にする配線方式が異なるように見え、この差が場所ごとのばらつきを大きくしていた
マルチクラスター運用の負担
- Googleの社内インフラは Borg、Xmanager、Colossus 上で、どこからでもアクセスできる環境だった
- 外部環境では複数のクラスターに新しい環境を自分たちで構築する必要があり、これは以前の経験と大きく異なっていた
- 一か所に大規模なアクセラレータプールを自前で作らない限り、複数クラスターのアクセラレータプールを使う状況は避けられないように見える
- GPU不足は調達を自然に 分散クラスター の形にしてしまう
- 大規模モデル訓練には数十TB級のデータが必要で、データを動かすこと自体が大きな負担になる
- 非常に大きな規模ではデータ複製も簡単ではなく、コスト負担も大きい
- 理想形は複数サーバーへジョブを送るオーケストレーション層だが、軽量で新しいスタートアップが初期からこうした高度なML訓練インフラを持つのは難しい
- Rekaは複数の社内ワークフローで問題を緩和しており、世界最高水準の実験インフラに向けて進み続けている
- このようなスクラッピーな構成は、最上位層や大企業以外ではおおむね一般的だと聞いているという
外部コードベースとPyTorchの選択
- 好んでいたコードベースは T5X と Mesh Tensorflow だったが、Rekaでは現実的な選択肢ではなかった
- Google外でのサポートがあまりない
- ある程度deprecatedな状態にある
- チーム内のGoogle出身でない人たちにとって親和性が低い
- Rekaはよりバニラに近く、安定して見え、広く使われている PyTorch を選んだ
- 初期にはpip、git、dockerのような外部開発環境に適応する必要があった
- 外部でGoogleのコードベースを安定的かつユーザーフレンドリーに使うのは難しかった可能性もある
- 外部コードベースの品質は、Googleで慣れていたコードベースよりかなり見劣りすると感じられた
- Googleの社内コードベースはNoam Shazeer、Barret Zoph、Adam Roberts、Hyung Won ChungなどのML研究者が直接書いていることが多かったと見ている
- 他社が作ったコードの中には、コード品質に特に不満を感じるものもあった
- 一部のコードベースではモデル並列化の設定を変えるために別途コンバータを書く必要があり、並列化変更が自動では提供されていなかった
- 大規模encoder-decoder訓練やprefixLM訓練のサポートも不足していた
- flash attentionはGitHub Issueで妥当な需要があったにもかかわらず、prefixLM訓練、つまりカスタムマスク対応を引き続き提供していなかったという
- Jaxを使うべきだという認識はあったが、スタートアップで素早く動くためにPyTorchを選んだ
限られたコンピュートとYolo run
- 体系的なモデルスケーリングは通常、1B → 8B → 64B → 300Bのように小さなモデルから大きなモデルへ複数段階の実験を行い、勝ち残ったものをさらに拡大する方式だ
- スタートアップでは、ハイパーパラメータを確認するための大規模スイープを行えるだけのコンピュートがはるかに不足していた
- Rekaは多くの Yolo run に依存したが、結果としてうまくいったと見ている
- 少数のより小規模・短時間のアブレーション実験だけで、強力な21BのReka Flash、7Bのedgeモデル、そして予定されている最大のcoreモデルにまで到達した
- 限られた実行回数で良いレシピを見つけるのは難しく、探索空間が非常に大きいため、一度に多くの変数を変える必要があった
- Big Tech流の体系性の代わりに、Yolo、勘、直感に大きく頼らざるを得なかった
- チームメンバーが以前のMLキャリアで培った直感は、少ない試行の中で当てる助けになった
- 以前の職場で良いモデルを訓練した経験があっても、訓練インフラ、データ、新しいアイデアの統合、環境問題の違いが結果に小さくない差を生むことがある
- 強い事前経験は探索空間を大きく狭め、少ない試行・資源・実験で強いモデルを訓練できたことのわかりやすい説明の一つと見なせる
1年未満の成果と残る課題
- コンピュート不足と不安定なコンピュート供給元は、予想よりはるかに大きな困難を生んだ
- Rekaは会社を立ち上げて資金を調達し、チップを購入したうえで、すべてをゼロから構築した
- 1年に満たない期間でGemini Pro/GPT-3.5に匹敵し、多くのモデルを上回ったとしている
- データパイプラインと人手評価などは、なお今後扱うべきテーマとして残っている
1件のコメント
Hacker News の意見
この文脈でいうスタートアップは、結局のところ少人数と、学習クラスタに使う大きな資金を持つ組織のように見える
記事では複数のサーバーレンタル事業者がいて、そのサーバーが複数のスタートアップや既存企業へ行くことを前提にしている
結局、複数の LLM 開発者が似たようなハードウェアと似たようなデータでテキスト・画像の学習を行い、おおむね同じことをして、それぞれが「秘伝のソース」で差別化しようとする構図になっている
そうした秘伝のソースが LLM の出力品質に差を生むことはあり得るが、全体としてはエネルギーを大量に使う巨大な重複作業に見える
最終的にはごく小さな割合だけがそこそこの成功を収めるだろうが、進歩の最前線では支払うべきコストである
計画された独占のほうが効率的な場合はあっても、そのような構造がイノベーションで市場に勝つことはまれである
創業者たちは「ほぼ最先端」の LLM を学習できるという理由だけで買収されることを期待しているようで、その程度の能力とインフラは、その上に何かを積み上げるだけの価値があるかもしれない
ただし、その話は投資家に説明するのがはるかに難しい
実際には、多くのスタートアップが作家や写真家を雇い、汚染されておらずラベルが非常によく付いた学習データを作っているのだと思う
civitai のほうを見ると、小さな計算予算でも、細かなラベリングだけでどこまで行けるかが分かる
LLM の大半の活用事例は、既成の基盤モデルをファインチューニングすることで支えられる
基盤モデルをゼロから学習するなら、収益化が難しい市場に入ることになるし、大手が新しい基盤モデルを 1 つ出すだけで、自分のモデルがやっていることの 95%以上をこなしてしまう可能性がある
文脈上、Yi Tay は Google PaLM、UL2、Flan、Bard などのテックリードで、現在は Reka の共同創業者である
Reka はここにも投稿されたことがある、興味深い小型マルチモーダルモデルをリリースしている
Google 出身者が独立系スタートアップで LLM を学習する立場なので、この文章を書いてほしいと依頼した: https://twitter.com/YiTayML/status/1765105066263052718
会話の録音はここにある: https://sub.thursdai.news/p/thursdai-feb-15-2024-openai-chan...
この記事で reka.ai を知ったが、HN ではまだ Reka の LLM はあまり取り上げられていないようだ [1]
好奇心からこの 1 時間、チャットインターフェース [2] で ChatGPT 4、Gemini Advanced、Claude 3、Mistral Large と比較しながらプロンプトを試し、その結果を [3] に載せた
全体として、Reka Flash は他のモデルより大きく悪くも良くもないように見える
もちろん、確かめるにははるかに多くのテストが必要である
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://chat.reka.ai/chat
[3] https://gally.net/temp/20240307llmcomparison.html
著者が、読者は「荒野」をGoogle ではない場所として理解するとただ前提している点は指摘しておきたい
この記事は Google のインフラとハードウェアチームに多くの功績を認めているが、その内側にいた人が、その後別の場所で関連する仕事をしてみた視点も読んでみたい
より正確には「キャリアを通じて Google の中で Google TPU を使っており、その故障の出方には慣れていたが、GPU の故障の出方はまったく知らなかった」に近い
主に GPU を使っていて TPU を使ってみたときは、デバッグしづらい理由でジョブが失敗し続けた
x86 チップと TPU デバイスの間にある間接レイヤーのせいで何時間も頭を抱えることが多く、x86+NVIDIA+PyTorch では経験しない種類のものだった
10〜15年前の Google は、1,000万ドル以上の価値を持つデータサイエンティスト、つまり Sawzall エンジニアを多く輩出し、彼らも「荒野」に出て似たような反応を示した
この記事はコミュニティに有用な記録を残すというより、筆者が自社と個人ブランドを持ち上げる性格のほうが強いように見える
私の考えでは、大規模学習でも GPU の故障を経験したことはない
現在の学習バッチジョブは、ロードだけで 6 時間かかる 20GB の JSON ファイルで、15 日以上問題なく動いており、さらに古い Tesla T4 を使っている
GPU にはメモリ制約の問題はあるが、計画して回避できるなら、実際にクラッシュを見たことはない
かなり明確な比喩に見えるし、大規模インフラプロジェクトを行うスタートアップなら、本物の荒野にキャンプを張るように物流体制を自前で構築しなければならない
Seven of Nine が Collective から切り離され、取るに足らない人間の能力に頼らなければならないと気づく場面のように読める
サプライヤーに関する洞察は有益だった
まさか学習の進捗をすべて失うわけではないだろうから、苦痛は主に問題を診断し、クラスタを再起動することにあり、データ損失は心配しなくてよいのだろうか?
ところで、彼らが売っている製品は何なのか？
Reka.AIのメインページは、トークン単位で課金する一般的なChatGPTクローンのように見える
他社と何が違うのか分からないし、価格もChatGPT 3.5-Turboと似ているように見える
LLMをゼロから学習する問題は、AIの反復速度と幅に、素のハードウェア改善と同じくらい大きな影響を与える非常に重要なテーマである
記事は面白いがやや浅く、数年にわたって何らかの形でGPUクラスタを扱ってきたなら、技術的に深いものでも驚くようなものでもない
元Googlerの視点は良かったが、Googleの外でLLMをやるときに、かつての同僚たちがなぜPyTorchよりJAXを勧めたのかはよく分からない
この新興企業が後で、学習の道のりについてより技術的なレポートを出してくれるとよい。たとえばこのPDFのようなもの: https://github.com/facebookresearch/metaseq/tree/main/projec...
Google寄りのバイアスもおそらく混じっているはず
大きな疑問は、正しいバックグラウンドと血筋を持たない小規模スタートアップが、LLM製品でどう資金調達するのかということ
LLMスタートアップの世界は、ヘッジファンドやプライベートエクイティの世界に似てきている
シード投資と資金調達の前提条件は、A) 名門での経歴と正しい血筋、B) 製品が始まる前から飛び込む準備のできた強固な投資家ネットワーク、のように見える
VCがこういう会社に投資する理由も、おそらくそのためだろう
世界中で資金調達に値する正しい経験を持つ人は非常に限られており、資金調達できる人だけがその経験を積めるので、自然な参入障壁が生まれる
少なくとも計算コストが十分に安くなるまでは、そうなりそうだ
「会社を立ち上げ、資金を集め、チップを買い、1年もたたずにすべてをゼロから構築しながら、Gemini Pro/GPT 3.5に匹敵し、多くのモデルを上回った」というくだりを見ると、GPT 3.5レベルのLLMに到達するためにチップやクラウドGPUへ投じた予算規模が気になる
ざっくりした桁でも、200万〜500万ドルくらいだったのだろうか？
タイトルは「ground zero」より「from the ground up」であるべきではないかと思う: https://en.wikipedia.org/wiki/Hypocenter
慣用句としては完全に受け入れられる用法である
LLMがテック業界にとって比喩的な核爆弾だという意味かもしれないが、正直なところ自分も混乱した
そういうタイプの著者から学びたいとは思わない
Googleのシステムが安定している理由は、Googleが25年にわたってデータセンターのハードウェア、ソフトウェア、プロセス開発に数百億ドルを投資してきたからである
より小さく成熟度の低い組織の非常に有能なチームでも、常にはるかに低品質な成果物しか出せない
もう一つ考慮すべきなのは優先順位である
Googleは安定性を優先し、比較的まれな故障であっても繰り返し失敗する部品は退役させる
より小さく洗練度の低いデータセンターは、頻繁に故障する部品も使い続けたり、特定部品の故障率を監視すらしていなかったりする
小規模なデータセンターは、Googleの古い部品や信頼性の低い部品を買って使うこともある
したがって、機械が不安定だからといってハードウェアチームの能力を示すわけではない
ハードウェアの低い安定性が作業を遅らせるなら、不安定なハードウェアに耐えられるようソフトウェアを改善するか、より安定した、より高価なハードウェア提供業者へ移ればよい