唐傑さんが語るGLM-5.3のスケーリング則、パラメータ数はもう主役じゃない

コードを読まないAIエンジニア
サムネイル

ベンチマーク表を開いたとき、いちばん先にパラメータ数の列を探していないでしょうか。

743Bと320Bが並んでいたら、なんとなく前者のほうが強いはずだと思って残りを読み始める。

その読み方に、GLM-5.3を作っている側が正面から待ったをかけました。

パラメータ数が多いほど強い、という読み方に作った側が待ったをかけた

唐傑(タン・ジエ)さんは清華大学でコンピュータサイエンスの教授を務めながら、2019年に大学発のスピンアウトとしてZ.aiを立ち上げた人です。

GLM-130Bの頃からGLMシリーズの開発に携わってきた、つまり今回のGLM-5.3を出している当事者にあたります。

その人が打ち出しているのが、パラメータ数という数字は単独では何も語らない、という整理でした。

データをどれだけ食わせたか、計算資源をどこに積んだか、どんな条件で動かすのか。

この3つと組み合わせて初めて、パラメータ数は意味のある数字になる。

さらにMoEのスパース性を加えた5本のつまみを、スケーリング則を読むときはまとめて見るべきだ、という枠組みで語られています。

面白いのは、これを言っているのが外野の批評家ではないところです。

パラメータ数の大きさで注目を集められる立場の人が、その指標を自分から降ろしにいっている。

GLM-5.3はベースを743Bのまま変えていない

主張の裏付けは、同じ会社が出したモデルそのものにあります。

GLM-5.3はGLM-5.2と同じ743Bのベースモデルで動いていて、アーキテクチャの変更も事前学習のやり直しも入っていません。

伸びはすべて、ベースを作った後にかける後段の学習をスケールさせた分です。

数字で見るとこうなります。

Terminal Bench 3.0が4.6%から28.3%、AutomationBenchが26.2%から48.2%、GDPval-AA v2のEloが1,508から1,769。

パラメータ数の列だけを追いかけていたら、この世代では何も起きていないという結論になります。

実際には、同じ器の中身をどう詰め直すかだけで一段上がっていた。

70Bのモデルが280Bのモデルに勝った実験は、2022年に出ている

この論点、スケーリング則の研究としてはかなり前に一度決着がついています。

2022年3月に出たTraining Compute-Optimal Large Language Modelsという論文で、DeepMindのチームがChinchillaという70Bのモデルを作りました。

比較相手は、同じ計算予算で訓練された280BのGopherです。

パラメータ数を4分の1に落とす代わりに、学習データを4倍食わせた。

結果は70Bの側の圧勝で、Gopherだけでなく175BのGPT-3にも、530BのMegatron-Turing NLGにも勝っています。

論文が出した結論は「モデルサイズを2倍にするなら、学習トークンも2倍にすべき」というものでした。

パラメータ数は器の大きさでしかなくて、中身が入っていなければ空のまま大きいだけ。

4年前に示されたこの結果が、いま同じ形でもう一度出てきています。

つまみは何本あるのか、私なりに整理してみる

5本のつまみを、GLM-5.3系で実際に何が起きたかと並べるとこうなります。

つまみ
何が決まるか
GLM-5.3系で見えること
パラメータ数
器の大きさ
743Bで据え置き
データ量
器をどこまで埋められるか
事前学習はやり直していない
計算資源の配分
事前学習と後段学習のどちらに積むか
後段に寄せた
スパース性
1トークンで実際に動く割合
Flashは320B中18Bだけ動く
実行時の条件
同じ重みでも変わる速度と文脈長
Flashは最初の1トークンが1.47秒

いちばん誤解を生みやすいのがスパース性のところです。

GLM-5.3-Flashは総パラメータが320Bありますが、1トークンを処理するときに実際に動くのは18Bだけ。

MoEは全部の重みを常時使う作りではないので、表に載っている320Bという数字と、推論で走る計算量は別物になります。

だから最近のモデル名は、総パラメータと活性パラメータを併記する書き方が増えてきました。

数字を1つに丸めると必ず嘘になる、というのを名前のレベルで認めたのがこの書き方だと思っています。

それでもパラメータ数だけがひとり歩きしてきた理由

理由ははっきりしていて、ソートできる数字がそれしかないからです。

学習データの量も、後段学習のレシピも、計算資源をどう割り振ったかも、企業はまず公表しません。

一方でパラメータ数だけはモデル名に書いてある。

唯一公開されている数字が、いつのまにか唯一の指標として扱われるようになった。

比較する側にとっても、これは都合がよかったはずです。

表を作るときに全モデルで必ず埋まる列がそこしかない。

読む側も一目で大小がわかるので、そこから読み始める癖がつく。

つまみが5本あるという話は、裏返せば残り4本が見えないまま比較されてきた、ということでもあります。

次にベンチマーク表を見るとき、パラメータ数の隣に何を探すか

実務の判断材料として、私が見ている順番はこうです。

1: 活性パラメータ。

総パラメータしか書いていないMoEモデルは、推論コストの見積もりが立たないと思っておく

2: ベンチマークのバージョン。

Terminal Bench 3.0と2.1のスコアを並べても意味がないように、物差しが変われば数字は化ける

3: 実行時の条件。

最初の1トークンまでの時間と扱える文脈長は、同じ重みでも提供元によって変わる

この3つを埋めてからパラメータ数を見ると、順位の見え方がかなり変わります。

GLM-5.3が743Bのまま一段上がったという事実は、その典型でした。

器はもう十分に大きくて、勝負はどう詰めるかに移っている。

次に「◯◯Bの新モデル」という見出しを見たら、Bの数字ではなく、その隣に何が書かれていないかを先に探してみてください。