Parameter Golfとは？OpenAIの16MB LLMコンペのルールと最終結果1.0565・上位手法

Parameter Golf（正式名「OpenAI Model Craft Challenge: Parameter Golf」）は、重みと学習コードを合わせて16MB以内に収めた言語モデルを8基のH100で10分以内に学習させ、FineWeb検証データの圧縮性能（BPB）を競ったOpenAIの公開コンペです。会期は2026年3月18日〜4月30日で、すでに終了しています。最終リーダーボードの1位は1.0565 BPBで、OpenAIが配ったベースライン1.2244から約13.7%下がりました。この記事では、ルールの細部、最終結果の推移、どの技術がどれだけ効いたか、失格になった提出の型を、GitHubリポジトリと各PRの一次情報で整理します。

まとめ：Parameter Golfの要点

• ルール：成果物（コード＋圧縮済み重み）は10進の16,000,000バイト以内。学習10分・評価10分、いずれも8×H100（SXM）。
• 評価指標：FineWeb検証セット（先頭5万文書）のBPB。トークン単位の損失をバイト単位に換算するので、語彙の違う提出どうしでも比べられる。
• 最終結果：1位は1.0565（codemath3000・PR #2135）。会期内の最後の記録は4月30日の1.0576。
• 効いた技術：語彙を1,024から8,192へ広げたうえでの int6・GPTQ 量子化、深さ再帰、評価時に採点済みの部分だけで学習するscore-first TTT。
• 運営の変化：提出者の大多数がコーディングエージェントを使い、OpenAIもCodexの選別ボットで審査した。上位の小改変コピーと規則違反の模倣が増えた。
• 今から：提出はできないが、MITライセンスのリポジトリで記録の再現や学習は続けられる。

Parameter Golfのルール：16MB・10分・8×H100

ルールの正本はopenai/parameter-golfのREADMEです。READMEは自らを「ニューラルスケーリング則でいうL(N)最適化」、つまりパラメータ数を固定し、データ量・計算量・ステップ数・アーキテクチャは問わずに損失を最小化する課題だと説明しています。そのうえで費用を抑えるため、記録として載る提出は8×H100で10分に制限されました。

16MBの容量上限：コードを含む16,000,000バイト

READMEのFAQは上限を「10進の16MB、つまり16,000,000バイトで、16MiB（16,777,216バイト）ではない」と定めています。差は777,216バイトです。数えるのは train_gpt.py のコードのバイト数と圧縮済みモデルのバイト数の合計で、評価中の外部ダウンロード・学習データへのアクセス・ネットワーク通信は禁止されています。

ベースラインの記録では、int8＋zlibで圧縮したモデルが15,815,847バイト、コードが47,642バイト、合計15,863,489バイトでした。上限まで残り136,511バイトしかなく、配布された時点ですでに上限ぎりぎりの設計です。ベースラインは9層・512次元・語彙1,024・KVヘッド4・入出力埋め込み共有（Tied Embeddings）で、パラメータ数は17,059,912でした。

BPBの計算式：損失を1バイトあたりのビットに換算

順位を決めるBPB（bits per byte）は、検証テキスト1バイトを表すのに平均何ビット要るかを示し、小さいほど上位です。ベースラインの train_gpt.py の eval_val は、自然対数の交差エントロピーをビットに直し、トークン数とバイト数の比を掛けています。

bits_per_token = val_loss.item() / math.log(2.0)
tokens_per_byte = val_token_count.item() / val_byte_count.item()
return float(val_loss.item()), float(bits_per_token * tokens_per_byte)

ベースラインの最終値（val_loss 2.0727・val_bpb 1.2244）を当てはめると、1トークンあたり2.99ビット、1トークンは平均2.44バイトです。語彙を大きくすると1トークンが表すバイト数が増えて tokens_per_byte は下がりますが、トークンあたりの損失は上がります。どちらに転ぶかを決めるのはBPBなので、語彙サイズそのものが競技の設計変数になりました。トークナイザーを変える提出は、バイト数の数え方に誤りがあると不当に得点が良くなるため、READMEは「より慎重に審査する」と明記しています。BPEなど方式ごとの違いはトークナイザーとは？BPE・WordPiece・Unigramの違いで解説しています。

記録として認められる条件

• 既存の最高記録を0.005ナット以上上回り、それを複数回の実行ログで p < 0.01 として示す（多くは3シードの平均）。
• 学習10分に加え、評価も8×H100で10分以内。評価時の系列長は自由。
• PRは /records にフォルダを1つ足すだけにし、README.md・submission.json・学習ログ・単体で動く train_gpt.py を入れる。
• 記録は「PRを作成した時刻」の順に受理される。

ただし最終表には、1位のp=0.014や4月27日の1.0611の行のp=0.188のように、p < 0.01を満たさない比較値を記した行も載っています。記録を更新しない独創的な提出や、10分の制限を外した提出（unlimited compute）は、非記録として別の表に載りました。

テスト時学習（TTT）が許される範囲

READMEは、評価中にモデルを更新するTTTを「すでに採点を終えた検証トークンでだけ学習してよい」と限定しています。検証データを学習中に読むことや、16MBの中に検証データを圧縮して持ち込むことは禁止です。上位はこの範囲を守るscore-first方式で、チャンクを先に採点してからそのチャンクでLoRAを更新し、文書の境目でリセットします。LoRAの仕組みはLoRA（Low-Rank Adaptation）とはを参照してください。

最終リーダーボード：1.2244から1.0565までの推移

READMEの記録トラックには、ベースラインを含めて48行が並びます。節目になった行を抜き出すと、効いた技術の順番が見えます（スコアは3シード平均などの提出値）。

3月中は量子化と評価方法の改善で1.10台まで下がり、4月は語彙の拡大・深さ再帰・TTTの組み合わせで1.06台に入りました。4月下旬以降の更新幅は1回あたり0.001〜0.002程度で、最後の1位はハイパーパラメータ1つの変更です。

締切と猶予ルール：PRを作成した時刻で判定

最後の行は会期の翌日付です。リーダーボードを更新したPR #2146は、2026年5月1日17時（太平洋時間）の締切より前に作成され、アイデアとコードが締切前に公開されていたPRなら、後から結果ログだけ足しても数えるという猶予ルールを示し、PR #1945・#1953・#2014・#2135の4行を追加しました。リーダーボードはこの5月4日の更新が最後です。

1位のBPB内訳：量子化による悪化とTTTによる改善

PR #2135は3シードの内訳を公開しています。平均は、量子化前1.0607、量子化後1.0691（+0.0084の悪化）、TTT後1.0565（-0.0126の改善）でした。成果物は平均15,945,206バイトで、上限まで約5万5千バイト。評価は最長567.1秒で、10分の評価枠もほぼ使い切っています。

学習の進み方もベースラインと対照的です。ベースラインは1ステップ43.54msで13,780ステップ回したのに対し、1位は約120msで約5,000ステップでした。1ステップが重い大きなモデルを、少ないステップ数で学習させて量子化する方向に上位は寄っていきました。

上位提出の技術：容量配分とBPB改善

16MBで何パラメータ持てるかは、1パラメータを何ビットで保存するかで決まります。次のコードは、ルールとベースラインの数値から予算を計算します（Python 3.9.6で実行して結果を確認）。

import math

CAP = 16_000_000  # 16MB = 10進の16,000,000バイト
print(f"16MiBとの差: {16 * 1024**2 - CAP:,} バイト")

model_bytes, code_bytes = 15_815_847, 47_642  # ベースライン記録の値
total = model_bytes + code_bytes
print(f"ベースライン合計: {total:,} バイト / 残り {CAP - total:,} バイト")

# train_gpt.py の eval_val と同じ式
val_loss, val_bpb = 2.0727, 1.2244
bits_per_token = val_loss / math.log(2)
tokens_per_byte = val_bpb / bits_per_token
print(f"bytes/token={1 / tokens_per_byte:.2f}")

budget = CAP - 50_000  # コード用に約50KBを残す（圧縮とスケール値は無視）
for bits in (8, 6, 4, 1.58, 1):
    print(f"{bits}bit: {budget * 8 / bits / 1e6:.1f}M パラメータ")

for vocab in (1024, 4096, 8192):  # 512次元・Tied Embeddings
    p = vocab * 512
    print(f"語彙{vocab}: int8で{p / 1e6:.2f}MB  int6で{p * 6 / 8 / 1e6:.2f}MB")

実行結果は、16MiBとの差777,216バイト、ベースラインの残り136,511バイト、1トークン2.44バイト、int8で15.9M・int6で21.3M・4bitで31.9M・三値（1.58bit）で80.8M・1bitで127.6Mパラメータでした。埋め込みは語彙1,024でint8なら0.52MBですが、語彙8,192では4.19MB（int6でも3.15MB）を占めます。圧縮率は重みの分布次第なので、この値は目安です。ベースラインもzlibで縮むおかげで、int8で17.06Mパラメータを収めています。

量子化：int8からint6・GPTQへ

ベースラインは学習後に行ごとのスケールでint8に丸め、zlibで圧縮するだけでした。上位はまず学習中に量子化を模擬するQATでint6へ下げ、次に学習後の丸め方を誤差の小さい方向へ選ぶGPTQに移りました。OpenAIの振り返り記事は、GPTQ-liteを初めて記録に使ったPR #414（signalrush）、Hessianを全部使うGPTQのPR #1060（dexhunter）、学習済みモデル自身に較正用テキストを生成させたPR #1019（abaybektursun）を挙げています。最後の1位もGPTQの較正バッチを倍にしただけの変更でした。手法の違いはLLM量子化とは？GPTQ・AWQ・GGUFの違いとPTQとQATの違いで整理しています。

三値（-1・0・+1）で73.7Mパラメータを詰めた記録トラックの提出は1.1570、1bitで106Mパラメータを2時間学習した非記録の提出は1.1239でした。ビット数を極端に下げてパラメータを増やす方向は、10分の制約下では最上位に届いていません。1bit LLMの実用例は1bit LLM「Bonsai」とはで扱っています。

語彙とトークナイザー：SP1024からSP8192・CaseOpsへ

4月1日の語彙4,096、4月5日の語彙8,192（埋め込みもGPTQで量子化）で記録が大きく動きました。埋め込みが数MB増えても、1トークンが表すバイトが増える効果が上回ったことになります。4月19日のCaseOps（PR #1729・romeerp）は、大文字・小文字を可逆な操作トークンに分けて語彙を節約し、BPBは元のバイト数で数える仕組みを付けました。OpenAIは振り返りで「データ表現の創造的なアイデア」として取り上げています。

アーキテクチャ：深さ再帰・並列残差・XSA

同じ層を繰り返し使う深さ再帰は、容量を増やさずに実効的な深さを稼ぎます。OpenAIは、4・5層目を繰り返し、再帰を学習の途中から有効にして、繰り返すMLPを部分的に別重みにしたPR #1204（msisovic）を「再帰層をうまく機能させた最初の記録」と評価しています。ほかに、注意とMLPを並列の残差経路に分ける並列残差、GQAに合わせた効率的な部分Exclusive Self Attention（XSA・PR #265）、直前トークンの埋め込みを混ぜるSmearGateと隣接トークン対のハッシュ特徴BigramHash（PR #65）が、上位の構成に積み重なりました。

評価の工夫：スライディングウィンドウとscore-first TTT

モデルを変えずに評価方法だけで点が動いたのも、このコンペの特徴です。3月19日には、評価をstride 64のスライディングウィンドウにして各トークンの予測に使う文脈を長くした提出が、1.1925を記録しました。TTTは4月以降の上位ほぼすべてに入っており、1位の内訳でもTTTが最大の改善幅（-0.0126）を担っています。

失格・除外になった提出の典型

PR #2146は、締切前に作成された192件のPR（#1944〜#2140）を、Codexの採点を並列に走らせて全件確認し、最後に時系列で突き合わせたと書いています。除外の理由は次の4つに分かれます。

• 学習データと検証データの重複：CaseOps用のデータを作り直す過程で、学習側に検証文書が混ざった（#2018・#2130）。
• バイト数の分母の誤り：変換後や再構成したテキストのバイト数で割り、元の検証バイトで数えていない（#2039・#2138）。
• 確率分布の正規化の失敗：バイト単位の混合予測が、全体を正規化した分布になっていない（#1991ほか5件）。
• 因果性の違反：単語内・単語単位のn-gramゲートが有効なままで、予測対象トークンに関する因果性の要件（C1）を満たさなかった（#2041・#2118ほか）。

4つは、データ・分母・確率分布・因果性という別々の箇所で評価の妥当性を損なう型です。同じ規則違反でもスコアが高いと、ほかの参加者のエージェントがそれを真似て無効な方向へ進んだとOpenAIは書いています。小型モデルの圧縮率を自社で測るときも、分母のバイト数と、検証データが学習側に入っていないかを最初に確かめるべきです。

非記録トラック：Transformer以外の挑戦

非記録の表（10分の制限を外した提出を含む）では、OpenAIによると表に載った提出の半数がベースラインの1.22を上回り、最上位は1.12（1bit量子化・1.1239）でした。READMEの表には、マスク型拡散言語モデル（MDLM・1.1465）、MambaとSliding Attentionを組み合わせたHymba（1.1467）、Mamba-3ハイブリッド（1.1473）が並びます。OpenAIが性能とは別に「お気に入り」として挙げたのは、状態空間モデルとJEPAの組み合わせ（CiprianFlorin-Ifrim）、DG Attention（ddavidgao）、バイト単位のH-Net（DariusFeher）の3件です。READMEの「やってほしいこと」の一覧でチェックが付いたのは1bitと三値の量子化だけで、JEPA・テキスト拡散・H-Netは非記録の提出があっても未チェックのまま、メガカーネルは提出が載らないまま会期を終えました。

コーディングエージェントが変えたコンペ運営

OpenAIの振り返り（2026年5月12日）によると、8週間で1,000人超の参加者から2,000件超の提出があり、提出者の大多数が作業にエージェントを使ったと記していました。実験の準備や見慣れないコードの読解が速くなり、参加の敷居は下がりました。一方で、提出の多くは上位の記録への小さな変更にとどまったとしています。

審査側も人手では追いつかず、OpenAIは新しい提出を監視して人の確認が要るものを選び出す、Codexベースの選別ボットを社内で作りました。1日に数百件が届く時期があったためです。最終のリーダーボード更新（PR #2146）も、共著者欄はCodexです。参加者側では、@notapplicaがエージェントと一緒に「Live Updates」という速報を書き、規則に収まるかを確かめる有志のツールも出ました。OpenAIのエージェントについてはCodexとは？使い方・料金・モデルで解説しています。

OpenAIにとっては人材発掘の場でもありました。READMEは6月に学部生・新卒・オリンピックのメダリストなどを対象に少人数の若手研究者を採用する計画を書き、参加者フォームは「参加に必須ではない」としていました。振り返りも「有意義な人材発掘の場になった」と書き、同様のコンペを今後も検討しているとしています。計算資源はREADMEが100万ドル分のクレジットと案内し、振り返りはこれをRunpodのスポンサーシップとして紹介しています。

NanoGPT Speedrun・Slowrunとの関係

READMEはParameter Golfを、同じFineWebと8×H100を使う2つのコンペの仲間として位置づけています。

modded-nanogptのREADMEによると、Speedrunはllm.cのGPT-2再現で45分かかった学習を、8×H100で40秒未満まで縮めています。Slowrunは逆に学習データをFineWebの1億トークンに固定して損失を競う競技で、8×H100の1時間・15分・2時間に加えて計算時間無制限の4トラックがあります。ベースラインは約47分で3.402です。Parameter Golfのベースラインもmodded-nanogptのコードを元にしており、ベースラインの時点でMuonオプティマイザが入っています。Karpathy系の小規模LLMの学習手順はnanochatとは？で紹介しています。

終了後にリポジトリで試す手順

会期は終わっても、リポジトリ（MITライセンス）・データのダウンロードスクリプト・全記録の train_gpt.py は公開されたままです。READMEの手順では、Apple Silicon搭載のMacならMLX版の train_gpt_mlx.py で手元で試し、本格的な学習はRunpodのH100に移ります。次のコマンドはCUDAのGPU機向けで、依存パッケージが入ったRunpodの公式テンプレート（1×H100）で動かす前提です。自前の環境では requirements.txt を先に入れてください。

git clone https://github.com/openai/parameter-golf.git
cd parameter-golf
python3 data/cached_challenge_fineweb.py --variant sp1024 --train-shards 1

RUN_ID=baseline_sp1024 \
DATA_PATH=./data/datasets/fineweb10B_sp1024/ \
TOKENIZER_PATH=./data/tokenizers/fineweb_1024_bpe.model \
VOCAB_SIZE=1024 \
torchrun --standalone --nproc_per_node=1 train_gpt.py

• 既定のダウンロードは検証セット全体と学習用80シャード（80億トークン）。--train-shards 1 で試験用に絞れる。
• train_gpt.py は既定で約10分で学習を止める。延ばすときは MAX_WALLCLOCK_SECONDS=0。
• 最後の final_int8_zlib_roundtrip 行に、量子化後のval_bpbと圧縮後サイズが出る。ベースライン設定なら約1.2が目安。
• READMEは8×H100の機体を1時間約20ドルとし、まず1×H100など安い構成での実験を勧めている。

上位の再現から始めるなら、READMEのリーダーボードの各行から records/track_10min_16mb のフォルダを開き、そのREADMEにあるコマンドで動かします。記録ごとに自分で1つずつ機能を外して比べると、どの部品がBPBに効いているかを自分のログで確かめられます。GPUの借り方はRunpodとは？料金・使い方を参照してください。容量や推論コストに制約のある環境で小型モデルを学習・量子化したい場合は、機械学習モデル開発の支援もご相談いただけます。

よくある質問

Parameter Golfとは何ですか？

OpenAIが2026年3月18日〜4月30日に開いた公開コンペ「Model Craft Challenge」です。コードと圧縮済み重みの合計を16,000,000バイト以内にし、8×H100で10分以内に学習した言語モデルのBPBを競いました。

16MBと16MiBは違いますか？

違います。ルールの16MBは10進の16,000,000バイトで、16MiB（16,777,216バイト）より777,216バイト少なくなります。コードのバイト数も合計に入ります。

最終的な1位のスコアはいくつですか？

記録トラックの1位はcodemath3000のPR #2135で1.0565 BPB（3シード平均1.05651）です。ベースライン1.2244から約13.7%の改善で、会期内の最後の記録は4月30日の1.0576でした。

BPBはどう計算しますか？

トークンあたりの交差エントロピー（自然対数）をln 2で割ってビットにし、検証データのトークン数÷バイト数を掛けます。値が小さいほど上位です。

今から参加・提出できますか？

記録としての提出は締め切られており、リーダーボードは2026年5月4日の更新が最後です。リポジトリとデータは公開されたままなので、ベースラインや上位記録を自分の環境で再現して学ぶことはできます。

関連記事

• LLM量子化とは？仕組みとGPTQ・AWQ・GGUFの違い・企業の採用判断を解説【2026年版】
• 量子化（モデル量子化）とは？仕組み・PTQとQATの違いと実装判断を解説【2026年版】
• トークナイザーとは？BPE・WordPiece・Unigramの違いと日本語での実装判断を解説【2026年版】
• nanochatとは？100ドルのChatGPTクローンは今48ドル・約2時間｜仕組みと学習手順
• Runpodとは？料金・使い方・支払い方法とGPUクラウドの選び方【2026年10月】