Gensyn open‑1b、80,957の訓練ステップにわたるハードウェア横断のビット単位監査チェーンを構築

GensynがApache 2.0ライセンスで公開したopen‑1bの主眼は、大規模モデルのベンチマーク順位を追うことではなく、「再現可能なレシピ」を抜き取り検査可能な訓練記録へと発展させることにある。モデルは合計16.1億パラメータを持ち、そのうち10.8億がembedding以外のパラメータだ。ベースモデルは48基のH100上で4,000億tokenを使い、80,957ステップにわたって訓練された。このほか、930億tokenで継続事前訓練したバージョンとSFTモデルもある。公式には、100ステップごとの完全なチェックポイント、コーパスのシャード、設定、評価コード、ステップごとの状態ハッシュも提供されている。

中核を成すのはRepOpsと固定データフローだ。行列乗算、正規化、勾配リダクション、乱数生成はいずれも固定された演算順序を採用し、データウィンドウもworld sizeやrankによって変化しない。各ステップでは、直前のステップのハッシュ、データバッチのダイジェスト、重み、勾配、optimizerの状態を連結して新たなダイジェストを生成する。監査者はCPU、CUDA、Apple Silicon上で指定したステップをリプレイし、同一のビット列が得られるかを照合できる。これは重みと訓練recipeを公開するだけの場合と異なり、「そのrecipeから実際にこの重みへ到達できるか」を検証する経路を追加するものだ。データ汚染の追跡、モデルのサプライチェーン証明、監督対象モデルのprovenanceガバナンスなどの研究に適している。

代償は明確だ。公式によると、再現可能なruntimeのModel FLOPs Utilization（MFU）は約5%で、同一のハードウェアとrecipeを使用した場合、最適化済みPyTorchより約5倍遅い。事前訓練全体には27.8 compute-daysを要した。モデル性能そのものも売りではない。中期訓練後のOLMo 2評価スイートにおける平均スコアは26.8で、OLMo 2 1Bの43.7を下回った。さらに重要なのは、1回のリプレイが一致しても、指定された入力とプログラムから期待されるダイジェストが生成されたことしか証明できず、過去にクラスターが実際にそのとおり稼働していたことを、それ単独では証明できない点だ。RepOpsのソースコードはまだ公開されておらず、訓練lossのログも意図的に非公開とされている。今後は、独立監査のカバレッジ、異なるGPU世代間でのリプレイ結果、そして固定リダクションのコストをより大規模なモデルやtensor parallelismにまで拡張できるかに注目すべきだ。