ベアメタルで70Bモデルを訓練するためのインフラ構成とオープンソーススクリプト
(imbue.com)- Imbueは少人数のチームで、自社のベアメタルインフラ上で70Bパラメータモデルをゼロから訓練し、クラスター構築から障害復旧までの運用手順とスクリプトを公開した
- クラスターはH100 GPU 4,088基とGPUサーバー511台で構成され、各サーバーの8基のGPUがInfiniBandを通じて大規模な同期訓練に参加した
- 実際の構築は、個別マシンのプロビジョニング、InfiniBandファブリックの整備、ホストのヘルスチェック、訓練エラーの診断、自動化の改善を繰り返す過程であり、約10%のマシンの起動失敗や大量のポート警告に対処する必要があった
- 公開ツールには、ホストのヘルスチェック、NCCLロギングパッチ、GPUストレステスト、NVLink・InfiniBandネットワークテスト、UFMイベントログパーサー、InfiniBandバーンインワークロード生成スクリプトが含まれる
- 大規模LLM訓練では、単一の不安定なホストやリンクが実行全体を遅らせる可能性があるため、自動ヘルスチェック・障害隔離・再起動・ポート無効化が継続運用の要となる
独自70Bモデル訓練のためのクラスター構築
- Imbueは数か月にわたり自社インフラ上で70Bパラメータモデルをゼロから訓練し、このモデルは推論関連タスクでzero-shot GPT-4oを上回った
- 公開範囲は、初期クラスター起動、OSインストール、訓練中のエラー自動復旧に至るエンドツーエンドのインフラ手順である
- あわせて公開したインフラツールは以下の通り
- Host-level health checks: ホストが既知のエラーなしで訓練に投入可能か確認するスクリプト
- NCCLパッチ: エラーやハング時により多くのログを残すよう改善
- GPU stress test: GPUが大きなテンソルを割り当て、標準的な演算を実行できるか検証
- Networking tests: 同一マシン内GPU間のNVLink通信と、別マシンGPU間のInfiniBand通信を確認
- UFM event log parser: Unified Fabric Managerイベントログを解析し、無効化すべきネットワークポートを判断
- InfiniBand burn-in workload generator: 利用可能なすべてのリンクにストレスをかけるInfiniBandバーンインワークロードを生成
クラスターとネットワーク構成
- 中核クラスターはH100 GPU 4,088基をGPUサーバー511台に分散配置し、各サーバーはGPU 8基を搭載した
- GPUサーバーが511台である理由は、一部の接続をInfiniBandネットワーク管理用のUnified Fabric Manager(UFM) ノードに予約する必要があったためである
- 各GPUはConnectX-7カードに直接接続され、InfiniBandネットワーク上の別GPUと、自身のConnectX-7カードを通じて同時に400Gbpsで送受信できた
- InfiniBandトポロジーは、すべてのGPUが理論上最大速度で同時に別GPUと通信できるfully non-blocking構成だった
- 3段階のInfiniBandスイッチアーキテクチャがネットワーク全体のスループットを提供
- 訓練通信はイーサネットではなくInfiniBandで実行
- イーサネットはデータセット、チェックポイント、その他のデータ転送に使用
- イーサネットで訓練通信を送ると、GPUからCPUへ移動した後に100Gbpsのイーサネットカードから送信されるため、はるかに遅い
- RoCEによるイーサネット訓練も可能だが、ハードウェアとソフトウェアの両面で追加作業が多く、一般にInfiniBandより信頼性が低い
- 別系統の管理用イーサネットネットワークは、BIOS、電源ユニット、低レベルのマシンインターフェースコントローラーへのアクセスに使用
- この管理ネットワークがなければ、数百台のマシンをUSBドライブ、キーボード、モニターで手動設定する必要があった
- 大規模な高性能訓練では、InfiniBand、イーサネット、GPU、ノードがほぼ完璧に動作する必要がある
- 12,000超の接続のうち1つでも不安定なら、訓練実行全体が遅くなる可能性がある
個別マシンのプロビジョニング
- 初期の管理ネットワークでクラスターにイーサネット接続を作成した後、BMC(Baseboard Management Controller) へのアクセス認証情報を確保した
- BMCはホストを遠隔監視するサービスプロセッサである
- ハードウェア状態、BIOS設定、電源管理APIを提供する
- 最初のサーバーにはDellのBMCであるiDRACを使ってUbuntu 22.04を手動インストールした
- ローカルコンピューターのISOイメージをマウントして起動でき、ブラウザベースの仮想コンソールも提供した
- 目標は、この手動インストールを全工程で唯一の手動インストールにすることだった
-
MAASとPXEブート
- 最初のマシンを準備した後、Ubuntu MAAS(Metal-as-a-Service) を導入して残りのサーバーをプロビジョニングした
- PXEブートと自動化されたiDRACツールで、各マシンにネットワークから起動するよう指示した
- サーバーはDHCPでMAASからIPを受け取り、初期カーネルをダウンロードした後、ローカルドライブが空でも永続的なOSインストールを自動実行した
- 実際には、MAASとBMCの連携が安定しなかったため、iDRAC APIで全マシンのMACアドレスを事前収集した
- MAASは訓練全体を通じて概ね信頼できたが、初期には設定固有の問題があった
- クロック差が大きく、HTTPS証明書検証に失敗してaptインストールが止まった
- MAASサーバーがDHCP、DNS、HTTPプロキシ、NTP、cloud-init設定管理、MAC・IP・ホスト名・メタデータの基準データベースを同時に担っており、原因追跡が難しかった
-
起動失敗と基本的な可観測性
- 大規模GPUクラスター構築でよくあるように、約10%のマシンが起動に失敗し、主な原因はサーバーの物理的な問題だった
- イーサネットケーブルの未接続または誤配線
- iDRACハードウェアの問題
- 電源ユニットの故障
- 不良NVMeドライブ
- 内部配線の欠落
- ネットワークカードやGPUが認識されない
- Imbueはこれらの問題に対するチェックを自動化し、一部マシンはDellの再検査に回し、データセンタースタッフに必要なチケットを登録した
- インフラ構築を自ら行ったことで、修理待ちの間も正常なマシンをすぐ利用できた
- すべてのサーバーにはDocker、データセンター向けGPUドライバー、Prometheus node exporter、NVIDIA DCGM exporter、そしてOS以外の全ドライブにRAIDZ ZFSプールを導入した
- ZFSにより、ドライブ1本が故障してもマシンを維持でき、透過圧縮によってプレーンテキストのデータセットや繰り返しログの保存容量を大幅に削減できた
- 400台のノードに並列でソフトウェアパッケージをインストールする際、帯域幅ボトルネックが発生した
- データセンター配備の複数コンポーネントで高温アラートが初めて発生し、初期の熱問題の大半はファームウェア更新で緩和された
- 大規模GPUクラスター構築でよくあるように、約10%のマシンが起動に失敗し、主な原因はサーバーの物理的な問題だった
-
単一ノードGPU訓練の確認
- 各マシンが独立して実際のGPUワークロードを処理できるか確認した
- 複数のマシンは次の問題により単一ノードGPU訓練に失敗した
- GPU関連のエラーは大半がカードをスロットに差し直すことで解決した
- UbuntuサーバーログにPCIe接続が
limited width: x4 < x16と表示された - PCIeスイッチバスのファームウェア更新後も、クラスターの約4分の1のホストで内部PCIeケーブルの再装着が必要だった
- 欠陥として表示されないが、アクセス時にマシン全体をフリーズさせるNVMeドライブがあった
- Linuxでハードディスク順序がランダムに表示され、MAASがOSを誤ったドライブにインストールした
- 誤った温度読み取りによりファンが常時100%で回転した
- CPUの動的周波数スケーリングがアクティブコアを2GHzに制限していた
- GDR、つまりGPUDirect RDMA Peer Memory Clientの適用に失敗した
InfiniBandのプロビジョニング
- InfiniBandは中央集権的な設計のおかげで、ネットワーク全体に単一の制御主体があり、320台のネットワークスイッチを1つのファブリックとして扱えた
- 最初の作業は、どのスイッチがどのマシンに接続されているかを把握し、配線図と照合して物理的位置に基づいてスイッチ名を変更することだった
-
誤ったファブリック設計と再配線
- 当初、UFMは320台のネットワークスイッチを検出できず、ファブリックに存在するはずのホストも見つけられなかった
- データセンターパートナーと確認した結果、スイッチは電源が入っており配線もされていたが、検出されていなかった
- ネットワーク配線リストを調査すると、上位ファブリックは1つの統合ファブリックではなく、共通のルーティング経路を持たない8つの分離されたネットワークで構成されていた
- 再配線後は、すべての物理接続が新しい設計と一致しているかを確認するチェックを追加した
-
温度警告とポートエラー
- 物理配線の問題を解決した後、UFMはすべてのInfiniBandスイッチに接続できたが、ほぼすべてのスイッチポートが過度な高温を報告した
- 実際のデータ転送前であっても一部のポートは摂氏70度を超えており、原因はネットワーキングラック内でスイッチ間の空間を通って熱い空気が前面に再循環する構造にあった
- 多くのポートは高いエラー率を示すか、正常状態と故障状態を行き来するリンクフラッピングを見せ、この問題はポートが実際に使用されたときにのみ現れるため、事前検知が難しかった
- ファブリック全体は1万本のリンクと高い冗長性を備えていたが、ファブリックの約10%に問題が出ると、adaptive routingのような機能でも不規則に切断するリンクを十分に迂回できなかった
- データセンターパートナーが警告ポートを清掃して再装着し、交換待ちの残りの警告トランシーバーは無効化した
- この時期には100〜200台のマシンでマルチノード学習を実行し、安定したInfiniBandの部分集合を見つけた
-
InfiniBandのバーンインとGPUDirect RDMA
- InfiniBandの問題をより効率的に診断するため、ファブリック全体の全ポートに対して可能な限り多くのデータを同時に流し込む特殊なワークロードを作成した
- これはクラスター全体で1つの大きなall-reduceを実行する方式とは異なっていた
- NCCLは単一ノード内通信をNVLinkとSXMソケット経路向けに最適化するためである
- UFMは大半のポートで理論上容量の97%超のデータ転送アラートを出し、一部のスイッチは一時的にクラッシュした
- 1日の終わりまで生き残ったポートは十分に堅牢だと見なし、残りは無効化するか後日の修理対象に回した
- GPUがCPUオーバーヘッドなしで通信できるようにGPUDirect RDMAを有効化した
- nvidia-peermemカーネルモジュールを有効化した
- 即時停止を防ぐためにPCIe ACSを無効化した
-
安定マシン群と保守
- 最新ハードウェアのGPUクラスターでは経験則として、毎週マシンの約3%が故障すると見込む必要がある
- すべてのマシンが均等に3%の確率で故障するのではなく、一部の問題の多いマシンが複数の形で繰り返し故障する
- 同じファブリックに多くのマシンを置けば、ランダムなマシン問題を追い続けるよりも、安定していることが分かっているgoldenマシン群を育てられる
- InfiniBandの保守は主に、UFMアラートへの対応、ケーブル・トランシーバー交換、故障スイッチの診断で構成された
- 大規模な退行は通常2つの要因から発生した
- クラスターの半分にだけ適用されたファームウェアアップグレードがUFMの状態を破損し、すべてのInfiniBandスイッチでUFM再起動が必要になった
- GPUボックスを同時に大量再起動すると、UFMの状態更新が殺到してUFMサービスの再起動が必要になった
ホストヘルスチェック体制
- Imbueは、学習ジョブを失敗させたり遅くしたりするさまざまな単一マシン障害を発見し、学習に十分健全なホストを判定するためのヘルスチェックを書いた
- コードはcluster-healthで公開されている
- 多くのチェックはImbueのランタイム環境に特化しているが、目標は学習準備状態について単一の入口からyes/noを返すことだった
-
迅速なヘルスチェック
- GPU Health Check: GPU数、ECC有効化、ECCエラー、NVLinkトポロジーとエラーを確認する
- Disk Space Health Check: ホストのディスク使用率が95%を超えていないか確認する
- Docker Health Check: GPU接続コンテナの実行有無と、モニタリング・プロファイリングコンテナの権限を確認する
- Dmesg Health Check: NVIDIA GPUまたはNVIDIAスイッチのXid・SXidエラーを探し、dmesgログ行が想定可能なログ一覧に分類されるか確認する
- iDRAC Health Check: DellマシンのiDRACエラーを確認し、致命的でないエラーメッセージは無視する
- このチェックはオープンソース公開の対象ではない
- Disk Health Check: zpoolのマウント、Docker接続、ディスクアクセス時のCPU停止有無を確認する
- InfiniBand Health Check: InfiniBandのエラー率上昇と古いドライバーファームウェアを確認する
- Nvlink Health Check: マシンのNVLinkエラーを確認する
- 経験上、学習失敗の原因にはならなかったが、遅くなる可能性はある
- GDR Health Check: マシンでGDRが有効化されているか確認する
- VBIOS Health Check: GPU VBIOSバージョンとH100ベースボードファームウェアが最新か確認する
- Flint Health Check:
flintとhca_self_testでMellanox OFEDドライバー、カードファームウェア、トランシーバーファームウェアのバージョンと、NVIDIAドライバーのコンパイル状態を確認する - PSB Health Check: PCIeデバイスを照会し、GPU、PSB、ネットワークカード間の接続速度と幅が期待どおりか確認する
- Dellが開発したスクリプトのため現在は共有できない
-
より長いヘルスチェック
- PyTorchで行列計算を初期化し、NVLink帯域幅、GPU計算速度、メモリを測定する
- GDRフラグを設定してInfiniBandとNVLinkの両方をテストする
ib_write_bwと--use_cudaでIBカードにデータを送り、PCIeとInfiniBandカードの帯域幅を測定する- フラッピングするInfiniBandリンクを捕捉するため約15分間実行する
- マルチノード診断の実行で、NCCLを初期化できるかとランダムな停止がないかを確認する
- 停止した場合、フォークしたNCCLコードが追加ログを残す
- 問題検知に12〜24時間かかることがあるため、新規ノードや疑わしい状況で主に実行する
- DCGM exportsでGPUクロックスロットルイベントを確認するが、想定内の
gpu_idleとpower_capは除外する - すべてのGPU、InfiniBandカード、CPU、ディスクを同時に使うマルチノード学習が、電力イベントを最もよくあぶり出す
訓練中の一般的なエラー診断
-
開始直後のクラッシュ
- 開始直後のクラッシュは再現と反復が比較的容易で、最も扱いやすいエラーだった
- まずコードのバージョン、設定、環境変数が正しいかを確認した
- Dockerイメージのキャッシュや不透明なsecrets設定のような中間抽象化が、原因特定を難しくすることがあった
- すべてのマシンがオンラインか、スタックトレースとログを簡単に集約・確認できるかも確認した
- ImbueはLoki、Prometheus、Grafanaスタックを使用している
- 同期型の分散実行では、最初のエラーが無関係な連鎖エラーを引き起こすことが多かった
- 自動再実行システムを作る中で、異なる再実行のログやエラーが混ざらないよう、ログ・エラー集約の重要性がさらに高まった
- よく見られたエラーは次の通り
Forward order differs across ranks...: PyTorch FSDP実装の特性によるもので、再実行で解決できたCUDA out of memory...: 設定とコードの確認、最近のコード変更のロールバックで解決した- CPU/RAM OOM: コンテナ外のホストのdmesgログでOOM Killerの呼び出しを検知するのが有効だった
-
訓練途中のクラッシュ
- ハードウェアが動き始めた後は、すべての診断ヘルスチェックを再実行し、不健全なホストを除外したうえで自動再起動するシステムがまず必要だった
- Xid・SXidのようなランダムなハードウェアエラーは、有意味なPythonスタックトレースなしに実行をクラッシュさせることがあった
- row remappingのように再起動で復旧可能なケースもあったが、uncorrectable ECCエラーは通常、ハードウェア保守や部品交換が必要だった
- 特に不正な形式の訓練データもクラッシュを引き起こした
- コーパス内の非常に大きな単一ドキュメントが、GPUまたはCPUのOOMを引き起こすことがあった
- 完全に決定的なデータローダーを使い、epochまたはstep番号とクラッシュを容易に対応付けた
- データが原因かどうかを確認するため、データ読み込みを無効にしたり、0だけからなるダミーデータに置き換えたりした
- イーサネットの一時切断やディスク容量不足は有用なエラーメッセージとして現れないことがあるため、ネットワークとノード状態の指標を記録して相関を確認した
-
スタックトレースなしの停止
- スタックトレースなしで停止したりタイムアウトしたりするエラーは、情報が不足し安定して再現しにくいため、デバッグが特に難しい
- 代表的なメッセージは
Watchdog caught collective operation timeout...の形式だった - 1台以上のホストがNCCL処理を完了できなかったり、NCCL・InfiniBand接続から外れたりすると、他のすべてのホストがそのテンソル演算で
NCCL_TIMEOUTまで同期的にブロックされた - NCCLライブラリの特性上、どのホストが原因かを見つけるのは難しかった
- ImbueはNCCL forkにロギング変更を追加し、クラッシュ時のin-flightメッセージや処理をより明確にして、問題のあるホストまたはGPUを特定した
- 正常に動作していないホストを見つけるために、特定のログメッセージを出力しなかったホストを確認する必要があることが多かった
- Py-SpyとGDBで停止したプロセスをリアルタイムにデバッグし、NCCL停止、ドライバ停止、Pythonコードのレースコンディション・デッドロックを切り分けた
MFUから見た訓練速度低下
- 一般的な速度低下や、従来観測されていた水準より低いMFU(Model FLOPs Utilization) は、複数の原因から発生する
- まず設定、コード、環境変数を再確認するのが有効だった
- 誤ったモデル
- 誤ったバッチサイズ
- 誤ったUFMまたはNCCL設定
- 誤った
CUDA_DEVICE_MAX_CONNECTIONS
- 平滑化された平均よりも、バッチ単位の即時MFUを測定するほうが、問題の種類の診断に有用だった
-
MFUパターン別の原因
- 訓練開始直後から期待値の1/10未満のMFUで安定している場合、通常はT2またはT3階層の死んだスイッチのようなInfiniBandハードウェア障害だった
- GPUとNICの間のハードウェア問題が原因の場合もあり、dmesgには
PCIe x16 lanes limited by ...と表示される
- GPUとNICの間のハードウェア問題が原因の場合もあり、dmesgには
- 開始直後から期待値の30%のMFUで安定している場合、あるホストのGDR設定またはGDR環境変数が誤っている可能性がある
- 開始直後から期待値の60〜80%のMFUで安定している場合、通常は劣化または故障したInfiniBandリンクが原因だった
- 特定のGPUに接続されたInfiniBand NICが故障していると、NCCLはローカルNVLinkを経由して同一ホスト上の別GPUのNICを使おうとする
- CPUスロットリングも原因となり得るため、特定ホストのBIOS設定調整が必要だった
- 単一バッチで10倍の急落が規則的に発生する場合、ほぼ常にチェックポイント処理または評価に関連しており、epoch・step数と照合して確認できた
- MFUの異常だけで自動アラートを設定するとfalse positiveが多くなる
- 単一バッチでの10倍急落が稀でランダムに発生し、すぐ回復する場合、実行中ホストのいずれかにCPU集約型ワークロードがスケジュールされていることが多かった
- 断続的なネットワーク障害やデータローダーのボトルネックも原因になり得る
- 実行が進むにつれてMFUグラフが徐々に低下し、再起動時に100%へ戻る場合、PythonおよびNVIDIAプロファイラで自動ガベージコレクションが原因であることを検証した
- 自動ガベージコレクションを無効化し、すべてのホストで一定間隔ごとにガベージコレクションを実行すると、スループット低下は解消した
- 初期性能は良いが、その後期待値の70%まで頻繁に急落する場合、NVIDIA GPU clock throttle reasonsとの相関があった
- GPU温度、ホスト冷却ファンの故障・劣化、電源供給装置の故障が原因だった
- 性能自体は良いが、期待MFUの90〜100%の間で高周波ノイズが大きい場合、通常はネットワーク上位層の中程度の劣化やフラッピングリンクのようなInfiniBandハードウェア問題だった
- 訓練開始直後から期待値の1/10未満のMFUで安定している場合、通常はT2またはT3階層の死んだスイッチのようなInfiniBandハードウェア障害だった
-
スループット回帰の確認質問
- 以前に正常動作していたことがあるかを確認する
- 最近のコードマージやドライバ更新のような変更があったかを確認する
- 健全なホストで実行中か、Docker Hub・GitHubのような依存サービスが動作しているかを確認する
- 直前の正常実行と同じコード、環境、設定、バージョン、ホスト一覧、rank順序、random seedで実行しているかを確認する
- 再現可能かを確認する
- 他プロセス、日次crontab、ホスト・DCGM・UFM指標との相関があるかを確認する
- 指標計測ツールが正しいかを確認する
- より小さなモデル、ダミーデータ、チェックポイント保存・読み込みの除去といった縮小コードでも問題が発生するかを確認する
自動化ツールと運用改善
- 学習は良い性能で始められても、最終的には何かが故障するため、人の介入を最小化するツールとシステムが必要だった
- Imbueは小規模チームのため、手動修理を続けるだけの人員が十分ではなく、可能な限り多くのプロセスを自動化した
- 学習実行時の問題の大半は、不良マシンまたはネットワーク構成要素に絞り込まれた
-
不良マシンの自動除外
- クラッシュした実行を最新チェックポイントから自動再起動するシステムを開発した
- 再起動プロセスでは、利用可能なすべてのマシンでヘルスチェックを実行し、その結果に基づいてマシンの健全性を分類する
- その後、最も健全なマシンで学習ジョブを再実行する
-
ネットワーク構成要素への自動対応
- 観測されたネットワーク構成要素の障害はすべてUFMが検知し、UFMイベントログに記録した
- 実際に問題となるイベントは数十種類のうち一部であり、その大半はリンクダウンまたは高いsymbol error countに関連していた
- スクリプトはUFMイベントログをパースして、直近のイベントに関連するリンクやポートを無効化し、メンテナンスチケットを作成し、修理完了後に再び有効化する
-
ローカルファイルシステムミラー
- クラスター内外のイーサネット速度は、大規模分散学習のボトルネックになり得た
- 約10Gbit/sの共有イーサネット接続は、数百のワーカーがデータセットとモデルチェックポイントを同時にダウンロードすると、すぐに飽和した
- Imbueはクラスター内部にクラウドストレージをミラーリングするローカルファイルシステムを構築し、S3から取得しなければならないファイル数を減らした
- マシンが頻繁に無効化または交換されるchurnに対応するため、各ファイルを3重複製した
- consistent hashingで負荷を均等に分散し、churn中のファイル移動を最小化した
- 限られたディスク容量のため、ファイルライフサイクル追跡と不要ファイル削除のツールも開発した
-
ローカル分散Docker registry
- Dockerイメージの転送にはKrakenを使用した
- KrakenはDockerイメージをpeer-to-peerで転送できるようにするオープンソースソフトウェアで、Imbueはほとんど問題がなかったとしている
-
性能監視と不良ホストの特定
- Torch profilerとNVIDIA Nsight Systemsを設定した
- Nsight Systemsは、forward/backward passとNCCL通信にどれだけ時間がかかるかを把握するのに有用だった
- モデルサイズとワーカー数を基準に、通信ボトルネックか計算ボトルネックかを判断する助けになった
- Docker privileged mode、性能監視イベント関連のセキュリティチェック無効化、プロファイル保存のための学習中断が必要なため、使用はやや難しかった
- 遅い学習バッチを検知して原因を特定するツールも作成した
- 最も有用だったツールは、各バッチ時間を監視し、異常に遅いバッチで全ワーカーのスタックトレースをダンプするものだった
- 微妙なハードウェア・ソフトウェア問題を抱えた特定ホストを特定しやすくなった
- ヘルスチェックが十分に成熟する前は、特定のマシン群で学習が失敗しても、どのマシンが原因なのか不明確だった
- たとえば48台のマシングループが失敗した場合、8台ずつの6グループ、6台ずつの8グループで小規模実行を立ち上げる
- 2段階の両方で失敗グループに含まれたマシンを、高い確信をもって問題マシンと判断した
構築過程で得た運用原則
- 特定の学習実行に必要な台数より10〜20%多いマシンを確保しておくと、マシン障害時にも容易に再実行できる
- すべてのマシン同士が近接して接続されるようにクラスターのネットワークを構成すれば、動作する任意の部分集合を利用できる
- 学習中に遭遇したハードウェア・ソフトウェア障害は再発するため、障害タイプごとにテストと自動化ソリューションを書く価値がある
- 不透明なエラーメッセージごとに、より解釈しやすいツールを作ることは有用だ
- 再現性のため、最も単純な変更であっても一度に1つだけ変更するルールを採用した
- 外部ツールを導入したり、新しい人がプロセスに加わったりする際には、後続ステップがその結果に依存する場合は特に、前提を再検証した
- 全体のプロセスには多くの監督と反復が必要だったが、インフラを完全に制御し、あらゆる抽象化レイヤーで問題をデバッグできたことが決定的に作用した
1件のコメント
Hacker Newsのコメント
高性能な学習に自前クラスタを使うには、InfiniBand、Ethernet、GPU、ノードに至るまで、すべての構成要素が完全に動作する必要があり、12,000を超える接続のうち1つでも不安定だと、学習全体が遅くなり得た
インフラ設定のためのオープンソーススクリプトとエンドツーエンドのガイドを公開しており、700億モデル学習ツールキット三部作の1つ。評価とハイパーパラメータ最適化ツール CARBS はこちらで見られる: https://imbue.com/research/70b-intro/
気になる点は2つ。第一に、4,000億パラメータモデルを学習するなら何が変わるのか知りたい。クラスタ全体としてはビデオメモリは十分に見えるが、実際の判断が気になる
第二に、この種のアーキテクチャがモデル学習の最終形だと考えているのかも気になる。あまりに脆弱に見えるので、より良い共有学習メカニズムやアーキテクチャ、より優れたクラスタ構造があるのか知りたい
後者なら、どうやって GPT-4 に勝ったのか知りたい
実際、この文と記事の大部分が Twitter、LinkedIn、Reddit にほぼ一字一句そのまま投稿されているように見えるが、単なるスパムなのか？
https://x.com/imbue_ai/status/1805629547473518695
https://reddit.com/r/learnmachinelearning/comments/1dobgbs/t...
https://www.linkedin.com/posts/mattboulos_training-a-70b-mod...
このうちどの程度が、いつ頃になれば、ゲーミングPC予算の趣味開発者の領域に入ってくるのか気になる
彼らが遭遇した問題を聞くのは面白い
ここではGPUが InfiniBand にアクセスできる構成のようで美しい。直接的に役立つ記事の1つ
良いエピソードで、こうした決定がなぜ下されたのか、その根拠を聞く価値がある
Zuckerbergがポッドキャストで次の1GWモデルを計画中だと言っていたが、実質的に中規模発電所付きのデータセンターという意味なので、なおさら気になる
気になる点はいくつかある。なぜ自前クラスタを構成したのか、クラウドパートナーと欠陥のある機器やスイッチを扱う経験はどうだったのか知りたい
また、all-to-all通信以外にクラスタアーキテクチャを選ぶ際に何を最も重視し、実際に最も価値があったものは何だったのか、Lokiベースだった点以外にロギングインフラはどうだったのか、ローカルDockerレジストリがなぜ必要だったのか、nvidia-container-runtime以外のイメージも使ったのか知りたい
PCIとInfiniBandバックエンドにGPUを接続し、ごく小さなARM調整コントローラだけを置いて相互に協調させる、というわけにはいかないのだろうか。以前の設計の慣性なのか、それとも特殊なGPUコントローラ市場が不足しているからなのか分からない
学習コードを本当に分析し、データを大量に前処理すれば、非常に軽量なCPU/RAMリソースでも可能かもしれないが、GPUが高価なので、システム全体のコストに占めるCPU/RAMの割合は小さく、その程度の最適化に開発時間を使うことが必ずしも必要とは限らない
超大規模クラウド事業者なら、そのような 0.x% のコスト効率も追求する可能性が高い。たとえば .png を .webp（マルチスレッドのロスレス）や .jpeg（ロッシー）に前処理したくなるかもしれないが、GPU が展開できる形式に変えるのは、学習中の CPU コストは減らせても、ストレージと転送コストが増えるため適さない可能性が高い
より正確に言えば、CPU 処理が学習のボトルネックなら、データ前処理と学習スクリプトの調整で可能な限り最適化すべき。ここで言っているのは「十分に速い」と「さらに速い」の間のギャップである: CPU が学習に十分速くない < CPU が学習にちょうど十分速い < CPU が学習に必要な速度より速い
もう一つの問題は、GPU 関連のハードウェア、ドライバ、運用経験がすべて PC 側にある点だ。ARM で動かすにはほぼゼロから始めなければならず、安定化にも多くの追加作業が必要になる。結局、プロセッサ費用を少し節約するために大きなコストを払うことになる
LLM/NLP の経験はないが、画像や音声のワークロードでは、一般的な 4〜8 コア CPU では RTX 2/3/4xxx GPU でさえ完全に活用するのが難しい場合がある。CPU や入出力がボトルネックになるのはそれほど難しくない
彼らが「self-coding」をしているというが、ノーコードやローコードソリューションに近いものなのか気になる
ウェブサイトにも興味を引かれそうな記事がかなりある: https://imbue.com/our-work/
そうしたプロジェクトには、作業をかなり独立した作業パッケージに分割できるという特徴があったが、モデル学習もそのように分割できるのかはよく分からない