この動画は、家庭環境でNVIDIA Grootロボティクス基盤モデルのファインチューニングを行う実践的なコーディングストリームである。配信者は自作のタトゥーロボット「Tatbot」という独自のエンボディメントに対してGroot N1.5モデルを適応させるため、Docker環境の構築からデータセット準備、依存関係の解決まで、実際の開発過程で遭遇する様々な技術的課題に取り組んでいる。リアルタイムでのデバッグ作業を通じて、ロボティクス分野におけるAIモデルの実装における現実的な困難と解決策を示している。
配信開始とセットアップ
YouTubeでテスト中、YouTubeでテスト中、YouTubeでテスト中、YouTubeでテスト中。さあ、今日はいつもとは少し違うことをやってみます。とてもリラックスした感じでいきます。
プレイリストを用意したんですが、まずは音声レベルが適切かどうか確認する必要があります。少し音量が低すぎるようなので、もう少し上げてみましょう。
今度は少し高すぎますね。もう少し下げましょう。私の声とこの音楽を完璧にバランスさせる必要があります。
そうですね、この辺りが良いレベルのようです。もう少しだけ下げてみましょうか。自分の考えも聞こえないくらい大きすぎるので、もう少し下げます。
実際、これで完璧だと思います。X skeletal Ghostさん、調子はどうですか？いい感じに聞こえますね。
これは少しコーディングストリームになりますが、実際にここで紹介してみましょう。XでもYouTubeでもライブ配信中だと思うので、始めていきます。
Finetuning at Homeの紹介
皆さんこんにちは、またHoopoストリームへようこそ。今日は居心地の良い雰囲気でやっていきます。「Finetuning at Home」と呼んでいて、今日は新しいことを試しています。背景に音楽を流しているんです。この楽曲は「Finetuning at Home」というトラックで、これはプレイリストで、UIOウェブサイトで生成されたAI音楽です。AI生成音楽のウェブサイトは100万個もありますが、これはたまたま使うことになったものです。ローファイでチルアウト、シンセウェーブな感じの楽曲の束で、うまくいけばコーディングのための完璧な背景音楽になることを期待しています。
Skeletal Ghostさん、little KMさん、そしてSagarさんからの質問で、GPUクラスターとは何か、VRAMとは何かということですが、我々は家でファインチューニングをしているので、実際にはもっとシンプルなものを使います。
watch -n 0.1 nvidia-smiを使います。基本的に0.1秒ごとにNVIDIA SMIを呼び出します。これがコンピューターで、Ubuntu搭載でGeForce RTX 3090を使っています。
Macでファインチューニングできるかという質問ですが、Mac Studioなどのマシンでは可能かもしれませんが、分からないし、難しいでしょう。CPUでファインチューニングすることも本当に必要に迫られればできますが、とても遅くなります。この3090は、我々がやろうとしていることには適していますが、それはより小さなモデルをファインチューニングするからです。もしこれで十分なパワーが得られないと感じたら、より大きなクラウドマシンでファインチューニングを試すこともできますが、家でファインチューニングすることを目指しているので、その雰囲気を追求していきます。
NVIDIA Grootモデルについて
今日は、NVIDIA Grootと呼ばれるロボティクス基盤モデルを具体的にファインチューニングします。NVIDIA Grootは以前にリリースされましたが、たった2日前に彼らがGitHubリポジトリに大量のアップデートをプッシュして、基本的に彼らのモデルをファインチューニングできるようになりました。彼らはこれをN1.5と呼んでいますが、それが我々が試そうとしているものです。
これは主にNVIDIA GrootリポジトリとHugging Faceロボットリポジトリを利用しています。カスタムエンボディメント用のデータセットでファインチューニングするために、これら両方のフォークを用意しています。
使用しているエンボディメントは以前にお見せしたことがありますが、こちらです。私はこれをTatbotと呼んでいます。タトゥーを彫るロボットです。実際にライブカメラも用意しているので、これがライブのTatbotカメラです。
これは彼らが使ったロボットとは異なります。先週話していた小さなVLAモデル、それはこれらのSO100アームに対応したもので、小さなVLAの訓練に使用されたデータのほとんどもそれらのアームからのものです。
NVIDIA Grootは我々のエンボディメントともう少し似ています。なぜなら、ここで見ることができるように、実際に多様なエンボディメントセットで訓練されており、両手器用な手も含まれているからです。
我々のセットアップは両手操作で、NVIDIA Grootには両手操作データの重要な部分が含まれているので、これをファインチューニングすれば我々のエンボディメントにより良いフィットを得られると感じています。
ファインチューニングの対象モジュール
この場合のファインチューニングは、VLMや視覚エンコーダー、テキストエンコーダー、これらのDITブロックにあまり多くの勾配をプッシュしたくないということです。これらはおそらくすでにかなり良い状態にあります。本当に勾配をプッシュしたいのは、これらの部分、つまり状態エンコーダー、アクションエンコーダー、アクションデコーダーです。
これらは、ここで見ることができるように、エンボディメント固有のモジュールとして記載されています。これらが実際の小さなニューラルネットの塊で、我々のアクションと我々のロボット状態を消費し、それがエンボディメントごとに訓練する必要がある理由です。なぜなら、このロボット状態はエンボディメントによって変わるからです。
NVIDIA用のデフォルトエンボディメントがどれなのか正確には分かりませんが、同じ次元数であったとしても、状態は異なります。関節は異なり、異なるものを表現するので、これらをファインチューニングする必要があり、それが我々がやろうとしていることです。
環境構築とリポジトリ管理
まず最初に、これらすべてを追跡したいので、TatbotリポジトリにMarkdownファイルを用意して、基本的に必要なすべての関連リンクを保持しています。ブログへのリンク、モデルへのリンク、リポジトリへのリンクなど、必要に応じて簡単に開けるようにしています。
そして、リポジトリをクローンするところから実際に実行するところまでの指示をまとめています。これらのものを維持することは常に非常に重要だと思います。なぜなら、2週間後には自分が何をしたか完全に忘れてしまうからです。だから、これがあれば戻って全部実行できます。
このようなフォークで作業している時、作業を始める前に常にやりたいことの一つは、基本的にメインリポジトリからプルすることです。ここで見ることができるように、私のフォークでは35コミット先行していますが、Hugging Face robotメインから5コミット遅れています。これは、私がプルして昨日作業して以来、Hugging Faceチームがすでに何らかのアップデートを行ったということです。
そこで行って、それをクリックして、何を変更したかを見ることができます。dev containerをgit ignoreに追加し、ここでいくつかの引用を変更しました。これらのどれも特に関連性があるものではありません。もう一つのドキュメントを追加し、小さなVLAファインチューニングのためのより多くのドキュメントを追加しました。これは実際にちょっと興味深いです。いくつかの定数、とりあえずこれを後で追加しましょう。まずプルしてから追加します。
定数、いくつかのものをここに追加しました。本当に我々に関係するものはありません。時々マージコンフリクトが発生することがあり、それは非常に厄介ですが、ここでは彼らが追加したもののほとんどが、このコードベースでの我々の違いに影響を与えるべきではないので、シンクフォークしてブランチを更新できるはずです。
これでブランチが更新され、今度はこのブランチが36コミット先行していることが分かります。これでクリーンになり、残りの日は作業に適した状態になりました。今日は何も踏む心配をする必要がありません。
データセットとモダリティ設定
では、ここに入ってpullで、先ほど行った変更をプルしましょう。
今日はこのwatch-n 0.1 nvidia-smiを使います。0.1秒ごとに基本的にNVIDIA SMIを呼び出します。これがコンピューターで、GeForce RTX 3090を搭載したUbuntuコンピューターです。
まず最初にやりたいのは、ここでクローンすることです。depth=1を入れておけばよかったです。そうしましょう。時々、これらのリポジトリでdepth=1を入れると、全部ダウンロードする必要がなくなるので、少し速くなります。
実際にどのくらい速くなるか見てみましょう。このフォルダを削除して、これを再実行してみます。少し速くなりましたが、それほどでもありませんね。
次に、お気に入りのPython環境マネージャーを使って仮想環境を設定し、バージョン11を使います。READMEから取得したことは分かっています。実際にNVIDIA Grootのリポジトリを見ると、彼らはPython 3.10とCUDAバージョン12.4を使用しているようです。これは我々がやっていることと似ていると思います。
古いバージョンのPythonを使うのは好きではありません。仮想環境を作成し、仮想環境をアクティベートし、ここで仮想環境があることが分かります。そして、pip install . baseを実行しました。これは実際に我々が望むもののみをpip installします。
ここで見ることができるように、彼らにはいくつかの異なるものがあります。これは常にインストールする一般的な依存関係の種類で、ここにはオプションの依存関係があります。baseはここにあるもののみをインストールします。例えば、ここにOrinがあります。これは興味深いですね。Orinは我々がTapbotにも持っているのと同じエッジデバイスです。うまくいけば、この3090で訓練して、それをOrinにデプロイできるでしょう。Orinで訓練することもできるかもしれませんが、かなり遅いでしょう。
歌詞があるのは嫌いです。歌詞は嫌いです。リミックスしましょう。でもインストゥルメンタルではありません。削除しましょう。人間の声は入れないでください。リミックスして、今作ったものを試してみましょう。Heat of the Night Remix V2。歌詞が入っているとどうしても集中できないんです。これで大丈夫です、これの方が私の雰囲気に近いです。
データセットの準備
仮想環境をインストールしたので、次はデータセットを取得する必要があります。これには、このような使い捨てのデータセットを使っています。実際に何か有用なことをすることは期待していません。これは基本的にTatbotの、小さなロボットデータセット・ビューアで見ることができますが、基本的にこのパターンをトレースしているだけです。これをキャリブレーションパターンと呼んでいます。
これがどのように見えるかは、こんな感じです。基本的に円、波線、水平線、垂直線です。これらは偽の皮膚で、これが私がタトゥーを彫るものです。
これは本当にただの使い捨てファインチューニングデータセットですが、実際に重要なのはパイプラインを動作させることです。つまり、これをすべてクリーンに動作させ、一度すべてがクリーンに動作すれば、より良いクリーンなデータセットを収集して、それでファインチューニングできます。でも今日は、全部がクリーンに動作させることができれば、それで満足だと思います。
おそらくこの異なる状態空間、異なるアクション空間で出てくるすべての問題をデバッグし、おそらく不正なキーがあるでしょう。それから依存関係の問題も解決する必要があり、さらに評価を実行するための依存関係の問題も解決する必要があります。それが我々が扱っている種類のものですが、これがロボティクスの現実なんです。半分は依存関係の問題を扱うことです。
DATASET_DIRとしてエクスポートし、Hugging Face CLIを使ってそのデータセットをダウンロードします。ダウンロードしました。これが良いところです。パイプラインをデバッグしている時は、実際にフルファインチューニングデータセットを使いたくありません。ファインチューニングデータセットはおそらくこれより少し大きくなるでしょう。
実際に、これらの種類の小さな偽のデータセットを使うことには利点があります。これは4エピソードだけなので、ダウンロードが非常に高速になり、1エポックが非常に高速になります。クラウド環境で訓練している場合、高速ダウンロードになり、多くの容量を占有しません。実際のファインチューニングデータセットと同じ形式だが、はるかに小さいこれらの小さなテストデータセットの一つを持つことは、実際にはチートコードだと思います。
モダリティコンフィグファイル
また、このモダリティコンフィグファイルもコピーする必要があります。これは私が作成する必要があったものです。configに入れて、これがこれまでの様子です。100%正しいとは思いませんが、ここで見ることができるように、基本的にロボットスタイルデータセットをGrootスタイルデータセットに効果的にマッピングする辞書のようなものです。
ロボットスタイルデータセットでは、手首カメラの画像はobservation.images.wristと呼ばれますが、Grootスタイルデータセットでは、それをvideoにして、その中にwristと呼ばれる辞書を追加したいということです。そして、その中におそらく実際の観測があります。ここにはインデックスがあります。グリッパーやアームのインデックスです。
Grootリポジトリの使用開始例に基づいて、これを大体でコーディングしました。使用開始例では、例えばUnitree oneがあります。Unitreeには手、腕、腕、手首、腰、脚があります。それがアクション空間です。UnitreeはG1で、全身制御を行うことができます。つまり、すべての腕、すべての脚、全身を一度に制御しているということです。ロコモーションと操作を分離するのではなく、効果的にVAを使って全身制御を行っています。これが現在人々がヒューマノイドを行う方法だと思います。
ロコモーションと操作の分離を超えていると思います。特に、例えばFigure 01も同様に全身制御を行っているからです。
little KMからの質問で、今週末のLeRobotハッカソンに参加するかということですが、ちょっとだけです。完全にではありません。追跡していて、Discordにいて、何が起こっているかを見ようとしていますが、家族がいるので、土曜日に10時間ハックするために行くと言うのは非常に難しいです。子供の世話をしなければなりませんから。
おそらく実際に何かを提出したり、チームの一部になったりすることはないでしょうが、配信を見たり、Discordで何が起こっているかをフォローしたりするかもしれません。精神的にそこにいると考えてください。オープンソースハッカソンの美学を支持していると思います。これは人々を関与させ、技術的進歩を推進する素晴らしい方法だと思いますが、父親なので参加するのは難しいです。
Unitreeを見ることができます。これはSO100で、小さなアームです。モダリティJSONがどのように見えるかを見ることができます。Tapbotのものは、これにインスパイアされて作りましたが、ここに間違ったものがあることはほぼ確実で、それが今日デバッグしようとしていることです。
Tapbotフォルダから関連するデータセットディレクトリにコピーして、このload_datasetを実行してみましょう。これは、データセットが少なくともある程度正しいかどうかを確認する簡単な方法だと思います。何か間違っている場合は…
初期エラーの解決
すぐに問題が発生しました。「left_armがstateとactionの両方の辞書に見つからないためスキップしています」。これは良くない音ですね。ロボットにleft_armがあってGrootがそれを探しているか、Grootにleft_armがあってロボットにそれがなかったということです。
ここのビジュアライザーを見て、どこかにleft_armがあるかどうかを非常に迅速に確認してみましょう。実際にはそのようなケースではないようです。ここを見ると、これはleft.joint0.poseと呼ばれています。ロボットスタイルでは、画像はobservation.imageと呼ばれ、関節はleft.joint_とそれから数字、それからposeです。なぜなら、それは関節位置だからです。
ここで見ることができるように、基本的に1.65から0.55の間です。ラジアンです。なぜleft_armとright_armが欲しいのでしょうか？実際にUnitreeを見てみましょう。SO100を見てみましょう。これらのキーは存在しますか？state single_arm、action single_arm、state left_leg、left_armです。実際に見えます。single_arm、left_leg、right_arm、left_armです。left_armが欲しいようですね。
arm_lの代わりにleft_armにしましょう。left_hand、left_arm、left_hand、right_arm、right_handにしましょう。
この少し更新されたTapbotコンフィグをコピーして、このload_datasetを再実行してみましょう。もうこれについて文句を言わないことを期待しています。
そうです！state.left_arm.shape 64×6が見えます。64はステップ数です。これを実行した時に、steps=64と指定したからです。基本的にフレームがロボットでの同等の抽象化です。一定時間ごとにフレームを取得します。手がゆっくり動いているのが分かります。各フレームがステップのようなものです。64はある意味でバッチディメンションです。これが実際のleft_armの次元数で、6であるべきです。stateとactionは同じです。これは関節空間制御なので、6×6が正しいです。
left_handは1次元です。なぜなら、このアームには小さなピンサーグリッパーしかないからです。これも正しいようです。
予備的にはOKのような気がします。次のことに進みましょう。
次にやる必要があることは… ちなみに、ここでやるべきことのリストは、このブログ投稿から来ています。NVIDIAチームの多くの人々（皆Nvidia、Nvidia、Nvidia、Nvidia）がHugging Faceでブログ投稿を作成し、LeRobotデータセットを使って彼らのモデルをファインチューニングすることについて話しています。
これは大きな出来事だと思います。なぜなら、NVIDIAにいることを想像してみてください。非常に多くのお金を持っていて、スタックの多くを所有しています。ハードウェアを持っていて、今度はモデル訓練に参入しています。シミュレーションも持っています。Isaac Lab、Isaac SIMなどのすべてのものです。独自のデータセット・ツールとデータセット管理ソフトウェアを作成するのは非常に簡単でしょう。
なぜHugging FaceのLeRobotツールを使うのでしょうか？独自のバージョンを作るでしょう。ビジネスの観点からはそれが彼らがすべきことです。でも彼らはそうしませんでした。「人々はこのLeRobotデータセット形式とそれに付随するツールを気に入っているようだ。私はこのデータセット可視化ツールを書く必要がなかった。LeRobotデータセット形式を使ったという事実のおかげで、これを無料で手に入れることができた」と言ったのです。
これがオープンソースの利点です。同じ種類の標準を使って多くの人が作業すると、多くの進歩を無料で手に入れることができます。LeRobotも非常に簡単にデータセットを管理・ダウンロードできます。すべてを無料で手に入れることができます。でもNVIDIAはそうする必要がありませんでした。
彼らがこれに使うことを決めたのは非常に興味深い動きだと思います。彼らは独自のブログページではなく、HuggingFaceのブログでさえ公開しました。これはオープンソースロボティクスにとって良いことです。つまり、人々がLeRobotデータセット形式とモデル管理などすべてを受け入れ始めていることを意味します。
これは良いことだと思います。なぜなら、あなたのロボットとエンボディメントをこのLeRobot形式で動作させることができれば、このファインチューニングを含む多くのものを無料で手に入れることができるからです。これが我々が効果的にやっていることです。
訓練の実行
次にやる必要があることは、実際に訓練を実行することです。Weights & Biasesにログインしましょう。現在hugとしてログインしています。それが我々です。WANDB_RUN_IDとプロジェクトをエクスポートする必要があります。
これはちょっと面倒です。例えば、小さなVLAをファインチューニングしている時、小さなVLAファインチューニングスクリプトでは、文字通りコマンドライン引数としてWandBオプションをパイプできます。スクリプトを実行する時に、文字通り「このプロジェクトを使用する」と言うことができます。
でも、Isaac Grootのファインチューニングスクリプトではそうではありません。ここのscriptsにあると思います。Grootファインチューンです。その能力はありません。WandBとTensorboardに報告する能力があります。Tensorboardはより自分でやるタイプで、WandBの前に使っていた方法です。でもそれが彼らが持っている唯一のオプションです。実際にWandBプロジェクトを指定することはできません。我々がここでやっているように、環境変数で指定する必要があります。
これを取って実行してみましょう。100%動作しないのは確実です。決して言うなとは言いませんが、動作しないことはほぼ確実に言えます。
何かをやっています。エラーが来ました。「引数data_configのパースエラー：無効な選択tapbot。forier, g_for_g1, unitree_g1, so_100, single_panda, gripper_bimanual_pandaから選択してください」。
何が起こっているかが分かります。この種のマッピングファイルを作成しただけでなく、我々のエンボディメント用のカスタムデータクラスも作成する必要があるということです。これは理想的ではありませんが、そんなに難しくないはずです。
この実際のスクリプトに入って、このdata_configが何をしているかを見てみましょう。data_config_classと検索すると、data_config_mapが見えます。これがすべてのアームです。これが我々のものを追加する方法です。
TapbotとTapbot data_configを追加しましょう。今度はTapbot data_configを追加する必要があります。
これらのクラスがポンド記号で区切られているのが分かります。これらのいくつかはbimanual_panda_gripperからインポート（継承）しているものもあれば、そうでないものもあります。このクラスオブジェクトがこのクラスオブジェクトの子であることを意味します。それに似ていて、いくつかの追加プロパティがあるかもしれません。
これが我々が本当に欲しいものです：base_data_config。ここにbase_data_configがあり、これは抽象クラスです。つまり、実際にこれのインスタンスを作成することは意図されていません。これは本当に継承することを意図しています。
テンプレートとしてこれらの一つを使ってみましょう。bimanualなものを使いましょう。G1 arms onlyのbimanualを使いましょう。これが良い出発点のようです。
FourierArmsOnlyConfigをコピー＆ペーストして、それを調べ、このコメントもコピー＆ペーストしましょう。コードスタイルの正しい考え方は、人々が持っているものを採用することだと思います。私には自分自身の好みのコードスタイルとフォーマット、コメントなどがありますが、必ずしも超こだわる必要はありません。Isaac Grootリポジトリにいるなら、Isaac Grootの標準に従います。
これをTapbot Data Configに名前を変更しましょう。video_keysは、headとwristになります。名前はそうだと思います。我々のGrootモダリティJSONを参照してみましょう。video.headとvideo.wristですね。
順序がここで重要かどうかは分かりません。実際に確認してみましょう。video head hand left hand rightです。時々順序が重要です。この場合は必ずしも重要ではないかもしれませんが、頭が先で、次に手という同じフォーマットに従うべきのようです。headを最初にして、次に手にしましょう。
state_keysはleft_arm、right_arm、left_hand、right_handです。我々も同じものを持っています。
annotation.human.task_descriptionです。我々にはこのaction here wristがありません。我々のはannotation.human.task_descriptionと呼ばれているだけです。他のものも同じかどうか見てみましょう。
これはより我々のものに似ています。annotation.human.taskです。完璧です。それが我々のものとまったく同じです。
observation_indices [0]、これは何を意味するのでしょうか？action_indices list(range(16))。observation_indicesについて見てみましょう。これらはすべて同じです。すべてのロボットエンボディメントがその値に対して同じ値を持っています。それが何を意味するにしても、おそらくそうでしょう。
action_indices list(range(16))、実際には14しかないので、それにしましょう。
video_modality、observation_indices、modality_keys、state_modality、observation_indices、state_keys、action_modality、language_modality、これは何でしょうか？
observation_indicesは、返されるデータが、サンプリングされたベースインデックス＋デルタインデックスで元のデータに対応するということです。基本的にインデックスをオフセットしているということです。それがここでやっていることです。ロボットデータセットには特定の次元ベクトルがあり、それがあなたの入力です。論文に戻ると、このロボット状態には特定の順序があります。ロボットの順序が奇妙だった場合、これがそれを可能にします。その順序を操作することを可能にします。
transform_video_to_tensor。これはビデオパイプラインです。これをファインチューニングしている時に、この画像が変換されてから、この視覚エンコーダーに送ることができるようになります。基本的な観点からでも、これによって消費できるデータタイプに変換される必要があります。最後にはnumpyに変換されますが、その前にはいくつか興味深いことがあります。
video_color_jitterがあります。これはデータセット拡張の一種です。これが行うことは、特にこのようなわずか数エピソードの小さなデータセットがある場合、毎回同じ画像を送りたくないということです。そこにある程度の違い、分散が欲しいのです。これは明度、コントラスト、彩度、色相を非常にわずかに変更します。ビデオで複数エポック訓練していて、同じデータを何度も何度も送っている時に、そこで少し違いが得られるようになります。
224×224にリサイズし、それからわずかに切り取ります。これは不要のようです。なぜ95%で切り取るのでしょうか？それが行うのは端の小さな部分を切り取るだけです。
stateについては、tensorに変換してからsigmoidに変換します。これは奇妙です。すべてがこれを持っているでしょうか？
これはFourrierG1 armsです。SO100を見てみましょう。こちらには video_crop_resize_jitter_numpyがあり、こちらには state_action_to_tensorとstate_action_transformがあり、それから正規化します。こちらの方が少し好きです。
実際にこれを複製できますか？そうですね。これでdata configになりました。SO100に戻りましょう。何らかの理由で、Fourierロボットエンボディメントにはこの奇妙なsigmoidコードがありますが、信用できません。これを行います。
action_concat、そしてgroupです。それをコピーします。
ここにダウンしたのでそれです。これで大体設定できたと思います。この間にはスペースが2つありますね。完璧にして、下にも2つのスペースがあります。
これをコミットしましょう。gitコミットメッセージには、ASDを入れます。これは良い実践ではないとしている不運なことです。こういうことを大量にやってきました。
私のコミットを見ると、どれだけ多くがASD、ASD、ASDだけかがわかります。最初にやっていたことは、自動メッセージを使っていました。基本的にこれを行って自動メッセージを取得できますが、とにかくこれらを読みません。これらの自動メッセージを読みません。1秒のラグが発生します。これをクリックして推論を待ってからコミットする必要があります。
ASDは、手がキーボードでその位置にすでにあるので、実際にはより速いです。gitコミットメッセージの目的は、従来のソフトウェアチームでは多くの人間がいるため、人間が互いのgitコミットを理解できることが有用だということです。彼らはそれらをクリックするでしょう。でも、このAI将来でのソフトウェアエンジニアリングの現実は、誰もあなたのgitコミットを読まないということです。誰かが読んでいたとしても、それはAIであり、AIがあなたのgitコミットを読んでいる場合、そのメッセージを見るのではなく、コミット全体を見るでしょう。
それが私がこの奇妙なASDを始めた理由です。でも、すでにボタンをクリックしたので、追加します。コミット、同期変更。
おそらく再度pip installする必要があるでしょう。最新のものを使わないと思います。これを実行しても、まだ追加されていないので、おそらく同じ文句を言うでしょう。
実際にそこにはまだないので、基本的に再インストールする必要があります。完全に狂ったことをして、文字通り削除して再実行してみましょう。
プッシュし忘れたら非常に悔しいでしょう。プッシュしています。良かったです。
それをリトライしてみましょう。見やすくするために少し大きくします。
これで良さそうです。
今度は訓練を試してみましょう。そのエラーは解決したはずです。
モデルのダウンロードと設定
実際にそれを通過したので、新しいdata configクラスを見つけることができました。これは良いことです。
今、NVIDIA Grootモデルをダウンロードしています。4つのピースに分かれています。safe tensorという形式で、これはもともと、これらのファイルをロードする時に任意のコードを基本的に入れることができたために生まれた形式です。人々はそこにマルウェアを入れることができました。そこで人々がこのsafe tensor形式を思いついて、それを少し防ぐことができました。
1つのGPUを使用、tune_vision_backbone_tower false、tune_backbone_llm false、tune_action_head_projector true、tune_action_head_dit。これはまさに我々が望むものです。tune_backbone_vision_tower、それはここのvision encoderです。tune_backbone_llm falseなので、これはここのものです。これらに勾配をプッシュしていません。tune_action_head_projector、それはここのaction encoderです。tune_action_head_dit、headです。これは、モデルを擬人化したい場合、これがお尻でこれが頭です。action DIT headは、DITの頭部分です。DIT diffusion transformerで、headはここのものになります。
ここの正しいものに勾配をプッシュしているようです。tune state projectorとは言っていませんが、おそらくそこに含まれていると思います。
video_embodiment_tag new_embodiment、これは少し怪しいです。tapbot embodimentのようなものが必要でしょうか？little low rank adapter、これはおそらくファインチューニングの良い方法です。これは、昔の安定拡散ファインチューニングをこれらのLoRAで行っていた方法です。少しのウォームアップ、少し中程度の学習率があります。tune LLM、tune visual、tune projectorです。tune diffusion model、これは興味深いです。
実際にこの拡散モデルにいくつかの勾配をプッシュしています。1,000ステップごとに保存、バッチサイズ8。おそらくこのバッチサイズを上げることができますが、まだ取得できるかどうか確信がありませんでした。
他に何を変更できるかを見てみましょう。実際にファインチューンに入ると、ここにある種のファインチューンコンフィグがあるはずです。スクリプト、Grootファインチューン。これが実際のファインチューニングデータクラスです。
data_output_dir、おそらくtempに入れたくありません。output_dir、いいえ、Tapbotディレクトリの一つに正しく入っています。
max_step、save_steps、tune_llm、tune_projector、resume、learning_rate、weight_decay、lora_rank。0の場合、LoRAは使用されません。条件があるかどうか見てみましょう。config.lora > 0の場合、config.lora_rank。
action_head_onlyなので、おそらく起こっていることは、完全に新しいエンボディメントを使っているので、基本的にこれらをゼロから再訓練する必要があるということです：state encoder、action encoder、action decoder。でも彼らがこれを持っている理由は、同じエンボディメントでも異なるタスクを使っているからかもしれません。リンゴを拾うタスクとモーターを掴むタスクがあるかもしれません。そして、LoRAファインチューンに使っているのは、同じエンボディメントだが異なるタスクのためかもしれません。
bfloat16、これも全く問題ありません。これが訓練組織です。
ステップ300、訓練エポック。これは私が言っていることです。300訓練エポックは、文字通りこのデータセットを300回モデルに送ることを意味します。モデルは文字通り同じエピソードを300回見ることになります。だからこそ、画像拡張をそこに入れる必要があります。そうでなければ、それに非常に激しくオーバーフィットし始めるからです。
おそらくアクション拡張も欲しいでしょうが、それは理論的に健全ではありません。画像拡張の全体的なアイデアは、画像が明度がわずかに高くても、出力するアクションは同じであるべきだということです。でも、アクションを変更することについてはそれと同じではありません。模倣学習の全体的な核心は、人間が基本的に神モードアクションを提供することです。この与えられた入力観測と状態に対して、これが出力すべきアクションです。
アクションノイズやアクション拡張は一般的にアクション拡張ではありません。状態拡張は可能です。状態を取って少しファズすることができますが、今は基本的にこのモデルが実行されるのを待っています。
その間に、ここに小さなNVIDIA SMIを開いてみましょう。control、無効化したくありません。control Rとそれからwatchなので、control Rは非常に有用な端末コマンドです。基本的に古い端末コマンドを掘り起こすことができます。
でも、もうそれを行う必要さえありません。control Kして「watch nvidia」と言うだけで、そこにあります。
0.1秒ごとにフォローアップを追加します。端末コマンドを知る必要さえありません。ツールがはるかに良くなって、やり方を知っているだけです。
これはまだダウンロード中です。どうやって時間を潰そうか？
一つできることは、これをコミットすることです。まだ解決していないことの一つだと思います。例えば、2つの異なるCursorワークスペースが開いていて、実際には2つの異なるコンピューターにありますが、いつも遭遇することの一つは、一方で編集を行ってから、もう一方でプルする時に面倒で、いくつかのマージコンフリクトを解決する必要があることです。
人々は作業ツリー、git作業ツリーでこれを行おうとしました。複数のコーディングエージェントや複数のCursorインスタンスが同じものにコミットしている場合、作業ツリーによってもう少しクリーンになります。でも、それは長期的な解決策のようには見えません。
git kind of workflowは、この新しいパラダイムで何百ものエージェントが同じコードベースで作業している状況下で歪んでいるようです。最も多くストレステストされたのは何でしょうか？人気のあるオープンソースプロジェクトを考えると、おそらく100人程度が真剣にプルして変更を行ってプッシュ、プルして変更を行ってプッシュしているでしょう。でも、このエージェント世界に入ると、同時に何かをGitHubリポジトリで作業している数千のエージェントという規模になるかもしれません。
100万のエージェントがすべて同じコードベースでプルしてプッシュしていたら、確実に何か違うものが必要になるでしょう。プルする頃には、すでに誰かがプッシュしていて、誰かがその上にプッシュしたマージコンフリクトを修正しようとしているからです。かなりクレイジーになるでしょう。
Groot modalityで、これをここで置き換えましょう。保存して、これをcontrol zしましょう。ここで保存、gitここで変更を破棄します。この変更を破棄して、このコンピューターでプッシュできるようにします。ASD、同期。今プッシュして、このコンピューターでプルします。プルしました。
ASDが見えにくくなりますが、いつでもその上にホバーして、この ASDが9:59にプッシュされたものであることを確認できます。これは今行ったものです。
このモデルのダウンロードがほぼ完了しているようです。
flash_attentionがないというエラーが出ました。依存関係の問題です。
まず最初にやることは、これをdata configにコピー&ペーストするのではなく、実際にここのこの正確なファインチューニングスクリプトを開きましょう。これをCursorに与えて、ここでこのコンテキストを与えましょう。チャットに追加して、Cursorがそれを解決できるかどうか見てみましょう。
その間に、flash attentionをコピー&ペーストして、実際のIsaac Grootでここを検索してみましょう。等号ですね。ここで見ることができます。flash attention 2、pip install force-reinstallです。これを行う必要があるかもしれません。
Cursorが何をしようとしているか見てみましょう。NVCC versionを実行します。pipを介してインストールできます。基本的にこれを実行する必要があるでしょう。
どのDockerfileかというと、これはDockerfileで、CUDA 12.4用の2日前のものです。PyTorch 2.6です。これが我々にとってテーマに沿っているかどうか見てみましょう。
PyTorchのバージョンは何でしょうか？Pythonを実行して、torch、torch.version、2.5.1 CUDA 12.4、2.6.0 CUDA 12.4です。全く同じではありませんが、これらは十分似ているので大丈夫だと思います。
また、この正確なCUDA versionを実行してみましょう。CUDA 11？なんで11.5と言っているんでしょうか？それは少し怪しいです。
このDockerfileを使ってみましょう。とりあえずこれをpip installしてみて、動作しない場合はこの訓練をすべてDockerfile内で行います。それは通常、とにかくよりクリーンなやり方です。
uv pip install flash_attentionです。2.41 post legacyビルドホイール。これは良くない状況ではありません。
彼らはここにDockerfileを持っているので、このDockerfileを使ってみましょう。これが最新リリースにあることが気に入っています。このDockerfileが最も最近のN1.5より古かったら、少し心配になるでしょう。
実際にこれを使ってみましょう。指示を変更する必要があります。
Dockerで訓練しましょう。docker build -f Dockerfile -tです。-fはどのDockerfileを使うかを指定し、このDockerfileは文字通りDockerfileと呼ばれています。それからタグを与える必要があります。実際にイメージをビルドしたら、そのイメージを何と呼ぶでしょうか？Groot_trainと呼びます。
それを実行しましょう。少し時間がかかるかもしれません。
このDockerfileをダウンロードしているのが見えます。これらのDockerfileは制御不能です。毎月、これらのDockerfileがどんどん大きくなっているようです。3ギガ、1ギガ、2ギガ、多くのがらくたです。
そのDockerfileをビルドしている間に、docker runコマンドを作成できます。これと非常に似ていますが、実際に実行するものを理解する必要があります。
docker run –gpus –rm、完了したら削除します。Groot evalがGroot trainであることを確認し、実行するコマンドは基本的にここのこれです。ただし、他のこともやりたいです。
-v、このモデルがダウンロードされる場所をマウントしたいです。最初にこの訓練スクリプトが行うことを覚えていると思いますが、このEagle等とプリトレインされたGrootをダウンロードしました。それをマウントしないと、毎回再ダウンロードすることになります。基本的に、このDockerコンテナを実行するたびに、再ダウンロードしようとします。
これはHugging Faceキャッシュの場所にダウンロードされると確信しています。これもマウントする必要があります。データセットディレクトリも同様で、–datasetと言えるようにマウントして、ここで–datasetと言えます。
Hugging Faceキャッシュディレクトリの名前をいつも変更しています。名前を確認してみましょう。HF、キャッシュ、echo hugging_face_cache_location hugging_face_home、それが呼ばれていると思います。そうです。
mount /ssd1/hugging_face、robot calibrationが見えます。
それがデータセットです。
transformer modulesがあり、Eagle HFモデルがあります。それが完全にそれです。
これを取って、このhugging_face_homeをマウントする必要があります。このDockerfileでhugging_face_homeディレクトリがどこにあると思うかですが、探してみることができます。hfを検索しましょう。
homeですね。何が起こるかというと、このPythonスクリプトを中で実行する時、Hugging Face homeディレクトリを検索して、モデルがそこにダウンロードされているかどうかを確認しようとします。それを行おうとする時、デフォルトのHugging Face homeディレクトリを使用し、デフォルトのHugging Face homeディレクトリは、ロードしようとする時にここで設定されます。
scripts、groot fine-tuneに行って、ある時点でプリトレインされたモデルをロードします。
data set video_backend、data_set_path、これは純粋なデータセットパスを取るだけのようです。それは問題ないようです。それを超えて、どこでモデルをロードするかです。groot_n15_from_pretrainedで、ここがbase_model_pathです。base_model_pathはどこですか？base_model_path nvidia/groot-n-1-pointなので、これはHugging Face pathのようなものです。
実際に、これを知っています。このスクリプトはプリトレインされたモデルをどこにダウンロードしますか？
プリトレインされたモデルの重みは、デフォルトでHugging Faceキャッシュディレクトリにダウンロードされます。ファインチューンされたモデルのチェックポイントと出力は、output dirに保存されます。通常、このキャッシュ/.huggingfaceの下です。
我々の特定のコンピューターには存在しませんが、それは… このDockerfileはまだダウンロード中です。全体のストリームを取るでしょう。
それを閉じて、それを仮定しましょう。cache/hugging_faceです。
出力ディレクトリもマウントする必要があります。その出力ディレクトリに出力するためです。-v、outputと言って、ここでDockerコンテナにこの出力ファイルに書き出すように指示します。
WandB変数もここに追加する必要があります。これとこれも同様です。
これをクォートで囲む必要があるかどうか分かりません。このDockerコマンドが正しくフォーマットされているか確認してみましょう。
ボリュームマウントでコロンの周りにスペースはないはずです。エントリポイントコマンドは別の行ではなく、同じdocker runの一部であるべきです。
上に戻りましょう。
これで小さなDockerコマンドの準備ができました。このDockerfileのビルドが完了するのを待って、テストアウトできます。
このビルドを待っている間にできることは、OrinにSSHして、それで評価をデバッグしてみることだと思います。
これを閉じましょう。これが我々の訓練コンピューターで、これが我々の評価コンピューターになります。実際にここで、このコンピューターでのコミットをプッシュしましょう。変更されたのが見えます。戻って、プルします。それで良いはずです。
今度は別のホストに接続します。96だと思います。96がOrinです。
接続されました。最小化します。「display not found」は問題ありません。tapbotに入って、git pullしましょう。それからcontrol shift control p、tapbotを開きます。
このフォルダーを開く必要があります。4回別々にログインする必要があるのは面倒ですが、そういうものです。
これは我々がLeRobotでやっていたすべてのクラップを開きました。でも実際にそれを削除しましょう。lerobotを削除して、両方をクローンしましょう。Isaac Grootもクローンしましょう。depth 1も入れましょう。そうするべきでした。
control r z、保存しません。これが私が話していることです。少し異なるコミットで多くの異なるコンピューターがあり、それを非常に迅速に追跡しないと、すぐに厄介な状況に陥る可能性があります。
ここから出て、もうそれに入りたくありません。開いているのは2つだけにしたいです。現在このDockerコンテナをダウンロードしている訓練コンピューターと、これであるOrinコンピューター、推論コンピューターです。
推論コンピューターでは、Orinコンピューターでも Dockerfileをビルドする必要があります。Groot_evalと呼びましょう。見やすくするために大きくしましょう。
残念ながら、ここでもう一つの長いDockerビルドを待つ必要がありますが、見ることができるように、これら2つの別々のDockerコンテナに対して行っていることです。このDockerコンテナは訓練用です。これは元のDockerコンテナで、CUDA 12 PyTorch 2.6から始まります。推論や評価のためには、このOrinのDockerfileを使います。これはL4T Jetpackから始まります。これは基本的にNVIDIA OrinやJetsonsなどのエッジコンピュートDockerコンテナファミリーです。
似ていることが分かります。ほとんどの依存関係がすでにここにあります。多くを変更する必要はありません。いくつかのものを追加し、Pythonを追加し、プロジェクトをコピーし、pip install orinでダウンロードまたはインストールします。これはこのプロジェクトでOrin依存関係のみをpip installします。これらは少し異なります。
すぐに見ることができるように、ベースイメージはtorch 2.5を使用し、Orinはtorch 2.7を使用しています。両方ともダウンロード中です。
どうですか、皆さん、何か質問はありますか？この ファインチューニングに関連していない何でも構いません。
Wandプロジェクト、ここにはおそらくいくつかの失敗した実行があるでしょう。いいえ、まだ失敗した実行はありません。良いです。
私のファインチューニングの最終目標は何かということですが、最終目標は、この特定のエンボディメントでGroot N1を取得することです。Groot N1、これはN1.5で、数日前にリリースされた最新リリースです。彼らは数ヶ月前にGroot N1をリリースしましたが、つい最近になってファインチューニングスクリプトを追加しました。2日前です。これが私が取り組んでいることです。
GrootはこれらのエンボディメントでTEST訓練されています。Fourierがあり、Unit Treeがあり、Pandaがあり、SO101があります。これが実際に101か100か分かりませんが、これらがGrootが訓練されているエンボディメントです。これが私のエンボディメントです。ここのTapbotです。Tapbotのロボットカメラをお見せできます。
Tapbotは、これらのエンボディメントとは異なる状態空間、異なるアクション空間を持っています。state encoder、action encoder、action decoderをファインチューニングする必要があります。ここのdiffusion modelにも勾配をプッシュしていると思います。action expert、時にはそう呼ばれます。
VLAのVision Language Actionのactionです。これがaction expertです。私のエンボディメント固有のデータでファインチューニングしたら、どれだけ一般的かを見ることができるはずです。技術的には、そこに入って「pick up apple」と入力して、アームが何をするかを見ることができるはずです。
これはおそらく動作しないでしょう。なぜなら、これは非常に良いファインチューニングデータセットではないからです。なぜこれが非常に良いファインチューニングデータセットではないかというと、一つは4エピソードしかありません。実際に文字通り後ろに私の子供が見えますが、これを録画している間です。
理想的には、50、maybe even 100エピソードのようなものがファインチューニングデータセットには良いでしょう。異なるエンボディメントに移行するためには。でも、おそらくもう少し一般的にしたいでしょう。このエンボディメントデータセットは、pretty muchまたはこのファインチューニングデータセットは、このタトゥーキャリブレーションタスクのようなもので独占的です。
おそらく、私のロボット用のファインチューニングデータセットを収集したいでしょう。ブロックを拾う、カップに何かを入れるなど、さまざまなタスクがあるものを。ここのテキストでもう少し多様性があるようにです。ファインチューニングしているので、これまでのところ、これらのエピソードのすべてが同じ正確なテキストがここに入っています。ビジョンもほぼ正確に同じです。
この汎用基盤ロボティクスモデルを取って、新しいエンボディメントで本当に良く動作させたい場合、おそらくこれで多くの多様性が欲しいでしょう。
今日やっているのは本当にこのファインチューニングワークフローをデバッグすることです。依存関係の問題、Dockerコンテナ、すべてを実行させることです。これを行うために実際に良いデータセットは必要ありません。例のデータセットが必要なだけです。何かを訓練している段階まで到達し、それから訓練からチェックポイントを取り、エッジデバイスで実行し、実際にポリシーに推論を実行させます。
すべてをデバッグしたら、戻って実際のデータセットを再録画し、それでファインチューニングするだけです。
でも、これでもっと多様性が欲しいです。Tapbotエンボディメントがいくつかの異なることをする、いくつかの異なることの良い小さな代表的なデータセットを取得する方法を見つける必要があります。
これが完了してダウンロードしたので、これが終了したことが分かります。今は構築しているだけです。構築の一部は pip stuff をダウンロードすることです。
GrootはEagle 2ビジョン言語モデルを使用しています。eagle 2はsmall LM2からファインチューニングされています。実際に全部Hugging Faceです。
ここで他の人々がどんなデータセットを持っているか見てみましょう。最近更新されたもので並べ替えしましょう。
10日前に誰かがSVLA SO100 sortingを作成しました。これは SO100ロボットと小さなVLAでのソーティングだと思います。それをコピーして、データセットビジュアライザー、ロボットビジュアライザーに入れて、このデータセットを見てみましょう。
50エピソード、少しそれより多いです。observation images top、observation images wrist、shoulder_pan、shoulder_lift、elbow_flex、wrist_flex、wrist_roll、ここで各関節に名前を付けています。action、observation.state。
観測が点線で、アクションが赤い線で、それらはほぼ重なっています。すべて関節空間だからです。理論的には、これを行う必要はありません。状態がアクションと異なる状況を想像できます。状態がCartesianかなんかのようなものですが、なぜそれをするのか分かりません。
これはまだ構築中で、それもまだ構築中です。
実際にこのポリシーを実行する方法を見つけましょう。訓練用のdocker runコマンドを構築したのと同じ方法で、非常に似ているでしょうが、実際に何を実行するかを見つける必要があります。
inference serviceを探しています。これが我々が欲しいものだと思います。実際にここに行って、inference serviceと入力しましょう。例のコマンドを探しています。
5つのポリシー配置、ポリシーサーバーを開始するには以下のコマンドを実行します。これも重要なポイントです。Orin AGXでここで推論を行っているにも関わらず、30ギガのユニファイドメモリを持っているこれは、実際にロボットを制御するわけではありません。Mircatと呼ばれる別のコンピューターがあり、これは実際のカメラが接続されているCPUコンピューターで、実際にロボットを制御するものです。
これはポリシーサーバーとしてのみ動作します。基本的にDockerコンテナ内でポリシーをホストするだけです。ロボットコンピューターが「観測と状態があります、アクションをください」と言った時、このものがアクションを与えます。
model_pathはチェックポイントへのパスです。
inference_policyはスクリプトです。
ここに来て、出力フォルダーを与える必要があります。ここのことは訓練に行って、このフォルダーに入れますが、そのフォルダーは正しいコンピューターにありません。実際にポリシーを我々のコンピューターからこのコンピューターに転送する必要があります。
これを行う前に、プリトレインされたまたはポリシーチェックポイントをコピーする必要があります。ohoと呼ばれるこのOrinに、これは家のoho tapbotに入れます。
実際にそれをしません。tmpに入れましょう。小さなtmpフォルダーに入れるだけです。つまり、ポリシーを実行する時、これをマウントする必要があります。-v、その特定のフォルダーをマウントします。
checkpointと呼んで、model pathは中にあるので、Dockerコンテナ内でこれがパスになります。そこを指します。
data_config、これも変更する必要があります。これは問題です。このDockerfileは我々のブランチを使用していないからです。
時々これらのDockerfileはリポジトリをプルしますが、これは実際にビルドを実行するローカルリポジトリを使用しています。それで問題ないはずです。
このembodiment_tag new_embodimentが気に入りません。なんか独自のエンボディメントがあるべきように思えます。実際にこのembodiment_tagで何が起こっているか理解してみましょう。new_embodimentを検索しましょう。すべての例がnew_embodimentを持っています。私が考えるほど怪しくないのかもしれません。
これに戻って、これがポリシーサーバーになり、クライアントノードはinference_policyです。これと同じです。getting started examples eval the robot、getting started examples eval the robot。
external robot inference client、それが同じものです。ホストポートを提供する必要があります。これは我々のOhoの場所を与える必要があります。
おそらくわずかに上に動くものを与えて、我々のファインチューニングデータセットが種類のゴミであっても、おそらく動作するものを与えましょう。
この評価が終了しました。
Docker環境での実行
訓練ではなく、評価です。
これを実行してみましょう。これを必要としますか？
docker run –gpus all –rm、しかし私たちはそれをこのようにしました。「bashC」と言って、複数の異なることを実行します。最初にやることは、pip install -eですが、no depthが欲しいです。
これがどのように見えるか見てみましょう。これを実行して、exitしてclearしましょう。
そして、そこに行きます。これは良くありません。モデルを再びダウンロードしようとしているのが分かります。つまり、このキャッシュフォルダーにそれを見つけられなかったということです。「このモデルを実行しよう」と言って、それを見つけられず、再ダウンロードしようとしましたが、毎回このDockerコンテナを実行するたびに再ダウンロードしたくありません。
キャッシュがどこにあるかを見つける必要があります。こうしましょう。これをすべて削除して、コマンドなしでDockerコンテナを実行します。Dockerコンテナbashに入れます。
Dockerコンテナ内にいます。transformersをインポートしたら、transformers.なんらかのキャスターのようなものがあるはずです。端末がこれを知っているかどうか見てみましょう。transformers hugging face cacheを見つけるには、おそらくそれを印刷する関数があるでしょう。
もちろん、docキャスターはusers homeにあるはずです。lsすると、そこにあります。
問題は、ここにhugging face cacheがないことです。/root/.cacheかもしれません。それが我々が欲しいものかもしれません。まずコマンドがあるかどうか見てみましょう。GPT 3、4oを使いましょう。
hugging face hubをインポートして、hugging_face_hub_downloadしましょう。それから印刷しましょう。
なんでこのパスを教えてくれるんでしょうか？Pythonパスモジュールは最悪です。
これをやりましょう。
完全にそれです。皆さんが正しかったです。/root/.huggingfaceを指していたのに、/root/.huggingface/hubを指すべきでした。
Dockerコンテナを出て、これを再実行してみましょう。
Dockerコンテナを内蔵でビルドしました。Grootを上書きしているのは全く問題ありません。
No Nvidia in found、それは良いことです。ダウンロードされたモデルを見つけたので、実際にこれを実行しようとしています。
「torch.cuda.is_available()」とやってみましょう。
「torch.cuda.is_available」のスペルはそうですか？なぜあれが間違って見えるのでしょうか？
False、これは良くありません。提供したDockerコンテナがCUDAを持っていないか、NVIDIAを持っていません。
nvidia-smi、コマンドが見つかりません。NVCC、CUDAがここにはあることは正しいです。
pip install -e no depthをやった時、すでにそこにあったものを上書きした可能性があります。
依存関係は楽しいです。
これをコピーして、control shift I、「Isaac, does the Groot dockercontainer not have NVIDIA?」と言います。Dockerfileを与えます。
Groot fine-tuneスクリプトも与えましょう。
コンテナ自体はCUDA対応ですが、Nvidia SMIがないことは、Nvidia container toolkitが使用されていないことを示唆しています。–gpus allでコンテナを開始する必要があります。
それが問題だったんです。何らかの理由でGPU 0を指定していました。デバイスを指定する時は通常そうできると思いますが、–gpus allが欲しいのです。
こんなところで心臓発作を起こすところでした。
実行中、実行中、モデルをロード、チェックポイントをロード。
実行中です！
Weights & Biasesログインが必要です。APIキーに行く必要があります。ブラウザーでどこに開いたでしょうか？
キーの提示方法で、キーの前面しか見せないので、大丈夫なはずです。
control shift paste、エンター。そこにあります。スペースが残っていませんが、作成に成功しました。ここに失敗した実行が一つあるはずです。
そこにあります。なぜ「-output」と呼ばれているのでしょうか？それはひどいです。
run IDはGroot testであるべきです。
「なぜこのDockerコンテナに十分な部屋がないのでしょうか」とCursorに聞いてみましょう。実際に確認してみましょう。df -h
このデバイスには多くのスペースがあるはずなので、何について話しているのか分かりません。
docker system prune -af –volumes、これが我々が欲しいものだと思います。shimサイズ32ギガバイト、それは多いです。8ギガバイトにしましょう。
今これを試してみて、これはTapbot Calibフォルダー内にも作成されているはずです。Tapbot output train tapbot calibあります。
これでも毎回WandBにログインし続ける必要があるのは面倒でしょう。
興味深い、unexpected input output torch size 8, 14, 32。
8はこのバッチサイズです。14はアクション形状です。32はおそらく長さです。
おそらく何が起こっているかというと、我々のデータセットに十分なステップがないということだと思います。おそらくこの32を調整する必要があります。なぜなら、これは基本的にアクションチャンクを行っているからです。もっと長いチャンクが必要だと思います。
それが私の推測です。より長いチャンクが必要です。Groot fine-tuneに入りましょう。または具体的にここ、models Groot N1 line 126。
line 126、ここでcontrol Fして32と言いましょう。
その32がどこで設定されているか見つけてみましょう。32を検索しましょう。LoRAですが、我々が欲しいものではありません。
batch_size 32ではありません。maximum embodiment 32ではありません。depth 32ではありません。float 32おそらく違います。length 328ではありません。明らかなものはありません。
Groot N1 line 183を見つける必要があります。control G 183、validate_inputs、これは締切後に内部で処理されるべきです。知っていて良かったです。
action.shapeは3であるべきです。action shape 1はaction horizonで、action shape 2はaction dimです。action horizonが我々が欲しいものです。action horizonを検索してみましょう。
16、訓練長のaction indicesからaction horizonが欲しいです。
type でない場合、action typeを印刷します。ここでaction typeを印刷しませんでした。shapeを印刷しました。shape でない場合、action shapeを印刷します。
これをロードしているので、ここでPDBを行い、マウントしているので、ここでこのファイルを変更するとすぐに、このDockerコンテナを実行した時に実行される実際のファイルになります。
Dockerコンテナにいて、これを実行して、これを実行すると、この debug traceでトリガーされるはずです。まずWandBにログインするよう求められますが、この場合は実際にno と言います。結果を可視化しません。
3、実行します。ブーム、トリガーします。このGroot N1ファイル内にいて、失敗する直前です。action.shapeが何かを見てみましょう。これが8, 14, 32です。3は問題ありません。self.action_horizonは何ですか？16です。self.action_dimは32です。
実際にaction dimは正しく、ここのaction horizonが14で、16であるべきです。14か16であるべきかです。ある時点でaction horizonを14に設定していて、16であるべきです。疑いは、これが我々が作ったファイルであるということです。
そのファイルはどこですか？Groot data data setですか？これですか？data configです。ここにあります。action_indices list(range(16))。
あ、それが問題です。action_indices list(range(14))、それを16に変更しましょう。
実際にもうそこにあるので、このimport pdbを取り除くことができます。再度pip installして、再実行できます。
なぜこれが更新されないのでしょうか？
再実行してみましょう。まだそのブレークポイントでトリガーしますが、今度はaction.shape 1が14ではなく16を正しく見るはずです。
そこにいます。action.shape 1は16で、self.action_horizonも16です。これで動作するはずです。
out of memory。動作しますが、このimport pdbを取り除いて、バッチサイズ2でやってみましょう。
このコンピューターで小さなVLAを訓練していて、バッチサイズ64でかなり良かったのですが、GrootがSmall VLAよりもかなり大きいことを覚えておく必要があります。Grootは約3Bパラメーターで、Small VLAははるかに小さく、400Mか何かです。なぜサイズが見えないのでしょうか？以前はここでサイズを見ることができました。
model tree preview not found。とにかく、小さいです。バッチサイズを小さくしましょう。
バッチサイズ2で実行してみましょう。
それが動作している間に、control shift G、それらを追加します。この変更もここにあるはずです。
もう一度out of memory errorです。
文字通りバッチサイズ1にする必要があるのでしょうか？それは良くありません。この3090でバッチサイズ1でこれを訓練できないということです。
おそらくやる必要があるのは、これを行うためにクラウドマシンを借りることです。
ありがとう、Rupender Singh、そのサポートに感謝します。あなたに十分感謝する言葉が見つかりません。うまくいけばこれが有用です。
これらのコーディングストリームは、論文ストリームほど人気がないことは分かっています。音楽を追加することで、もう少し聞きやすくなるかもしれないと思いましたが、論文ストリームほど楽しくありません。情報密度も高くありません。多くはただランダムなことをデバッグしているだけで、それほどクールではありません。
でも、これは経験の一部だと思います。一部の人にとってはこれが有用だと思います。機械学習やコーディング、プログラミングを始めたばかりの人にとって、誰かが実際にこれを行うのがどのように見えるかを知りたいのです。どんな人間のスキルでも、教科書を読むことはできますが、本当にやりたいのは誰かがそれを行うのを見ることです。
誰かが何かを行うのを見て、「ああ、それがそれなんだ。私がプログラミングや機械学習をしているとしたら、それは何から構成されるのか？」と思うことができます。それは日々このことから構成されます。コマンドを追跡し、これらの小さなコマンドをいじることです。それが日々のことです。
うまくいけば、その意味で有用です。人々がその雰囲気がどのようなものかのアイデアを得ることができます。これが私が毎日のほとんどを過ごしている方法です。背景に音楽をかけて座って、この種のことをいじるだけです。
これは30分前に終わっているべきでしたが、out of memory errorで終わることになりましたが、次のステップはクラウドマシンを開いて、クラウドマシンでそれを実行することでしょう。それから後で扱うクラウドマシンのことがすべてあるでしょう。
とにかく、皆さん、みんなでぶらぶらしてくれてありがとう。良い週末を過ごしてください。Ed Rupender Snooks Mark Jamal Cole Richard Rad Orz Lil KM Sagar Josh Majetti Sheldonに感謝、みんなでぶらぶらしてくれてありがとう。良い週末を過ごして、また後で会いましょう。
コメント