はじめに
富士通、理化学研究所 AIP、東京科学大学、東海大学の研究チームが arXiv で公開した論文 「PHOTON: Hierarchical Autoregressive Modeling for Lightspeed and Memory-Efficient Language Generation」（Yuma Ichikawa, Naoya Takagi, Takumi Nakagawa, Yuzi Kanazawa, Akira Sakai）で提案された新アーキテクチャ PHOTON が、興味深かったのでまとめてみました。
X で面白かったと投稿したところかなり沢山の反応をいただけたのでみなさんも興味を持たれるのではないでしょうか。
日本から大規模言語モデルのアーキテクチャーに新しい１ページが追加されるかもしれないと思うとワクワクしますね！
この記事では、厳密さよりも自分のざっくり理解をメモとして残して共有することを目的にしていますので不正確なところがあると思いますがお許しください。
そもそも何が問題だったのか ～ Transformer の「水平スキャン」 ～
ChatGPT や Claude をはじめ、現在の主要な LLM はすべて Transformer というアーキテクチャを基盤にしています。Transformer をざっくり言うと、「これまで出てきたすべてのトークン（単語のようなもの）を毎回振り返りながら、次のトークンを 1 つずつ決めていく」仕組みですね。
論文ではこの状況を、Transformer は「水平方向のトークンごとのスキャナ（horizontal token-by-token scanner）」のように動き、生成のたびに伸び続けるトークン列に逐一アテンションを張る、と表現しています。文脈理解には強い反面、致命的な弱点があります。
長い文章を扱うと、過去のトークンの内部状態を保存しておく KV キャッシュ が GPU メモリを圧迫し、生成のたびに大きなキャッシュを読み書きするコストが支配的になります。結果として、推論性能は計算能力ではなく メモリ帯域（memory-bound）によって頭打ちになります。論文も「特に長文・多クエリ配信ではこのボトルネックが顕著」と指摘しています。これが世界的な GPU 需要逼迫の一因にもなっているわけですね。
このあたりの「Prefill フェーズと Decode フェーズで何がボトルネックになるのか」「Decode フェーズはなぜメモリ帯域律速になるのか」「KV キャッシュをどう再利用すれば TTFT を削減できるのか」については、以前 LLM の推論インフラを理解しよう！モデルルーティングゲートウェイ Shepherd Model Gateway（SMG） という記事にまとめましたので、よろしければそちらも合わせて読んでみてください。SMG のような 推論インフラ側 の工夫が KV キャッシュのヒット率を上げて TTFT を 70 〜 75 % 削減する話だとすれば、今回の PHOTON は モデルアーキテクチャ側 からそもそも KV キャッシュを劇的に小さくしようというアプローチで、両者は綺麗に補完関係にあると言えます。
PHOTON のアイデア ～ 「水平スキャン」をやめて「縦の階層スキャン」へ ～
PHOTON の問いはシンプルです。「生成は本当に、一続きの履歴を 1 トークンずつ水平にスキャンし続ける必要があるのか？」というものです。自然言語にはもともと、サブワード → 単語 → 文 → 段落 → 文書、という階層構造があります。PHOTON はこの構造を素直にモデル化し、従来の 水平スキャン をやめて 垂直方向・多重解像度の階層スキャン に置き換えようというものです。
PHOTON は "Parallel Hierarchical Operation for TOp-down Networks" の略で、その名の通り 階層構造 と トップダウン生成 がキモです（"Parallel Hierarchical Operation for TOp-down Networks" という見事な文字列を生成した著者のみなさん、凄いですね。LLM かな？）。
まずはイメージから ～ 「全体をつかむ係」と「細部を書く係」の分業 ～
難しい話に入る前に、まずは PHOTON がやっていることのイメージをつかんでみましょう。
PHOTON は文章生成の仕事を、2 人の係に分業させていると思ってください。
- 全体をつかむ係（要約担当）: 過去の文章をざっくり要約して、「今の話の流れはこんな感じ」という大まかなメモだけを持っておく人
- 細部を書く係（生成担当）: 要約担当からメモを受け取り、「今書くべき数単語」だけを集中して書く人
従来の Transformer は、この 2 人の役を 1 人で兼任しているようなものでした。1 トークン書くたびに、過去の全文章を最初から読み直していたわけです。当然、文章が長くなると読み直すコストが膨れ上がります。
PHOTON はこれを分業します。要約担当は「短い要約」だけを保持していればよく、生成担当は「すぐ周辺の数トークン＋要約担当からのメモ」だけを見れば次の単語を書ける。だから読み直すべき情報量が圧倒的に少なくて済む、というのが基本的な発想です。
しかも、要約担当が作ったメモが同じであれば、細部を書く係は 複数の場所を並列に 書き進めることができます。これがスループット向上の源泉になります。
仕組みを少しだけ正確に ～ エンコーダとデコーダ ～
ここまでのイメージを、論文の用語で書き直すと次のようになります（細かい記号は読み飛ばしても OK です）。
ボトムアップ・エンコーダ（要約担当）
下から上へ、トークンを要約していくパートです。各レベルで
- Context Chunker: 前のレベルの単位をいくつかまとめて 1 つのチャンク表現にする
- Context Encoder: そのチャンク列を自己回帰 Transformer で処理し、文脈を反映させる
の 2 ステップを行います。これを階層的に積むことで、文章全体を「少ない粗い情報」にどんどん圧縮していきます。
トップダウン・デコーダ（細部生成担当）
逆方向に、粗い要約から細かいトークンを作っていくパートです。各レベルで
- Context Converter（1 次元畳み込み）: 1 個の粗い潜在ベクトルを、下位レベル用の「条件付け接頭辞（数個のベクトル）」に展開する（要約担当が渡してくれたメモを、細部担当が読みやすい形に書き直す係）
- Context Decoder: その接頭辞を頭につけて、チャンク内のトークンを自己回帰的に生成する局所的な因果 Transformer（実際に細部を書く係）
ここで重要なのは、Context Decoder が見るのは 「自分のチャンク内のトークン＋上位からの条件付け」だけ ということ。文章全体の長さには依存しません。アテンション幅が固定なので、
- 過去全体を毎回見に行くコストが消える
- 異なるチャンクは独立に動かせるので 並列生成 できる
という二重のメリットが得られます。
学習の工夫 ～ 上下の係の「答え合わせ」 ～
ここで素朴な疑問が湧きます。要約担当（ボトムアップ・エンコーダ）と細部担当（トップダウン・デコーダ）は別々のネットワークなのに、本当に同じ「話の流れ」を共有できるのでしょうか？ ボトムアップで作った要約と、トップダウンで使われる要約が食い違ってしまえば、分業はうまく回りません。
そこで PHOTON は、学習のときに次の 2 種類の「誤差」を 同時に小さくする ように学習します。
-
次の単語の予測誤差
普通の言語モデル学習と同じで、「直前までの文章を入力したとき、次に来る単語をどれくらい外したか」を測るおなじみの誤差です。論文では Next-Token Loss と呼ばれています。 -
上下の要約の誤差（Recursive Loss）
各レベルで、「ボトムアップで作った要約」と「トップダウンで復元した要約」がベクトルとしてどれくらい食い違っているか（具体的にはコサイン距離）を測ります。要するに、要約担当と細部担当の間で 答え合わせ をさせて、食い違いを誤差にする仕掛けです。
この 2 つを足した合計誤差が小さくなるように学習することで、「言語モデルとしての性能」と「上下の係の連携」を両立させているわけです。
もう一つの工夫 ～ Recursive Generation（RecGen） ～
階層モデルの素朴な実装には弱点があります。新しいトークンを生成するたびに、エンコーダを下から上まで走らせ直して階層状態を更新する必要があり、せっかくの階層構造のメリットが薄れてしまうのです。
PHOTON はこれを避けるため、Recursive Generation（RecGen） という生成方式を導入します。要点はこうです。
- 一度プリフィル（プロンプト処理）を済ませたら、最上位レベルの KV キャッシュだけ を GPU 上に残す
- それより下の階層のエンコーダ KV はすべて捨てる
- 新しいトークンを作るときは、デコーダ側のボトルネック復元（top-down で出てきた中間表現）を使って最上位ストリームを直接更新する
つまり、ボトムアップの再エンコードを完全にスキップし、グローバルに育つ KV は最上位だけに限定します。論文には「ボトルネック再帰整合性（bottleneck recursive consistency）が満たされていれば、HierGen（素朴な階層生成）と RecGen は同じ出力分布を生む」という証明スケッチも示されており、先ほどの Recursive Loss はこの整合性を学習段階から促す役割を担っています。
実験結果 ～ 何がどれくらい嬉しかったか ～
論文では、LLaMA ベースのバニラ Transformer および Block Transformer を比較対象に、600M / 900M / 1.2B のサイズで PHOTON を学習し（学習データは The Pile）、KV キャッシュメモリあたりのスループット（TPM = Throughput / Memory）と言語モデリング品質を比較しています。詳細な数表は割愛し、ここでは「結局、何が言えたか」だけまとめます。
- 同じメモリで桁違いに多くのトークンを生成できる: バニラ Transformer に対して、設定によっては TPM が 数百倍 に達する。最も極端な 1.2B モデルの decode-heavy 設定では約 475 倍。論文アブストラクトの「最大 約 10³ 倍」という表現はこれを丸めたものです。
- 品質は少し落ちるが、トレードオフでは圧勝: WikiText パープレキシティはわずかに悪化するものの、TPM と品質のパレートフロンティアではバニラ Transformer・Block Transformer の両方を一貫して上回ります。「同じ品質なら圧倒的に省メモリ」「同じメモリなら圧倒的に高品質」という関係です。
- Recursive Generation がさらに効く: ボトムアップ再エンコードを省く RecGen を使うと、HierGen からさらに 2〜4 倍 の TPM 改善。特に decode-heavy 設定では、バニラ Transformer 比で 最大 約 1,856 倍 の TPM 優位に達しうると報告されています。
- 長文・多クエリ配信で特に効く: 効果が大きいのは「長いコンテキスト」と「同時に多くのリクエストを捌く」シナリオで、まさに現在の LLM サービスがボトルネックを抱えている領域です。
要するに、「同じ GPU メモリで桁違いに多くのテキストをさばける可能性」を、品質をほぼ落とさずに示した ——というのが論文のメッセージです。
なぜ重要か ～ 長文と同時多数リクエストへの効き目 ～
PHOTON が本当に価値を持つのは、長文処理と多数の同時リクエスト処理という、まさに現在の LLM サービスがボトルネックを抱えている領域です。
より少ない GPU で同等のサービスを提供できる可能性、数万〜数十万トークン級の長文コンテキストを現実的なコストで扱える可能性、そして GPU 逼迫問題に対する「アーキテクチャレベルの解答」になりうる、という意味でインパクトは大きそうです。
Transformer の登場から約 9 年、「次に来るかもしれないアーキテクチャ」はいくつも提案されてきましたが（Mamba などの状態空間モデル、各種 Linear Attention、Block Transformer など）、PHOTON は 言語そのものが持つ階層構造に素直に寄り添い、それを推論時の状態管理にまで持ち込む という点で、ひときわ筋が良さそうに見えます。日本の研究機関発というのも、個人的には嬉しいニュースです。
もし PHOTON が大規模モデルでも成功したら
少し想像を膨らませてみると、PHOTON のアプローチが数十 B 〜 数百 B クラスでもうまくスケールした場合、私たちの LLM 体験はかなり変わりそうです。
同じ GPU でずっと多くの同時ユーザーを捌ける
KV キャッシュが桁違いに小さくなれば、1 枚の GPU に乗るバッチサイズを大幅に増やせます。先に紹介した SMG のような推論ゲートウェイがキャッシュヒット率で TTFT を削るのと組み合わさると、「同じ GPU 台数で 10 倍、100 倍のリクエストを捌く」ことが現実味を帯びてきます。
長文コンテキストが当たり前になる
数十万トークン級のコンテキスト（書籍 1 冊分、巨大なソースコードリポジトリ全体、長時間の会話履歴）を、現在のような「お金持ちの特権」ではなく、普通のサービスでも気軽に使える機能にできるかもしれません。
GPU 逼迫問題への構造的な解答になりうる
現在の GPU 不足は、半分以上が「メモリ帯域とメモリ容量」の問題です。アーキテクチャ側でそこを大きく削れるなら、必要 GPU 数そのものが減り、電力・コスト・サプライチェーンの制約が一気に緩む可能性があります。
エッジ・オンプレ LLM のハードルが下がる
同じメモリで何倍ものスループットが出せるなら、今は無理だったエッジデバイスや小規模オンプレ環境でも、長文対応の実用的な LLM を動かせる可能性が出てきます。
もちろんこれは「うまくスケールしたら」という前提付きの夢物語ですが、推論インフラ側の工夫（SMG など）と組み合わさると、LLM の経済性が一段階変わるインパクトを持ちうる研究だと感じます。
限界と今後 ～ 論文の Limitations から ～
論文は最後に、以下の限界点を率直に挙げています。
- 学習に使ったコーパスは The Pile 単一で、評価ベンチマークも限定的。データ・タスク横断での一般性はこれから確認する必要がある。
- 最大モデルが 1.2B パラメータ。数十 B、数百 B クラスでの効率と品質のトレードオフがどうなるかは未検証。
- チャンク長や Converter 幅といった主要設計パラメータの感度解析・アブレーションが十分ではない。
つまり、「方向性は非常に有望だが、本当に LLM 全体を置き換えられるかは大規模化での追試次第」というのが論文自身の立ち位置です。
それでも、「Transformer の弱点をハードで殴るのではなく、アーキテクチャで解く」という方向性は、これからの LLM 研究の大きな流れになっていきそうです。今後、より大規模なモデルでの追試や実サービスでの適用例が出てくるのか、注目していきたいですね。
参考文献
- 論文（arXiv abstract）: https://arxiv.org/abs/2512.20687
- 論文（HTML 版 v2）: https://arxiv.org/html/2512.20687v2
- 論文（PDF）: https://arxiv.org/pdf/2512.20687
- Block Transformer（比較対象）: Ho et al., "Block Transformer: Global-to-Local Language Modeling for Fast Inference," NeurIPS 2024