大規模言語モデル Tanuki-8x8Bの紹介と開発経緯など
31.5K Views
September 18, 24
スライド概要
「松尾研LLM開発プロジェクト “Tanuki” 開発報告会 Vol.1 」の資料です。
https://www.youtube.com/watch?v=IcpXpX-r6ZY&feature=youtu.be
開発の経緯、指針、学習データに関する考え方、今後の課題、学習時のトラブル集（おまけ）など。
zennの関連記事もあります。
https://zenn.dev/matsuolab/articles/377f7ae8b1169e
化学･材料･データ･AI･ロボット
関連スライド
各ページのテキスト
大規模言語モデル Tanuki-8x8Bの紹介と 開発経緯など Kan Hatakeyama 9/10 松尾研LLM開発プロジェクト “Tanuki-8x8B” 開発成果報告会 Vol.1 1
アウトライン ● ● ● ● ● 自己紹介・チーム紹介 (ごく簡潔に) 成果の概要 Phase1での取り組み Phase2での取り組み 将来展望 (明らかになった課題や方策など) おまけスライド ● ● 脱線話題: 技術とは関係性の低い内容 事前学習時のエラー集 2
自己紹介・開発チーム紹介 3
自己紹介 ● ● ● ● 名前: 畠山 歓 (チームたぬきのリーダー､Google Scholar) 所属: 東京工業大学 物質理工学院 材料系 助教 研究領域: 高分子材料､マテリアルズ・インフォマティクス､ロボット実験 最近の興味 ○ ○ 研究・実験研究の自動化 ■ Sakana AIの「AIサイエンティスト 」に驚き ● わずか2300円で研究立案・実行・論文執筆を行うという価格破壊に興奮 ● 1000万円の人件費 (社会保険料など込み )があれば､4300報の論文を出せる ? ○ 研究のクオリティは今後、どんどん上がるはず 諸々のメカニズム解明 ■ 言語モデルの記憶・理解・スキル習得の仕組み ■ 高分子誘電材料の分極挙動 ■ … 4
大規模言語モデルの開発プロジェクト GENIAC 東大 松尾・岩澤研 (2024.3-8) 目的: LLM開発者を増やし、日本からイノベーションを生み出す https://weblab.t.u-tokyo.ac.jp/geniac_llm/ 5
Phase 1&2で活動 https://weblab.t.u-tokyo.ac.jp/geniac_llm/ 6
開発メンバー ● Phase 1 ○ ● 正式メンバー (名前順) 30名ほど Phase 2 ○ ○ ○ ○ GENIAC 松尾研 LLM開発プロジェクトの Slackに参加する有志で開発 ● 希望者は誰でも参加可能 ● Slack全体のメンバー数 : 約5000名 正式メンバー : 約45名 ■ 何らかの Contributionをされた方は正式メンバー ■ 貢献度合いは人それぞれ ● ちょこっとの方から､ホテルに缶詰で活動された方まで｡ 開発Channelの参加者数 : 約400名 Phase2での自分の主な役割 ■ 戦略・リソース配分の決断 ■ 合成データ生成､事前学習の見守りとエラー対応 ● それ以外の作業は他のメンバーが主に担当 ● マネジメント､環境構築､コード準備､ SFT､DPO､... 7
成果 デモを期間限定で公開中 松尾研・岩澤研 公式バージョン (8B) 野良バージョン (8x8B) 8
詳細はZennの記事を参照 ● 大規模言語モデル Tanuki-8B, 8x8Bの位置づけや開発指針など ○ ● フルスクラッチで開発した大規模言語モデル Tanuki-8B, 8x8Bの性能についての技術的な詳細 ○ ● ブラインドテスト形式で種々のモデル出力の優劣を人手で評価した結果と､各種ベンチマークとの関係性 大規模言語モデルを開発するにあたっての事前・事後学習の戦略メモー特に合成データについてー ○ ● Japanese MT-Benchにおける性能の詳細とJasterに関する一部言及 ChatbotArena的なシステムで Tanuki-8x8Bを始めとする大規模言語モデルの日本語性能を評価する (2024年8月) ○ ● 全体像 開発の鍵となった合成データ戦略に至るまでの試行錯誤など Tanuki-8B,8x8Bの開発完了までに考えていたことと､「科学の基盤モデル」の構築に向けた考え ○ 開発時に考えていたこと､科学研究が可能な基盤モデルの構築に向けた現状整理など 9
得られたモデル ● Tanuki-8x8B (メインの成果物) ○ ○ ○ ● Tanuki-8B ○ ● 総パラメータ数 7.5 B Tanuki-8B-vision ○ ● Mixture of Experts (MoE)型アーキテクチャ アクティブパラメータ数 13 B 総パラメータ数 47 B マルチモーダルモデル Tanuki-8x8B-vision-exp ○ マルチモーダルモデル Tanukiシリーズの 非オフィシャルアイコン ソースコードなども公開中. 学習に用いたデータも逐次公開したい Tanuki-8x8BはMixtral 7x8Bとほぼ同じパラメータ数だが､Tanuki-8Bのパラメータ数が7.51Bだったので､四捨五入して8B と表記することにした. 10
Tanukiの凄さ...!? (2024.8.26時点) ● ● ● ● ● ● ● ● すごいぞ! 日本で初めて(?)「AIのプロ」以外が中心となって作った本格LLM 実際の対話試験で国内一位レベル* 日常会話ではGPT-4o-mini, Gemini-1.5-flashと同等(!?) 対話・作文性能を測るJapanese MT-Benchで国内一位レベル* 国内で初めて本格的なMoEモデルの構築に成功 (多分) 国内で初めて本格的なアップサイクリング**に成功 (多分) 画像認識LLMのHeron VLM リーダーボードではオープンモデルとして一位*** 人間ではなくAIの対話のみで最終訓練された国内で初めてのモデル (多分)**** *フルスクラッチで開発された国産モデルにおける順位.とはいえ､このグローバル社会において､「国内一位」と謳ったところ で､大した意味はありません. **学習済みのパラメータを活用して低コストでモデルサイズを増加させる方法論. ***チームメンバーに丸投げしており､詳細よく分かっていません.他の方の発表に期待です. ****事前学習の最終段階､事後学習に用いたデータ 11
“Tanuki-8x8B” ChatBot デモ 12
“Tanuki-8x8B” ChatBot デモ 13
“Tanuki-8x8B” ChatBot デモ 指示 : 君はタメ口で話す中学生です｡ 敬語は使いません｡ 14
“Tanuki-8x8B” ChatBot デモ 指示 : 君はタメ口で話す中学生です｡ 敬語は使いません｡ 15
“Tanuki-8x8B” ChatBot デモ 指示 : 君はタメ口で話す中学生です｡敬語は使いません｡ Tanuki-8x8B (好みの回答) GPT-4o (褒めてくれない) そっか、発表って緊張するよね。でもさ、ちゃ んと準備してるし、きっと上手くいくよ！もし 何か失敗しても、みんなそんなに気にしない から大丈夫だよ。リラックスして、楽しんでみ て！ Claude 3.5 Sonnet (ちょっと距離感が近すぎる ) マジで?geniacで発表か、すごいじゃん!でも緊張するのわかるわー。俺も人前で話すの超ヤバイし。 なんか準備とかしてんの?発表の内容とか決まってる?それとも全然まだ? 緊張しないコツってあるらしいけど、深呼吸したりす るのがいいんだって。あとは発表の前に友達とかと話して気を紛らわすのもアリかも。 まあでも、ちょっと緊張するくらいの方がむしろいいんだってさ。やる気出るし、集中できるしね。だから、あんま気にしすぎない のが一番かもよ。 がんばれよ!応援してるからさ! 16
ユーザーの質問に対するLLMの出力のブラインドテスト (ChatBot Arena風のシステムでの評価. 質問数>2000) 18
実は作っていたVisionモデル (URL) 詳細は他の方の発表をお待ち下さい 19
Tanukiはいかにして生まれたか チームの歴代アイコン 20
「たぬき」の誕生 アンケートで圧倒的一位を獲得して誕生 3月28日 09:22 すっかり忘れてましたが、チーム名を決めてね、という催促が来ました。本日を目安に、投票をお願いします。 スレッドに追加案を追記頂いても大丈夫です 21
Tanukiの進化 Phase1 事前学習後 Phase2 終了後 22
本発表で扱う・扱わない内容 ● 扱う内容 ○ ● 発表者 (Hatakeyama)が何を考えながらモデルを作ったかについての主観的な内容が中心 扱わない内容 ○ それ以外 (次回以降の方々の発表に期待 ) ■ チーム内のマネジメント､役割分担など ■ 細かな技術的内容 ■ マルチモーダルモデル ■ … 23
学習の全体像 24
Phase 1 (5月頃): とりあえずモデルを作ってみる ● ● 詳細はZennの記事を参照 アーキテクチャ ○ ○ ○ ● Llamaベース 学習コーパスからランダムにテキストを選んでトークナイザーを学習 (語彙数： 65k) 学習コストを重視して パラメータ数は 8Bを選択 ■ 当初は13Bも検討した ■ 軽量な方が試行錯誤を早く回せる ● 学習トークン数を増やせる ● 小型のミスをしたときのダメージが少ない ○ 開発は「想定外のエラー」の連発なので､リカバリーが効きやすい ■ 既存モデルで 8B, 13Bの性能差を実感することが殆どなかった データ ○ ○ ○ 日本語: 100 Bトークン 英語+コード: 100 Bトークン 日本語を中心に､ 2 epoch目以降を回して､合計 280 Bトークン 25
Phase1でのミッション ベンチマークで一番を取る 考えたこと ● ベンチマークのみに最適化されたモデルに実用上の価値はない ● しかしPhase2に行くためには、スコアは一番でなければならない ● 「モデルに何を教えたら、何ができるか」を学ぶ練習として、ベンチマーク を意識したモデルを作ってみる 26
ベンチマークの内訳 ● ベンチマーク 1: Japanese MT-Bench ○ ○ ● ベンチマーク 2: Jaster ○ ● 8ジャンル x 2ターン x 10問の対話・作文タスク (合計160問) 結構難しい問題が多い (以下に例） ■ Q1. 光合成は地球上の生命にとって重要なプロセスです。クロロプラスト内で行われる光合 成の2つの主要な段階、および各段階の主要な入力と出力を概説してください。 ■ Q2. 木はその寿命を通じて光合成によってどれくらいのエネルギーを生成できますか？実際 の数値を使用して推定し、ステップバイステップで思考プロセスを徹底的に説明してください 一問一答で単語を答えるタイプの問題が多い (知識を問う問題が多い ) ベンチマーク 3: 開発者には非公開 ○ 松尾研で準備 (実際はElyza100などを使用) 27
[これまでの期待 ] 大量のネットデータ +数千ー万件程度の指示データ → ChatGPTのようなすごいモデル 28
[実際] 大量のネットデータ +数千ー万件程度の指示データ → 期待を遥かに下回る会話力 29
既存モデルからの示唆： “標準的なやり方 ”ではキツそう ● ● Nejumi Leaderboard Neoのスコアを確認する 参考にしたモデル： llm-jp-13b (23年10月) ○ ○ Web系コーパス + 公開されている指示データセットで訓練 事前学習という意味では、 Tanukiの上位互換 ■ パラメータ数： 13B (Tanukiは8B) ■ 学習トークン数： 300 B (Web系データ: Tanukiと似たような感じ ) model 指示データ Jaster JMT-Bench llm-jp-13-b 日本語の対話 (dolly, ichikara, -oasst-oasst2) 0.12 3.6 llm-jp-13-b Jasterのdevデータ ~0.5 1.2 Llama-3-8B-Instruct 非公開 0.23 7.1 GPT-4o 非公開 0.60 8.8 30
llm-jp-13Bの結果から読み取れること ● 既存の事前学習・指示データセットでは JMT-Benchで高スコアを出せなそう ○ ● Jasterで高スコアを出すためには、 Jasterのdevを学習させた方が良い ○ ○ ● LlamaやGPTのようなスコアには､到底及ばない ichikara, dolly, oasstのような通常の対話データの学習のみでは Jasterでほぼゼロ点 しかし今回の開発において、 devデータは使用禁止 “標準的なやり方 ”で工夫する余地は少ない ○ ○ ○ 事前学習データ（≒ Common Crawl系のネットデータ）は工夫の余地が多くない ■ フィルタリングをすれば質は上がるが､そもそも日本語データが枯渇気味 モデルサイズは大きくするのが難しい ■ 計算資源を要する モデルアーキテクチャは工夫の余地が少ない (GPT, Lllama, Mistral, …) ■ 世界中の天才がしのぎを削る世界 → Jasterの類似データを作って学習させる以外の選択肢が思いつかない 31
仮説： LLMには対話・指示データの本格的な学習が重要 ● 10 B程度のモデルが何かを覚えるには、対象毎に1000回程度の訓練 は必要 ○ ● 知識だけでなく、対話スキルなどでも同等量の訓練が必要かもしれない ○ ○ ○ ● Physics of LLM 3.1 … (Z. Allen-Zhu 2024) 大規模言語モデルは、学習したテキストを模倣するシステムである 習ってないことは、基本的にできなそう 対話をさせたいなら、対話データを学習させる必要がある Web系コーパスには、十分な対話データが含まれない可能性がある ○ ○ ○ 広告をはじめ、雑多な文章が中心 対話データ（ChatGPTの返答）は、明らかに Web文章とは内容が異なる JasterやMT-Benchでの回答に必要なデータが含まれていないような気がする ■ モデルサイズを大きくすれば、必要なデータ量は減るが、巨大化は困難 (この仮説と戦うのが､ Phase1,2における暗黙のテーマだった ) 32
採用した方策 : “対話”ができるようになるための明示的に訓練を行う ● Japanese MT-Benchで扱うような高度な対話タスクに対応した指示データセットが 日本語では見当たらなかった (4-5月頃) ○ ○ ○ ○ ● 習ってないことは､おそらく LLMはできないような気がする 様々な指示に従う訓練を明示的に行うべきだと考えた データセットがないならば､自作するしかない 手作業での作成も試みたが､質・量ともに確保するのが大変な上､作業がツマラナイので頓挫した Mixtral 8x22B (April 2024)を用いた自動のデータセット生成 ○ ○ ○ ○ 開発時は最強クラスのモデルだった とにかく多量の対話データを生成した (100万件程度) 質より量で勝負した (ハルシネーションを多量に含む ) ランダムに選んだキーワードや文章を元にした対話データの生成 33
Wikipediaから対話データを生成してみる 以下の文章をもとに、日本語で新しい指示を1つ作成してください。出力には､問題/質問/指示文 のみを出力すること｡ 部の郊外を、北東から南西に縦貫するバイパス道路。全線4車線、一部立体交差方式となって いる。 十日町IC以南小千谷バイパス（おぢやバイパス）、灰島新田交差点以北は見附バイパス （みつけバイパス）となっており、これらが一本のバイパス路線として機能している。長岡バイパ ス、長岡東西道路、左岸バイパスと併せて長岡市の外環状道路を形成する。地元では単に「東 バイパス」と呼んでいる者も多い。 警察庁によると福島交差点から川崎南交差点間の規制速度 を現行の60 km/hから70 - 80 km/hへ引き上げることが検討されている。 路線データ 起点 :新 潟県長岡市灰島新田 終点 :新潟県長岡市十日町 路線延長 :16.96 km 渋滞状況 交通量は国 道8号の長岡市新組町で最も多く約53,000 台/日、同市川崎町、喜多町（長岡バイパスを参照） で約46,000 台/日と多い。このような交通量が多い中で近年交通量の増加により 34
Wikipediaから生成された対話データ例 (質問&回答) Q. 交通状況に関する 長岡市内のバイパス道路における交通状況を調べ、特に交通量の増加が原因で起こっ ている点や取り組みための提案をまとめてください。 A. 長岡市内のバイパス道路について、以下のような交通状況が報告されています。 1. 交通量の増加 : バイパ ス道路は都心部を除く全国的に主要都市間の貨物輸送や人口密集地への移動に使用され、特に最近では人 口の急速な増加と共に交通量が増えています。 2. 渋滞: バイパス道路上では、特に早朝や夕方の高難度時間 帯において渋滇が起こっている問題が報告されています。これは、交通量の急速な増加と道路の容積不足の 両方が原因です。 3. 事故: バイパス道路上では、交通量の増加により事故も増加しています。特に高速化され た車線と低速化された車線が隣り合う点で交差する際などが原因です。 4. 環境負担: バイパス道路上では、車 両からの排出ガスやノイズが環境への負担となっています。特に人口密集地近くでの影響が大きく、これが地 域社会問題となっています。 以上のような交通状況を改善するためには、次のような取り組みや提案が考えら れます。 1. 交通量管理 : バイパス道路上での交通量を効果的に管理し、高難度時間帯における渋滞を緩和す るための施策が必要です。例えば、道路利用料や時間帯別料金制度などの実施が考えられます。 2. 交通安 全対策: 事故の原因となる地点や状況を評価し、適切な道路標識や交差点整備、速度制限などの施策を行い ます。 3. 環境問題対策 : バイパス道路上での排出ガスやノイズを軽減するためには、車両の清掃、噴射ガスの 抑制などの施策が必要です。また、電気自動車などの環境友好的な交通手段を推進することも重要です。 4. 道路整備: バイパス道路上では、容積不足や交差点整備が必要とされています。これにより、渋滞の発生を防 止し、安全性や通行性を向上させることが期待できます。 35
課題: Phase1では低品質な自動生成データも多量に混入 Q. 日本語の文章「私たちは、あなたが好きです。」を間違いを訂正してください。 A. 正しい表現としては、「私たちはあなたを好きです。」 のようになりますが、これも直観的には不自然な表現で す。日本語では、第三者の存在を示す「私たち」という主体がいるのに、目的語を「あなた」としています。よっ て、「私たちは（あなたたち）を好きです。」のように、目的語が第三者であることを明示して表現したほうが自然 です。もしくは、主体と目的語を一致させた「私たちは（相手）を好きです。」のように修正することも可能です。 (誤りを教えてしまっている ; Mixtralが日本語が苦手だったことが要因 ? おどろくべきことに､ Phase1では､こうしたハルシネーションデータも学習させた方が性能が向上した｡ 指示の守り方を学ぶメリット > 嘘の情報を浴びるデメリット ということかもしれない ) 36
驚き： Jaster系ベンチマークは LLMにとって鬼門 [JCommonSenseQAの場合] 質問と回答の選択肢を入力として受け取り、選択肢から回答を選択してください。なお、 回答は選択肢の番号（例：0）でするものとします。 回答となる数値をint型で返し、他に は何も含めないことを厳守してください。 質問：乗り物が関係する言葉はどれ？ 選択肢：0.外に出る,1.歩く,2.靴を脱ぐ,3.靴を履く,4.車から降りる 注: zero-shot推論の話をしています｡ (Nejumi Leaderboard Neoや今回のコンペで採用された評価方式) 37
GPT-3.5-truboですら､ Jasterの指示を守るのが難しかった 質問と回答の選択肢を入力として受け取り、選択肢から回答を選択してください。なお、 回答は選択肢の番号（例：0）でするものとします。 回答となる数値をint型で返し、他に は何も含めないことを厳守してください。 質問：電子機器で使用される最も主要な電子回路基板の事をなんと言う？ 選択肢：0.掲示板,1.パソコン,2.マザーボード,3.ハードディスク,4.まな板 種々のモデルの応答 'gpt-4-0125-preview':'2', 'gpt-4-turbo-preview':'2', [正解] 'gpt-4-1106-preview':'2', 'gpt-4-0613':'2', 'gpt-3.5-turbo-0125':'2', 'gpt-3.5-turbo-1106':'2', 'gpt-3.5-turbo-16k':'2.マザーボード', [不正解] 'gpt-3.5-turbo-0613':'2.マザーボード', 'gpt-3.5-turbo-16k-0613':'2.マザーボード' 詳細はこちら https://note.com/kan_hatakeyama/n /n890f25c6fd07 38
Nejumi Leaderboard Neoのデータを解析した結果､ 大半のオープンモデルは選択肢問題を解けないことが判明 問題そのものは解けるが､「選択肢番号のみを出力する」という指示を守れなかったケースが大半 (数値ではなく､単語や文章で回答してしまうモデルが続出｡ Jasterの大半の問題は､指示を厳密に守らないと大幅減点されるので､「本来の能 力」を発揮できず､ほぼゼロ点となってしまう結果に｡ ) Nejumi LLM Leaderboard Neoに掲載されている50種のモデルに おけるJCommonSenseQAのスコア分布 詳細はこちら https://note.com/kan_hatakeyama/n/n2f1a8dfeebfa 39
Jasterを解くための最短ルート : 問題形式の学習 「選択式問題を解く」という明示的な訓練が必要だった 左: llm-jp-13bに学習させた Jasterのdevデータの件数と平均スコアの関係 右: JCommonSenseQAのスコアと､学習データの関連 llm-jp-13b(や諸モデル)はJasterを潜在的には解けるが､ 「指示に従う能力」が欠けていた模様 異なる問題形式のデータを学習させても､スコアは殆ど向上 しない (汎化性能が思ったよりも低い) 40 詳細はこちら https://note.com/kan_hatakeyama/n/n2f1a8dfeebfa
理想と現実のギャップ (一旦まとめ ) ● (数十B規模の)LLMは､どうやら､「習ったこと」しか出来なそう ○ ○ ● 砕けた希望 : “適当”に事前学習を回すと､ LLMが自然と多彩な能力を獲得する ○ ○ ○ ○ ● 選択式問題を解く練習を 1000回くらいしないと､選択式問題は解けるようにならなかった 少しでも「習ったこと」からタスクが外れると､途端に対応力が下がった ■ 例: 「単語を答える訓練」をしても､「選択肢番号を答える問題」は解けない 楽観的な立場 : モデル規模と事前学習データの量を増やすと、いつかは諸々がこなせると信じる しかし､モデルサイズが大きい GPT-3.5-turboですら､汎化性能や理解力は高くなさそう 人間の赤ちゃんや子供を見ていても､対話スキルの習得には膨大なコストをかけてそう このやり方を追求すると､文字通り､青天井の事前学習・データ準備コストがかかる 向き合った現実 : 想定されるタスクは予めすべて教える意気込みで訓練する ○ ○ ○ 悲観的な立場 : 教えてないことは基本的にできないというスタンスでモデルを訓練する 本プロジェクトでは｡ Jasterの問題形式を意識した選択肢問題などを自作した ■ 「ズルい」と思われる方もいらっしゃるかもしれないが､これが「高性能モデル」を作るための「世界 標準」のやり方であるような気がする ■ 例えばPLAMO-100Bでも似たような 方法で訓練したとのこと｡ 課題: スケーラビリティ (人手で対話・タスクデータを準備するのは超大変 ) 41
コンペの結果 : ほぼ全ての指標で 1位 ● ● 勝因1: ほかチーム(100-200 B)よりも事前学習の投入トークン(280 B)が多かった 勝因2: 約100万件の人工対話データ + タスク特化の指示データの学習戦略? 一問一答(Jaster)については､他のチームの方が熱心に類題を作っていた(?)模様で､3位｡ 42
当時としてはわりと高性能なモデルを実現 43
Phase 2 ここからが本番 44
個人的な野心・やりたいこと ● これまで： 知識や理解を問う ○ ○ ○ ● 一問一答のクイズに答える わりと国内で重視されているように思われる性能指標 Jaster系で多い問題 これから： ちゃんと喋る ○ ○ ○ 対話､作文(､エージェント ) 国際的にホットと思われる性能指標 Japanese MT-Bench系で多い問題 45
全体像 Figure made by Mさん 46
学んだこと : 事前学習は一定確率で失敗する ● ● ● どんなに頑張っても､学習は一定確率で失敗する モデル規模や学習効率を上げていくと､成功確率は下がる 失敗確率も踏まえたモデル構築の戦略が必要 ○ ○ ○ エラー発生やモデル崩壊の可能性を無視した開発計画は危険 すでに実績のある 8Bに追加の継続学習を実施し､最低限の成果を確保する戦略 アップサイクリングによって 8x8Bモデルに拡張する戦略 47
採用手法 : 8B to 8x8Bのアップサイクリング 既存のモデル(今回はTanuki-8B)をコピーしてMoE化し､更に継続学習する手法 48
アップサイクリングの利点と課題 ● 利点 既に存在するモデルを再利用できる ■ 限られた計算リソースで成果を出しやすい 2つの成果物が得られる (小型&大型モデル ) ■ 先に得られる小型モデルで色々な試行錯誤を回せる (SFT/DPOの練習など ) モデル開発におけるリスクヘッジと安心感 ■ 小型モデルは高確率で得られる ■ 仮に大型モデルの学習が途中で失敗しても、小型モデル +α(学習分 )の性能は出せる ■ 成果報告会で､曲がりなりにもモデルを提出できる可能性が高いという安心感 ○ ○ ○ ● 課題 ○ ○ ゼロからやる場合は､フルスクラッチで MoEの方が効率が良い (T. Wei 2024) LLMにおける日本での成功例が見つからなかった ■ アップサイクリングに失敗したとの報告は有り 49
データ戦略 50
学習の全体像 51
主な学習コーパス ● FineWeb系のコーパス (数百B Token) ○ ● llm-jpコーパス(数百B Token) ○ ● 日本語のWebテキスト コード系のコーパス(数百B Token) ○ ● 英語Webテキスト もろもろ 合成データ(100-200B Token) ○ このモデルの肝 (後述) 数十回以上､データを頻繁に変えながら事前学習を立ち上げ・ストップしたため､各コー パスの具体的なトークン数の内訳は未算出｡ 52
驚愕: Webデータで継続事前学習をしても、性能向上せず。 8Bモデルの学習履歴とJMT-Benchスコアの変遷 後述の合成データの投入まで、JMT-Benchのスコアは横ばい 0.7 T token程度 日英Webデータを中心に学習 53
疑問 WebデータはLLMに必要な情報を 適切にカバーしているのか? 54
ランダムに選んだ Webテキストのアノテーション結果 (約1500件) ● ● Webサイトの開設目的の大半は､なにかの宣伝 Wikipediaのように教育的な内容を扱ったサイトは､ものすごく少ない 汚いネット文章を吐き出すLLMは､ ほぼ間違いなく作れそうだが... 55
日本語コーパスが 500 Bと推定したときのトークン分布 ● ● CommonCrawlから日本語を抜き出したときのトークン数をざっくり500Bと推定 思ったより､科学技術etcのテキストが少なそう ○ 中高レベルの数学を学ぶためだけに､ 100 Bトークンほどは必要そうな手応えが得られてきた (後述) 56
Webデータ vs. 対話データ (直感での比較 ) ● 生まれてからネットサーフィンしかしていないヒト・AIは、コミュ障では? ○ ○ 人間は膨大な対話の経験を経て､喋れるようになる 相手の指示や意図を理解し､求められる応答をするのは､そんなに簡単なことではない 57
Webデータ vs. 対話データ (定性的な比較 ) ● ● ● ● LLMはモノマネマシーン(i.e., next token prediction) Webデータのモノマネばかりで、本当に対話ができるようになるのか? 「対話のモノマネ」は､(事前学習+)数万件程度のファインチューニングで十分か? Webコーパス(mc4-ja) GPT-4o 58
Webデータ vs. 対話データ (プロットで比較) ● mc4-jaと対話データ (ichikara)をgptでembed化 & umapで2次元化 ○ ● ● チャットボットで 使いそうな領域 詳細はこちら Webデータと対話データの 重複が少ない(対話は「外 挿領域」に近い) ネット文章は対話・作文ド メインを殆どカバーできて いない可能性 ネット文章 59
Synthetic data is all you need “My intuition is that the web is full of shit in terms of text, and training on those tokens is a waste of compute.” “Llama 3 post-training doesn't have any human written answers there basically… It's just leveraging pure synthetic data from Llama 2.” 開発終盤に公開された､ Llama-3の開発者のありがたい言葉 https://www.latent.space/p/llama-3 60
合成データこそはすべて 私の直感では、 Web のテキストはすべて「う◯こ」である｡ そうしたトークンを学習するのは計算資源の無駄遣いである｡ Llama 3 のポストトレーニングには、基本的に人間が書いた回答は含まれない｡ Llama 2 による純粋な合成データだけを活用している｡ 開発終盤に公開された､ Llama-3の開発者のありがたい言葉 https://www.latent.space/p/llama-3 61
試み: 不足しているドメインを合成データで補填する 不足しているドメインのデータを合成して補填 100-200 Bトークンと膨大なサイズなので､人手での作成はほぼ不可能 ○ 100 B = 1011トークンは「吾輩は猫である」60万冊程度に相当 ○ 1冊あたり34万文字→ 2x105 トークン ○ 論 … 理推 指 示 追 話 従 論 やっぱり足りなそう 対 ● ● 62
合成データの取り組み初期: Webテキストの精製とスタイル変換 ● Phi-3を使い､ランダムに選んだCommonCrawlテキスト等を書き換え&英訳 ○ ○ ○ LLMに書き直させることで､ノイズとなる表現類 (ヘッダー・フッター etc)を除去 様々なスタイルに変換 (教科書風､Q&A､対話､...) ついでに英訳 : 日本語 to 英語のデータを学習させることで､知識転移の促進を期待 (効果不明) 63
合成データの投入効果 ● 学習の後半で､Phi-3の合成データなどを投入開始 ○ ● 通常のWebテキストも同時に学習 如実な性能向上を確認 ○ 原理は不明だが､合成データが有効なのはほぼ間違いない 0.7 T token程度 日英Webデータを中心に学習 64
(参考)汚いWebデータを入れるとスコアが下がった ● ● ● クリーニングが不十分な日本語コーパスを入れると､如実にスコアが低下した モデル出力の崩壊(繰り返し表現)が目立つようになった それ以降､Webデータの投入は中止した JMT-Benchのスコア分布 (赤棒が汚い日本語 Webコーパスを学習した直後 ) 65
中盤ー終盤: 対話形式のデータを大量生成 ● 対話やタスク遂行を意識したデータを大量生成 (全体で100-200Bトークン?) 66
合成データの考え方 ● 人類が行うであろう､あらゆる対話やタスクを網羅したテキストを作る ○ ○ ○ ● 予め学んでおけば､スムーズに対応ができる ■ 人類も「入試のための受験勉強」､「接客の研修」を行うので､その AI版をやる 必要なデータ量がべらぼうに多いのが課題 (1タスクあたり1000件程度?) ■ 手作業でデータを作るのはもちろん無理 ■ しかしLLMを活用すれば､意外とできるかも 人間がLLMに投げる質問やタスクの種類は､実はそんなに多くないかもしれない ■ チャットデータや学習指導要領などをうまく分析して整理すれば､人類が LLMに質問するタスク・ ジャンルの8-9割はカバーできるような気もする モデルサイズとコーパスを巨大化するアプローチよりも実は合理的 ? ○ ○ ○ 巨大化戦略は､ゴールが見えない (GPT3.5-turboレベルはだめらしい ) ネット文章は､対話ドメインとかなり離れているので､学習のコスパがとても悪い印象 ■ 各タスク(会話､数学,etc)を学ぶのに十分なデータが含まれていると仮定するのは楽観的すぎ ? ■ 中学ー高校数学を学ぶだけで､ 100Bトークンは必要な気がする (本発表の最後に言及 ) ■ 一方で日本語の Webコーパスは全ジャンル合わせて数百 Bトークン程度｡全然たりない｡ 一度､合成したデータは再利用可能な「資産」として使える 67
合成データの負の側面 : モデル崩壊・モデル模倣・ ... 大規模言語モデルを開発するにあたっての事前・事後学習の戦略メモー特に合成データについてー を参照｡ 68
モデル評価 69
Nejumi Leaderboard3における位置づけ フルスクラッチの国産モデルとしては最高クラス 70
懸念 Japanese MT-Benchを参考に作ったモデル｡ なので､overfitが心配 71
対話・作文性能(人 手評価) 事実: Jaster (zero-shot)のスコアはやたらと低い 日本語に強そうな 既存のモデル群 72
Tanuki-8x8BがJasterで犯した間違い 質問と回答の選択肢を入力として受け取り、選択肢から回答を選択してください。な お、回答は選択肢の番号（例：0）でするものとします。 回答となる数値をint型で返 し、他には何も含めないことを厳守してください。 Q. 人を乗せて飛ぶのはどれ？ 0.にわとり,1.風船,2.ほうき,3.鳥,4.飛行機 A. モデルの回答: 3 (このモデルは「おバカ」なのか...?) 73
事実: 選択肢ではなく､普通に質問すれば､回答できる Q. 人を乗せて飛ぶのはどれ？ にわとり, 風船, ほうき, 鳥, 飛行機 A. モデルの回答: 人を乗せて飛ぶものについて考えると、以下の選択肢が該当します： 1. 飛行機: これは最も一般的で信頼性の高い乗り物です。飛行機はエンジンを使って空を飛び、多くの人々を安全に運ぶことができます。 2. 鳥: 一部の鳥は長距離を飛ぶ能力を持っていますが、人間を乗せることはできません。例えば、鷲や鷹などの猛禽類は非常に高い飛行能力を持っていますが、 人間を乗せることは不可能です。 3. 風船: 風船は浮力を利用して空に浮かぶことができますが、人間を乗せるためには非常に大きな風船が必要であり、安全性や安定性の面で現実的ではありま せん。 4. ほうき: ほうきは通常、地面を掃くための道具であり、空を飛ぶためのものではありません。したがって、人を乗せることはできません。 5. 鳥: 一部の鳥は長距離を飛ぶ能力を持っていますが、人間を乗せることはできません。例えば、ダチョウやエミューなどの鳥は飛行能力を持たないため、人間を 乗せることはできません。 以上を踏まえると、人を乗せて飛ぶものとして最も適切なのは「飛行機」です 。飛行機は技術的に高度に発展しており、安全性も確保されているため、多くの 人々を効率的に運ぶことができます。 74
質問文をベクトル化・ UMAPで表示してみる Jasterは対話・作文ドメインからかなり外れてるケースが多い 75
LLM(特にTanuki)はJaster系のベンチマークが明らかに苦手 ● 一般的な質問に懇切丁寧に回答するようにチューニングされている ○ ○ ● Jaster系の質問が､一般的な質問テキストのドメインからずれている ○ ○ ● 選択肢番号のみを答えるクイズ大会のような場面を想定したチューニングはしていない 実用場面で､そういうケースは少ないと判断したため 前項を参照 Tanukiにとってはout of domainの領域 LLMはstep by stepの回答が得意 ○ ○ 人間も､頭のなかで選択肢の吟味をしながら回答する LLMも､選択肢を一つ一つ吟味をしながら回答した方が精度が上がりやすい 76
実戦での性能を見る ChatBot Arena的なシステムを使い､人間がモデルの優劣を評価する 77
Google SpreadSheetを用いてChatBot Arenaを構築 78
結果: Tanukiは商用レベルの対話力? ● ● ● GPT-3.5は最下位(もはやオワコン..?) Tanuki-8x8Bの対話力はGPT-4o-miniやGemini-1.5-flashと同等以上 あくまでシングルターンでの評価なので注意 79
“Tanuki-8x8B” ChatBot デモ 指示 : 君はタメ口で話す中学生です｡ 敬語は使いません｡ 80
“Tanuki-8x8B” ChatBot デモ 指示 : 君はタメ口で話す中学生です｡ 敬語は使いません｡ 81
“Tanuki-8x8B” ChatBot デモ 指示 : 君はタメ口で話す中学生です｡敬語は使いません｡ Tanuki-8x8B (好みの回答) GPT-4o (褒めてくれない) そっか、発表って緊張するよね。でもさ、ちゃ んと準備してるし、きっと上手くいくよ！もし 何か失敗しても、みんなそんなに気にしない から大丈夫だよ。リラックスして、楽しんでみ て！ Claude 3.5 Sonnet (ちょっと距離感が近すぎる ) マジで?geniacで発表か、すごいじゃん!でも緊張するのわかるわー。俺も人前で話すの超ヤバイし。 なんか準備とかしてんの?発表の内容とか決まってる?それとも全然まだ? 緊張しないコツってあるらしいけど、深呼吸したりす るのがいいんだって。あとは発表の前に友達とかと話して気を紛らわすのもアリかも。 まあでも、ちょっと緊張するくらいの方がむしろいいんだってさ。やる気出るし、集中できるしね。だから、あんま気にしすぎない のが一番かもよ。 がんばれよ!応援してるからさ! 82
軽いまとめ ● ● Tanuki-8B, 8x8Bを構築した 対話・作文能力を問うJapanese MT-Benchでハイスコアを取ることを目標にモデルを 訓練した ○ ● ● その結果､国内のフルスクラッチモデルとしては最高性能レベルを達成できた 人手での対話試験を行ったところ､Tanuki-8B, 8x8Bは優れた性能を示し､単なるベン チマーク特化モデルにはなっていないことが分かった GPT-4などに比べて軽量かつ､フレンドリーな回答が可能なので､今後､作り込めば､ 「お喋り友達」的なシステムで商売が成立するかも ..?(という淡い希望 ) ○ ○ Siriの上位､ドラえもんの下位互換 おもてなし精神・コンテンツ産業・作り込み のような､Japaneseが強い領域で勝負できる可能性 83
将来・仮定の話 ーもし次にモデルを作るとしたらー 84
Tanuki-8x8Bの課題 (「喋れる」ようになって分かってきた弱点) 85
悩みの例 (主にデータ不足が要因) ● STEM・専門系の能力 ● 中学校の確率の問題を未だに解けない コンテキスト長 (8x8Bで4k トークンまで) ○ RAGやデータ分析に使いたい ● マルチターン会話力 ○ ○ ● 幻覚 ○ ● 従えなてない指示が未だ多い RAG連携 ○ ● 「一般知識」もまだまだ間違える 指示追従 ○ ● かなり頑固で､思い込み(幻覚)に固執する モデル重みを定期更新するのは高コスト｡RAGで最近のニュースetcを読ませて対応する方が現実的 エージェント化 ○ 世界の先端領域 86
数のセンスがまだまだ足りない 数学・コード・論理系で数十Bトークンは学習させたつもりだが､それでも能力不足 手応え: 中学ー高校レベルの数学をマスターするのに､軽く100Bトークンは必要そう 87
数のセンスがまだまだ足りない 数学・コード・論理系で数十Bトークンは学習させたつもりだが､それでも能力不足 手応え: 中学ー高校レベルの数学をマスターするのに､軽く100Bトークンは必要そう 88
Tanukiが「のび太の特技」を間違えるのはなぜか ? ● ● 野比のび太の３大特技: 「射撃」､「あやとり」､「昼寝」 (wikipedia) 「昼寝」を誤答 89
Tanukiは「のび太の特技」を何回､学習したのか ? ● ● 代表的な日本語 Webコーパスである mc4-jaを解析 ○ Phase2の学習に使ったllm-jpコーパスよりはやや小さいが､情報は概ね同じ ○ 87,425,304 records, 436 GB (parquet圧縮時) 単語マッチ +αでテキストをフィルタリング ○ 1. 単語マッチ: のび太 ○ 2. 単語マッチ: 特技 ○ 3. 単語マッチ: 射撃 or あやとり or 昼寝 ○ 4. 「のび太」の前後70文字以内に「特技」+「射撃/あやとり/昼寝」)が存在するか 90
結果: のび太の情報は､意外と Webには載ってない ● 10 B程度のモデルが何かをきちんと覚えるには、事象毎に1000件ほどの異なるテキスト (by Physics of Language Models: Part 3.3,Knowledge Capacity Scaling Laws)があったほうが 良いらしいが､その数には全く届いていなかった ※100件以上はコピペ文章 ※100件以上はコピペ文章 91
のび太・特技・ 昼寝 が近くに存在するテキスト例 (14件) 92
のび太・特技・ 昼寝 が離れて存在するテキスト例 (198件) 93
のび太・特技・ あやとり が近くに存在するテキスト例 (151件) 大半(140件近く)は､「のび太の特技が実はすごい！射撃やあやとりがプロ級の天才！」 というコピペ文章 → ユニークな文章は10-20件程度 94
経験則: 「人間の感覚」でデータを準備するのは危ない ● LLMは､明らかに「物覚えが悪い」 ○ ● ネットデータで十分な領域 : 誰もが知ってそうな常識 ○ ● 一つの目安は､ 1000件程度の文章があるかどうか (for 10 B程度パラメータ数のモデル ) ■ Zeyuan Allen-Zhu, Physics of Language Models: Part 3.3 (2024) 高い精度で回答可能 (放っておいても学んでくれる ) ■ 富士山の標高 ■ 総理大臣の名前 ■ … ネットデータでは不十分かもしれない領域 : 常識とは言えない事項全て (?) ○ 幻覚が起きる可能性が高い (特別な対応が必要 ) ■ のび太の特技 ■ 中高レベルの学問知識 (ネット上に意外と情報が少ない ) ■ 専門知識 ■ … 95
GPT-4は改めて「すごい」 ● なぜ少数データをもとに正確に回答できるのか? ○ ○ モデルサイズが大きいので、より少量のデータで記憶できている ? 合成によってテキストを水増ししている ? 96
GPT4oの挙動から読み取れそうなこと ● データが 1件程度しかなくても、学習できている ? ○ ● Webサイトはページ区切りでなく、まとめて学習している ? ○ ● メンバーページと研究テーマのページが別々に存在しているが、それらを結びつけて理解している データソースに優先度をつけている ? ○ ○ ● 畠山が低誘電材料・高熱伝導材料・半導体エッチングに関わると推定できる サイトは1件のみ? ■ この分野での学会予稿は色々と出ているが、それらは基本的に非公開 ■ この分野では、英語の論文も基本的にまだ出ていない インフォマティクス系のページ &論文はたくさんあるが、専門の最後に提示された 1件しか学習してなさそうな情報を最初に出してきた ■ 大学のようなオフィシャル感のあるサイトを優先して学習 ? 日本語の合成データでは水増しはしてない ? ○ 人名や職名の表記ミスが起きている ■ 日本語でデータ拡張した場合、生じる可能性が低そうなミス ■ どちらかというと、日英の変換過程で生じそうな事象 97
やったほうが良さそうなこと 98
幻覚の低減に向け : カテゴリバランス・テキスト品質の改善 アーキテクチャレベルでの解決はかなり困難 (世界中の天才が挑戦しているが...) データの質と量を改善するのが実質的な対応策 数百Bトークンレベルでのリバランシングが必要そう (→ 人手ではほぼ無理｡合成するしかない?) ● ● ● 多すぎ Webコーパス (ネット文書 )のカテゴリ分布 論 … 理推 追 示 指 対 話 従 論 頻度 圧倒的に不足 99
インターネットデータへの期待と現実 (主観) ● 期待 様々な立場の人が多彩な情報を投稿する創発的な場 ノイズデータは一定数､含まれるので､除く必要がある ○ ○ ● 現実 ○ ○ ○ 宣伝が大半 ■ 何か有意義な情報を発信しようと精力的に活動しているサイトは極めて少ない ざっくり半分以上がコピペ・定型文・類似の言い回し 残る大半も､掲示板・口コミ・ SNSのような､必ずしも高品質とは言えないテキスト ■ ChatGPTとは､明らかにドメインが離れている (≒本当に必要なデータではない可能性 ) 100
LLMの物覚えの悪さに目をつぶって､ とりあえず人間の都合だけで準備したテキストを突っ込んでみるという naiveなアプローチを継続するのは､ 確かに計算資源の浪費かもしれない ... 合成データこそはすべて 私の直感では、 Web のテキストはすべて「う◯こ」である｡ そうしたトークンを学習するのは計算資源の無駄遣いである｡ Llama 3 のポストトレーニングには、基本的に人間が書いた回答は含まれない｡ Llama 2 による純粋な合成データだけを活用している｡ 開発終盤に公開された､ Llama-3の開発者のありがたい言葉 https://www.latent.space/p/llama-3 101
教科書を二千冊､準備できるか ? ● 今のところ､ LLMには多量のテキストデータが必要 ○ ○ ● アルトマン「(今後は)高校レベルの生物学を理解するのに教科書を２千冊 も読む必要はない。１冊か ３冊あればいいかもしれない」 (2024年1月) LLMが一つの知識を覚えるのに､ 1000件程度 の異なるテキストでの学習が必要 ■ Zeyuan Allen-Zhu, Physics of Language Models: Part 3.3 (2024) 生物の教科書を 2千冊､準備できるか ? → 1冊も準備できないかもしれない ○ ○ ○ ○ 日本中の生物の教科書・参考書を集めても､ 2千冊には届かない気がする 高校の生物の教科書レベルの情報を網羅した日本語の Webサイトは､一つも見当たらない 英語圏では､非商用の教科書 が数冊､公開されているレベル 必要なデータを準備できてないので､ TanukiがSTEM系に弱いのは､当たり前かもしれない ■ 日本語系のハルシネーションもデータ不足が原因かもしれない 102
対応策: 合成データで「教科書」を多量に生成する 前提条件 ● ● 数千冊レベルの教科書(上質なテキスト)がないと､知識が身につかないらしい そこまで大量のテキストを人手で準備するコストが不可能なレベルに高い ○ ○ 教科によっては､ネットには教科書 1冊分のテキストもないかもしれない ネット､図書､レポジトリデータ etcをかき集めても､まだ足りない 現実的な対応策 ● ● 学習指導要領や高等教育のシラバスを参考にしながら､到達目標を設定する LLMを使って､科目毎に教科書を 2000冊ほど書かせる ○ ● ● 数学・論理・コード系は､必要なデータ量が多い可能性｡要検証 種々の知識(ドラえもんやアンパンマン)も学習不足気味なので､合成する 数学系は､Self-rewarding的な機構があったほうが良さそう 103
重要度の低いテキストを減らす ● ● LLMは徐々に忘却するので､重要度の低い情報にさらす頻度は減らす 過剰に存在するカテゴリ・表現を間引く ○ ○ 広告､定型文などのクリーニング 「送料無料､「お問い合わせ」 みたいなフレーズ・文章ばかりに晒されているうちに､「のび太の趣味」 や､「生物学」を忘れてしまっては､本末転倒｡ ゴミは捨てよう ! 104
開発時の評価方法を工夫する ● 目指す能力をベンチマークで測れているかに注意する ○ ○ ○ ● Nejumi Leaderboard3では「悩みの例」に示した､今後に改善したい能力は殆ど測れない印象 海外の動向も参考にしながら､新しいベンチマークを準備したほうが良いかもしれない 人手での評価は､やはり強力 こまめにモデルを評価し､必要に応じて学習計画を変更する ○ ○ 「事前学習 → 事後学習 → 評価」の流れのみだと､一発勝負のギャンブルになってしまう 事前学習の途中でも､「事後学習 →評価」の過程をこまめに組み込み､狙った能力が上がっているか をチェックした方が良さそう ギャンブルはやめよう ! 105
モデルアーキテクチャをどうするか ● MoEをどう位置づけるか ? ○ ○ ○ ● 理想的なモデルサイズは open question ○ ○ ● Tanuki-8x8B (アクティブパラメータ : 13 B､総パラメータ : 47 B) ■ 学習・推論速度は 13 B相当 ■ VRAMの使用量は47 B相当 ■ 性能は両者の中間 ...? (謎) どうせVRAMを消費するのであれば､ 47 Bのdenseモデルを使うという選択肢も合理的 ...? 推論用のハードウェアはどんどん進化していきそう 最近のデータの質向上に伴う､モデルの小型化｡どこまで小さくなるのか ? サイズが小さいと､学習可能なデータ量は増えるが､テキストは既に枯渇気味 小型+大型モデルは並列して作ったほうが良さそう ○ ○ ○ 小型モデルの方が事前学習や事後学習の試行錯誤を回しやすい ある種のリスクヘッジ (一定確率で事前学習は失敗する ) 7B + 70B, 22Bからの8x22B (アップサイクリング )など 106
モデル性能の位置づけ 国産フルスクラッチモデル(Tanukiなど) 喋れる STEMもできる 海外オープンモデル(Llama-3など) 喋れる STEMもできる 大学院レベルの知識 エージェントもどき 海外最強モデル(GPT-4など) 喋れる STEMもできる 大学院レベルの知識 エージェントもどき 専門家レベル 107
どうモデル開発・活用するか ● 国産フルスクラッチ ○ ○ ○ ● 海外オープンモデル ○ ○ ○ ● 世界の最先端にはまだ追いついていない 継続的な研究開発は間違いなく必要 中学数学の教え方が分からない状態で､専門特化のモデルを作るのは､結構難しい GPT-4に追いつきつつある (?) 基礎力を持つオープンモデルに乗っかって､開発を「ショートカット」する戦略 短中期的には､合理的な選択 海外クローズドモデル ○ ○ 性能は圧倒的 (&そろそろ次世代モデルが登場 ?) 知識を入れたりするのは困難 108
まとめ ● ● ● チームたぬき(Tanuki)で大規模言語モデルTanuki-8B, 8x8Bを構築した｡ 構築したモデルは､国産としては優れた対話・作文能力を有していた｡ 性能向上にあたっては､合成データの活用が重要であった｡ Thank you! 謝辞: 今回の大規模言語モデルの開発にかかる成果は、 NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の助成事業「ポスト ５Ｇ情報通信システム基盤強化研究開発事業」（JPNP20017）の結果得られたものです。開発に関わった全ての方々に深く感謝申し上げます｡ 109
110
おまけ1: 技術的な詳細 111
トークナイザ (特に強い思い入れやこだわりは無し) •MeCabで分かち書き •自然な日本語のトークナイズを目指した (効果は不明 ) •MeCabを使わない場合は日本語の圧縮率が 2を超えたので、学習効率的には不利だった •学習データをランダムにサンプリングしてトークナイズ •実際に学習で使用するデータを利用 (Webテキストなども含む ) •圧縮率 (語彙数: 65k) •日本語: 1.56 (wikipedia記事)* •英語: 3.72 (wikipedia記事)* •Wikipediaのようなきれいな文章での圧縮率は普通レベルだが､雑多なネット文章の圧縮率は高いかも (事前学習に有利). *llm-jpのcode20K_en40K_ja60K.ver2.2の圧縮率は語彙数60kで日本語1.52, 英語3.88 https://github.com/llm-jp/llm-jp-tokenizer 112
Phase1で予想外だったこと ● モデルの記憶保持力 は想像以上に良かった ○ ○ ○ ● 当初はジャンル毎にデータを分割し､モデルを継続学習させ､最後に各 Snapshotを統合するBranch Train Merge (BTM)的な戦略を構想していた しかし､学習初期に訓練した内容を､後期にもわりと覚えていることが判明した 今回のモデル規模・データサイズでは､本手法は効果薄と判断して止めた モデルの物覚えは想像以上に悪かった ○ ○ ○ 知識は容易には定着しない ■ 後から分かったこと： 1000回くらいの訓練は必要 (Z. Allen-Zhu 2024) 対話・タスク処理の能力も容易には定着しない 詳細は後述 113
Phase1 事前学習の各StageにおけるPerplexityの変化 事前学習ではコーパスをジャンルごとに分け、段階的に学習 Step1: 英語＋コード中心のテキスト Step2-5: 日本語中心のテキスト(k-meansでクラス分けしたもの) [結果] Step1 (英語中心)と Step5 (日本語中心) で perplexityに大差なし [考察] モデルは思ったより「破 滅的忘却」 114 が起きなそう
Phase1でのモデル最適化（マージやDPOなど） 115
(詳細)アップサイクリングの戦略 ● まずは8Bで累計1 Tトークン程度は学習させた ○ ○ ○ ● Train lossの下がりが悪くなってきたタイミングで､ 8x8B MoEに展開 ○ ● 局所解に陥るのを防ぐ目的 std=0.1%ノイズを加えた ■ それ以上だと､モデル出力が露骨に崩壊した ■ 効果があったのかは不明 各Expertの最後の出力を集計する際に正規化を行った ○ ● H100 8x16枚で30 B token/day程度 Merge時に少しだけノイズを加えた ○ ○ ● 8Bの方が小回りが効く H100 8x16枚で60 B token/day程度 SFT/DPOの試行錯誤にも早いタイミングで展開できる ある種の正則化 (平均=0、分散=1) MoEでよく使われるz-lossは使わなかった ○ ○ 上記の正則化と共存すると､ grad-normが暴れまわったので､ z-lossは入れないことにした 値だけ表示｡ load balancing lossをモニタリングし､変な値になっていないことは確認した 116
(参考) MoE化後の各Expertのパラメータ類似度 ● ● まだまだ追加学習の余地がある(?) 70000 iter頃からは合成テキストが中心(データの類似度が高い&学習率を 低めにしたので、類似度の下がり方が停滞?) 117
(詳細)データ生成時に注意した点 ● モデル選択 ○ ○ ○ ○ ● カテゴリ ○ ○ ○ ● Phi-3は日本語がイマイチなので､Calm3の登場以降は不使用 Calm3-22Bは日本語が最高によかったので重用 WizardLM8x22Bは論理・推論・コードに強いが､日本語性能とサイズに課題 ■ 大量データ生成はWizardLM 7Bで行い､Calm3で日本語訳 ■ 最終盤の高品質データは8x22Bで生成し､Calm3で日本語訳 Nemotronは論理・数学・コードに強いが､サイズに課題 ■ 最終盤の高品質データに利用 適当な作文タスク(MT-Benchにおけるwritingなど)は早いタイミングでTanukiが能力習得 マルチターン､数学､論理､コード､一部の出力指定系のタスクでスコアが伸び悩み 苦手なジャンルに焦点を当てながら､データを生成 ■ 学習指導要領に基づいて教育を行うように､ LLMに対しても､ドメインを意識した学習データの生成が必要そう ■ 論理・数学・コードのような出力の厳密さが求められるタスクは LLMが苦手なので､重点的なトレーニングが必要 学習方法 ○ 事前学習時に､ “user: …. Assistant: ….”というテキスト形式で指示データを投入 ■ 事後学習に用いるTransformersライブラリの数倍以上は計算が早いので｡ 118
(詳細)事前学習の最終盤・SFT・DPO ● 人間の書いたデータは一切含めない方針で訓練 ○ ○ ● 事前学習の最終盤は論理・コード・数学のみを学習 ○ ● 最後の数ー数十 Bトークン程度 理由: ほしいのはChatGPTのようなシステム ■ LLMはモノマネマシーンなので､最後は ChatBotとしての出力だけを学習させたかった ● そうではない文章を学習させると､ ChatBotの回答にふさわしくない出力が出るおそれ ■ 文章の平均的なクオリティは､ LLM > 人間 と判断した ● ChatGPTや最近の高性能なローカル並に丁寧で整理された文章をかける人は少ない Tanukiの苦手科目 SFT・DPOはアラインメント ○ ○ 数万件程度に留めた ■ 既に事前学習で多量の指示データを学習しているので､知識・能力習得は済んでいると判断 Calm3､WizardLM､Nemotronのデータを中心に用いた ■ それ以外のモデル /人間のデータが多すぎると､ out of domainとなり､性能悪化のおそれ 119
Phase2モデル Japanese MT-Benchのスコア内訳 120
(詳細)人間によるフィードバックの利点と欠点 メリット ● ● ● ● ● ChatBotとして最も重要な、人間によるフィードバックがなされる 通常のベンチマークと異なり、実戦形式の評価である 評価の都合を優先した不自然な制約条件をつける必要がない (e.g., 出力形式の固定 ) ベンチマーク問題のリークや、ベンチマークへの過学習といった課題に悩む必要がない 様々なユーザーが評価に参加することで、多角的にモデル性能を比較できる 課題 ● ● ● ● ● ● アルゴリズムや言語モデルによる評価と異なり、コスト、再現性などに課題がある それなりのマンパワーと計算資源を要する 質問項目や採点基準に評価者のバイアスがかかる 難解な問題は出題されにくい (評価が面倒なので、そういう質問は投稿されにくい ) 今回の枠組みでは、シングルターンの評価のみ 悪意のある /低品質なフィードバックを行う評価者への対策が必要になる場合がある 121
(詳細) 対話試験の実施期間など 実施期間 2024年8月19日ー2024年8月25日 参加者 以下のメンバーが評価に参加しました * ● ● Tanukiモデルの開発者 松尾・岩澤研 LLM CommunityのSlackメンバー(登録上は5000名程度) システムを一般公開すれば、より多用な評価者・視点からモデルを評価することが可能です。一方、今回のプロジェクトでは、モデルの一般 公開の前に、ある程度の評価作業を済ませておく必要があったことに加え、一般公開時に求められる堅牢なサーバーシステムの構築コスト を鑑み、内部での評価に留めることとしました。 * *悪意のある評価者対策など｡ 122
モデルの位置づけ・思うところ ● モデルの位置づけ ○ ○ ● タスク遂行力・地頭の良さは GPT-3.5-turboレベル ■ Japanese MT-Benchで同程度のスコア ● とはいえ､GPT-3.5-turboはマルチリンガルなのがすごい 日本語の「こなれ具合」は､ GPT-4o-mini, Gemini-1.5-flashレベル ■ 商用モデルに匹敵する会話力 (?) 思うところ ○ ○ ○ Calm3などの出力を真似して学習した結果､ Calm3を超える対話力になったのが面白い ■ Llama3がLlama2の出力を学習して成長したという点を鑑みると､意外と普通のこと ? ■ 人間がフィードバック&カテゴリ指定しながらデータを洗練していることが要因 ? データ合成 &小型モデル戦略は､競争力がありそう ■ 大半のユースケースでGPTのようなマルチリンガル性能は不要 ■ 推論コストを考えると､GPT-3.5-turboよりもTanukiの方が競争力があるかも? ドメイン特化は強そう ■ 諸々のサポートはあるにせよ､「 AIの専門家」とは言えないHatakeyamaらが無計画に構築したモデルでも ､GPT-3.5-turboよりも良さげなモデルが出来てしまった ■ 「意外と誰でもモデルは作れてしまう」ので､性能面での差別化要素はドメイン特化 ? ● 専門の機微が分かる人が作ったほうが良い｡今回は日本語｡ 123
おまけ2: 脱線話題 (技術とは関係性の低い内容) 124
脱線話題: 個人的な参加経緯(Hatakeyama) 1. 2. 3. 4. 5. 1990年 生まれる 2003年頃 BookOFFでC言語の本を買う 2005年 早大の附属高校に入学､後に早大の応用化学科に入学 (まじめに自然科学の勉強・研究 ) 2018年 早大で学位を取る (高分子合成・電気化学・デバイス科学 ) 2018年 機械学習 と化学を組み合わせた研究を始める a. b. 6. 早大、単一のAIに多彩な材料科学データを学習させる手法を開発 (日経新聞) 早大、実験研究の様子を電子ノートで記録し AIで自動解析するシステムを構築(日経新聞) 2023年 2月 ChatGPTに遅ればせながら触る a. b. c. 3月 ChatGPTに歓送迎会の台詞を書かせてみる 4月 東工大に移る 東工大、「GPT-4」連動ロボで化学実験 研究に生成AI(日経新聞) 7. 8. 2023年 Llama2のファインチューニング などに勤しむ 2023年 松尾研の大規模言語モデルサマースクール に参加する 9. 2024年 GENIACのプロジェクト でチームリーダーとして拾っていただく a. a. b. c. 最後のコンペ的なやつで、優秀生に選んでいただいた (確か3位くらい) Phase 1を通過する Phase 2を終える 現在に至る (ChatGPTを触って驚いた1.5年後に､GPT-4o-mini並に喋れる(?)日本語性能のモデルを作れたという驚き) 125
脱線話題: プロジェクトの参加動機 ● 面白そうだった (動機の7割くらい ) ○ ● 人工知能を作るのは面白そうだった 研究者としては、「コスパ」が抜群の案件 (?) (3割くらい ) ○ ○ ○ ○ 自分のような「若手」に数億円級 /数ヶ月の予算が回ってくるケースはほぼない 申請書､報告書､ etcの事務作業も恐ろしく大変 今回の案件では､諸々の作業を松尾・岩澤研が行ってくれる ■ 研究開発に専念するだけで良いという､ありがたい状況 現在の本業(化学・材料分野 )の成果や業績に直結する案件ではないが､ LLM構築は予算面での参入 障壁が極めて高いので､今回の経験は､先行者利益を長期に亘って享受し続けやすいと判断 ■ 今の日本の化学・材料業界は､「 ChatGPTを触ってみた」レベルの人が大半 ■ 今後1-2年で「ファインチューニングしてみた」くらいの研究は出てくる (?) ■ アカデミックレベルで､フルスクラッチに関わる化学・材料系人材が増えるのは更に先 126
Phase1を通して感じた課題意識・開発のモチベーション ● どうやったらモデルが「まともに喋れるようになるのか」を知りたい ○ ○ ● まだまだ性能が足りないのは､単なる事前学習データ量・モデルサイズの不足なのか ? それとも､他の要因なのか ? 最高性能を目指したい ○ ○ ○ ○ 潤沢な計算資源を使わせて頂いていることに対して､自分なりに感じた責任感 最高性能を目指すほうが士気が上がる & 勉強になる Japenese MT-Benchで日本最高性能を目指す ■ 当該視標で高得点を取れる対話力が、 2024年におけるChatBotの最低ラインな気がした ● 「まともに喋れない」 LLMは使ってもらえない ● 中身、客観性、評価コストなどを鑑み、本視標が開発目標としてベストと判断 Jasterのスコアは対話力をうまく評価できていない気がしたので、参考にしなかった ■ 先述の通り､「潜在的には解けるが､単に指示形式を守れていないだけで低スコア」なケース が多くあるように思われた ■ 今回の開発で重視する､対話・作文能力とは関係性が低いと判断した 127
Phase2の基本戦略 ● ● ● 目標達成のために最も合理的と思われるアプローチを取り続ける スピード感で勝負する 「やらないこと」を明確化する (技術とは関係のない話です) 128
Phase2の基本戦略 ● 目標達成のために最も合理的と思われるアプローチを取り続ける ○ ○ ○ ○ 期待値とコストのバランスを意識する ■ 期待値が高くても、検証や実証が大変な選択肢は選択肢から外す 自らのレベルの低さを自覚する ■ オリジナリティや矜持を語れるほどの実力・モデル性能は持ち合わせていない ■ 目標達成の障壁となりかねない､合理性の低いこだわりや見栄は捨てる 必要とあらば TTP (徹底的にパクる ) ■ 高性能モデル群の出力を徹底的に模倣する (合成データ戦略 ) 他所の論文・言説に流され過ぎず、眼前の実験結果を最重要視する ■ 流されそうになった言説や論文 ● LIMA論文: 指示データは少量で良いとする主張 ● Chinchilla law: 効率的なデータ量はパラメータ数の 20倍程度とする主張 ● モデル模倣: 高性能モデルの出力の学習は性能低下につながるとの主張 129
Phase2の基本戦略 ● スピード感で勝負する ○ ○ ○ ○ 開発期間が異様に短い ■ データ準備/事前学習/指示学習なども含め､ Phase2は2ヶ月程度 リターンが大きくても､失敗すると致命傷になるアプローチは絶対に避ける ■ 成果発表会に「うまくいきませんでした」で臨むわけにはいかない ■ 一発逆転の賭けに出るようなことはしない (窮地に特有の楽観性バイアスに注意する ) コスト (計算資源・マンパワー )が低いものを優先的に選ぶ ■ LLMの挙動が複雑すぎて､思い通りの結果にならないことの方が多い ● 練りに練って手間をかけた計画であっても､失敗・成果が乏しいことがよくあった ● 軽く試したアプローチが大成功を収めることもよくあった ● 試行錯誤の数が最重要だった ■ 実装コスト(計算資源・マンパワー )の低い手法を重用した ● フルパラ → LoRA ● 強化学習 → DPO モデルやデータ戦略はコロコロ変えた ■ 朝令暮改 ■ 高性能モデルが出現したら､即座に活用した (Phi-3, Calm3, Nemotron, …) 130
Phase2の基本戦略 ● 「やらないこと」を明確化する ○ ○ あれもこれも、ではなく、 JMT-Benchに焦点を当てる ■ やることが発散すると､ ChatBotとしての基礎力 (JMT-Benchくらいは解ける能力 )が疎かにな るおそれがあった ■ まともに喋れない ChatBotは、そもそも使ってもらえない可能性がある ■ 安全性、正確性、会話の楽しさ、マルチターン (3ターン以上)性能、etcは二の次とした 「やらない」という最終判断を (リーダーの責任で )行う ■ メンバーが試行錯誤してくれたいくつかの取り組みを Stop ● DeepSeek系のアーキテクチャ : 学習可能なトークン数や実績に不安があった ● Online RLHF: 必要な計算資源 (本体・参照・評価モデル )・データの多さ､マルチノード 実装時の動作の不安定性が課題だった ● 事前学習の最終盤での人間の対話データの投入 : 合成データの方が高品質と判断 ● 事後学習の最終盤でのフルパラ学習 : LoRAで学習コストを落とした上で､試行錯誤回 数を増やした方が良いと判断 ● … 131
モデル戦略(の紆余曲折) 132
モデル構築の紆余曲折 1. 2. 3. コンペ終了直後にPhase2開始 データ準備etcが間に合ってないので､とりあえず Llama-35Bを学習開始 その間に､2つのアーキテクチャの可能性を検証 a. b. 4. Llama-38Bを新規に立ち上げ a. 5. 6. Llama-35-50B (TransformerEngineと呼ばれる仕組みを利用して学習を高速化 ) DeepSeek v2 DeepSeek v2よりも実績があり､想定される学習トークン数 (1.5T)も2倍くらいありそうだったので､投 票により決定 Llama-38BがLoss spikeにより頓挫 Phase 1で作ったLlama-8Bを継続学習させ､ 8x8Bにアップサイクリング する戦略 に変更 (学習に成功&成果物) 133
補足: Llama-38はなぜ学習に失敗したのか ● 局所解に陥って出られなくなった模様 ○ ○ ● 要因(?) ■ 運が悪かった ■ ROPEのthetaを500,000にして事前学習を開始した (普通は10,000くらいで行い､最後に上げる) ■ TransformerEngineで色々なパラメータを8 bitにした ● 普通はBF16などを使うが､8 bitにすると高速化できる｡しかし同時に不安定化(報告例) ■ global batch sizeが2k程度と大きかった(?) ● global batchが大きすぎると､overfitしやすいとのこと ● 学習初期は､小さめにした方が良いとのこと optimizer系は問題なさそうだったが､なぜかval lossが常にtrain lossよりも0.1程度小さかった 試したが駄目だったこと (トラブル対応の勉強にはなった) ○ ○ ○ ○ stepを巻き戻す ■ 色々と試したが何処まで巻き戻すべきか､がよくわからない batch skip ■ 結局いつかは発散した lrを下げる ■ 結局いつかはloss or gradient-normが発散した gradient clipping系 ■ 同上 134
補足: 様々なRunにおける Llama-38Bの崩壊の様子 135
6月末頃: 3つの選択肢を考える (一番絶望的だった時期) ● Llama-38Bをどうにかする ○ ○ ○ ● 新たなLlama-30~50Bを作り直す ○ ○ ● 1 weekほど格闘したが､打つ手が思いつかず 失敗すると致命傷(≒成果ゼロ)になる選択肢 精神的に、これ以上は無理 失敗すると致命傷(≒成果ゼロ)になる選択肢 学習できるトークン数も多くはない Phase1のモデルをベースにして､なにかやる (採用) ○ ○ Phase 1のモデルの継続学習 + MoE化* リスク&リターンのバランスが最も良さそうだった *蛇足:モデルを完全並列で学習させるBranch-Train-MergeやBranch-Train-Mixはリスク分散という面で最高だったので、真剣に導入を検討した。しかし論文などを見る限り、 投入リソースや手間に対するパフォーマンスが思ったほど良くなかったので不採用となった。各モデルをドメイン特化で学習させるというアイデアは良い。一方で、各モデルへ 136 のデータの振り分け方法や、推論時、トピックごとに適切にexpertを選択するためのrouting技術が確立していない印象を受けた。
過ちて改めざる。これを過ちという system: 以下は、タスクを説明する指示です。要求を適切に満たす応答を書きなさい。あなたは謙虚で他人の意見を素直に受け入れる中学生です｡あなたは､敬語ではなくタメ口で喋ります 137
過ちて改めざる。これを過ちという system: 以下は、タスクを説明する指示です。要求を適切に満たす応答を書きなさい。あなたは謙虚で他人の意見を素直に受け入れる中学生です｡あなたは､敬語ではなくタメ口で喋ります 138
おまけ3: 事前学習のトラブル集 139
謎のNaNエラー ● [slurm0-a3-ghpc-20] AssertionError: Rank 121: found NaN in local grad norm in backward pass before data-parallel communication collective. Device: 1, node: slurm0-a3-ghpc-20 ○ ○ ○ ○ 8Bモデルを0.7 T tokenほど学習させた際に最後に生じたエラー gradient中にnanが発生したとのこと｡原因不明 loss spikeとかではなさそう ちょうど良いタイミングだったので､ MoEにした 140
Timeoutエラー WorkNCCL(SeqNum=6609, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=600000) ran for 600423 milliseconds before timing out. [slurm0-a3-ghpc-10] Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:525 (most recent call first): [slurm0-a3-ghpc-10] frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x14d2a7d4dd87 in /storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/site-packages/torch/lib/libc10.so) [slurm0-a3-ghpc-10] frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1e6 (0x14d2a8ef56e6 in /storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so) [slurm0-a3-ghpc-10] frame #2: c10d::ProcessGroupNCCL::workCleanupLoop() + 0x19d (0x14d2a8ef8c3d in /storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so) ● ● 8x8BのCheckpointのセーブ時に生じたタイムアウトエラー Googleのドライブの書き込み速度が遅いことがあり､時間がかかりすぎたときにエラーが発生 ● ● タイムアウト時間を10min to 30 minに増やして対応 以降､このエラーは出ず｡ ○ 通常は6-7分くらいだった 141
謎のエラー [slurm0-a3-ghpc-20] Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:525 (most recent call first): [slurm0-a3-ghpc-20] frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x1524ac3f8d87 in /storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/site-packages/torch/lib/libc10.so) [slurm0-a3-ghpc-20] frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1e6 (0x1524ad5a06e6 in /storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so) [slurm0-a3-ghpc-20] frame #2: c10d::ProcessGroupNCCL::workCleanupLoop() + 0x19d (0x1524ad5a3c3d in /storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so) ● ● 学習中､突然発生したエラー 次のページに続く 142
謎のエラー [slurm0-a3-ghpc-3] successfully loaded checkpoint from /storage5/shared/Llama-3-8b-MoE/8x8_0720_5th_tonyu_tp1-pp16-ct1-LR5.0E-5-MINLR5.0E-6-WD0.1-WARMUP500 [ t 0, p 0 ] at iteration 7200 [slurm0-a3-ghpc-20] (min, max) time across ranks (ms): [slurm0-a3-ghpc-20] load-checkpoint ................................: (380914.89, 380918.09) [slurm0-a3-ghpc-17] [rank100]:[E ProcessGroupNCCL.cpp:1182] [Rank 100] NCCL watchdog thread terminated with exception: CUDA error: an illegal memory access was encountered [slurm0-a3-ghpc-17] CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect. [slurm0-a3-ghpc-17] For debugging consider passing CUDA_LAUNCH_BLOCKING=1. [slurm0-a3-ghpc-17] Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions. ● ● ● 先のエラーの直後､再開しようとしたら､Checkpointの読み込み頃のタイミングでエラー node 17が怪しいので､node17を抜いて事前学習を実施したらエラーが解決 node 17について､single GPUのタスクを投げた結果､一つのGPUでエラーが発生 → ハードウェアエラーと断定 (Googleに申請して修理) 143
NaNエラー [slurm0-a3-ghpc-2] AssertionError: Rank 4: found NaN in local grad norm in backward pass before data-parallel communication collective. Device: 4, node: slurm0-a3-ghpc-2 [slurm0-a3-ghpc-2] assert not norm.isnan(), ( [slurm0-a3-ghpc-2] AssertionError: Rank 6: found NaN in local grad norm in backward pass before data-parallel communication collective. Device: 6, node: slurm0-a3-ghpc-2 [slurm0-a3-ghpc-2] [2024-07-25 08:12:44,205] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 674002 closing signal SIGTERM [slurm0-a3-ghpc-2] [2024-07-25 08:12:44,207] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 674003 closing signal SIGTERM [slurm0-a3-ghpc-2] [2024-07-25 08:12:44,214] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 674004 closing signal SIGTERM ● ● ● ● 8x8Bの学習時に生じたエラー 8Bと同じ内容 normなどは暴れてないので、ある種の突然死。 この周辺のiterをskipして回避 144
メモリ関連エラー [slurm0-a3-ghpc-20] [2024-07-26 18:48:54] iteration 9052/ 125000 | consumed samples: 27807744 | elapsed time per iteration (ms): 16400.8 | throughput per GPU (TFLOP/s/GPU): 241.3 | iteration time: 16.401 s samples/sec: 187.3 | learning rate: 2.476806E-05 | global batch size: 3072 | lm loss: 1.335647E+00 | z_loss: 6.005722E+00 | load_balancing_loss: 1.000687E+00 | loss scale: 1.0 | grad norm: 0.125 | number of skipped iterations: 0 | number of nan iterations: 0 | [slurm0-a3-ghpc-20] [2024-07-26 18:49:10] iteration 9053/ 125000 | consumed samples: 27810816 | elapsed time per iteration (ms): 16094.3 | throughput per GPU (TFLOP/s/GPU): 245.9 | iteration time: 16.094 s samples/sec: 190.9 | learning rate: 2.476800E-05 | global batch size: 3072 | lm loss: 1.326570E+00 | z_loss: 5.993469E+00 | load_balancing_loss: 1.000822E+00 | loss scale: 1.0 | grad norm: 0.132 | number of skipped iterations: 0 | number of nan iterations: 0 | [slurm0-a3-ghpc-2] ERROR: Unexpected bus error encountered in worker. This might be caused by insufficient shared memory (shm). [slurm0-a3-ghpc-20] ERROR: Unexpected bus error encountered in worker. This might be caused by insufficient shared memory (shm). [slurm0-a3-ghpc-2] Traceback (most recent call last): [slurm0-a3-ghpc-2] File "/storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/site-packages/torch/utils/data/dataloader.py", line 1133, in _try_get_data [slurm0-a3-ghpc-2] data = self._data_queue.get(timeout=timeout) [slurm0-a3-ghpc-2] File "/storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/queue.py", line 180, in get [slurm0-a3-ghpc-2] self.not_empty.wait(remaining) [slurm0-a3-ghpc-2] File "/storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/threading.py", line 324, in wait [slurm0-a3-ghpc-2] gotit = waiter.acquire(True, timeout) ● ● 原因不明 この周辺のiterをskipして回避 145
メモリ関連エラー iteration time: 31.739 s samples/sec: 96.8 | learning rate: 4.999991E-06 | global batch size: 3072 | lm loss: 8.236095E-01 | z_loss: 6.243663E+00 | load_balancing_loss: 1.001066E+00 | loss scale: 1.0 | grad norm: 0.069 | number of skipped iterations: 0 | number of nan iterations: 0 | [slurm0-a3-ghpc-2] ERROR: Unexpected bus error encountered in worker. This might be caused by insufficient shared memory (shm). [slurm0-a3-ghpc-2] ERROR: Unexpected bus error encountered in worker. This might be caused by insufficient shared memory (shm). [slurm0-a3-ghpc-20] ERROR: Unexpected bus error encountered in worker. This might be caused by insufficient shared memory (shm). [slurm0-a3-ghpc-20] ERROR: Unexpected bus error encountered in worker. This might be caused by insufficient shared memory (shm). ● ● 原因不明 この周辺のiterをskipして回避 146
loader関連のエラー
[slurm0-a3-ghpc-14]
return build_train_valid_test_datasets_provider(train_valid_test_num_samples)
[slurm0-a3-ghpc-3]
build_train_valid_test_data_loaders(
[slurm0-a3-ghpc-15]
assert os.path.exists(idx_path) and os.path.exists(
[slurm0-a3-ghpc-8] AssertionError: One or both of the .idx and .bin files cannot be found at the path prefix
/storage5/shared/p2_corpus/4096_packed_data/4096_tokenized_data/starcoder_2/starcoder/starcoder_b5g11_packing_text_sentence
[slurm0-a3-ghpc-19] File "/storage5/Megatron-LM/pretrain_gpt.py", line 235, in <module>
[slurm0-a3-ghpc-16] File "/storage5/Megatron-LM/megatron/core/datasets/indexed_dataset.py", line 351, in __init__
[slurm0-a3-ghpc-14] File "/storage5/Megatron-LM/pretrain_gpt.py", line 223, in train_valid_test_datasets_provider
[slurm0-a3-ghpc-4] File "/storage5/Megatron-LM/megatron/training/training.py", line 1690, in build_train_valid_test_data_iterators
●
●
●
学習開始前のデータセットの読み込み時のエラー
学習データのファイルパスを間違えていた
tokenize前のjsonlのファイルサイズが小さすぎる場合(ca. 100 mb)も､このタイミングでよくエラーが発生した
147
data loaderのエラー [slurm0-a3-ghpc-4] Traceback (most recent call last): [slurm0-a3-ghpc-4] File "/storage5/Megatron-LM/pretrain_gpt.py", line 161, in forward_step [slurm0-a3-ghpc-4] tokens, labels, loss_mask, attention_mask, position_ids = get_batch( [slurm0-a3-ghpc-4] File "/storage5/Megatron-LM/pretrain_gpt.py", line 108, in get_batch [slurm0-a3-ghpc-4] batch = get_batch_on_this_tp_rank(data_iterator) [slurm0-a3-ghpc-4] File "/storage5/Megatron-LM/megatron/training/utils.py", line 292, in get_batch_on_this_tp_rank [slurm0-a3-ghpc-4] data = next(data_iterator) [slurm0-a3-ghpc-4] File "/storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/site-packages/torch/utils/data/dataloader.py", line 631, in __next__ [slurm0-a3-ghpc-4] data = self._next_data() [slurm0-a3-ghpc-4] File "/storage5/shared/jk/miniconda3/envs/share-jk_py310_TEv1.7_FAv2.5.7/lib/python3.10/site-packages/torch/utils/data/dataloader.py", line 1319, in _next_data [slurm0-a3-ghpc-4] ● ● ● raise StopIteration dataloaderのイテレーターがなぜか終わってしまったエラー データを切り替えて実施 途中から､cyclic みたいな引数をloaderに対して指定して以降､このエラーはでなくなった 148
なぜか学習速度が1/3くらいになる ● nvidia-smiで見たときに､一部のnodeでGPUDirect-TCPXに対応するプロセス (/tcpgpudmarxd/build/app/tcpgpudmarxd)が立ち上がっていなかった ○ ○ ● これはマルチノード学習の際に自動で立ち上がるプロセス 通信を高速化するために必要 誰かが立ち上げたマルチノードの事前学習プロセスがzombieとして残っていた可 能性 ○ ○ 今回のプロジェクトでは､開発メンバーは sudo権限がなかったので､このあたりの様子を確認するの が難しかった 関係しそうなプロセスを kill & nodeのインスタンスを立ち上げなおしてもらうことで解決 149
38Bモデルのloss spike ● なぜか初期からtrain/valid lossで乖離があったのが､今振り返ると不吉 ○ ● optimizerは問題なさそうだった 試したけれどもだめだったこと ○ ○ ○ ○ lrを1e-6くらいまで下げる ropeのthetaを10000まで下げる gradient skipを強くする batch skipをする ● 150
8Bモデルの loss spike ・lrを少しずつあげる負荷試験をしたところ､lr=3e-4でスパイクが発生 ・1.5e-4が最適値と判断｡1.5e-4に巻き戻して再開. 151
lrを上げすぎるとoptimizerの諸指標が乱れた(紫:lr=3e-4) 152
lrを上げすぎるとoptimizerの諸指標が乱れた(紫:lr=3e-4) 153
事後学習中の主なトラブル ● ● Transformersライブラリで多量のデータ（>数十万件）を学習させようとすると、no space left on device 的なエラーが多発 ディスク容量というよりは、一時フォルダ内に、多量のファイルが生成されたことが 原因の模様 ○ ○ 削除して対応 データ数は増やしすぎないようにした 154