[P] Grokの更新にクリップ：Weight Norm Clippingを39〜249×に | 6つのタスク（mod演算、混合オペレーション、S5パーミュテーション） | タスクごとの max_norm の測定値

最大ノルムのアブレーションによる、mul mod -97 でのシード0結果（混合加算・減算・乗算・除算モード p97、および S5 パーミュテーション）

以前の投稿の更新です。私たちは独立した2名の研究者です。

前回の投稿から、モジュラー乗算を6つの代数タスクへ拡張しました：

• 4つのモジュラー算術演算（加算・減算・乗算・除算 mod 97）
• 4つすべて（加算・減算・乗算・除算）をall-modとして単一データセットに混ぜた混合タスク
• S5 パーミュテーションの合成（非可換、120要素）。

手法（変更なし）： オプティマイザの各ステップ後に、デコーダ重みに対して行ごとのℓ₂クリッピングを行います。重み減衰なし、追加のメモリなし。実装： norms.py

95% の検証精度に到達するまでの中央値（Lion+Clip、タスクごとに各値につき n=100 シード、各タスクでの最適 max_norm）：

Task	Median [95% CI]	AdamW baseline	Seed 0 speedup	max_norm
mul mod 97	550 [530–560]	35,040	66×	2.0
add mod 97	570 [555–590]	40,240	69×	1.75
sub mod 97	775 [740–870]	57,670	87×	1.5
div mod 97	730 [700–790]	71,160	39×	1.75
all-mod (mixed)	3,090 [2880–3300]	86,400	50×	1.75
S5 permutation	1,348 [1252–1424]	390,896	249×	1.0

S5 の結果は私たちを驚かせました。ベースラインは 390,896 ステップかかります。Lion+Clip の中央値は 1,348 です。非可換な構造のために、より狭いクリッピング半径が必要になりました—S5 は max_norm=1.0 で鋭く最適であり、1.25 を超えると急速に悪化します。一方、モジュラー乗算は 2.0 に満足しています。

最も興味深い発見は：max_norm は代数的な複雑さと相関することです。逆数に依存する操作（div, sub）は 1.5–1.75 を好みます。直接的な操作（mul, add）は最大 2.0 まで許容します。混合タスクや非可換タスクは、よりタイトに引き寄せます。右下のパネルは、この3種類すべてのタスクタイプにわたってそれを示しており、各値につき n=100 シードです。

合計の実験回数：

Adam	Lion	SignSGD	Total
Runs	2,126	7,137	2,125
Unique Seeds	821	2,521	822

ベースラインを含む

正直な範囲： すべての実験は代数タスク（モジュラー算術とパーミュテーショングループ）です。結果が他の領域へそのまま移る可能性はありません—私たちはそのような主張はしていません。

コード + PDF：
https://github.com/NiftyliuS/cliptogrok
https://github.com/NiftyliuS/cliptogrok/blob/main/cliptogrok.pdf

fast-weight-attention において、lucidrains が実装も提供しています。

私たちはまだ arXiv の認定（cs.LG）を求めています—可能なら DM してください。