世界を動かす技術を、日本語で。

2つの10桁の数字を加算できる最小のトランスフォーマー

2026年2月27日原文(github.com)

概要

  • AdderBoard Challenge は、10桁同士の加算を99%以上の精度で実行できる最小のTransformer構築コンテスト
  • 手動設計(Hand-coded)学習済み(Trained) の2カテゴリで性能を競う
  • 自己回帰型Transformer であることが必須条件
  • 各手法の工夫や結果は リーダーボード で公開
  • パラメータ数の削減正確な加算表現 が主な研究課題

AdderBoard Challengeとは

  • 10桁の整数同士を加算し、 99%以上の精度 で正しい和を出力する最小のTransformerモデルを競うチャレンジ
  • Dimitris Papailiopoulos (@dimitrispapail)による運営
  • 当初はClaude Code(6,080パラメータ)とCodex(1,644パラメータ)がスタート地点
  • コミュニティの貢献で パラメータ数が劇的に削減 されている現状

部門と評価基準

  • Trained(学習済み)部門
    • SGDやAdam、進化的探索など、汎用的な学習アルゴリズムで重みを学習
    • データフォーマットやトークナイゼーション、カリキュラム学習、アーキテクチャ探索の工夫が評価対象
  • Hand-coded(手動設計)部門
    • 重みを理論的に解析的に設定(SGD等の発見性は不問)
    • アーキテクチャが加算を表現できることの構成的証明

主なルール

  • 自己回帰型Transformer であること
    • 少なくとも1層の 自己注意(Self-attention) レイヤーを含む
    • 入力はトークン列、出力は次トークンの予測(逐次的な自動生成)
    • キャリー伝播もこの自己回帰過程から自然に発生する必要
  • forward()は標準的なテンソル入出力計算
    • 問題特化の制御フローや明示的なキャリー変数、文字列操作は禁止
    • 推論ループは他のタスクにも使える汎用的なもの
  • 入力フォーマットの工夫は可
    • 桁の逆順や区切り文字など、固定された形式なら許容
  • 99%以上の精度 を10,000組の乱数ペアで確認

パラメータカウントの基準

  • 重みの重複・タイイング後の一意なパラメータ数 で計測
  • 固定/サイン波的な位置エンコーディングはカウント対象外
  • 学習済みの位置エンコーディングはカウント対象

リーダーボード(抜粋)

Hand-Coded(手動設計)

  • 1位:36パラメータ/100%精度/alexlitz
    • 2層デコーダ、d=5、ALiBi(slope=log(10))、ゲート付きReLU FFNなど
  • 2位:40パラメータ/100%精度/Wonderfall
    • 1層デコーダ、d=2、周期的RoPE、2ヒンジReLU MLPなど

Trained(学習済み)

  • 1位:311パラメータ/99.999%精度/rezabyt
    • 1層デコーダ、d=4、Rank-3ファクトライゼーション、RMSNorm、グロッキング
  • 2位:335パラメータ/99.92%精度/h3nock
    • カリキュラム学習、タイドエンベッド等の工夫

技術的工夫・発見

  • Rank-3ファクトライゼーション による大幅な圧縮
  • ALiBi の傾きlog(10)設定で基数10の重み付けを実現
  • 自己注意 による桁揃え、 MLP での1桁加算、 自己回帰生成 でキャリー伝播
  • パラメータ数約800 で急激な精度変化(パラメータクリフ現象)
  • 手動設計モデルは学習済みモデルよりはるかに小型化可能 (例:36 vs 311パラメータ)

提出方法

  • Issueの作成 または Pull Request でエントリー
    • コードへのリンク、テスト結果(精度)、検証スクリプトの実行結果を添付
    • 検証はverify.pyで10,000組+エッジケース10組を評価

研究的意義

  • Transformerが整数加算をどこまで小さく表現できるか の探求
  • 桁揃え・逐次加算・キャリー伝播という3つの能力を最小構成で実現する挑戦
  • 低パラメータ・高精度モデル設計の知見 の蓄積
  • 汎用的な自己回帰モデル設計の理解深化

参考リンク

  • 公式リポジトリ(GitHub)および各エントリーのgist/repo
  • MITライセンス

Hackerたちの意見

要するに、別の重みのセットを入れ替えて、同じ推論コードを使って別のタスクをこなせるなら、そのセットアップは正当だよ。もし推論コードがアルゴリズムから切り離せないなら、それはダメだね。なんで自分たちでコードを書かないのか不思議だな。そうすれば、モデルに焦点を当てられるのに。

手書きでコードを書くって、これ、6ヶ月前のこと?

ルールにどれくらい合ってるか分からないけど、Twitterで誰かが28パラメータって言ってたのを見たよ。

そういう単目的のネットワークを固定重みでLLMの中に埋め込むのって、事前学習の前に意味あるかな?

いい質問だね。うまくいくかもしれない、こういうテストを実行することも考えたよ。でも、いくつかの条件が必要なんだ。サブネットワークは「勾配抵抗」になるように作るか、凍結したままでなきゃダメ。発見された回路や手作りの回路がそのまま勾配圧力に耐えられるわけじゃないからね。特に、初期のプレトレーニングで飛んでくる勾配の種類はね。実際のLLMのプレトレーニング中に形成されるネイティブな表現とインターフェースできる必要があるけど、これは簡単じゃない。プレトレーニングの早い段階でこれが起こるべきだよ。勾配がサブネットワークを通るようにルーティングされ始めなきゃ。そこから「リッチがリッチになる」ダイナミクスに任せられるけど、そのためにはフルネットワークがサブネットワークを発見して使い始める必要がある。そして最後に、我々が望む用途で使われ始めなきゃいけない。もし「加算プリミティブ」の構造が他の何かに吸収される可能性もあるよ、トレーニングランに早めに入れたら、LLMのネイティブ回路が存在しない時にね。全体的に、初期テストとしては、同じサブネットワークの200の凍結コピーをLLMの異なる層に散布して、プレトレーニングを通してのダイナミクスを観察するのがいいと思う。発見を助けるために、プレトレーニングデータに追加の合成加算問題を入れるのもアリだね。原則的な解決策というより、エンジニアリング的な解決策だね。

それについても考えてた。もし、(一部の)チューリングマシンの能力を持つサブネットワークを手作りしたらどうなるかな?そういう回路はトレーニング中に自然に出てくるのかな?推論はそれを使って複雑な計算ができるの?

自分の提出物についてブログ記事を書いたよ(現在、36パラメータでトップの手書きのやつ)。

この質問は、あなたのブログ記事が数学を知っている誰かによって英語で書かれていることを確認する以上のことができない自分からのものです。もしN人の賢い人間が手動でLLMを作ったら、最前線のモデルと同じくらい賢いものができるかもしれないけど、サイズは45倍小さくなる可能性があるってこと?(1644 / 36 ≈ 45、Nは非常に大きい、時間は指定なし)

詳細は全部見てないけど、最初の埋め込みがどうなってるか見たかったんだ。14x5の行列があるのも確認したよ。手動で設定する時(学習するんじゃなくて)、「パラメータ」を数える定義がちょっと曖昧になるよね。あれは全部パラメータだって言えるかも!たとえシンプルに設定してもね。

すごくクールだけど、代わりにaddのCPU命令を提案してもいい?64ビットの数をサポートしてるし、ハードウェアにエンコードされてるから、パワーを食うGPUを経由する必要もないし。しかも、ほぼすべてのISAが最初からaddを持ってるから、クロスプラットフォームの可能性も高いよ。

「2つの数を足すことができる最小のスパコンクラスター」

まあ、すごいスピードで近くでレースさせるために、たくさんの高性能な車をサーキットに入れる必要はないよね。特に、都市バスはずっと前からあるし。

Hacker Newsで議論の続きを見る