数日前に投稿した、「マルチタスク推論のための微調整」についての続きです。それ以来たくさん読みましたが、難しい3B対7Bの問いはもう過ぎ去って、代わりにNemotron 3 Nano（最近NVIDIAがリリースした30B-A3BのハイブリッドMamba-Attention-MoE）に着地しました。私がより良く学習させたいマルチタスクの構造に対して、アーキテクチャの対応が密です。問題は、これまで密な（dense）Transformerの微調整についてしか読んだことがないので、ハイブリッドMamba+MoEアーキテクチャが、一般的なLoRAレシピの中で実際に何を壊してしまう（あるいは壊れやすい）のかが分からないことです。
相変わらず独学で、MLの正式なバックグラウンドはありません。約1年、API経由でLLMを扱ってきました。何かをエンドツーエンドで実際に微調整するのは今回が初めてです。
なぜNemotron 3 Nanoを特に選んだのか（選択自体が間違いである可能性がある前提で）：
- 23 Mamba-2 + 23 スパースMoE + 6 GQAアテンション層、MoE層ごとに128エキスパート、トップ6ルーティング
- 合計30B / 約3.6Bがアクティブ — トークンあたり計算量の爆増なしに容量を確保
- 長いコンテキストにまたがる状態認識型推論に対して、Mamba-2層が適切な構造フィットに見えた
- NVIDIA Open Model Licenseでオープンウェイト — やりたいことに対して整っている
何を微調整しようとしているのか（LoRA、より強い教師から推論トレースを蒸留）：
- 状況の中で構造的に何が起きているか、そして表面上で何が述べられているかの違いを読む
- あまりにも早く一つに崩さず、複数の正当な視点を保持する
- 入力に絡み合った複数の問題があるとき、負荷のかかる（支えになっている）主要なスレッドを浮かび上がらせる
- 文脈状態を記述する少数の数値入力特徴量に基づいて出力を条件付けする
40〜80kの例を計画中で、Sonnet 4.6で生成し、最も難しい20%にはSelective Opus 4.7を使用します。ORCAスタイルの説明チューニングで、単なるI/Oペアではありません。
ハードウェア： 前回投稿のM4 Macの計画は取り下げます。Nemotron 3 Nanoは24GBのユニファイドメモリに収まりきらないだけでなく、重みだけでも足りません。RunPodでトレーニング用にH100 80GBをレンタルします。5〜6回のイテレーションで使う予算は合計で約120ドルです。
特に心配していること（見つけたどの標準的な微調整チュートリアルにも、ハイブリッドアーキテクチャが載っていないため）：
- LoRAの下でのルータ。 MoEルータの重みに対してLoRAを安全に適用できますか？ それともルータは凍結して、LoRAはエキスパートのFFN＋アテンションだけにしますか？ 凍結する場合、マルチタスクの専門化はまだ生まれますか、それともすべてが同じエキスパートに押し込まれてしまいますか？
- 低ランク適応下でのMamba-2層。 標準的なLoRAチュートリアルは、純粋なアテンションを前提にしています。Mamba-2には選択的SSM状態と異なる投影構造があります。入力/出力の投影に対する標準的なLoRAはうまく機能するのか、それとも（状態の初期化、低ランク摂動下での再帰安定性など）標準ガイドでは扱われない落とし穴がありますか？
- 負荷分散ロス＋マルチタスクの不均衡。 4つの能力で例の数が異なる場合、補助的な負荷分散ロスはタスク固有の勾配と戦ってしまいますか？ 既知の失敗パターンはありますか？
- 30Bスパースベースでの壊滅的忘却（catastrophic forgetting）。 エキスパートにLoRAアダプタを付けると、密な微調整と同じようにベースの推論が劣化しますか？ それともスパースなルーティングが構造的にそれを守りますか？
- エキスパート専門化に対する評価の粒度。 ある単一の能力が静かに悪化していても、異なるエキスパートが別々のタスクを担当することで、集計指標が良好に見える可能性があります。マルチタスク下のスパースMoEでは、適切なホールドアウト評価設計は何でしょうか？
スタック： Unslothを使う予定です（彼らのNemotron 3 Nanoサポートは最近出荷されたようです）。タスク（能力）ごとのホールドアウト評価セットは、Batch 1の前に作成して固定します。教師側で、バッチAPI＋プロンプトキャッシングを使ってデータセットコストを抑えます。
求めていないもの：
- 「とりあえず試してみて」— 最初の実行はすでに間違っている可能性が高いので、どの次元が最も私を驚かせそうかを知りたいです
- 「先に小さい密モデルで」— すでに検討済みです。このハイブリッドアーキテクチャ自体が、まさにこのモデルを選びたい理由です
- 汎用的なLoRAチュートリアル — 密TransformerのLoRA文献には慣れています。ギャップはMamba＋MoEの具体にあります
求めているもの：
- 実際にMamba＋MoEハイブリッド（Nemotron、Jamba、関連があればMixtral）を微調整した人たちの「失敗談」。どこでうまくいかなかったのか教えてほしいです
- 特にスパースMoE上でのマルチタスクLoRAに関して、見落としているかもしれない論文 — 私が見つけたマルチタスク文献の大半は密（dense）を前提にしています
- 低ランク適応下でのルータ勾配に関する落とし穴
- 標準的なLoRAランクのスイートスポット（8〜32）が依然として成り立つのか、それともMoE＋Mambaが「何が効くか」を変えるのか
見つけたことはまとめて書くつもりです。初めてのプロジェクトは失敗しても有用なネガティブ結果を生みますし、個人開発者規模でのNemotron 3微調整については、現時点では基本的に公開された書き込みがほとんどありません。
[link] [comments]
