富士通PHOTONの「最大475倍」は単発高速化ではなくKVキャッシュ削減のマルチクエリー性能
目次
ITmediaに出ていた富士通PHOTONの記事は、「Transformerの最大475倍」という見出しがかなり強い。
ただ、これは単発チャットの応答が475倍速くなるという意味ではない。
論文側で見ているのはTPM、つまりK tokens/s/GiBで、同じGPUメモリあたり何トークン出せるかというマルチクエリー寄りの指標だ。
富士通の発表でも、注釈でマルチクエリー性能を「GPUリソース当たりのスループット」と書いている。
同じGPUに複数リクエストを詰め込むサーバー運用、長い文脈、複数候補を出して統合する推論で大きく見える数字になる。
前に国産LLMの作り方をPLaMo、LLM-jp、Sakana Fuguで見たときは、重みを作る、公開する、外部モデルを束ねる、という作り方の違いを見た。
PHOTONはそのどれとも違って、Transformerの推論時メモリI/Oを減らすためにアーキテクチャを変える話だ。
トークン列をそのまま長く持たない
通常のTransformerは、次の1トークンを出すたびに、過去トークンのKVキャッシュを参照する。
文脈が長くなるほど、計算そのものよりKVキャッシュの読み書きが支配的になる。
GPUの演算器が余っていても、メモリ帯域で詰まる。
PHOTONはここを、階層的な潜在ストリームで置き換える。
底から上へは、トークン列をチャンクごとに圧縮して、より粗い文脈表現を作る。
上から下へは、その粗い表現を使って局所的なトークン表現を復元する。
flowchart TD
A[入力トークン列] --> B[チャンク化]
B --> C[粗い文脈状態]
C --> D[さらに粗い文脈状態]
D --> E[トップダウン復元]
E --> F[局所チャンク内で生成]細かいトークン列全体を毎回グローバルに読み直さない。
グローバルな状態は粗い単位で進み、細かい生成はチャンク内の短い注意範囲に収まる。
論文の言い方では、水平に伸びるトークン列を毎回走査するのではなく、複数解像度の文脈へ縦にアクセスする。
さらに論文は、生成を進めるとき最も粗い潜在ストリームだけを更新し、底からの再エンコードを省く「recursive generation（再帰的生成）」を入れている。
新しいチャンクを足すたびに全階層を作り直さず、上位の粗い状態を1段進めて、その下の細かい復元だけ回す。
decode時にKVキャッシュを往復させる量が減るのはここで、メモリあたりスループットが伸びる理由になっている。
この構造は、Gemma 4のMTP drafterみたいな投機的デコードとは別物だ。
Gemma 4のMTP drafterは、本体モデルが出す次トークンを補助モデルで先読みして、本体が並列検証する。
PHOTONは、そもそも本体の文脈保持の形を変える。
KVキャッシュの重さには、別角度から当てる手もある。
DeepSeek V4-Proは、アテンション構造はそのままKVヘッドを1個に絞る実質マルチクエリーで、キャッシュ自体をV3.2比で1割まで削っていた。
あちらはヘッド数を減らす方向、PHOTONは文脈の持ち方を階層に変える方向で、狙う先はどちらもdecodeのメモリI/Oだ。
475倍は1.2Bモデルのdecode-heavy条件で出ている
論文の表では、Vanilla Transformer、Block Transformer、PHOTONを600Mと1.2Bで比べている。
評価環境はNVIDIA DGX H200。学習はPile-uncopyrighted 134B tokensで、コンテキスト窓は2048。
効率評価は、長い入力で短く出すprefill-heavyと、短い入力から長く出すdecode-heavyの2条件だ。
1.2Bモデルのdecode-heavy条件では、Vanilla Transformerが2.56 K tokens/s/GiB、PHOTONが1216.67 K tokens/s/GiB。
ここを割ると約475倍になる。
同じ行で見ると、スループットは1.00 K tokens/sから43.80 K tokens/s、メモリは0.390 GiBから0.036 GiBに下がっている。
同じ1.2Bのprefill-heavy条件でも、1.21から543.86 K tokens/s/GiBなので約449倍。
600Mではprefill-heavyで約390倍、decode-heavyで約417倍になる。
「最大475倍」は一番良い条件だけを切り出した数字ではあるが、ほかの条件でも桁は同じだ。
比較対象は2つある。素のVanilla Transformerと、すでにブロック単位で文脈を畳んでいるBlock Transformerだ。
475倍はVanillaに対する数字で、効率化済みのBlock Transformer（1.2B decode-heavyで540.20 K tokens/s/GiB）と並べると、PHOTONの1216.67は約2.25倍にとどまる。
桁が変わるのはあくまでVanilla比で、メモリ効率を意識した既存手法に対しては「倍」のオーダーだ。
論文アブストラクト自身は「up to 10³×」、つまり最大1000倍と書いている。
ただし表で確認できる最大は1.2B decode-heavyの約475倍で、1000倍に届く行はない。
プレスリリースの475倍はアブストラクトより控えめで、表の実測に沿った数字のほうだ。
ただし品質は同じではない。
1.2BではWikitextのperplexityが19.68から23.79に悪化し、ゼロショット平均もTransformerより下がる。
PHOTONの売りは、同じ出力品質で475倍速いことではなく、品質を少し落としてメモリあたりの生成量を大きく増やし、その余った計算枠を複数候補生成に回せることにある。
品質低下を複数候補で戻す
富士通の発表は、PHOTONアーキテクチャとマルチクエリー統合技術をセットで説明している。
同じ問題に対して、少し違う問いや候補を複数作り、最後に多数決や候補選択でまとめる。
単発の1回答でTransformerに品質差があるなら、安く複数回答を出して差を埋める、という使い方になる。
富士通は、9つのクエリーを統合すると従来Transformerと同水準の性能に届いたと書いている。
PHOTON単体の品質低下を無視して「475倍」と読むと、数字の使い道を間違える。
9本走らせてもなおGPUメモリあたりの余裕がある、という読み方になる。
Sakana Fuguのように外部モデルを束ねる方式とは、束ねる粒度が違う。
Fuguは複数の既存モデルを呼び出して、司令塔が結果を組み直す。
PHOTONの話は、同じモデルアーキテクチャ内で複数候補を安く出し、統合で品質を戻す方向だ。
どちらも「1回だけ答えさせない」発想だが、コストが発生する場所はかなり違う。
評価モデルは1.2Bまで
今回の論文で評価したモデルは600Mと1.2Bまで。
商用LLMで問題になる7B、30B、70B、MoEの数百B級で、同じ比率が出るかはまだ分からない。
コンテキスト長も2048なので、富士通が狙う「長文・多数ユーザー」の本番条件より短い。
論文自身も、最大文脈が2048に制限されていること、最大モデルが1.2Bであること、階層数やチャンクサイズなどのアブレーションが不足していることを限界として挙げている。
ここはプレスリリースの数字だけでは拾いにくい。
もう一つ、既存Transformerの重みをそのままPHOTONへ変換できる話でもない。
PHOTONは階層エンコーダ、階層デコーダ、再構成損失、次文脈損失を含む別アーキテクチャとして学習する。
既存のLlama系モデルにプラグインを挿して475倍、というタイプの高速化ではない。
この点でも、Gemma 4 MTPやvLLMの推論最適化とは導入コストが違う。
MTPは既存モデルに補助モデルを足す話で、vLLMの推奨値を調整すれば試せる。
PHOTONはモデルを作る側の話で、推論サーバー運用者が明日オプションを1つ足して使えるものではない。