『記憶』だけを6.9Bパラメータまで太らせたら、モデル本体を大きくするより効率が良かった

decoder-onlyのLLMは、長期記憶と推論を同じパラメータ集合の中で一体化して持っている。この設計だと、記憶容量だけを独立に増やすことが難しい。2026年7月30日にarXivへ投稿された論文「Memory Decoder at Scale」は、この「記憶」を切り出して独立にスケールさせる手法を、6.9Bパラメータ・300Bトークンという規模まで試している。著者はRubin Wei氏、Jiaqi Cao氏ら7名で、所属機関名はarXivのアブストラクトページには明記されていない。

3行まとめ

1. Memory Decoderという「パラメータ化された長期記憶モジュール」を、6.9Bパラメータ・300Bトークンまでスケールさせた。この規模では、標準的なFaissパイプラインによる索引・検索コストが実用に耐えなくなるため、Faiss索引・検索の分散パイプラインと、kNN分布のスパースなバッチ読み込みという2つの独自実装で対処している。
2. 17ベンチマークで、410MパラメータのPythiaモデルに6.9Bの汎用記憶モジュールを組み合わせたところ、平均スコアが29.86から37.34まで上がり、総パラメータ数が39%少ない12BパラメータのPythiaモデル単体(37.24)を上回った。
3. Qwen3 Baseモデル(0.6B〜14B)についても、1.7Bのドメイン特化記憶モジュールを組み合わせると、3つのドメインにわたる平均スコアがどの規模でも9ポイント以上向上したと報告している。

「記憶」と「推論」を分けて、記憶だけを大きくする

論文のアブストラクトは、この研究の出発点をこう説明している。

"Decoder-only language models entangle long-term memory and reasoning in a single parameter set, making it difficult to scale memory capacity independently. Memory Decoder introduces a parametric long-term memory module but only studies it at a relatively small scale." （「decoder-onlyの言語モデルは、長期記憶と推論を単一のパラメータ集合の中で絡み合わせており、記憶容量を独立にスケールさせることを難しくしている。Memory Decoderはパラメータ化された長期記憶モジュールを導入するが、これまでは比較的小規模でしか検証されていなかった」）

この論文は、その「小規模検証」だった先行研究を、実際に大規模化したらどうなるかを検証したものだ、という位置づけになる。

Faissパイプラインが壊れる規模まで踏み込んだ

大規模化する上でぶつかった技術的な壁として、論文は索引・検索コストを挙げている。

"At this data scale, the combined cost of indexing and search makes a standard Faiss pipeline infeasible. We address this bottleneck with a distributed pipeline for Faiss indexing and retrieval, together with sparse, batch-wise loading of kNN distributions." （「このデータ規模では、索引付けと検索を合わせたコストにより、標準的なFaissパイプラインは実用に耐えなくなる。我々は、Faissの索引付けと検索のための分散パイプラインと、kNN分布のスパースかつバッチ単位での読み込みによって、このボトルネックに対処する」）

Faissはベクトル検索によく使われるMeta製のライブラリだが、300Bトークン規模のデータに対して素朴に使うと破綻する、という具体的な技術的知見がここに書かれている。「記憶をスケールさせる」というアイデア自体は目新しくなくても、実際にスケールさせようとすると索引付けのインフラそのものを作り直す必要がある、という点は実践面で参考になる。

「記憶にパラメータを割く方が効率が良い」という中心的な主張

論文の核心的な主張は、モデル本体を大きくするより、記憶モジュールにパラメータを割いた方が、パラメータ当たりの性能向上が大きいというものだ。

"Across model scales, we find that allocating more parameters to memory yields a better parameter-performance tradeoff than scaling the base model alone. On 17 benchmarks, pairing a 6.9B general memory with Pythia-410M raises its average score from 29.86 to 37.34, surpassing Pythia-12B (37.24) with 39% fewer total parameters." （「モデル規模を通じて、記憶によりパラメータを割り当てることは、ベースモデル単体をスケールさせるよりも良いパラメータ対性能のトレードオフをもたらすことがわかった。17のベンチマークで、6.9Bの汎用記憶を410MパラメータのPythiaと組み合わせると、平均スコアは29.86から37.34まで上がり、総パラメータ数が39%少ないPythia-12B(37.24)を上回る」）

「410M＋6.9Bの記憶＝合計7.3Bで、12B単体を上回る」という計算になる。パラメータの絶対数だけを見ればPythia-12Bの方が小さいわけではないが、著者らの主眼は「同じ量のパラメータをどこに割り振るべきか」という問いにあり、記憶に厚く割り振る方が良いという結果を示している。

Qwen3 Baseモデルについても同様の傾向が報告されている。

"For Qwen3 Base models ranging from 0.6B to 14B, 1.7B domain memories improve the average score across the three domains by more than 9 points at every scale." （「0.6Bから14BまでのQwen3 Baseモデルについて、1.7Bのドメイン記憶は、3つのドメインにわたる平均スコアをどの規模でも9ポイント以上向上させる」）

こちらは汎用記憶ではなく、特定ドメインに特化した記憶モジュールを付け足すパターンで、モデル規模が変わっても効果の大きさがほぼ一定だった、という点が報告されている。

GitHubとHugging Faceで実際に何が公開されているか

arXivのアブストラクトページには著者所属の記載が無かったため、論文のHTML全文版とGitHubリポジトリを直接確認した。著者らはRubin Wei氏・Jiaqi Cao氏・Jiarui Wang氏・Junming Zhang氏・Qipeng Guo氏・Bowen Zhou氏・Zhouhan Lin氏の7名で、上海交通大学 人工知能学院 LUMIA Lab、上海人工知能研究院（Shanghai Artificial Intelligence Laboratory）、清華大学電子工学科の3機関にまたがっている。

GitHubリポジトリ（LUMIA-Group/MemoryDecoder-at-Scale、Apache 2.0ライセンス）のREADMEを実際に開くと、コード・モデル・データが実際に公開されていることを確認できた。「学習済みの汎用記憶・ドメイン記憶とデータ成果物は、Hugging FaceのMemoryDecoder-at-Scaleコレクションで公開している」と明記されており、リンク先のHugging Faceコレクションページも実際に開いて存在を確認した。

READMEの評価セクションから、「17ベンチマーク」「3つのドメイン」の内訳も具体化できた。

3行まとめで触れた「3つのドメイン」は、README本文で明示的に「biology, law, and finance（生物学・法律・金融）」と書かれており、それぞれBioInst・LawBench・FinEvalに対応する。「17ベンチマーク」の全リストはREADME単体では数え切れなかったが、General downstreamのグループが複数の個別タスクをまとめて指している可能性が高く、内訳の完全な列挙は論文本体の評価セクションを読む必要がある。

Pythia比較の公平性までは検証していない

コード・重み・ベンチマークの内訳は今回GitHub・Hugging Faceの一次情報で埋められたが、Pythia-410M/12Bという比較対象の選び方が公平かどうか(たとえば学習トークン数が揃っているか)は、論文本文の実験設定セクションを通読しないと判断できず、この記事では確認していない。「17ベンチマーク」の完全なリストと個別スコアの内訳についても、README本体からは分からず、論文本文の表を1つずつ確認する作業はこの記事の範囲を超える。

この論文を読みながら気づいたのは、「記憶を切り出す」というアイデア自体は目新しくなくても、著者らが最も紙幅を割いているのはモデルの新規性よりも「300Bトークン規模でFaissが壊れる」という泥臭いインフラ上の壁とその対処法だったという点だ。アルゴリズムの提案より、スケールさせる過程で出てくる実装上の障害の方が、この論文の実質的な貢献に見える。

Zennでの「Memory Decoder」検索結果は0件だった。この分野に近い話題として、AIエージェントの記憶管理サービスMem0がDeepSeek HarnessやAWS Strands Agentsに公式対応した動きを別記事で扱っている。ただしMem0は外部の記憶ストアを検索ツールとして呼び出す設計であるのに対し、Memory Decoderはモデル自体のパラメータとして記憶を組み込む設計であり、アプローチはまったく異なる。

関連記事

• Mem0が2つのエージェントフレームワークに公式対応