PHOTONは、富士通が開発した言語モデル向けの新しいアーキテクチャです。正式名称はParallel Hierarchical Operation for TOp-down Networksで、文章をトークン単位で横方向に処理し続ける従来のTransformerとは異なり、意味のまとまりを階層化し、上位から下位へ並列に復元する考え方を採用しています。
富士通は2026年6月24日、PHOTONが特定の数値実験において、Transformerと比べGPU当たり最大475倍のマルチクエリー計算能力を示したと発表しました。研究論文は、長いコンテキストと複数クエリーの処理で、メモリ効率と生成スループットを改善する狙いを説明しています。
この「最大475倍」は、すべてのLLM、すべての業務、同じ品質条件で常に得られる速度ではありません。1.2Bパラメータの研究モデル、複数クエリー、許容した性能差など、測定条件を含む研究結果です。技術の可能性と、現在の製品導入判断を分けて読む必要があります。
Transformerで推論コストが増える理由
現在の多くのLLMはTransformerを基盤にしています。文章をトークンへ分割し、新しいトークンを一つ生成するたびに、過去の情報を参照します。長い入力や長い出力では、参照する状態が増え、計算だけでなくGPUメモリへの読み書きがボトルネックになります。
推論時には、過去のキーとバリューを保存するKVキャッシュが使われます。再計算を減らせる一方、会話が長くなり、同時利用者が増えると、KVキャッシュがGPUメモリを占有します。モデルの演算性能が高くても、メモリからデータを運ぶ速度が追いつかなければ、GPUを十分に活用できません。
この問題は、長文要約、RAG、コーディングエージェント、複数エージェント、推論を何度も試す処理で大きくなります。一つの問い合わせに一つの短い回答を返すだけでなく、複数候補を生成して比較する運用では、出力トークン数とメモリ使用量が費用へ直結します。
PHOTONの階層型アーキテクチャ
PHOTONの論文は、Transformerを「水平方向にトークンを一つずつ走査する」方式と捉え、PHOTONでは「垂直方向に複数解像度の文脈を走査する」と説明しています。下から上へ向かうエンコーダーがトークン列を低頻度の文脈状態へ圧縮し、上から下へ向かう軽量なデコーダーが細かなトークン表現を並列に復元します。
たとえば文章を、文字やトークン、短い意味単位、より大きな文脈という階層で扱うイメージです。すべての細かな状態を同じ頻度で更新するのではなく、粗いレベルで全体を捉え、必要な細部を並列に作ります。論文では、最も粗い潜在ストリームだけを更新し、下からの再エンコードを省く再帰的生成も提案しています。
狙いは、生成時に読み書きするKVキャッシュを減らし、限られたGPUメモリでより多くの出力を同時に生成することです。モデルの「賢さ」だけを高めるのではなく、推論のデータ移動と並列性を設計し直す研究です。
最大475倍という数値の意味
富士通の発表では、600M、900M、1.2BパラメータのPHOTONモデルをTransformerと比較し、メモリ使用量を抑えながら高い生成スループットを確認したとしています。1.2Bモデルでは、わずかな性能劣化と引き換えに、約475倍のマルチクエリー計算能力を実現したと説明されています。
ここでいうマルチクエリー性能は、GPUリソース当たりのスループットです。一つの回答が475倍速く表示されるという単純な意味ではありません。同じGPUメモリの範囲で、多数の生成候補や問い合わせを並列に処理できる能力に関係します。
研究論文の要旨では、実験条件においてメモリ単位で最大1000倍のスループットという結果も報告されています。評価指標と比較条件が富士通の広報発表とは異なるため、数字だけを並べて一般化してはいけません。モデルサイズ、入力長、出力長、バッチ、品質、ハードウェア、実装を合わせた再現評価が必要です。
マルチクエリー統合との組み合わせ
富士通は、PHOTONで多数の候補を低コストに生成し、それらを統合して回答品質を高める「マルチクエリー統合技術」も説明しています。同じ問題へ少し異なる質問や候補を作り、多数決、選別、統合で最終回答を決めます。
LLMは一回の生成で誤ることがあります。複数の推論経路を試して一致を確認する、役割の異なるエージェントへ検討させる、候補コードをテストして選ぶ方法は品質向上に使われます。しかし、通常は生成回数に比例して費用と時間が増えます。PHOTONの並列性が実用規模でも成立すれば、候補を増やす戦略の費用構造が変わる可能性があります。
一方、同じモデルから似た誤答を大量生成しても、真実には近づきません。統合方法、独立性、外部検証、ツール実行が必要です。安価に多く生成できることと、正しい回答が得られることは別です。
企業利用で期待される領域
問い合わせが同時に多いチャットサービスでは、GPU当たりの処理量が高まれば、待ち時間と推論費用を下げられる可能性があります。長文を扱うRAGでは、文書と会話履歴が増えることで生じるメモリ負荷の改善が期待されます。
AIエージェントでは、一つの依頼を計画、検索、検証、修正へ分解し、多数のモデル呼び出しを行います。複数エージェントや候補統合はさらに出力を増やします。PHOTONの特性は、このようなマルチクエリー処理と相性がよいと考えられます。
オンプレミスや限られたGPUでLLMを運用する企業では、同じメモリで扱える同時処理数が増えることに価値があります。消費電力とGPU調達の削減にもつながる可能性があります。ただし、企業がPHOTONを選択できる製品、学習済みモデル、推論ランタイムとして提供されるかは、今後の情報を確認する必要があります。
現時点の限界と確認事項
第一に、研究で評価されたモデルは、現在の最先端LLMと比べ小さい規模です。大規模化したときに、学習安定性、品質、多言語、ツール利用、長文、量子化がどうなるかは追加検証が必要です。
第二に、Transformerの周辺には、学習基盤、推論エンジン、量子化、監視、開発ツールの大きなエコシステムがあります。新アーキテクチャが優れていても、既存資産との互換性、開発者が使える実装、モデル配布、ハードウェア最適化が整うまで時間がかかります。
第三に、性能比較では品質を揃える必要があります。富士通の発表は、1.2Bモデルでわずかな性能劣化と引き換えに高い並列処理能力を得たと明記しています。業務では、何を「わずか」と許容できるかが用途で異なります。法務、医療、安全判断では、速度より精度と検証可能性が優先されます。
第四に、推論費用はアーキテクチャだけで決まりません。モデルサイズ、入力と出力、GPU価格、稼働率、電力、ネットワーク、運用要員、再試行、監視を含む総費用で比較します。
導入候補になったときの評価方法
実用版が提供された場合は、自社の代表データでTransformer系モデルと比較します。品質、初回応答時間、トークン生成速度、同時処理数、GPUメモリ、消費電力、失敗率を測ります。短文だけでなく、長文、複数ユーザー、エージェント、RAGなど、導入予定の負荷を再現します。
モデル単体のベンチマークに加え、API、認証、監視、ログ、障害復旧、バージョン更新を評価します。既存プロンプト、ファインチューニング、RAG、ガードレールを移行できるかも重要です。特定アーキテクチャへ依存しすぎないよう、モデル呼び出し層と業務ロジックを分離しておくと比較しやすくなります。
まとめ
PHOTONは、文章を階層的に圧縮・復元し、生成時のKVキャッシュとメモリ負荷を減らすことを狙う、富士通の新しい自己回帰言語モデルアーキテクチャです。長文や多数の候補を扱うマルチクエリー処理で、GPU効率を大幅に改善する研究結果が示されています。
最大475倍という数値は、特定条件でのGPU当たりマルチクエリー性能であり、あらゆるLLMが475倍高速になるという意味ではありません。今後は、大規模モデルでの品質、実装、製品化、互換性、第三者検証が重要です。企業は技術動向を追いつつ、実用版が出た段階で自社負荷と品質基準を使って評価するのが適切です。