Reactive Optimizers: トレーニング中にオプティマイザのソースコードを書き換える

Reactive Optimizers

← Xingjian Bai

Xingjian Bai, Jia-Hao Liang, Jayden Teoh, Vincent Sitzmann
October 2026

TL;DR オプティマイザの中核にエージェントを配置します。エージェントはトレーニングの動向を監視し、それらに反応して、トレーニング中にオプティマイザのソースコードを書き換えます。タスクに対して調整済みのレシピがない場合、画像および言語タスク全体で、市販の最良のレシピに匹敵するか、それを上回ります。さらに、損失の急増を防ぎ、過学習から脱却するための洗練されたスケジュールと複雑な戦略を自発的に考案することを示します。OPALパッケージを使用して、独自のトレーニング実行で試してみてください。

X post: x.com/SimulatedAnneal/status/2112936831398375800

A static optimizer
step 0

A reactive optimizer
step 0

LightningDiT-XL/1 on ImageNet

今日、ディープニューラルネットワークを最適化するために使用されるレシピは、通常、トレーニングが始まる前に完全に決定されます。トレーニングがどのように進むべきかについては、人間の創意工夫が数多く注がれてきました。適応的なステップサイズ
[1]、事前条件付け
[2, 3]、直交化された更新
[4, 5]、トレーニングステップに紐づけられたスケジュール
[6, 7]、およびモデルサイズに合わせてスケーリングされた学習率
[8]。自動発見
[9, 10, 11, 12] は、より良いオプティマイザを求めて多くの実行で探索します。手作業で作成されたか、自動で発見されたかにかかわらず、オプティマイザはトレーニングの終了まで変更されずに実行され、もし適応するとしても、事前に書かれたルールに従います。この範囲では、以下の質問が未回答のまま残ります。予期せぬ損失の急増や停滞にオプティマイザはどのように応答すべきか？ 一つのモジュールの勾配が振動し始め、他のモジュールはスムーズに改善し続ける場合はどうなるか？ そして、新しいタイプのアーキテクチャがAdamやMuonでうまくトレーニングされない場合、アーキテクチャが劣っているのか、それともそれに適したオプティマイザに出会っていないだけなのか？

本稿では、従来のオプティマイザの範囲を拡大し、トレーニング自体に反応するようにして、単一のトレーニング実行内で常に適応するオプティマイザを実現しようと試みます。このリアクティブ・オプティマイザは、その場で推論し、各パラメータグループの重み更新ルールを書き込みます。最適化コードを直接書き込むことで、複雑なスケジュールを実装したり、トレーニングの事故に対応したり、存在している単一のトレーニングエピソードに合わせてオプティマイザをカスタマイズしたりする自由が得られます。トレーニング中にオプティマイザを適応させる初期の試み
[12, 13, 14] や、モデル自身がファインチューニングを指示できるようにする試み
[15] に基づいて、リアクティブ・オプティマイザは完全にゼロショットであり、繰り返し実行から学習したり保持したりするものはなく、オプティマイザのアルゴリズム全体を書き換えの対象とします。

画像生成と言語モデリングのタスクから実用的な状況から始めます。ここでは、リアクティブ・オプティマイザは静的なオプティマイザよりもはるかに優れたパフォーマンスを発揮できます。次に、リアクティブ・オプティマイザの創発的な特性、すなわち洗練されたスケジューリング、損失の急増の抑制、過学習からの脱却を探求します。最後に、そのコストはいくらで、大規模でどの程度実用的かという問いを投げかけます。リアクティブ・オプティマイザは、エージェントの世代ごとにさらに強力になり、新しいアーキテクチャや新しいデータセットに対してレシピが存在しない場合に最も有用であり、ディープラーニングの最適化のパズルを解決するための1ステップになると予想しています。

Contents

• 1. トレーニング without a recipe
• 2. Updating with spontaneous analysis
• 3. What is dynamically changing during optimization?
• 4. Real-world applicability
• 5. Conclusion

1. Training without a recipe

PhD学生が新しいアイデアを思いついたと仮定します。それは、彼自身のデザインのモデル、またはトレーニングする新しいデータセットです。彼にはGPUが1日しかなく、LLM APIトークンも控えめな割り当てしかなく、真剣なトレーニング実行は1回しかできません。学生はどうすべきでしょうか？ 明らかな行動は、最も標準的なトレーニングレシピ、または最近の論文からのレシピを選択し、それが自分のシナリオに適していない可能性、損失の急増/停滞などに対処することです。

根本的な問題はより広範です。GPU時間、研究者の時間、または壁時計時間に制限がある場合、最適な最適化レシピを事前に知ることなく、ディープラーニングモデルを最高のパフォーマンスにトレーニングするにはどうすればよいでしょうか？ 新しいアーキテクチャ、モダリティ、言語、科学データはすべてこの設定に該当し、多くの人が大規模なスイープを行う余裕はありません。

リアクティブ・オプティマイザは、その予算をさらに活用する方法を提供します。GPU時間/人間の時間ではなく、LLMトークンを消費します。オプティマイザがトレーニングのインシデントに反応して自身を調整することで、レシピ調整の負担の多くを軽減できます。

Results in brief

modded-nanogpt
[16] の最適化トラック（トラック3）から始めます。これは、この設定に特化して多くのレシピが調整された言語モデルの事前トレーニングタスク（162M GPTをFineWebでトレーニング）です。このタスクから、わずかに異なる2つの自然な設定を作成します。(1) 代替言語データセット（中国語、タイ語、キルギス語を選択）でトレーニングされた同じモデル、および (2) バッチサイズが4分の1の元の設定。どちらにも、その設定に合わせて調整されたレシピはありません。そのため、新しいトレーニングをワンショットで行いたい場合に自然に選択できるオプションである5つのリーダーボードレシピを自然な調整で採用した場合と比較します。これらの新しい設定すべてにおいて、リアクティブ・オプティマイザは最良のベースラインを上回るか、それに匹敵します（図1）。

また、350言語のデータセットを提案し、各データセットに小さなGPTを標準レシピでトレーニングするGoldfish
[17] にもリアクティブ・オプティマイザを直接適用します。これは、ワンショットでオプティマイザの適応性をテストするのに理想的な場所です。アムハラ語データセットでは、公式レシピは保持されたFLORES-200テキストで83.48ビット/文で終了します（低い方が良い）。この同じレシピで初期化されたリアクティブ・オプティマイザは、ワンショットで81.11で終了します（スワヒリ語でも同様のゲインが得られます）。標準レシピの学習率をスイープすると、リアクティブ・オプティマイザよりも先に80.89で終了する静的なレシピが見つかりますが、そのスイープされたレシピから初期化されたリアクティブ・オプティマイザは、80.73でさらに先に終了します。

また、文献では通常、最適化ハイパーパラメータをスイープしない画像生成にもリアクティブ・オプティマイザを試します。これは、拡散モデルの設計とオプティマイザの設計がほとんど直交すると見なされているためです
[1]。LightningDiT-XL/1
[18]（ガイダンスありでFID-50K 1.83対2.18、ガイダンスなしで4.33対5.15）およびRAEv2-B（3.19対3.39）で、公式レシピよりも先に終了します。後者はMuonのバリアントでトレーニングされます。

図1は、これらの実行を示しています。各実行はClaude Opus 5.5がエージェントを駆動しています。リアクティブ・オプティマイザをOPAL（OPtimizer with an Agent in the Loop）と名付けました。これらの結果を合わせると、ワンショット設定では、リアクティブ・オプティマイザが、事前に決定されたレシピに従うよりも優れたソリューションにつながる可能性があることを示しています。

modded-nanogpt Track 3

Goldfish, Amharic

LightningDiT-XL/1

RAEv2-B

Figure 1. OPAL（OPtimizer with an Agent in the Loop）、我々のリアクティブ・オプティマイザ、さまざまな設定で。最適化ハイパーパラメータがほとんど調整されていない設定の多くでは、リアクティブ・オプティマイザは、標準的な選択肢に対してトレーニング損失とテストパフォーマンスを改善します。modded-nanogptでは、#2はAdamW、#21はShampoo、#36は調整済みのMuon、#30と#46はより複雑なMuonベースのレシピです。

実用的なメリットを超えて、ゼロショットエージェントが独自のやり方でトレーニングの動向を分析・観察した後に下す自発的な決定に興味をそそられます。次の2つのセクションでは、リアクティブ・オプティマイザが何を監視し、それに応じて何を変更するかを探求します。

1 例として、DiTとSiT
[19] の標準レシピは、一定の学習率のAdamWでトレーニングされます。これは、Muonとそのバリアントが拡散トランスフォーマー
[20；Li et al.
[21]；RAEv2のGMuon
[22)] で採用され、拡散モデル
[23)] のオプティマイザの最近の制御されたベンチマークとともに変化し始めています。

2. Updating with spontaneous analysis

analysis.py
トレーニングの動向の自己記述プローブ
training run
agent
updater.py
次のステップのための適応型オプティマイザ

Figure 2. エージェントがトレーニング中に繰り返し書き換える2つのプログラム。コードを完全なインターフェースとして使用することで、エージェントに何を監視し、何を変更するかを選択する最大限の自由を与えます。

図2は、エージェントがオンザフライでオプティマイザコードを更新する方法を示しています。具体的には、オプティマイザの各ステップで使用されるファイル updater.py を書き換えることをエージェントに許可します。コードを完全なインターフェースとして使用するのは、エージェントが最適化のどの部分でも簡単に変更できるためです。しかし、エージェントが変更を加える前に、まずトレーニングがどのように進行しているかを独自に観察する必要があり、書き換え可能な2番目のプログラム analysis.py につながります。

エージェントが決定を下すためにどのような情報を使用すべきでしょうか？ 生のトレーニング状態は非現実的です。重み、活性化、勾配はエージェントのコンテキストを圧倒するでしょう。代わりに、トレーニングの動向の統計と幾何学は、各パラメータグループの勾配ノルム、変更する重みと比較した更新のサイズ、連続する勾配間のコサイン、異常に大きな勾配スパイクを示すテンソルなど、意思決定に役立つ可能性があります。したがって、オプティマイザと同様に、エージェントに最大限の自由を与えます。エージェントは、トレーニングの動向から知りたいものを何でも抽出するためにプログラム analysis.py を書き込みます。その自己記述プローブはトレーニング全体で実行され、エージェントが要求するものをトレーニングの状態から取得し、次の決定のためにエージェントに渡します。

双方向ループを完成させます。analysis.py を通じて、トレーニングはエージェントがそれをどのように見たいかという形でエージェントに到達し、updater.py を通じて、エージェントの決定はトレーニングの各ステップに到達します。これらの2つのプログラムにより、エージェントは最大限の柔軟性をもって、途中で新しい最適化アルゴリズムを考案できます。

3. What is dynamically changing during optimization?

このセクションでは、リアクティブ・オプティマイザがトレーニング中に何を行うかを見て、これらの結果の背後にある決定を調べます。要約として、図3は、各エージェントがいつ、どのように、なぜコードを編集したかを示しています。

赤いティックにドラッグして、エージェントがそこで何を変更し、なぜ変更したかを確認してください。

プログラムを変更したすべての決定

niche practice
block-specific
observation-originated
time-step-specific
fix or revert
analysis only

Figure 3. OPALのリアクティブな決定の概要。トレーニング全体を通じて、OPALは独自の監査信号を構築し、モジュール固有で、独自の観察によってトリガーされ、トレーニングの特定の期間に合わせてタイミングが取られた変更を行います。

このセクションの残りの部分では、これらの適応をタイプ別に調べます。

3.1 Learning-rate schedule

Designed by hand
DeepSeek-V3

• learning rate
• a new stage

論文のセクション4.2
[24] より。

Set by OPAL
SiT-B/2

• block matrices
• adaLN modulation
• timestep embedder
• patch and class embedders

Figure 4. DeepSeek-V3の学習率（手動設計、左）と、OPALが4回の実行で設定した学習率（各レシピのレートの倍数）。

最先端のトレーニング実行には、DeepSeek-V3の学習率の5段階のような複雑なハイパーパラメータスケジュールが付属しています
[24；図4、左]。このようなスケジュールは、トレーニングプロセス中に人間によって書かれることもあります
[25]。エンジニアは限られた数の決定しか下せず、それぞれが限られた数の信号を評価します。リアクティブ・オプティマイザは、この作業を引き継ぐことができ、そのような制限はありません。頻繁に決定を下し、各決定で実行履歴全体にアクセスできます。図4
[[https://xingjianbai.com/reactive-optimizers/#fig-lrmulti]] が示すように、エージェントが構築したスケジュールは複雑で、各パラメータグループに個別の多段階スケジュールがあり、実行ごとに異なります。それらのいくつかは、実行中に学習率を上げるという、現代のスケジューラでは珍しい動きですが、多くのシナリオで自然に役立ちます
[6, 26]。さらに、以下の4つの例 は、決定の根拠として引用された証拠を示しています。

エージェントはこれらの決定を analysis.py からの診断に基づいて行います。例としては、モジュールの連続する勾配間のコサインをオーバーシュートの兆候として使用（「手がかりから推測」 を参照）；数百更新ごとに2つの学習率間でA/Bテストを行い、それぞれの下での損失の低下速度を比較（「A-B-Aテスト」）；学習率を上げ、下げ、再び上げるという試行錯誤（「試行錯誤」）；および損失の傾向により、エージェントが計画よりも早くクールダウンを開始する（「再計画されたクールダウン」）。これらのスケジュールの変更はそれぞれ、トレーニングの動向の観察と、その観察に基づいた推論を含みます。

エージェントが学習率を設定する方法：4つの例

Deduced from clues
SiTエージェントの分析プログラムは、各パラメータグループの連続する勾配間のコサインを測定しました。負の場合、エージェントは学習率を下げました。タイムステップエンベッダーの学習率は0.3倍から0.15倍になり、その理由はこのように述べられています。

Step 7,506, Decision 6Timestep-embedder learning rate goes from 0.3× to 0.15× (1.5e-5) after update 7506, because its cosine is still around −0.22.

コサインがわずかに正のままであったMuon行列の場合、学習率を上げました。

A-B-A test
RAEv2エージェントは、数百更新の連続する区間で2つの学習率を交互に（A-B-A）使用し、それぞれの下でのトレーニング損失を比較しました。このようなテストの後、更新3,100から2倍に切り替えました。その理由は次のように述べられています。

Update 3,000, Decision 12The A-B-A test points the other way from my provisional read at update 2750: 2× gives faster real progress than 1.5×.

Trial and error
同じエージェントが各グループの学習率を1.3倍に設定し、バックボーンの勾配がステップごとに符号を変え始めたときにバックボーンの学習率を1倍に戻し、次の決定で各グループの学習率を1.5倍に上げました。

Update 1,000, Decision 4My explanation from last time was wrong, so I'm raising the learning rate in every group to 1.5× (3e-4).

その後、学習率は2倍、2.5倍、2.75倍と約650更新ごとに実行され、2倍を維持しました。以下は、公式レートの倍数としてのバックボーン注意行列の学習率です。2つの深い低下は、テストとして使用された学習率の75更新削減です。

1×2×1.5×2.5×2.75×1001Kupdate 25,0201.5×2.5×2.75×0update 25,020

Re-planned cooldown
ステップ190Kで、SiTエージェントは計画されたクールダウンを320Kから280Kに移動し、学習率のフロアをピークの0.1から0.05に下げました（図4のSiTパネルの曲がり）。その理由は次のように述べられています。

Step 190,152, Decision 53the constant-rate phase is now mostly holding the weights at a noise floor set by the learning rate, rather than making progress.

RAEv2エージェントは、計画された75%ではなく、実行の45%である更新11,250でクールダウンを開始し、損失の傾向と学習率の減衰に関する論文
[27] を引用しました。

3.2 Optimizer design

AdamW
Muon
partial Muon
bfloat16 moments
float32 moments

Language modeling

Image generation

Goldfish Amharic 64,626 updates

48 matrices → Muon at 2,300

LightningDiT-XL/1 80,000 updates

112 matrices → Muon at 801+28 adaLN at 4,001, +2 at 6,401 (all 142)

modded-nanogpt Track 3 3,250 updates

embedding → float32 at 1,040

RAEv2-B 25,020 updates

2 input convs → Muon at 6,501
back to AdamW at 7,001

Figure 5. 4つのOPAL実行におけるオプティマイザタイプと精度の変更。一部の実行では、重みは標準的なMuonに単純に移動されますが、他の実行では、OPALはモジュールタイプごとに段階的に移動し、非常に小さな部分の重みに高精度を選択し、観察された信号を引用します。

リアクティブ・オプティマイザは、どのルールがどのテンソルを更新するかを変更します。実験では、多くが最初に与えられたAdamWから、アテンションおよびMLP行列についてはよく知られたハイブリッドであるMuonに切り替えますが、残りはAdamWのままです。その後、より具体的な変更を加えます（図5）。

オプティマイザは、精度の重要性がどこにあるかを決定することもできます。modded-nanogptトラック3では、トークン埋め込みのエントリが約15のサイズであり、隣接するbfloat16値が0.0625離れているため、学習率が減衰するにつれて、丸めによって各更新の大部分が失われることを測定しました。更新1,040から、その特定の行列のAdamモーメントをfloat32に保ち、丸め補正付きで重みを書き戻し、他のすべてのテンソルはそのままにしました。

3.3 Momentum

［図: Figure 6. Tilted double-well potential のバリアント、我々がオプティマイザをテストする34のランドスケープの1つ。破線はスライダーで選択された静的な設定、青線はリアクティブ・オプティマイザの動作です。リアクティブ・オプティマイザは、緩やかな傾斜に沿ってモーメンタムを上げ、勾配が低下するとそれを下げ、オーバーシュートするとクリアし、一般的なオプティマイザがデフォルト設定で停滞する場所で最適値に到達します。］

2Dのトイランドスケープでリアクティブ・オプティマイザがモーメンタムを操作する能力を調査します。ここでは、エージェントに新しい機能を与えます。モーメンタムのリセット、これまでの最良点への復帰、ランダムな近傍点へのジャンプです。これらのトイ設定では、標準的なOPALは数回の決定でデフォルトレシピを2次メソッドに置き換えるだけで、非常に速く完璧なパフォーマンスに到達します。そのため、OPALをヘビーボールアルゴリズムに制限し、ハイパーパラメータを制御できるようにしました。図6のランドスケープでは、開始点は、一般的なオプティマイザが停滞するほぼ平坦なサドルに隣接しています。リアクティブ・オプティマイザは、平坦なストレッチを横断するためにモーメンタムを上げ、最小値の近くで勾配が低下するとそれを下げ、オーバーシュートするたびに最良点に戻ってモーメンタムを再開し、300ステップの予算の終わりに最小値に到達します。実行した34のランドスケープすべてで、平均スコア-11.6（log10(f − f
*), 低い方が良い）を達成します。一方、単一の静的設定はすべてパフォーマンスが悪くなります。12の一般的なレシピの最良値で-2.2、382,080のスイープされたレシピの最良値で-7.4です（図6）。

3.4 Loss spikes

delta test accuracy before and after each corruption

1
2
3
4

OPAL
−50.0
−66.3
−12.1
+0.7

Muon+clip
−74.4
−73.6
−75.5
−28.5

Muon
−73.6
−77.7
−69.1
−37.2

AdamW+clip
−62.7
−60.0
−38.1
−42.0

AdamW
−61.4
−32.4
−53.8
−68.5

Stable-SPAM
−54.0
−66.3
−69.8
−70.7

OPAL
Muon+clip
Stable-SPAM
loss damping
clipping
batch gate

Figure 7. CIFAR-10でのResNet-18、4つのストレッチのランダムな画像とラベル（シェーディングあり）。左：テスト損失；マーカーにホバーして、OPALがガードを変更した理由を読み取ります。右：各ストレッチでのテスト精度の変化。リアクティブエージェントは、数回見た後、データ破損によって誘発される設計されたタイプの損失スパイクから防御できます。

大規模なトレーニングでは、OPALはモジュール固有のクリッピングで勾配スパイクのダメージも制限します。別のSiTエージェントは、ログに記録された18の勾配スパイクのうち17がタイムステップエンベッダーに起因することを追跡し、各テンソルにクリッピング閾値を追加しました。これは、そのテンソル自身の最近の勾配ノルムから設定されるため、エンベッダーのスパイクは他のすべてのテンソルの更新をカットしなくなります。その古いグローバル閾値はバックストップとしてのみ残ります。どちらの動きも標準的なプラクティスではありませんが、どちらも前例があります。各テンソルを独自の履歴に対してクリッピングする
[28]、およびGLM-130Bが行ったように、スパイクする単一レイヤーを減衰させる
[29]。

スパイクは、特定のバッチとモデル状態の相互作用を通じて、データからも発生する可能性があります
[30]。クリッピングは一般的にノイズのあるラベル
[31] に対して保護しません。制御された実験では、CIFAR-10に4つのランダムな画像とラベルのストレッチを挿入し、OPAL（破損について知らされていない）と静的なオプティマイザでResNet-18をトレーニングします（図7）。最初の2つのストレッチは、OPALにテスト精度の50および66ポイントのコストをかけ、ベースラインと同程度です。その間に、損失減衰を追加し、クリッピングに置き換え、その後、損失が最近のクリーンなバッチよりもはるかに高いバッチを保持するゲートを記述しました。そのゲートを調整した後、3番目のストレッチは12ポイント、4番目は0ポイントのコストで済みましたが、クリップされたベースラインとStable-SPAM
[32] は、各ストレッチで依然として28から76ポイントを失いました。

3.5 Overfitting

Test loss on CIFAR-10 with 10% mislabeled training images

OPAL
AdamW, the recipe it started from
early stopping
optimizer change

Setting

A ResNet-18 trained on CIFAR-10 for 120 epochs without data augmentation. Among the 50,000 training images, 10% are held out with their correct labels as a development set; among the rest, 10% get a wrong label, drawn uniformly from the wrong classes and fixed for the run. The agent saw training statistics, along with dev loss and dev accuracy; it was not told about the specific setting (that some labels were wrong), and it never saw the test performance. We make the network normalize its logits (a centered form of LogitNorm,
[33]) to prevent loss-hacking behavior. AdamW runs from learning rate 3e-3, which is also the starting recipe for the reactive optimizer.

Figure 8. 45,000枚のCIFAR-10画像で120エポックトレーニングされたResNet-18、10%に誤ったラベルが付いています。エポック24と28のティックにホバー：開発損失が上昇し、エージェントが反応します。OPALは、徐々に高くなる学習率と、開発セット上の重み平均で過学習に対抗します。

誤ったラベルのデータでトレーニングすることは、過学習をテストするための標準的な方法です
[34]。そのような設定を設計し（図8の下に詳細)）、オプティマイザがトレーニングセットと開発セットからのシグナルに反応して、過学習を自分で克服できるかどうかを尋ねます。そのままトレーニングされたAdamWベースラインは、テスト損失2.49、精度73.5%で終了します（開発セットで早期停止した場合、1.01および72.9%；重み平均を使用し、そこで選択された平均を使用した場合、0.83および77.5%）。リアクティブ・オプティマイザは、損失0.69、精度78.6%で終了します。記憶の直接的な尺度として、4,500枚の誤ってラベル付けされたトレーニング画像を分類するように求められた場合、ベースラインはトレーニングされた誤ったラベルをすべて与えます。早期停止バージョンは19%、重み平均バージョンは14%です。一方、リアクティブ・オプティマイザは、そのラベルをわずか4%しか与えず、真のラベルを78%与えます。その戦略は、徐々に高くなる学習率と重み平均を組み合わせ、開発セットで最終平均を選択します。これは、独自の分析プログラムによって「拡張SWA」
[35] と呼ばれます。図8 のティックにカーソルをホバーすると、その正確な決定を確認できます。

Summary of analysis

上記では、リアクティブ・オプティマイザが、従来のオプティマイザには見られない特性である、データセット、個々のモジュール、および各実行の動作に適応できるレシピを持つことを示しました。このようなカスタマイズと自己適応性により、洗練されたスケジュールを作成し、複雑なトレーニングランドスケープをナビゲートできます。

それでも、ハイパーパラメータの調整、損失スパイクの抑制、過学習の監視は、人間の専門家ができることですが、それほど便利ではなく、コストも高くなります。エージェントがより賢くなり、何百もの論文を記憶し、数千トークンの思考連鎖を持ち、数百万のトレーニングシグナルをコンテキストに持ち、すべてのステップを手にしていると、リアクティブ・オプティマイザはさらに改善され、ここで実証されたものよりもさらに難解なメカニズムをトレーニング中に開発し、人間の専門家が手作業で調整できる範囲を超えるものになると確信しています。このようなメカニズムには、損失ランドスケープの二次曲率の追跡、各データバッチの信号の分散の監査、またはこれまで見たことのない最適化スキームの実装などが含まれる可能性があります。

4. Real-world applicability

リアクティブ・オプティマイザは実用的か？ 最初の懸念は、推論の決定を待つ時間です。最も単純な設計では、トレーニングはエージェントが推論する間停止し、かなりのオーバーヘッドが発生します。OPAL実装では、エージェントが思考している間トレーニングを続行することを許可するオプションを提供し、後でエージェントの編集を適用します（例：Goldfishでは中央値で65更新後）。ほとんどのオプティマイザの決定はそれほど時間的制約がないため、パフォーマンスへの影響はほとんどないはずです。このオプションを使用すると、図9 の実行は、静的な実行にわずかな時間しか追加しません（1.01倍から1.14倍）。より大規模では、現在の実装は、シャーディングトレーニングとオプティマイザコンパイルをサポートするためにまだ作業が必要であり、これらの実用的な懸念は後続の作業に委ねます。

no agent
training does not wait for the agent
waiting for the agent

wall-clock time relative to no agent ↓

1×
1.01×
1.01
1.30×
Goldfish Amharic
1 H100
Goldfish
Amharic
1 H100

1×
1.11×
1.11
4.39×
modded-nanogpt Track 3
8 H100s
modded-nanogpt
Track 3
8 H100s

1×
1.14×
1.14
1.30×
LightningDiT-XL/1
8 H100s
LightningDiTXL/1
8 H100s

Figure 9. エージェントなしでトレーニングされた同じタスクに対する壁時計時間の相対値。各決定でエージェントを待つトレーニングは、はるかに時間がかかります（1.30倍から4.39倍）。一方、待たないトレーニングは、静的な実行にわずかな時間しか追加しません（1.01倍から1.14倍）。残りのオーバーヘッドは、エージェントが記述したものを実行するコストです。これは、レシピの（Muonの直交化やテンソルをfloat32に保つなど）よりもステップあたりのコストが高く、分析プログラムの測定コストです。

APIトークンとGPU時間を比較すると、リアクティブ・オプティマイザの推論コストは、トレーニングコンピューティングと比較してわずかです。単一のトレーニング実行で約100回の決定を行う場合、LightningDiTエージェントのコストは、Claude Opus 5.5の定価で6.42ドルで、約74 H100時間（AWSの現在のオンデマンド価格で約510ドル）のトレーニングに追加されます。より大規模なトレーニングでこれを装備しても、相対コストはさらに小さくなります。確かに、FLOP数で数えると、フロンティアエージェントのサイズを考えると、どのようなリアクティブ・オプティマイザでも非現実的でしょう。ここでは、ほとんどの研究者にとって、GPU時間とクローズドソースモデルへのトークンアクセスは異なる商品であり、フロンティアが進歩し続けるにつれて、特定の機能の価格は下がり続けることを指摘するだけで十分です。

もう1つの制限は、リアクティブ・オプティマイザが観察して反応するための余地を必要とすることです。実行が短い場合やレシピが微調整されている場合、そのゲインは減少します。modded-nanogptトラックはそのような設定です。このタスクに多くの人々がほぼ正確に調整したレシピの3,250更新です。そこでのゲインは、試した他のタスクよりも小さく、それらのタスクは約8倍から120倍長くトレーニングされます。さらに、リアクティブな動作は不確実性の別のソースを導入し、トレーニングを再現しにくくする可能性があります。本稿のほとんどの実験は1回実行され、数件は3回実行されます。リリースされたパッケージでの再実行は、OPALリポジトリにあります。

ファインチューニングプラットフォームは、トレーニングをすべての人に提供しています。Tinker
[36] とPrime IntellectのHosted Training
[37] は、ユーザーが背後にあるGPUを管理することなく、独自のアプリケーションのためにオープンウェイトモデルをファインチューニングできるようにします。しかし、これらのプラットフォームでは、優れたトレーニングレシピの精神的な負担は依然として人々にのしかかります。リアクティブ・オプティマイザは、これらのプラットフォームの上に自然に適合し、その負担をエージェントにオフロードし、各ユーザーがモデルを独自のニーズに合わせてパーソナライズするのを支援します。

5. Conclusion

これまでは、オプティマイザはトレーニング前に書かれていました。エージェントは、長いコンテキストウィンドウと専門知識を持つ安価な推論形式として、新しい可能性を生み出します。それは、ネットワークがトレーニング中に最適化イベントに反応して決定を下し続けるオプティマイザです。リアクティブ・オプティマイザがトレーニングの動向を監視し、トレーニングが展開するにつれて、パラメータの異なるグループに対して、適切なステップで、自身のコードを書き換えることを実証しました。トイおよびスケールアップされた実験では、これらの実行のほとんどは、開始したレシピよりも先に終了しました。

設計した分析および更新メカニズムは、可能な限りシンプルかつ汎用的であることを意図しています。標準的なオプティマイザをラップするもので、モデル、データ、またはトレーニングの動向について何も仮定しません。レシピが存在しない場所では、今日でも役立ちます。例えば、生物学または他の科学データセット上のモデル、レシピが書かれていないアーキテクチャ、またはレシピが調整されていない言語は、すべてそのようなリアクティブ・オプティマイザの優れたユースケースです。これは、オプティマイザのエージェントが、人間の専門家が何百回ものトレーニングステップで、専門家が座って同様の決定を下す時間を持てなかった場所で、イベントに反応して同様の決定を下す役割を果たすためです。このように見ると、リアクティブ・オプティマイザは構築するのが自然なものであり、静的なものに対するそのゲインは予想されるべきです。さらに、トレーニング実行は、人間が使用できるよりもはるかに多くの情報を含んでいますが、そのほとんどは今日無視されています。リアクティブ・オプティマイザは、このすべての情報にアクセスできます。単一のモノリシックなオプティマイザという概念がなくなった世界を想像してみてください。それに取って代わるのは、各特定の実行に適応する最適化インテリジェンスであり、それは勾配ベースではなく、ゼロオーダー
[38]、言語ベース、またはそれ以上のものである可能性があります。おそらく、将来的には、最適化の決定を人間ではなくエージェントに委任すべきでしょう。

過去10年間で、ディープラーニングモデルはトレーニングを通じて不当に効果的なパワーを獲得してきました。しかし、その作成のまさに中心であるオプティマイザは、依然として機械的です。本稿は、トレーニングが私たちに与えてくれた魔法をトレーニング自体の中心に吹き込み、将来さらに多くの能力を生み出すループを形成しようとする試みです。

Code repository

pip install opal-optimizer

import torch
import opal

opt = torch.optim.AdamW(model.parameters(), lr=3e-4)
sched = torch.optim.lr_scheduler.CosineAnnealingLR(opt, T_max=steps)
opt = opal.wrap(opt, model, scheduler=sched, total_steps=steps,
                goal="...", max_cost_usd=20)

for step in range(steps):
    loss = criterion(model(x), y)
    loss.backward()
    opt.step(loss=loss)
    opt.zero_grad()
    sched.step()

Acknowledgements

We sincerely thank George Cazenavette, David Charatan, Shivam Duggal, Jyo Pari and Qianwei Jia for their invaluable advice on this write-up; thank Zhenting Qi and Zeqing Yuan for their discussion. We are also grateful to Professor Phillip Isola and the Isola lab for their insightful feedback on an earlier version of this post.

Citation

@misc{bai2026reactive,
  title  = {Reactive Optimizers},
  author = {Bai, Xingjian and Liang, Jia-Hao and Teoh, Jayden and Sitzmann, Vincent},
  year   = {2026},
  month  = {oct},
  url    = {https://xingjianbai.com/reactive-optimizers/},
  note   = {Blog post}
}

References

1. Kingma and Ba. Adam: A Method for Stochastic Optimization. ICLR 2015. arXiv:1412.6980.
2. Gupta, Koren and Singer. Shampoo: Preconditioned Stochastic Tensor Optimization. ICML 2018. arXiv:1802.09568.
3. Vyas et al. SOAP: Improving and Stabilizing Shampoo using Adam. arXiv:2409.11321, 2024.
4. Jordan et al. Muon: An optimizer for hidden layers in neural networks. Blog post, 2024.
5. Liu et al. Muon is Scalable for LLM Training. arXiv:2502.16982, 2025.
6. Loshchilov and Hutter. SGDR: Stochastic Gradient Descent with Warm Restarts. ICLR 2017. arXiv:1608.03983.
7. Hägele et al. Scaling Laws and Compute-Optimal Training Beyond Fixed Training Durations. NeurIPS 2024. arXiv:2405.18392.
8. Yang et al. Tensor Programs V: Tuning Large Neural Networks via Zero-Shot Hyperparameter Transfer. arXiv:2203.03466, 2022.
9. Lu et al. The AI Scientist: Towards Fully Automated Open-Ended Scientific Discovery. arXiv:2408.06292, 2024.
10. Prime Intellect. Autonomous Speedrunning Experiment. GitHub, 2026.
11. Chen et al. Symbolic Discovery of Optimization Algorithms. arXiv:2302.06675, 2023.
12. Metz et al. VeLO: Training Versatile Learned Optimizers by Scaling Up. arXiv:2211.09760, 2022.
13. Daniel, Taylor and Nowozin. Learning Step Size Controllers for Robust Neural Network Training. AAAI 2016. doi:10.1609/aaai.v30i1.10187.
14. Jaderberg et al. Population Based Training of Neural Networks. arXiv:1711.09846, 2017.
15. Zweiger, Pari, Guo, Akyürek, Kim and Agrawal. Self-Adapting Language Models. arXiv:2506.10943, 2025.
16. Jordan. Modded-NanoGPT Optimization Benchmark. GitHub, 2026.
17. Chang et al. Goldfish: Monolingual Language Models for 350 Languages. LREC 2026. arXiv:2408.10441.
18. Yao, Yang and Wang. Reconstruction vs. Generation: Taming Optimization Dilemma in Latent Diffusion Models. arXiv:2501.01423, 2025.
19. Ma et al. SiT: Exploring Flow and Diffusion-based Generative Models with Scalable Interpolant Transformers. arXiv:2401.08740, 2024.
20. Chen, Sun and Yuan. CMuon: Accelerating and Stabilizing Diffusion Transformer Training via Chunked Momentum Orthogonalization. ECCV 2026. arXiv:2608.02502.
21. Li et al. Scaling Muon for Diffusion Transformers. arXiv:2608.20818, 2026.
22. Singh, Zheng, Wu, Zhang, Shechtman and Xie. Improved Baselines with Representation Autoencoders. arXiv:2605.18324, 2026.
23. Bolatov et al. Optimizers for Diffusion Models: A Controlled Benchmark. arXiv:2609.23055, 2026.
24. DeepSeek-AI. DeepSeek-V3 Technical Report. arXiv:2412.19437, 2024.
25. Zhang et al. OPT: Open Pre-trained Transformer Language Models. arXiv:2205.01068, 2022.
26. Smith. Cyclical Learning Rates for Training Neural Networks. WACV 2017. arXiv:1506.01186.
27. Bergsma, Dey, Gosal, Gray, Soboleva and Hestness. Straight to Zero: Why Linearly Decaying the Learning Rate to Zero Works Best for LLMs. ICLR 2025. arXiv:2502.15938.
28. Wang et al. AdaGC: Enhancing LLM Pretraining Stability via Adaptive Gradient Clipping. ICML 2026. arXiv:2502.11034.
29. Zeng et al. GLM-130B: An Open Bilingual Pre-trained Model. arXiv:2210.02414, 2022.
30. Chowdhery et al. PaLM: Scaling Language Modeling with Pathways. arXiv:2204.02311, 2022.
31. Menon, Rawat, Reddi and Kumar. Can Gradient Clipping Mitigate Label Noise? ICLR 2020. OpenReview, 2020.
32. Huang et al. Stable-SPAM: How to Train in 4-Bit More Stably than 16-Bit Adam. arXiv:2502.17055v2, 2025.
33. Wei, Xie, Cheng, Feng, An and Li. Mitigating Neural Network Overconfidence with Logit Normalization. ICML 2022. arXiv:2205.09310.
34. Nakkiran, Kaplun, Bansal, Yang, Barak and Sutskever. Deep Double Descent: Where Bigger Models and More Data Hurt. ICLR 2020. arXiv:1912.02292.
35. Izmailov, Podoprikhin, Garipov, Vetrov and Wilson. Averaging Weights Leads to Wider Optima and Better Generalization. UAI 2018. arXiv:1803.05407.
36. Thinking Machines Lab. Announcing Tinker. Blog post, 2025.
37. Prime Intellect. Getting Started (Hosted Training). Documentation, accessed October 21, 2026.
38. Dahal, Mandal, Gülbahar and Vegesna. Dust: Pretraining Transformers Without Backpropagation. Q Labs, 2026.

← Back to the homepage

---