グローバルに参照する状態数長さに比例 vs 1/C
2026年6月、富士通が発表した LLM アーキテクチャ PHOTON は、 文章を横にトークン単位で舐める Transformer に対して、 要約の階層を縦に潜る。この教材では、報道で独り歩きしている「475倍」を スループット × メモリの積へ分解する。そのうえで、 475倍が階層化だけで出ている数字であって RecGen 抜きであること、 同じ表で Block Transformer が既に211倍を出していることまで含めて、 どこからどこまでが PHOTON 固有の貢献なのかを切り分ける。 論文自身が認める品質のトレードオフと測定プロトコルの非対称も明示する。
KVキャッシュとは何か／なぜメモリ律速になるのかが曖昧なら、先にこちらを。 KVキャッシュ電卓で「1トークン何KB・1本何GB・GPUに何本載るか」を手を動かして掴んだうえで、 本稿に出てくる RecGen の「再帰」が 自己回帰 / 漸化式 / 往復整合性の3つのうちどれを指しているかを分解してあります。
PHOTON が何を解いたのかは、「何が詰まっていたのか」を先に押さえないと分からない。
LLM の推論は2つの局面に分かれる。プロンプトを読み込む prefill と、1トークンずつ吐く decode。 このうち decode は、1トークン作るのに過去の全トークンぶんの KV キャッシュを読み直す。 演算量に対してメモリ読み書きの量が大きすぎるため、GPU は演算器を遊ばせたまま メモリ帯域で律速される（memory-bound）。
しかも KV キャッシュは系列長に比例して伸びる。長文を読ませるほど、 1トークンあたりの読み直し量が増える。ここで効いてくるのは占有量ではなく累計トラフィックで、 保持量が O(T) でも、T トークン生成しきるまでの読み出し総量は O(T²) になる （t トークン目は t 個ぶん読むので、足し上げると二乗）。 文脈が2倍なら占有は2倍だが流れる量は4倍——これがいわゆる「メモリの壁」で、 GPU を買い増しても計算性能ぶんだけは速くならない領域に入っている。 （前提編の KVキャッシュ電卓で 「70B級・32k文脈で1本10GiB」といった実数を掴んでおくと、以降の倍率が体感に接続する。）
① 1トークンあたりの読み直し量を減らす（＝キャッシュを小さくする）。 ② 同じメモリでより多くのクエリを同時に走らせる（＝バッチを増やして帯域を償却する）。 PHOTON はこの2つを同じ仕掛けで同時に取りに行った。だから成果指標が 「速度」ではなく TPM＝メモリあたりスループット（tok/s/GiB）になっている。 475倍という数字はここから出ている。
論文の中心的な比喩。Transformer は horizontal token-by-token scanner、PHOTON は multi-resolution vertical scanning。スライダーで文脈長を変えて、参照する状態数がどう乖離するか見る。
概念モデル この表は階層構造から算術的に導いた説明用の数値であって、論文の実測値ではない。 実測は 05 に分離して掲げる。要点は倍率そのものではなく、 Transformer の行だけが文脈長に比例して増え、PHOTON のローカル行は定数のままという形にある。
PHOTON は「Transformer をやめた」のではない。Transformer ブロックを解像度の違う2つの流れに配置し直した。
| モジュール | やること | 効いてくる場所 |
|---|---|---|
| Context Chunker bottom-up |
level-(l−1) の表現を C 個ずつまとめ、連結または線形射影でチャンク特徴にする。トークンを意味のまとまりに潰す工程。 | 系列長が 1/C に縮む。ここが全効率の源泉。 |
| Context Encoder bottom-up |
粗い時間解像度の上で自己回帰的に走る Transformer。要約列の言語モデルにあたる。 | ここだけが「長い文脈」を見る。ここのKVが最上位キャッシュ。 |
| Context Converter top-down |
1次元畳み込みで、1本の要約ベクトルを C 本の条件付けベクトルへ広げ戻す。 | 上位の意図を下位へ配る配線。並列展開が可能になる。 |
| Context Decoder top-down |
因果 Transformer だが attention がチャンク内に限定される。上位の条件付け＋近傍だけで実際のトークンを書く。 | ここの計算量・キャッシュは文脈長に依存しない定数。 |
主実験は L=2、C₁=4、C₂=4（＝最上位1状態がトークン16個ぶん）。 品質寄りの設定として C₁=2、C₂=2（＝4トークンぶん）も検討されている。 C を大きくするほど縮むが、上位が背負う情報量が増える——ここが効率と品質のダイヤルになっている。 論文は「チャンクサイズやコンバータ幅の感度解析が十分でない」ことを限界として自ら挙げている。
階層化しただけでは半分しか得しない。PHOTON の効率の残り半分はここから出る。
素朴に階層モデルを回すと（論文の言う HierGen）、1チャンク生成するたびに ①下ろしてトークンを書く → ②書いたトークンを Chunker/Encoder に通して上げ直す → ③最上位を1歩進める、 という往復が要る。②があるかぎり全階層のエンコーダ側 KV を保持し続けねばならない。
RecGen の着眼は「デコーダは、上げ直さなくても上げ直した結果をすでに持っている」こと。 top-down デコーダのボトルネックには、そのチャンクの再構成 Â が出ている。ならばトークンを再エンコードせず、 Â をそのまま最上位エンコーダへ渡せばいい。
Â（デコーダの再構成）と A（エンコーダが出すはずの要約）が食い違えば当然破綻する。 論文は付録Aで条件を明示していて、Â_g = A_g が成り立つ限り、HierGen と RecGen は同じ最上位更新を行い、 出力トークン列の分布も一致する（Theorem A.6：p^Rec = p^Hier）。 重要なのは、等号が必要なのは L→L−1 のボトルネック界面だけで、 それより下の再構成には何の仮定も要らない、と明記されている点。効かせどころが1箇所に絞られている。
整合性は再帰損失（式1、コサイン距離）を重み α で足して訓練時に促す。ただし 主実験の設定は α = 0.0——「階層アーキテクチャ由来の利得を切り分けるため」と明記されている。 α ≈ 0.3 はアブレーション（B.1）で平均ゼロショット精度が最大になる値であって、主表の設定ではない。 さらに興味深いのは、α = 0 でも再帰損失は学習を通じて減り続けるという観察で、 論文は「階層アーキテクチャ自体が自己整合的な要約を促しているのかもしれない」と述べている。 RecGen が α=0 の設定でも成立している根拠がここにある。
スループット 70.43 → 163.71 K tok/s（約2.3倍）、メモリ 0.023 → 0.012 GiB（約1.9倍削減）、
積で TPM 4.5倍。保持されるのは最上位のグローバル KV のみで、
level 1…L−1 のエンコーダ側キャッシュは prefill 後に破棄される。
見落とされやすいが、減るのはキャッシュだけではない。
上げ直しが無くなるということは、decode 中はエンコーダ階層を一度も呼ばないということでもある。
プロンプトを読む prefill で一度使ったら、あとはデコーダ側だけを GPU に置いておけば生成が回る。
つまり KVキャッシュに加えて、モデルの重みの常駐量そのものが減る——
論文は「decode 中は階層デコーダのみを GPU 上に保持し、モデル常駐と KVキャッシュの両方を削減する」
「GPU常駐のモデルフットプリントを半減させる」と書いている。
砂時計型のアーキテクチャの、上半分を降ろせる、ということ。
ここが肝心：次節の475倍は RecGen 抜き（標準の HierGen デコード）で測られている。
RecGen はその上に乗る別倍率で、600M で vanilla と比べると
最大 1,856倍（DE の TPM 7.35 → 13,642.50）。Abstract の「10³×」はこの数字を指している。
ここが本題。報道の見出しだけ読むと取り違える。論文実測・1.2B / decode-heavy
TPM は メモリあたりスループットという合成指標で、 「同じ GPU メモリで、どれだけ多くのトークンを吐けるか」を測る。だから 475倍は体感速度ではない。1本のリクエストの応答が475倍速くなるのではなく、 速度が約44倍、そのうえ1本あたりの占有メモリが約11分の1になり、同時に載る本数が約11倍になる——その積である。
両方の因子とも、出どころは階層化そのもの——decoder の attention が チャンク内（span R_l + C_l）に閉じて系列長 T から独立になること、 グローバルに保持する KV が T/C に縮むこと。主表は RecGen 抜き（標準の HierGen デコード）・α = 0.0 で測られている。 475倍に RecGen は入っていない。RecGen は前節のとおり、この上に別倍率として乗る。
| 1.2B モデル / decode-heavy | Vanilla | Block Tf. | PHOTON | 読み |
|---|---|---|---|---|
| TPM（K tok/s/GiB） | 2.56 | 540.20 | 1,216.67 | vanilla比 475×／Block比 2.25× |
| decode メモリ（GiB） | 0.390 | 0.051 | 0.036 | 10.8× 削減 |
| decode スループット | 1.00 | 27.55 | 43.80 | K tok/s。43.8× |
| WikiText PPL ↓ | 19.68 | 22.84 | 23.79 | Block にも負けている |
| ゼロショット平均 ↑ HS / SciQ / ARCe | 58.8 | 54.2 | 52.1 | SciQ が 81.5→69.3 と大きく落ちる |
同じ表で Block Transformer（Ho et al., 2024）が既に TPM 540.20＝vanilla比 211倍を出している。
つまり475倍の大半は「階層化・ブロック化」というアプローチ一般の効果であって、
PHOTON が Block Transformer に対して稼いでいるのは 2.25倍。
しかも品質は Block のほうが良い（PPL 22.84 < 23.79）。
論文の主張は「どちらか一方の軸で勝つ」ではなくTPM–品質のパレートフロンティアで優位という形になっており、
そこは正確だ。PHOTON 固有の貢献として読むべきは、単発の倍率よりも
推論をまたいで持続する多階層の状態（Block Transformer は単一階層のブロック注意にとどまる）と
RecGenのほうだと思う。
PPL 19.68 → 23.79、ゼロショット平均 58.8 → 52.1。小さくない差だ。ここを飛ばして475倍だけ語るのはフェアではない。
チャンク長 {C₁,C₂} が圧縮率をそのまま決めるので、これがパレート上を移動するレバーになる。 4×4 → 2×2 に絞ると、PPL 29.91 → 24.28、ゼロショット平均 48.72 → 52.01 と品質が戻る一方、 DE の TPM は 3,062 → 418 に落ちる。それでも同規模の vanilla（DE TPM 7.35）よりはるかに効率的で、 品質寄りに振ってもフロンティアから外れない、というのが論文の主張。 効率倍率は固定値ではなく、どこで妥協するかを選べる量だと読むのが正しい。
富士通が提示する答えは マルチクエリ統合——少しずつ振ったクエリを複数走らせ、 多数決や best-of-N で束ねる。9クエリ程度の集約で従来 Transformer と同等の出力品質に届いたとされる。 プレス
論理としては一貫している。1本あたりが安くなったぶんを本数で買い戻す。 メモリが11分の1なら、同じ GPU に10本以上載る。9本束ねて品質が並ぶなら、 それでもまだスループットの取り分は残る——これが「単発品質では負けているのに勝ち」と主張できる構造だ。 裏を返せば、1本しか走らせない用途では PHOTON の旨味はかなり削られる。
論文自身が認めている——「RecGen 下で perplexity やゼロショット精度を、尤度ベースで整合的に測るのは自明でない」。 そのため報告されている品質数値は teacher-forced な HierGen で測られており、RecGen そのものの出力品質を直接測ってはいない。 効率の数字は RecGen 込み、品質の数字は HierGen 側。この非対称は、 数字を引用する側が黙って落としてはいけない部分だと思う。
① 事前学習コーパスが単一（The Pile）で下流ベンチも小さく、データ配合やタスク族をまたいだ一般化は未確認。
② 最大モデルが 1.2B。10B超の規模で効率と品質のトレードオフがどう振る舞うかは未特性化。
③ チャンクサイズ・コンバータ幅など主要な設計選択の感度解析が不足。
要するに現時点では「有望な方向であり、大規模での検証が要る」という自己評価であって、
製品化時期・提供形態・価格はいずれも未公表である。
PHOTON は Transformer より475倍速い。
速度は約44倍。475倍はメモリあたりスループット（TPM）で、速度×メモリ削減の積。応答レイテンシの話ではない。
Transformer を捨てた新方式。
Encoder も Decoder も中身は Transformer。変えたのはどの解像度の列に attention を張るかという配置。Attention 自体は健在。
光を使った計算だから PHOTON。
Parallel Hierarchical Operation for TOp-down Networks の頭字語。フォトニクスとは無関係。
品質も上がった。
単発の PPL は 19.68 → 23.79 と悪化。同等品質はマルチクエリ統合（約9本）で埋める前提。
475倍は RecGen の成果。
主表は RecGen 抜き（HierGen）・α=0.0 で測られている。475倍は階層化だけの数字で、RecGen はその上に乗る別倍率（600Mで TPM 4.5倍、vanilla比 最大1,856倍）。
475倍は PHOTON 固有の手柄。
同じ表で Block Transformer が既に211倍。PHOTON の対 Block 優位は 2.25倍で、PPL は Block が上。主張は「フロンティアで優位」であって単軸の圧勝ではない。
もう使える。
研究発表段階。最大 1.2B、単一コーパス。提供形態・時期・価格すべて未公表。
長文が読めるようになる技術。
読める長さではなく長文を読むコストの話。文脈窓の拡張手法ではなく、decode の memory-bound を外す手法。
ここは論文の主張ではなく、この会の文脈での読み。事実と推論を分けて書く。
知財実務で LLM に流す仕事は、長い・大量・そして一発勝負ではないという三拍子が揃っていることが多い。 明細書1本が数万トークン、先行文献は数百件、そしてクレームドラフトも拒絶理由応答も 「1案を信じる」より「N案出して選ぶ」ほうが実務に合う。PHOTON が最適化した軸—— 長文文脈での decode コストと、同時多数クエリのスループット——は、この形とよく重なる。
特に best-of-N が安くなるのは効く。単発品質で少し負けても9本束ねて並ぶなら、 「LLM に9通り書かせて人が選ぶ」という運用が、いま1通り書かせるのと同程度のコストで回る可能性がある。 クレームドラフトの対戦形式や、FTO の観点出しのように多様性そのものが価値になる工程とは相性がいい。
・現時点で 1.2B。実務で使う 30B〜100B 級で同じ挙動が出る保証はまだない。
・単発品質が落ちる設計なので、1本の答えを厳密に詰める用途（条文解釈、数値の突合）には向き方が違う。
・品質評価が HierGen 側で測られている以上、「475倍で同等品質」と一息に言うのは論文より強い主張になる。
・アーキテクチャ研究であって製品ではない。稟議に載せる段階の話ではない。